“Usually it takes effort to finish in the bottom 3.6%.”
That’s what my good friend David said after reviewing the status of my waterfall bracket heading into the Final Four. Even though I made what I thought were good picks, I may have turned in the single worst bracket of my life.
To recap the series, we’ve been comparing waterfall and agile methodologies using a March Madness bracket as our example. Prior to a single game being tipped off we spent a significant amount of time researching, planning and making picks. Then we locked down our plan and hung on for the ride. To represent agile methodologies in software projects, we also filled out a bracket with the freedom to adjust picks each round based upon new information (i.e., who won/lost from the last round).
Let’s get to the scores to see how each methodology is faring:
Points / Pick
Round of 64
Round of 32
2 / 4
? / 2
? / 1
30 / 64
39 / 64
Clearly agile is killing waterfall, particularly in the later rounds. In fact, my waterfall bracket was completely dead after Saturday’s Sweet Sixteen games. Every single team I had originally picked going to the Elite Eight was out.
If my waterfall bracket were a complex software project, not only would we be doing poorly, but our project would likely be at risk of shutdown. As unforeseen events continued to pull us off course, we’ve come to a place in our waterfall bracket where we’re literally without hope. We cannot add any further value to our bracket in the last two rounds.
Thankfully in my agile bracket I can adjust my plan and make informed decisions as we move forward. If this was a software project, I may have made some planning mistakes, but because I’ve been able to adjust to the situation as we learn new information the project can continue to efficiently move forward and deliver value.
We Can’t Predict The Future
No amount of planning can accurately and perfectly predict the future. With waterfall’s focus on exhaustive upfront planning and documentation, it can be incredibly difficult and painful to adjust to new discoveries or surprises. Waterfall development stresses perfect completion of each phase (analysis, design, implementation, verification etc) before moving to the next one. This approach sets the stage for the possibility of having to throw out large volumes of work. As the project morphs over time, we may find that our early work was built on poor assumptions and ultimately doesn’t add the value we once thought it did. Remember how my waterfall bracket worked out?
With agile methodologies, we admit upfront we can’t predict the future and will likely gain additional insight as we progress. We acknowledge we must make a concerted effort to change and adapt quickly once new information or priorities come to light. This allows us to focus on delivering valuable software quickly.
So What Actually Went Wrong With My Waterfall Bracket?
First of all, it turns out the aggregate metric on which I based most of my decision making, ESPN’s Basketball Power Index, was not nearly as helpful at predicting the future as I had anticipated. This single incorrect assumption caused me massive headaches down the road. Secondly, my championship team, Duke, got knocked out by Mercer in the round of 64.
In complex software projects (and brackets) we need the flexibility to adjust based on our mistakes and account for unexpected events. The freedom to correct our plan allows us to efficiently deliver valuable software.
To paraphrase the poet Robert Burns, “The best laid plans of mice and men often go astray”. We can plan for everything but the unexpected. Unfortunately, the unexpected is often what derails our plans.
Other Posts In This Series
The Agile March Madness Bracket: Picking the Best Bracket
The Agile March Madness Bracket: Unforeseen Events Have Changed Everything