The Agile Pigskin

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 

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….

This type of communication is paramount in football.  I have just named a few different communication scenarios, but there are many more.  In project management and specifically Agile, communication is just as important. If you have been part of waterfall team, you are all too familiar with the non-communication method, and delivering what the customer “asked for” but not what they “needed”.  I have been part of teams where the customer has specifically said “well, that report is no longer needed because of the way we do business now”  and our team commenced to moving it into production because, hey, that’s what they asked for and it’s too late now to start changing requirements.  Does that make sense to anybody?  That doesn’t work in any other parts of life.  Imagine not being able to take a different class in college or being able to change your major because it’s not the same one you picked as a freshman.  To put it in football terms, imagine coming to a game with every single play laid out in order and you could not change it, and the fact that the defense is changing, or someone gets hurt doesn’t change your game plan.  You will lose!  And the same thing happens on a project, most times you will lose if you take this mentality, communication is key!

Agile as a methodology has a manifesto.  This manifesto is crucial to understanding the foundation on which Agile was founded.  The agile manifesto is as follows:

 Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

 That is, while there is value in the items on the right, we value the items on the left more. Let’s look specifically at the customer collaboration over contract negotiation piece.   Many teams spend more time covering their backside with sign off sheets and emails and change control meetings than they do actually building the software.   I am not saying that there is no value in any of these things, but its usually done in the spirit of when this goes wrong, I need my butt covered therefore I need you to sign this unchangeable contract for us to begin so that we cannot be held liable if you decide to change your mind.  And we wonder why so many software projects go south.  We began with the end going wrong in mind!  The truth is, the customer doesn’t always know what they want at the beginning of the project, they may have an idea, and that idea may change and evolve over time, like most ideas do, and that’s ok.  Agile as a methodology is setup to deal with the evolving idea. Talk to the customer often and embrace the change that they bring, stop resisting it, plan for it and become the partner for the customer.  Spend time understanding their ever evolving needs and wants and work to respond to those and in some cases anticipate the change.  You can only achieve this through constant collaboration, so do that, do Agile!

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 4^th 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!

This halftime period is similar to the sprint retrospective at the end of a sprint.  The sprint retrospective meeting is usually held after the sprint review meeting and before the sprint planning meeting. The purpose of this meeting is similar to the purpose of the “huddle” in the locker room during half time.  It is a time to inspect the previous sprint.  What went wrong that we need to fix, what went right that we need to do more of etc. The sprint retrospective should only be attended by the delivery team. After all, you don’t have the fans and the team owner in the locker room during half time, at least not usually. The locker room is for those who are directly responsible for putting points on the board. Similarly your sprint retrospective should be restricted to those people who can put story points on the sprint board.

The sprint retrospective is important because it gives the team a chance to talk through things such as velocity and story point completion:  did we bite off more than we can chew?  Were our story point estimates off etc.   Because this can quickly become a complaining cop out fest, it is important that the scrum master keep an eye and an ear in tune to make sure this meeting stays on the right track.  The meeting should be no longer than 3 hours and please do not include product owners.  Members of the team may be apprehensive to discuss their shortcomings if the “wringable neck” is in the room.

As important as the retrospective is, I see numerous agile implementations that have never even heard of it.  If you are not discussing the rights and wrongs of the past, how will you get better?  No matter how many points a team is up at half time, they still head off to the locker room.  I have yet to see a situation where an NFL coach says to the team, “Well I tell you what guys, we are up 21 to 0,  there’s no need to discuss anything, just have a seat on the bench and enjoy the half time show… you guys are perfect anyway”.  That didn’t even feel right for my fingers to type that!  Well not having a sprint retrospective  is just as asinine.  You will hear many excuses to not have one, the biggest one being we just don’t have the time, to which my reply is always, “If you don’t have time to increase the quality of what you are delivering and how you delivery it, exactly what are you spending your time doing and just how do you expect to get better at it?”

The agenda for the sprint retrospect should be similar to that of a post mortem meeting: What did we do very well this sprint, what needs to be improved, what should we never under any circumstances do again, what did we under/over estimate.  Try to keep the tone positive and the meeting moving.  Scrum masters, don’t let the team run amuck with 3 hours of crying and moaning, keep them focused on getting better deliverables.

Remember to keep it cool, keep it collective and keep it agile.