Why Agile is like Football: Halftime

August 04, 2011 12:22 AM | COMMENTS (0) | |

In my high school days I played in the band. I went to high school in Texas, and everyone with a pulse knows how Texans feel about our high school football.  That is serious “bidness”, heck, there have been movies filmed on the subject.  Here is a little known fact, as big as the football games are, there are a select few schools in Texas where the band is an even larger draw than the game itself.  There were games, and quite frankly still are, where the fans come out specifically to hear and see “The battle of the bands” during half time.  Fortunately for me, I attended one of those schools, and I was in the band. Ah the memories.  I digress, while halftime was our time to shine, it meant something totally different to the football team. For the squad, this was a time to reflect on what just happened on the last two quarters and to bring out the good and bad of the first half.  There will be observations made in the locker room that will give more of a 50,000 foot view of the game while pointing out very specific areas that need to change.  This time of retrospective inspection is needed to properly assess and plan for the next two quarters.

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.