Agile anti-pattern: Going to longer iterations

This is another common theme among teams just starting with agile.  It usually goes something like this:

1. The team has an unsuccessful iteration.
2. They determine all the unfinished work is testing.
3. During the retrospective they resolve to give more help to the testers so they can finish in time.
4. The next iteration is also unsuccessful.
5. The team determines once again all unfinished work is testing.
6. During the retrospective they decide the only way to have enough time for testing is to move to a longer iteration length.

Uh oh, Houston we have a problem!

This is not going to lead to success.  Think about it for just a minute.  The reasoning behind doing this is to give testers more time to test.  That sounds great in theory, but what are the developers doing during the extra time?  No, sorry, but they aren’t doing anything like sitting on their hands.  They are creating more software.  So if they are creating more software, when does it get tested?  Well, during the extra time of course!  But, but, the extra time was for testing the stuff they ALREADY created.  That’s right, we give extra time to test the stuff they created during the original iteration length, while then taking that time to create proportionally more software.  The result is pretty ugly – the testers now fall short by an amount of work which is directly proportional to the change in iteration length.  If the original iteration was 2 weeks, and the new iteration is 3 weeks, testers will fail to complete 50% more work in the new iteration length.  Bottom line, we didn’t make the problem better.

This is one of the worst antipatterns because for some reason people actually believe it should work.  Somehow they will wave a magic wand and developers will just slow down enough to let testers catch up with the new iteration length.  Sorry folks, it doesn’t work that way.  So what can you do instead?  You might try making a new rule:

There is no code except tested code

How does this help?  Well, developers can no longer say “I coded that already” for just one example.  It isn’t “coded” until it has passed testing.  This means developers get zero credit for anything which isn’t tested.  Now it is not just testers which fell short during the iteration, it is the team.  If testing is constantly falling behind and coders can’t just blame the testers, what are their options?  Well, for starters they can help the testers out.  Maybe figure out how to automate more tests.  Maybe use unit test-driven development so the software that gets tested is more solid and likely to pass the acceptance tests.  Maybe developers turn into testers in order to complete the iteration.  Believe me, the more times developers have to run tests, the more automation tools and frameworks will start to show up or become easier to use (and this is a good thing!).

This is based on the lean principle to improve the system by doing two things:  measuring UP and optimizing the whole.  I’ll almost certainly have blog posts on both of those topics in the near future, but feel free to purchase Mary and Tom Poppendieck’s books on Lean Software Development (see our books page) if you want to read about them.

Thanks for reading this entry.  If you were considering a longer iteration length I hope this post stopped you from making a big mistake!

Until next time I’ll be Making Agile a Reality™ by having my clients expose the real elephants in the room and getting rid of them.