Commentary on The Art of Agile Development's Iteration Demo practice.

One of the most common problems I'm seeing with agile teams these days is trouble making and meeting iteration commitments. In other words, these teams often have half-done stories at the end of each iteration. As a result, their iteration demo is often disappointing.

The causes of this failure can be complex and varied... actually, wait. That's baloney. I'm trying to be honest here, not sell you "everybody's right" pablum. It happens when you take the easy way out. That road looks easy and simple, but it's strewn with traps. (Call it Ackbar Way.)

Trap #1: The Ever-Increasing QA Burden

Many agile teams I know have adopted short iterations, daily stand-up meetings, and the planning game, but they haven't taken a serious approach to agile engineering. Their iterations look like mini-waterfalls. Programmers design and code, then hand the results off to QA for testing. (These teams struggle with requirements analysis, too, but that's a topic for another day.)

QA ends up with an ever-increasing test burden. Even if QA creates automated tests, those tests tend to be integration-style tests, which are slow and fragile (see video at right). They're a maintenance burden. More often, though, the testing is done manually, which is an even bigger burden.

Worse, this burden scales proportionally with the size of the software, and is repeated with every iteration. Before long, testers are running out of time to test the developers' work, bugs are spilling over into the next iteration, and the team's ability to plan reliability goes to hell in a rather uncomfortable handbasket.

End result: buggy iteration demos. Fix: prevent bugs using agile engineering techniques and involving customers rather than trying to test the bugs out.

Trap #2: Wishful Thinking

The other big cause of disappointing iteration demos is quite simple: teams sign up for more than they can do. They often blame this on poor estimation, but that's not really the problem. The real problem is that, for whatever reason--eagerness to please on the part of developers, or pressure on the part of customers and managers--the team ignores or inflates their velocity when planning the iteration.

Velocity is quite simple, of course. You take all of the stories from the previous iteration, set aside those that weren't "done done", and add up their estimates. That's your velocity, and you aren't allowed to include any stories that were partially done, untested, or otherwise unacceptable to your on-site customers. Those stories have to be ready to ship. (There's some nuances, but teams having trouble meeting commitments need to go with the straight-and-narrow approach.)

The "done done" requirement is quite strict and can lead to disappointing velocity numbers. So people fudge. Rather than calculating velocity from completed work, they estimate it with "capacity" by counting developer-hours and multiplying by an arbitrary percentage. Or they take partially-done stories and award themselves part of the story's estimate. This adds enough subjectivity to the mix that the team can now set their velocity to the number they wanted, while maintaining the illusion that it's based on real facts and calculations.

Part of the problem here is a macho desire to improve velocity, based on the misguided belief that higher velocity leads to higher productivity. (It's the other way around. Sorry.) Whatever the reason, making up a pleasant velocity figure does not change your ability to actually deliver software.

End result? When the iteration demo rolls around, the team hasn't finished everything. In fact, they don't even finish as much they were capable of finishing, because rather than getting half of the work all the way done, they get most of the work partway done. Very little is done done. This, of course, leads to a crappy velocity and increases the desire to make up a happier number.

The fix? It's the easiest thing in the world, and the hardest. Just stop making up your velocity. Calculate it based on what's "done done," and be cautious about increasing it. This may not yield a number you like. Actually, it probably won't yield a number you'll like. But you will be more productive and you will be able to make commitments. You'll probably spend less time fighting fires, too, and you'll finally be able to start tackling your underlying productivity problems rather than playing games with numbers and staring uncomfortably at your feet during your iteration demos.