Waterfall vs Agile

Posted by in Agile, Project Management

Let’s start with looking at the myth.

Agile means less documentation, less work, no management and you could do whatever you want.

Not true.
In fact Agile methodologies means more management, but mainly more self-accountability. It’s a way to engage all the participants of the team and do the planning together (with the people who knows their stuff). It’s also a way to be able to quickly change requirements and add features – by being in close contact with the customer we’ll deliver what the business needs now. It doesn’t mean we can change it right away – there is still a heavily guarded gate, namely the “Product Backlog”. This list of “requirements” or even better worded: Business needs – in the form of little stories – are managed by the Product Owner. Nothing gets added to the list without that person adding it. Nada. Zip. Zero. The beautiful thing is the visuality that this brings, the Product Owner also needs to prioritize all the items, in order of appearance – so the project team knows what the most important to the business. So when planning what to do, the team plan short – in just two weeks – what they should deliver. They sign up for the tasks they think they can deliver – fully functional – in two weeks. This is called a sprint. A contract has been made here. First, the team, by signing up for those tasks, have made their commitment. Secondly, in return the team will be left alone to do their thing for two weeks, promised by the Product Owner. Nothing else gets added during this time. When the two weeks are done and the review is made – this process is repeated. It could be new features or changes.
This doesn’t replace a fair amount of upfront planning, as the Waterfall is about. You still need to have a roadmap for your product and a holistic way forward, and the details can be filled in by this approach.

If we look at the methodology called “Waterfall” – it’s really nothing else than “old school plain project management”. It’s the way it’s always been done and it definitely works. It will deliver a measurable result in a well estimated time within budget and scope. No frills. Just what we planned. As the name suggests, it starts at the top of the waterfall. You are sitting in the water pool and plan everything. Gather requirements, getting the scope well thought thru, aligning everyone. Making decisions. Forming the project team, asking line managers for their team members commitment. Do your  fair share of negotiation. Budget is set – goals are decided and communicated. Kickoff time. You jump in the barrel and hit the waterfall. Everything you do now as a PM is about controlling, managing, communicating, tracking and making sure everything is happening according to plan. If it doesn’t – one of your contingency plans will help you find alternatives on how to solve the situation. It’s costly and hard to change the requirements or add features, simply because they weren’t planned before, and always mean a deviation from the plan. You can handle changes, by implementing governance – which basically means make sure you have a process that takes the new request in consideration – and makes a plan around how to handle it. This has and impact on resources (time), scope and budget. This is brought to your change control board and it could be approved or rejected. If approved you need to implement the changes to the organization, and usually this means changing of deadlines. If rejected your customer might not be happy – but they understand.
In the end – if the project is properly management and you have been working with a great team – you will after a few months deliver a product exactly to the specifications written down when it started. So far so good.

It may be that the business need has changed meanwhile. Then the risk is that you’ve delivered something that doesn’t fit the business need anymore. Then it needs to be changed, force implemented or dropped. All those cases means a loss. It could also be that the business didn’t change during your waterfall project. Great! You have now delivered something really stable, thought thru that works.

Despite of what this text may suggest, I’m not a profound believer of Agile/Scrum. I just have the opinion, that it is an opportunity to try something else. If it fits the project type – closer to marketing, something that is rapidly changing and if you are able to get a dedicated team with specialists – you’ll probably reach better results trying any agile methodology, because of its iterations and ability to change. If you are working on a well defined project that has been done before, is nothing new and the spec is very clear. Choose the old school methodology and you can deliver the correct value to the business.

Agile, is a way of engaging the participants of the project to a higher degree, making the team accountable for the decisions, and watch out now – allowing the team to “self-manage”. (Within the constrains).

Waterfall is the classic PM methodology, where the Project Manager assigns you a predefined task, and has a deadline to it. Less accountability for you – you just need to do what you are tasked to do in the decided time frame. This works better if you work in multiple projects and can’t be dedicated to one project.

There are ways of combining the two in order to get the best out of “two worlds”. That may be another post…