Agile antipattern: Insanity! (5 insanity antipatterns)

It is sometimes said the definition of insanity is doing the same thing over and over again and expecting a different result. This definition has been attributed to Ben Franklin and Albert Einstein, but research shows it is unlikely either originated it (there are many more instances on the web, I just referenced one).  In years past I modified the quote to say good developers test quite well, bad developers run the same code over and over again expecting it to pass at some point in the future!  I think we would all agree we try not to be insane.  Unfortunately, when it comes to agile implementations we can not only become insane, but we sometimes even try to defend the insanity!

Below are 5 common ways agile teams can be considered insane:

1. Never meeting iteration commitments – Too often teams overcommit for an iteration and carry work into the next iteration.  When this occurs on an infrequent basis it is probably no big deal, but too often teams do this quite frequently.  I covered this in a blog entry devoted to moving work to the next iteration.  But this behavior can also turn into the “extend the iteration” antipattern.  When teams don’t fall into one of those antipatterns they end up missing commitments regularly, which is the first of my 5 insanity antipatterns.  We can’t keep doing the same thing and expect a different result.  The team needs to understand they are missing their commitments and take action.  I hate to say this, but an agile team which does this too often starts to have credibility issues with management and may eventually find themselves unemployed!  To fix this pattern take the number of story points completed in an iteration and make that be the commitment for the next iteration.  If this continues to fail (ie, velocity continues to decrease) it may be time to consider using some Kanban principles like limiting work in progress (WIP).  Make a rule that no individual can have more than one task they are working on, and only X number of stories (where X is perhaps 1/2 the number of developers) can be in progress at once.  This will ensure everyone will be working together on completing stories before moving to the next one.
2. Testing late – This is probably the most common insanity antipattern for agile.  Teams continue to believe they can test after coding is completed and get good results.  This doesn’t work on large waterfall projects and it doesn’t work when turning an agile process into a mini-waterfall process instead.  This is often attempted by using the “code freeze during the iteration” antipattern.  Some teams avoid the code freeze but still try to jam in all the testing late in an iteration.  Testing should START by writing tests the first day of an iteration and tests should be run constantly as code evolves from nothing to being completed.  Remember, automation is your friend.  Dont’ fall into the “using manual tests” antipattern (unless the manual testing is for usability or exploratory purposes in which case it is warranted).
3. Poor estimating – Recently my friend (and fellow Agile Cooperative member) Richard Lawrence sent a “tweet” which was a quote from Eli Goldratt: “It’s better to be approximately correct than precisely incorrect.”  In almost every agile course I facilitate I ask the question of whether spending more time creating an estimate will make it be more accurate.  The answer so far has been NO every time I’ve asked.  I believe the students are correct, and Mike Cohn agrees with me in his books.  We tend to try to fix this antipattern by spending more time creating our estimates only to be wrong again and again.  This is going the wrong direction.  Teams need to get better at estimating by doing things differently.  I hope my blog entry “Ten Ways to Improve Your Planning Poker Results” will help.
4. Not trying to improve – I wish I could say this one is rare, but it is extremely prevalent among the “we started doing agile from what we learned in books and at conferences” crowd.  Although retrospectives are mentioned in books, for some reason it is rare to implement them as part of a new agile process.  I think this is probably because people think a retrospective is like a Lessons Learned meeting and are therefore useless.  Nothing could be further from the truth!  Retrospectives are a KEY component of a successful agile process.  A retrospective is the only time improvements can be made.  Start with “What did we do well?”  Then “What did we do less well?” and finally “How will we improve?”  Then move on to #5 below 🙂
5. Not assigning action items – Part of the reason Lessons Learned meetings don’t work is because action items are not assigned in order to make sure they get accomplished.  During each retrospective make an improvement plan consisting of a few items and assign people to make sure the actions are completed!  Without this sort of accountability no action plan will succeed.  Remember, this is a team commitment to improvement, so members of the team should be assigned.  It shouldn’t all fall on the Project Manager or Scrum Master.

In my opion, all of these items become insanity antipatterns when we do them more than once.  If we fail to learn our lesson then we have no one to blame but ourselves for the continued poor results.  If you see any of these antipatterns occurring then TAKE ACTION!  Make sure your team addresses the situation in a way which makes sense.  After all, continuing to do nothing is insane. 🙂

Until next time I’ll be helping teams keep their sanity by Making Agile a Reality™.