As I said in a previous post, I had the pleasure of attending a presentation by Ron Jeffries at the St. Louis XP User's group meeting back in January. Another portion of his talk that really hit me was on the subject of "done equals done."
"Done equals done" is another way to reference the XP practice that an iteration should result in releasable bits. Of all the items Ron talked about, this is the one topic that I have always felt challenged by.
Here at Appistry we tackle very difficult problems. We often experiment. We often make interface changes at the end of an iteration to provide the best solution to the user. Typically this has resulted in documentation and QA lagging an iteration or so behind main development efforts. Our end of iteration build will pass build, unit, and integration tests but will usually not be run through our full QA suite. Ron says we have been doing this wrong.
Consider the impact of mandating "done equals done" within your development team:
- QA and documentation will never come to development in the course of an iteration to ask how something from last iteration worked. This keeps the focus of the whole team on the current stories.
- Development/QA will no longer have to guess that a 4 to 6 week QA cycle at the end of implementation will be enough and cross our fingers that we aren't going to go long.
- Management gets to decide when we are going to publicly release the build because there is always build ready to go. (See my previous post on smaller releases help management.)
Developers will have to change our level of commitment during iteration planning. We aren't just building our stories, we are making sure we are really, truly done. Clearly we won't complete as many stories within a single iteration, but we are just fooling ourselves that we are saving time. We incur a time penalty with the context switch of completing docs and QA tests during subsequent iterations.
If there was one action item I set for myself after the meeting it was to incorporate this practice to our normal methodologies. I strongly suggest that you consider applying "done equals done" to your practices as well.
