XP: Constant shippability #.NET #Delphi #extreme programming
One of the tenets of XP is that, at the end of each iteration (every 1-2 weeks), the software should be shippable.
Whether it actually gets shipped isn't particularly relevant. Management could decide to ship it, if that was the right business decision for them to make. But that's not the real reason we keep the software shippable.
The real reason is this: You don't know how long something new will take, until you're done. Something will always come up.
If you have ten major new feature areas to work on for the next version of your software, it may be tempting (it was to our team) to work on all the hardest things first, the high-risk changes. We were doing that for a while, a few months back. Doing the hard things first would give us extra time to test those changes, we reasoned. So for a while, we thought, we'll work on all ten major features at once.
This, we have since come to realize (after being told several times by our XP coaches), is not necessarily the right thing to do. It's better to get things finished, because as you work on major feature A, you'll realize that you have to do more work than you originally thought, or that you don't understand something you thought you did. Obstacles come up, inevitably. But you don't know how much those obstacles are slowing you down. And if you have ten projects going at once, you have at least ten times the uncertainty.
Alistair Cockburn draws a parallel to packing the contents of a house. It's a bad idea to pack all the rooms at once, because you have no clue how much progress you're going to make. It's much better to pack one room at a time, and get it finished before you move on to the next one. That gives you a much better idea of how fast you're going, and how soon you'll finish, and whether you're going to be in deep trouble the day the moving truck arrives.
More importantly, when you finish packing a room, you want it to be completely packed. From Cockburn's article:
It is practically impossible to tell whether one is 60% or 70% done (speaking to both software and room-packing). For most of the project, one sees neither the true size of the task at hand, nor the (slower than expected) rate of progress. Missing both of those, it is impossible to tell when one will get done. In both cases, an ugly surprise awaits at the end, when a myriad little unexpected items suddenly become visible (think about when you loaded all the boxes into a moving truck and walked back into the house, only to discover all sorts of things that suddenly "appeared" when everything else was taken out).
There should be nothing remaining in that room when it's packed — as Cockburn puts it, "not even a sock". Because if there is a sock left, then there might be something else, too. Having helped a friend move recently, and later having to go back to her apartment to pick up some items she hadn't brought along, I can attest to this. If there's background clutter, it's that much harder to tell where the foreground is. You work on a feature until you're satisfied that a customer could use it tomorrow. Then, and only then, it's done, and you can move on.
Even if you have to have all ten features done before you ship, you still need to focus on a few at a time, and get each one done. Until it's done, you have no idea what kind of progress you're making, and you have no way of predicting whether you'll meet your ship date. Even if the news is "we're in trouble", you'll know that sooner, not later, and can tell management so they can act on that information. Nobody wants to hear "we can't possibly ship for another two months" the day after the drop-dead date. Nobody wants to hear that anytime, but if you tell management you'll slip by two months, and you tell them three months ahead of time, they can do something about it: cut features, change the date, hire more people, whatever it is that needs to be done.
We finally figured out the sock thing a few months ago. We rearranged our tasks, and have been knocking out one major feature after another. And with the possible exception of bugs (we still haven't achieved the XP goal of always fixing bugs as soon as they're found, but we're getting darned close), we're all pretty confident in our progress. The days of "well, we'll probably ship one of these months" are gone, and I, for one, am thrilled.