One of the great things about Extreme Programming is that the customers get to decide exactly how to spend their money. We as developers work with our customers to create a set of stories, prioritize them according to the business need, and then go to work, getting constant feedback and course corrections as we go.
One problem I’ve seen lately is that our customers have correlated units to time, and so they do things like put a pair on a project for a day, and then perhaps not authorize a pair for the project again for another few days.
The problem, of course, is that each time a pair comes back to a project that is on hold, they have to ramp back up to the tasks, figure out where they were, and generally try to get back into the flow. This constant flux for projects can lead to longer time to release, but it also can lead to more mistakes being introduced.
Today, I was flipping through CNN.com and stumbled on a real life example of this very thing. Here’s the quote:
One explanation for the accidents may be that workers have been out of the rhythm of preparing for [releases], since there has been only a single [release] since…early 2003, Parsons said.
“I think anytime you have big gaps in between doing something…you are always concerned that you’ve lost a little bit of your edge,” Parsons said.
Who’s Parsons? He’s Bill Parsons, Deputy Director of the Kennedy Space Center, talking about the string of accidents that has plagued them over the past few months. The [release] brackets replaced “shuttle launches” from the quote. Luckily we aren’t doing anything quite as high profile as that, though millions of users would see the effects of our mistakes.
So how do you manage your customers to prevent this from happening? In the case of KSC, they can’t release anything else, so they are stuck with the gap. But in software projects, one has to be very careful not to count towards velocity any project that wasn’t delivered during the iteration with running, tested features that delivered value to the customer. This also includes bugs, meetings, research, and other activities that aren’t providing real value for your customer.
Of course, sometimes you as developers have to just tell your customer that you just need to work on a project in whole pieces, and the business value why. In our case, it was causing a higher bug rate and slower adoption for several projects, and by serializing them they were able to get them all finished and released. Our customer listened, and understood, where he didn’t before.
I don’t know how to help NASA and the KSC, but hopefully you have an environment where you can help you and your customer from making mistakes just because of parallel development.