Waterfall Deconstructed

It’s hard to find anyone that actually defends a Waterfall process anymore.  Agile methods might have their flaws, but at least they are usually much lesser flaws than Waterfall.

Yet I actually meet many teams that claim to be practitioners of Agile and Lean, yet when they show me how they work, I all too often have to reluctantly point out to them that they might have the rituals and ceremony of Agile, and they’ve got the Lean buzzwords down, but when you peel all that away, they are really still practicing Waterfall.

I wrote about this topic more generally in Product Fail, but one follow-up question I often get is what are the telltale signs of teams that are still caught in this trap?

There are three defining characteristics of Waterfall teams.  Any one of these is a very strong indicator of Waterfall, but in my experience, if you find one you will usually find all three:

Risks At The End

If the team waits months until their engineers have actually built a product or feature, or even a half-baked approximation of a product (usually incorrectly referred to as an “MVP”) before they see if this is something they can sell, and that user’s can use, and that is technically feasible, and that can work for the business, then all the risk is at the end of the process; which is the traditional defining characteristic of Waterfall.

We are looking for the team to tackle these risks before they have the engineers spend the time and money to build a shippable product.

Requirements Driving Design Driving Code

If the team has a product manager defining (or worse, gathering) requirements, either in the form of some requirements document and/or user stories, and then passing those along to a designer that is asked to design a user experience that meets those requirements (usually in the form of annotated wireframes and/or comps), and then that information is provided to engineers at Sprint Planning where they are asked to architect an implementation, estimate and then build, then this sequential product definition gets to the heart of what makes a process Waterfall.

What we are looking for instead, is defining the product collaboratively, with product, design and engineering working side-by-side, in a back and forth, give and take, to come up with a solution that is valuable, usable, feasible and viable.  The enabling technology informs the design and the functionality, as much as the other way around.

Focus on Output

If the efforts of the team are focused on delivering a feature or a project, usually due to some product roadmap commitment, and there is no team accountability to an actual business result, then this is the third clear sign of Waterfall.

We are looking for a team to take responsibility for solving the underlying business and/or customer problem and not just delivering the feature on the roadmap.  If that feature doesn’t solve the problem, then they need to iterate on that feature, or take another approach to solving the problem.

Sometimes Agile teams talk about the concept of “Done Done” which generally refers to getting something to the point it really is shippable – not just done coding, but is integrated, QA’d and shipping.  That’s significant, but not nearly as far as what I’m talking about.  For modern product, it also has to solve the underlying business problem, and that typically involves much more effort and skill.

The Big Tell

There is one extremely easy way to quickly assess if the team is very likely still Waterfall.  Just find out overall how many things were defined (in the last month or quarter), and then how many things were actually built and delivered (in the last month or quarter).

A team still essentially doing Waterfall will deliver roughly as many things as they define.

A team that’s truly embraced modern methods and has meaningfully moved beyond Waterfall, will have tried out at least twice as many ideas in discovery as they build out in delivery.  A really good team will deliver an even smaller percentage (not by delivering less but by trying out many more).

It’s only product discovery if you’re actually discovering a solution that works.  It’s just same-old product definition if you’re simply defining what you want engineering to build.

This is why I push teams, whatever their preferred process or techniques, to ensure they are focused on these three big areas: tackling the risks up front, defining products collaboratively, and focusing on results.  These are also, not coincidentally, the three overarching themes in my new book.