As I mentioned recently, my group has been experimenting with some XP-inspired agile planning. Now that that’s stabilized, the question is: where next? It’s still my plan for the group to end up at full XP, if possible. (Asuming our experiments with it continue to turn out well, of course.) It’s also still my plan to do this in steps, despite the recommendations of others to do things whole-hog. I say this for three reasons (the latter two of which are largely informed by those Weinberg books I was reading):
- I think I would get significant push-back if I wanted to make the transition whole-hog: less significant than I would have a few months ago, but enough to be a potential problem.
- Making changes is hard, and risks falling into chaos. Given that making changes is necessary, however, you want to develop a skill at making changes. So get good at making small changes with clear goals, at observing how well those goals were actually met, at figuring out whether or not people go along with the changes, at addressing the reasons why people don’t go along with those changes. And make sure that you know when changes are causing initial chaos, when they’re starting to stabilize, when they’re fully integrated into the culture.
- I don’t support XP because it’s a nifty acronym: I support it because I think it will have certain concrete benefits. Similarly, I think the individual practices will have certain concrete benefits (though many additional benefits come from interactions from practices). Even if you do XP all at once, you need to develop a good sense for whether you’re getting the desired benefits and, if not, why not. (For example, you may not be doing XP right, it may not be the best fit for your situation, or it may all be a bunch of malarkey that only gullible fools like me could possibly believe in.)
To me, developing the sense of whether or not you’re getting the expected benefits is at least as important as the actual benefits of XP’s practices. But once you’re working on developing that sense, it becomes quite reasonable to adopt XP incrementally: you should still see enough benefits at each stage to keep you going, and if not, stopping and figuring out what’s going on is at least as sensible a response as trusting in the powers of the combined XP practices.
With this in mind, given that my group’s use of planning cards has stabilized nicely, the question is: what aspect of XP should we integrate into our work? There are, I think, three things left to do:
- Pair programming.
- A Customer.
- Everything else. (Reexamining our unit testing and constant refactoring to make sure we’re doing it as well as can be; making our coding standards stricter; seeing if we can come up with a metaphor, though I’m not optimistic.)
My preference would be to carry out those steps in the order listed, in two- to three-month increments. I’m not sure who would serve as the Customer role, so I’d rather put off the work of getting that set up. But I think that pair programming would help reinforce a lot of the progress that we’ve made recently: increase our refactoring, increase our testing, decrease pigeonholing.
The only worry I have with pair programming was that we flirted with it last December, with unimpressive results. I think that I have an idea of some things that we did wrong: we were spending too much time working on areas that only one person knew about, we were spending too much time on hygiene tasks, we weren’t being strict enough about it (in particular, I didn’t step in when I saw two people programming alone), and we just weren’t as used to working together or working on different things as we now are. So I think we can get it right if we try again now.
Talking it over with my group and my manager, they agree that it’s a reasonable next step, so we’ll begin on Friday. (It’s hard for me to figure out the power dynamics within my group: I don’t think I’m running roughshod over my underlings, but I can never tell.) I found a pleasant book on the subject (Pair Programming Illuminated, by Williams and Kessler), which I hope will help guide me past some of the pitfalls. We’ll see how it goes; I’ll report back in a month or two.
There are no revisions for this post.