The Cornerstone of Agile Planning

Commentary on The Art of Agile Development's "Done Done" practice.

In the "Alternatives" section of the "Done Done" practice in The Art of Agile Development, Shane and I wrote:

This practice is the cornerstone of XP planning. If you aren't "done done" at every iteration, your velocity will be unreliable. You won't be able to ship at any time. This will disrupt your release planning and prevent you from meeting your commitments, which will in turn damage stakeholder trust. It will probably lead to increased stress and pressure on the team, hurt team morale, and damage the team's capacity for energized work.

There's a lot of truth in this little paragraph. Many teams I know have exactly these problems: they can only ship after several days (or weeks!) of Herculean effort; they're unable to meet release commitments; stakeholders don't trust them; and of course the team is under constant stress and pressure.

"Done done" is at the root of all of these problems. Once you complete a story, from end to end, you can tell how long a story really takes. Once you can do that, you can start making reliable estimates. (They won't be accurate, but they'll be consistent, and that's good enough.) Once you can make reliable estimates, you can make and meet iteration commitments. Once you can make and meet iteration commitments, you start building stakeholder trust. Once you build stakeholder trust, you can start negotiating scope. Once you can negotiate scope, you can make and meet release commitments. Once you can make and meet release commitments, you build trust even further, and that relieves stress and pressure on the team, which increases productivity and leads to a virtuous cycle of increased trust, collaboration, productivity, and value.

So many good things from such a simple concept. And the funny part is that "done done" is really easy to do! Just stay on task until everything is done. The hard part is the political will--sacrificing the appearance of high speed in order to take care of all of the nit-picky details. (It's also hard if you don't have a cross-functional team that sits together, but that's a whole 'nother conversation.)

I'm often asked where to start with agile development. If you have trouble making and meeting commitments, this is a good place.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.