Think Different about development. Think NFL!



In my living room, I have two Apple ads framed on my wall. While that sounds blasphemous for a guy who has his checks signed by Bill Gates and Steve Ballmer, I have to say that I've never been more impressed with an ad campaign. This was about five years ago when Apple did the series where they took some of the most revolutionary people in the world and simply used their image. No product placement. No explicit mention of Apple. Just a small logo and two words: "Think Different". I bought a poster of the Cesar Chavez image for my then-fiancee for Christmas five years ago and she bought me the Thomas Edison poster for me a year later. There were plenty of other options (Jackie Robinson, Carl Sagan, Mahatma Gandhi, Jim Henson) and I was so enamored with the concept that I was tempted to buy them all. I am pleased to say that the ads don't encourage me to buy Apple products (I don't even own an iPod!), but they are a constant reminder that the best ideas are ones that aren't always easily accepted.


That concept of "thinking different" has been prevalent in my day-to-day life of late. I have been involved in a lot of discussions over the last few weeks regarding the software development lifecycle and how to best deliver a quality product to market. One of the projects we are working on has been using agile principles while another project is considering it. In both cases, we are getting serious resistance, either by stakeholders in the project who fear the project will be a failure, or participants who, well, fear the project will be a failure. Let's face it--people don't like change and adopting unconventional principles violates human nature. There are things we take for granted--death & taxes, the sun rising in the east, and waterfall development. Some give lip service to being more agile, but I think people get lost in the literal definition of the word (see dictionary.com) and the actual agile practices that are gaining momentum (see the Agile Manifesto). I've tried to be the advocate and defender, but it's hard to get people to shake old habits--especially when the voodoo is being spouted by the "business guy".


As I always do, when I need guidance on agile development, I seek out Jim Newkirk. This week, I was talking to Jim about this and he was talking about certain analogous situations where agile "methodologies" are used outside the software industry. Jim has always been clear that, without clear buy-in by everyone on the project, an agile project will fail. Thus, Jim's spent many more years than I have supporting agile methodologies and usually manages to articulate the issues far better than I could. For example, in response to a comment by someone that they wanted to be "more agile", Jim responded "being more agile is like being more pregnant".


Anyway, we were bouncing ideas off each other about how to explain it to others. Then, a couple of days ago, it hit me where agile development really occurs: the National Football League. Allow me to elaborate:


Let's break down a typical game for a team. Long before kickoff, a coach and his staff carefully reviews the opposition and determines their game plan, identifying the opponent's strengths and weaknesses and developing a series of plays and approach to taking control of the game. The goal is clear (score more points than the other team) and they use the information accessible to them at the time to formulate their strategy for game day. They may show a preference for running the ball over passing the ball or focusing on directing the offense to the left side than the right side. Based on this analysis and chosen strategy, they select the optimal players, put them on the field, and practice the plays consistent with the game plan. The mornning of game, the coach gives the inspirational speech, announces how the game will evolve, assures victory is imminent, and the players psyche themselves up for the battle .


But once the game starts, all assumptions are thrown out the window. The game rarely goes exactly according to plan. Think of all the things that could happen. The opposition could throw a wrinkle in the game plan by running new defenses. Your star player may get injured. The other team's star may get injured. When these things happen, you have to adapt to the changing circumstances. In football, gameplans are being constantly revised in continous increments. Each drive, the coaches send the quarterback out there with instructions on what primary plays to choose from. After each play, the team huddles up and listens to instructions for the next play as determined by the quarterback. This is also the opportunity for a player to share extra information that the rest of the team may not be aware of ("They aren't defending me", "I'm hurt--don't run behind me", "You are not blocking my man", etc). And then, after all of that, at the line of scrimmage, if the quarterback sees something in the defense, he can still "call an audible" and change the play seconds before the ball is snapped. As a coach, quarterback, or any other part of a football team, you are most successful when you are a feedback-driven system, responding to your environment. But despite these continually evolving situations and the shifts in execution that may result from them, that main goal remains the same--score more points than the other team.


Now imagine running an offense where you call every play for the entire game before kickoff. If you fall behind 21-0, you continue to run the ball even though that takes time off the clock and practically assures defeat. Or one player decides to change a play, but the rest of the team refuses because there was no real communication. Or if your star receiver gets hurt and yet you continue to call the play that features him, but now rely on his far less capable backup. Or worse yet, you don't even bother to replace the injured star because you never took the time to listen. And then, when you don't score any points after you had promised to score 40, you look at team with a sense of bewilderment ("how did we miss our target? I drew it up perfect!"). A coach or player that opreates in that manner will not last long in the NFL. But that's what waterfall software development feels like. It's a regimented set of plays that sets itself up for failure by not constantly re-assessing in a rapidly-changing environment. It assumes everything will go pretty much according to plan when nothing in life ever really does. There's no emphasis in communication--it's all supposed to be thrown in a document instead discussed face-to-face (no need to practice as long as everyone owns the playbook, right?).


In this football analogy, I see each offensive drive as an iteration/sprint and I see the huddle as the standup meetings. All 11 guys are in that huddle, everybody makes sure they are on the same page, share information from the last play and come out ready to succeed for that next play. The goal is always to ship a quality software product on schedule and on budget--that's how you win the software development game.


A friend once told me "agile development is performed by those who don't know what they are doing", a dig at the fact that if you don't have a documented plan, you are making it up as you go along. Well, spend your Sundays watching guys like McNair, Manning, and Favre and you'll see they know exactly what they're doing--even if they didn't know minutes earlier that they'd be doing it. I suppose that's my way of Thinking Different about how to Think Different...


Skip to main content