EMAIL NOTIFICATIONS:  OFF  ON

Why Agile is Like Football: 1st Down

October 18, 2011 11:27 PM | COMMENTS (0) | |

We have all heard the instructions on how to eat an elephant: One bite at a time.  If we were to apply the same concept to football we can say we play the game of football one down at a time. The best players in football are only worried about the current down and may a couple ahead but no more, and the past plays don’t count for much either. When you think about it, it matters very little what happened on the last play, as far as its impact on this one.  The activities in the last play don’t change the fact that the current play needs to happen.  We can say the past may dictate what we need to do in the current. For example if the last play ended in a 3 and 5 situation and now it’s 4th and 5, that may influence what you do on the next play, especially when you calculate the length of space between you and the goal line.

The game of football is not played all at one time, it’s played one down, one play at a time.  A project is the same way, which makes the Agile methodology an excellent candidate in which to implement.  A project, like a game of football, is implemented one step at a time.  One meeting, one line of code,  one QA test at a time. We all realize that the end goal of a project (or at least most projects) is to deliver something (often times software in my line of work) that is relevant and provides value to the customer or business.  If we go back to football terms, the teams ultimately only care about winning a superbowl, but let’s break that down into stages.  Within the context of winning, they must first win the play-offs. In which case, they must clinch a division title.  To accomplish this they must do well in the regular season. But even more basic than that, at times they want to score a touchdown, or perhaps a field goal or extra point. At some point in the game a given football team may only be concerned with the first down.  There may be several attempts at first downs during a “drive”.  If the team did not concentrate on these small increments of success, it would be near impossible to reach the goal of winning the game.  The Agile methodology with is incremental style of working allows us to accomplish the same type of thinking.  Even though we understand the goals of the complete project (hopefully), we gain value in breaking that goal down into smaller manageable pieces that can be delivered in a short period of time.  This gives us the sense of work being done, plus we can apply parkinson’s law: Work expands so as to fill the time available for its completion.  This works both ways, when a task has been given only a limited time to be completed, it usually is completed in less time than if the same task were given a longer time frame.  I am sure you have seen this before, especially in the area of requirements gathering.  If you have a requirements gathering deadline of 4 months, it will take 4 months to gather requirements.  If you have a requirements gathering deadline of 4 days, it will take 4 days.  And, I know this is hard to believe but it can happen, if you have a requirements gathering deadline of 4 hours, you can get it done in 4 hours.  How long do you think it actually takes to say what you want?  Depending on the complexity, it doesn’t have to take forever.

This mentality was played out in my department recently when our city was selected to host a superbowl.  The department was tasked with creating a certain type of software that would be done prior to the superbowl for use during the superbowl. Even though the deadline was tight, this was a project that absolutely could not be late because of the nature of it.  Long story short, the project was completed and successful.  I would be willing to bet if the same team had been given a year to do the same work it somehow would have taken a full year. But I digress, small sprints full of accomplishments are the way to go for several reasons: The mental boost of accomplishing something, Parkinson’s Law, earlier release of working software, and better prioritization of features. Product owners are now able to see progress on a bi weekly basis instead of waiting a year to see what they even forgot they asked for. 

Ready....Set.....Agile