The game of American Football is generally played in 4 quarters. Each one of these quarters lasts 15 minutes. The 15 minutes represents 15 minutes of actual playing time. During each quarter, each team is given a set of time outs to use in order to pause the game and get the players off the field for a few moments of rest, refocus or sometimes just to ice the kicker. When a player with the ball steps out of bounds, misses a pass, scores a touchdown, calls a timeout, gets hurt, spikes the ball, kicks a touch back, or takes a knee in the end zone on a return, it causes the clock to stop thus prolonging the end of the game. The game clock is also paused at the 2 minute warning mark or the quarter ends. I have never understood just why one would be rewarded a time out just because it is close the end of the period, but I digress. Every now and then the scores at the end of regulation play will be congruent, thus causing a situation where the game time extended into “overtime” play, thus prolonging the end of the game a bit further.
It is strange how you never really hear anyone asking the players what time ill the game end. This is because the onlookers have been conditioned to think about the game in a certain way, and time is not the only factor. Technically speaking a game of American Football is 60 minutes of play. However the game will never last only 60 minutes. Even though there is a “general” understanding of how much time a game will take, you will be hard pressed to find an onlooker willing to wager on the timeframe within 2 standard deviations.
If you think of the game as a product or a release, you will see many similarities; however in your case it is pretty much a guarantee that someone will ask you when will this piece of software be complete. I would venture to say that this is the number 1 question that is asked, followed by “are we going to make our date.” If you are new to agile, this may also be a pain point for you as well. If you come from a PMP world, I would like for you to take a trip with me, let’s call it the land of Agility. Ok so I’m not good with names, but just go with me here. Take a deep breath, sit down, relax and take this statement in: Agile sprints are always on time, dates do not slip. Ok, breathe! I know what you are thinking, that’s impossible. Let me take you out of the land of software development back into the land of football. In a football game, would you ever ask will we get to the end of the game? Will we make it on time? The truth is a football game ends when the whistle blows at the end of the 4th quarter provided there is no overtime.
The truth is your sprint will end at the end of two weeks, or three weeks or whatever you have set. If you have a product backlog and have estimated properly you can kind of guess how many sprints it will take to get through the current backlog and therefore project a date. However, there is no guarantee that the current backlog will stay static in number stories and or priority of those stories. Since these two things are not static it becomes difficult to give a time estimate that is accurate, similar to guessing how many minutes a football game will take or even how many plays need to be started in order to complete. The truth is you simply do not know, you can guess, but it’s really a pointless exercise, you have too many moving variables. You do have some constants however, one being the fact that you will have 4 quarters, you just cannot be sure what will happen in them. If you take this approach with your software development, you may see the quality and usability of what you create increase, as well as confidence from the product side of the house over time. What I mean here is that the one constant you have is time. You can effectively say that given our current velocity and backlog we can finish this product by x date. Even though this is not ideal for Agile, in the real world execs want dates. Now, here is the tricky part, you can guarantee a product on that date, what you cannot guarantee are the features that will be available at that point. The variables are addition of stories, reprioritization of stories, delivery team personnel changes etc. Since these are not foreseeable, neither is the deliverable.
All this may be hard to swallow for a project manager, but let me add this nugget. As a project manager, you now get a chance to influence the development process by making sure the highest priority items are added to the software first and you see working software at the end of each sprint, potentially every two weeks! If you have been working in a waterfall environment, you may not see a piece of software for a year! And on top of that, it’s not what you wanted. Now you will be able to see if a development team is off track right away and not waste years of development effort.
The important thing to remember about Agile is the end goal, pardon the pun. Just as in football, the goal is not to just finish, but it’s to put the most points on the board by the time you finish. In software development that equates to working software being the end goal.
Agile on 3, BREAK!