Agile antipattern: Extending an iteration

I had a previous blog post about stopping an iteration and how it was a really bad idea. Another blog post was about moving work from one iteration to the next and again it mentioned how this is a bad idea. This post looks at the problem which is similar to both of those: extending an iteration. I’m sure there are some agile trainers and coaches that will take me to the woodshed for saying this, but I’ll say it anyway…

EXTENDING AN ITERATION IS NEVER GOOD!

I don’t know how to make my feelings on this topic any more clear. Well, ok, I can think of one way. What I really meant to say is…

I’m going to go a little further and call this an agile antipattern.  Why?  Because if you extend an iteration you are likely to cause all kinds of issues like:

1. The iteration cadence is disrupted, so people who were respecting the team by scheduling appointments and vacations not to be on planning days are now out of luck on that front.
2. As I have said in a previous blog post – don’t accept mediocrity!  Extending an iteration is usually done just so the team can feel they finished.  That is the wrong behavior – the team needs to know they did NOT succeed in this case!
3. Velocity is based on the amount of work completed in an iteration.  If an iteration is extended how do you account for the velocity?  Does “yesterday’s weather” still have meaning?
4. How often is acceptable for this behavior?  I tend to be very black and white (blunt and reality-based is the way I describe myself to class attendees), so to me it is never acceptable. Using this guideline eliminates the entire conversation.
5. One of the nice things about agile is failure happens quickly.  If the team extends an iteration to avoid failure is it living up to the spirit of agility?
6. Teams should try to deliver the highest value, with high quality, as quickly as possible.  If an iteration is extended it is no longer clear whether the team is taking this into account.  Were all stories completed except the lowest priority stories (good behavior), or were random stories uncompleted (bad behavior).  We might never know if the iteration is extended and everything magically gets completed.

I like to think I’m not dogmatic about agile, but in some instances like this I appear to be dogmatic.  I prefer to call myself a pragmatist, but others may disagree.  I’m sure there are some reasons when extending an iteration may make sense to some people, but I have yet to see a situation where the benefits outweighed the negatives.  Teams usually don’t understand all the negatives when making the decision and instead are left to pick up the pieces after the downstream effects become exposed.

Until next time I’ll be Making Agile a Reality™ for my clients by helping them complete iterations successfully so they never have to consider extending one!