Agile antipattern: Changing the definition of done

Ever see a burndown chart like the one to the left?  I’ve been on a big burndown chart kick lately and when I saw this one I just couldn’t resist using it.  This one is a bit different from my previous blog entries here and here.  This burndown chart is a release burndown rather than an iteration burndown.  It sure looks like the team was incredibly successful and finished early, right?  Wrong!  What this burndown actually shows is all of the stories being “done” and the release not actually occurring for several more iterations.  How is that possible?

Unfortunately this is a symptom all too common for agile teams, so learn from this blog entry and don’t repeat the mistakes of others!  What this shows is a lack of commitment to a definition of done.  I touched on this briefly when I wrote about using a rules of engagement document.  If you don’t settle on a definition of done the pattern in this burndown chart can easily occur.  This pattern can also occur when a team is trying to hard to meet their deadlines.

If you went back and examined what occurred in this example you would find a team pressured to try to hit a release date by working at an unrealistic pace rather than a sustainable pace.  In order for the team to keep looking like they were on track for an ontime release they built technical debt by not sticking to a strong definition of done.  The result is a tremendous amount of testing which was delayed and triggered massive test-fix cycles.  In fact, the original release date was projected for after iteration 6, but instead it took 4 more iterations to actually release the product.  Technical debt cannot simply be allowed to build.  Software projects don’t have the luxury of deficit spending like the US Government.  At some point the bill will come due and it will almost always come due prior to release.  In fact, if it comes due after release it is even worse – you now are in emergency mode because customers are suffering!

Rally Software recently posted their definition of done on their blog.  It makes for some interesting reading and gives good perspective for other agile SaaS companies.

Richard Lawrence has a recent blog entry on this topic as well.  Richard encourages teams to not build technical debt and in fact he encourages growing your definition of done in order to release high value, high quality software as quickly as possible.  It is fascinating reading based on his work at a large organization.

Until next time I’ll be Making Agile a Reality^® by helping teams agree and abide by their definition of done.