March Madness - A Perfect Analogy for Agile vs. Waterfall Methodology
Each year millions of Americans fill out NCAA March Madness brackets trying to pick as many games correctly as possible. I use this analogy to explain the differences between waterfall and Agile and highlight the benefits of Agile for product development.
March Madness is one of my favorite sports "seasons" each year. The NCAA basketball tournament contains a combination of powerhouses from major conferences, but also the Cinderella stories of small school teams from small conferences who get their chance to compete.
Many fans (even those that don't watch basketball all year long) participate in "bracket challenges" to see who can pick the winners of the tournament games.
The reason this is so much fun is that it is unpredictable. Generally the higher seeds win, but without fail, every year, there are some exciting, completed unpredictable results. This year, who expected Yale to beat Baylor or Stephen F. Austin to beat West Virginia?
.jpg "GetFile-(17).jpg")
I use this as an analogy for the differences between Agile and traditional (waterfall) methodologies for software development / technology projects.
The quick version of it is that in a March Madness bracket challenge you have to use a Waterfall approach to picking the games.
- You do all of the "analysis" up front, looking at match ups of different teams, strength of schedules, individual player match ups, etc.
- You pick all of the future outcomes (multiple rounds into the future)
- You then lock in that "plan" and play all of the games
Your bracket (just like your requirements or project plan in Waterfall) aren't setup to respond well to changes. After the first round of games, we now know that Baylor is not going to be in the Final Four, so all of the time and effort spent analyzing the matchup between Baylor and Oklahoma in the Elite Eight was waisted effort and the picks are now surely wrong.
An Agile approach would allow you to do all of that analysis on the first round of games only, with only some light "roadmapping" of the rest of the games. You'd then watch the first round of games (do the 1st sprint) and adapt your plan. You'd then do that detailed analysis on the 2nd round of games, based on the actual results of the first games. You still wouldn't pick every game correctly, but you would ultimately get a lot more of the games correct and spend a lot less time analyzing things that are never going to happen.
My friend and colleague Austin Walker put this theory to the test the last couple of years and wrote about the outcomes. You can read his series here:
About: Justin Bell is a Vice President at Credera. He enjoys leading teams and working with clients on their digital strategy, understanding how technology can be used to accomplish business objectives and IT Velocity/Efficiency initiatives.