Why Agile is Like Football: Don’t Stop

September 07, 2011 07:33 AM | COMMENTS (0) | |

And Tony Romo gets the snap, drops back in the pocket, he searches for an open man, the blitz is on, he scrambles out of the pocket, almost goes down…. He breaks a tackle, he slips but he’s still on his feet, the defenders are in hot pursuit, he looks down field, his eyes light up, he finds a man, he cocks back to  throw and…he…he….he decided to stop and walk off the field?! Can you imagine this? In your wildest dreams can you see the super bowl just stopping because a player just, well, he just wants to after the first 5 minutes of play?  The mere thought of this simply absurd and quick frankly unthinkable.  If this were to happen imagine the outrage from the fans, the concessionaires, the owners and even the advertisers, it just simply would not happen.

Your sprint should be the same way.  I will say this as plainly as I can, DO NOT BREAK A SPRINT.  For the sake of those that may be brand new to Agile, I will explain.  A sprint is a timed cycle in which a team of trained individuals, usually referred to as a delivery team, commits to getting a certain amount of work done.  That cycle or sprint, sometimes referred to as an iteration, is typically 2 weeks, although some teams have been known to do longer, even 30 day sprints.  There are several ways to break a sprint.

The first way to break a sprint is to simply stop in the middle of a sprint. For whatever reason to just stop in the middle of a two week sprint is detrimental to velocity (the speed at which a team works comfortably) as well as overall morale.  Take the opening football example, if this were to happen, what would that do to the spirit of the offensive line, who takes hits ever down incurring collisions similar to a car wreck some 50 times a game, to have their quarterback quit on them and stop the game in the middle? Not good!  There are many excuses to stop a sprint:  Requirements change, priority change, business re-focus, RIF (reduction in force) issues etc. However most of them are just that, excuses.  I have seen sprints survive all of these, you can abandon a user story or a task without abandoning the entire sprint. It may be true that the business has refocused and wants something different than what you are currently working on and that’s ok. First off, that decision usually doesn’t come that quick so there is time to finish a sprint and discuss the change at the iteration planning meeting.  Secondly rarely is the change so dramatic that it eliminates an entire backlog. Simply put, there is always work to be done.

The second way to break a sprint is to take breaks between sprints.  Some teams may say that it is necessary to take a break between sprints in order to tackle things such as defects.  Once again, this is breaking the momentum of a team and it is similar to saying I have to put my marriage on hold while I father a child or while I have this project at work, after which I will go back to being married.  Defects should be handled right alongside other stories. This will do two things: Encourage good coding standards to avoid defects in the first place and give a true velocity of a team overtime in real world conditions.  On a football team no one keeps stats on how many catches someone made in practice, it only counts when the clock is ticking.

Some may argue that in football they have timeouts, half times and two minute warning breaks.  In Agile we have the same thing, they are called weekends!  (smile) 

My mamma always says Agile is as Agile does….