The Cascade - An Agile Waterfall Conclusion - Part 3

In Part 1, we discussed the basics of the Waterfall method of project management , how it can get out of hand and some of the benefits it can afford us.

In Part 2 , we discussed similar traits for Agile project management.

Finally, this part 3 , we will aim to take stock of what is actually needed for these two project methodologies to work for us.

And that's really the key to all of this. The project methodologies are here to work for us - not for us to be restricted by them . With this simple yet fundamental shift in mindset , let's discuss.

The Cascade

What’s this ? – A new breed ? Well not exactly. This methodology is kind of a cross between the two and has been seen in the wild where the team try to take the best of both worlds and in a sense is an enhancement of the iterative waterfall.

You have fixed milestones that you must hit, strict timelines and budget and also have daily scrums, scrum of scrums, backlog grooming sessions and requirement refinements as you go along.

This may sound like a recipe for disaster and indeed can well be unless managed very efficiently. On the flip side, when done well, it can work wonders even under very tight deadlines.

Regardless of whether you consider this to be a flavor of Agile or a flavor of Waterfall, it has very limited squeeze room for developing refined requirements. Each backlog grooming session must be extremely productive and must yield 80 to 90% of requirements for tasks being discussed.

It also needs a very high, discipline and engagement and participation levels, on all sides.

This puts a lot of pressure on each role to get it right straight off the bat – This includes the Devs, the BAs , Product Owners, PMs, testers, everyone!

If you do slip you will find yourself readjusting the backlog, MVP and project plans ALL THE TIME and you will begin to wonder why you started this method in the first place!

Why do it at all you ask ?  

A plan that aims to achieve the best quality of solutions that agile can bring but within the relatively hard lines and scope boundaries traditionally associated with waterfalls, can be seem very compelling and even seductive to attempt.

I believe it can be done but you need a crack team for this to work one that.

1.      Knows all the requirements.

2.      Is able to provide detailed design during the backlog review quickly.

3.      Business know what they want for at least 75% of the  solution.

4.      BAs are well prepped and familiar with technology and domain to increase their independence

It should also be noted that the above alludes to some form of pre-project audit of requirements to have taken place to set the stage up for success.

But then, with such a team and all that info, shouldn’t any method work?

Let the method work for you

I think this is a very important realization to be had. Each methodology is great in its own right and depending on what your organizational culture has to offer and what you are trying to do, one method can yield a better way to operate than the other. 

Many large programmes around the world have been successfully delivered using Waterfall as have many failed. Same for Agile

Having said that , I do think that traditional waterfall of gestation time of 10-12 months before a project goes live is a thing of the past . Other than that both Agile and ‘cascading waterfalls’ have their ups and downs At the end of the day it really comes down to your organization’s culture and the team you have to work with.

There has to be a very good balance between what method the management wants to follow, the organizational culture and the skill-sets of people you have with yourself.

No one method is going to act as a silver bullet.

Finally , an oft overlooked aspect of project management can dramatically impact the success of any methodology and that is contractual obligations.

If the contract terms are at odds with the methodology , e.g. payment based on specific features or penalty based on scope creep. , then your battle would have begun even before the teams hit the ground !

To avoid this, ensure your sales team are aligned with the delivery team . It's not uncommon at all for these two sides to be out of sync. In fact, it might even be a defacto norm in some areas - so beware!

That concludes our 3 part series on my experiences with different styles of project management and execution . I hope it was useful , and that it has given you some food for thought.

Let me know what you think in the comments, whether this is something that you resonate with or indeed something that is completely opposite of your experience !