Given a choice between waterfall versus agile project management, I’d choose agile. We live in a world of unknowns, and we all fall into common traps. Despite our better natures, we try to make order out of chaos, predict unjustifiable conclusions, and design much of our personal and professional lives to fit a template that matches our expectations. In other words, we are aware of Plan B but expect Plan A. When things don’t work out, we roll up our sleeves, promise to “work smarter, not harder,” and attempt to do better the next time.
This adherence to predicting the unpredictable is acceptable when dealing with risk management, such as what type of insurance to buy. In this case, we make a probability estimate of the likelihood that, say, our septic tank overflows, flooding our basement. But this same approach can often get in the way when we attempt to apply probability estimates to project management’s waterfall style. This is because the failure points are too complex, and the project is often too long to predict correctly. So, we end up starting on day one with a planned set of activities and milestones and then follow the thread to what we hope is its ultimate, incident-free conclusion, perhaps two months, six months, or a year in the future. In case our plans go awry, traditional management techniques provide recovery efforts, but only reassurances in the form of modified time, scope, or resources.
Even the best-laid plans eventually hit bumps and even walls along the way. They must because the waterfall framework derives from goals that may be unrealistic, predictions that may be based on inaccuracies, and expectations that may drift due to changing requirements. As discussed, human beings fail to account for the unknowns that invariably occur along the way, such as staff rolling off teams, missed requirements that devolve into scope creep, or plain bad luck when the server crashes at 4 am. As motivational speaker Denis Waitley said, “expect the best, plan for the worst, and prepare to be surprised.”
The agile framework doesn’t work from predictions and expectations. Quite the contrary, one of agile’s fundamental values is “responding to change over following a plan.” Part of agile is about placing the demands of the moment to meet the stakeholders’ immediate needs. This philosophy makes sense: why work on a component required two months ago when new priorities supersede that request? Thus, agile allows teams to focus on the immediate task at hand by addressing the unpredictable nature of plans and accepting inevitable failures and missteps along the way.
Agile was designed to address the inconsistencies of classic project management, which includes the waterfall framework. As such, it places a strong emphasis on a more democratized form of self-coordination including accountability, individuality, and collaboration. While critics have deemed agile’s features too expressive and informal, we must keep in mind that no framework is perfect. With all the unknowns that can and do occur during a project’s lifetime, the agile framework still is the best way to promote a steady delivery stream during times of looming chaos and unpredictability.
The Benefits of Waterfall: Focusing on a Balanced Plan
Rock Roque, NetImpact Strategies
One of the major questions project managers have to answer is: when do I choose agile, and when do I choose waterfall to manage my project? It seems like nowadays all everyone’s talking about agile this and agile that, but what about waterfall? Is it dead? Obsolete? In my opinion, no, waterfall is alive and well – for reasons discussed later in this piece, it will hopefully make more sense as to why that is – It’s less of a question of “Why won’t waterfall work for my project?” but more of “how can my team and I get better at estimating and predicting?” This factor is where people are quick to point out the shortcomings of waterfall, and often, they are right. But this can improve with how waterfall is embraced and practiced.
As a digital designer, I will tell you that working within preconstructed parameters is great. It is essentially a secret ingredient that is guaranteed to make your customer happy when properly applied. Now working without parameters is even better — at least from a design perspective. Why is it better? It allows free-thinking, creativity, and ultimately a better product. The same is true with the waterfall framework when preliminary meetings happen between you as the project manager, your team, and the customer. It really goes without saying that this is one of the most important part of the entire project. It sets the stage with baselines and a plan, one that can be modified down the pipeline and even have touch points built in for customer interaction. To me, it is not that waterfall isn’t useful, it’s a question of application and when it is appropriate.
One of the biggest complaints I have heard about the waterfall process, is that there isn’t enough customer interaction or there is too much rigidity with introducing new ideas or priorities. If done properly with this framework effective communication with customers and flexibility can be built in and be link to each project milestone or even in between. Often, we hear the argument that “agile is responding to change rather than following a plan .” My opinion is that if project teams work more in the moment following more of a day to day, or week by week approach without necessarily following a well-structured plan, the team may have more predetermined issues in the projects pipeline than having finetuned the planned and predictions at the start.
