The waterfall is a great project management approach but we need to move beyond it.
Are you still doing Waterfall? The practise of creating a detailed plan, followed by the phase of implementation, the documentation in Agile Project Management isn’t the same as Waterfall. In fact, the waterfall is now considered obsolete – which makes sense because it relies on assumptions that are no longer true today. We live and work in a world where change is constant, so our actions should be too.
So what’s wrong with waterfall? A lot! It limits interaction between stakeholders and development teams. Let me explain: when an organization adopts Waterfall, it strips away the visibility that everyone else has into what team members are working on during any given frame of time. For example, in a typical Waterfall approach, once the product owner hands over an item to be developed by the team, she or he has no clear visibility into how development is progressing.
An Agile Project Management approach bridges this gap between what’s needed and when thus making it possible for stakeholders to have more involvement in the process. It also allows both groups to see at a glance where work is behind and where everything is on track. This practice leads to faster revisions, fewer reworks and better expectations management overall. And that means improved collaboration.
But there’s still another fundamental problem with Waterfall – it doesn’t make allowances for a change! Waterfall assumes that requirements are set in stone, allowing little room for adjustments along the way. Of course, in real life, situations often change – priorities shift, and business needs met with one product may not be applicable to another.
This kind of freedom is hard for a Waterfall model to accommodate because it’s static – its methodology relies on strict adherence to the plan that was created at the beginning of the project. The longest waterfall project I have ever worked on still took three years from start to finish – it doesn’t exactly encourage quick response times!
And then there are all those extra costs involved if an organization decides that they need something different down the road: more time and money for rework, additional fees for consultants or outside resources, tweaks and changes to existing codebase… you get the picture.
In case you’re still not convinced, I’ll give you one more reason why Waterfall isn’t the best option out there: it’s counterproductive! The practice of having a plan to make decisions on is great for making sure your team sticks to their responsibilities, but that same rigidity that drives adherence to the plan can also prevent growth and innovation. To understand why this happens, let me give you an example: if the product owner requests something in version 1..10 of the product, then nothing else will be developed until those requirements are met. But what if that feature (or anything else from his or her list) needs tweaking? Or fixing? Or even scrapping? With waterfall, these changes cannot occur without spending money and time on redoing work that’s already been done. But a company using Agile Project Management can choose to change course on any of these fronts as they see fit – the point is, this flexibility is possible without having to start from scratch.… Read More