No — Waterfall is not sometimes correct. It is always Wrong

Every other day I meet people that says something along the line of

We’re doing agile for some of our work, but other needs waterfall so we have control.

I’m getting tired of hearing that statement. Working with Waterfall (phases with big batches of work) is, in a software development perspective, always wrong. I know from working in a big corporation it’s more of a change in mindset and getting rid of some misconceptions about lean and Agile that gets people moving. The Waterfall ways of thinking is obsolete.

You should get out of that thinking as fast as possible. However, I know in a big corporation it’s more of an mindset change and getting rid of some misconceptions about lean and agile.

The waterfall approach

Let’s first explore the waterfall method; this has been around much longer and is a more classic approach to project management. Key features include: Detailed schedule and scope planning at the beginning of the engagement

• A sequential design, build, test, deploy process
• Relies on detailed documentation
• Final product is rigorously tested across user groups once the project is complete

Some drawbacks to the waterfall approach are the lack of flexibility and room for error. The project is mapped out detail by detail before the engagement even begins, leaving no room for error. If a mistake is made in the planning process, a requirement is missed or a new requirement surfaces mid-project, the project experiences serious delays and disruption. If your organization runs multiple waterfall projects, a delay in one can cause delays in others, as important resources are not available. Additionally, this planning simply takes a long time, and the delay in beginning the project can have other costs associated with it.

Another drawback is that testing is only done one time at the end of the project. In a larger waterfall project, going back to find and fix flaws becomes more difficult and time consuming. This requires that unit testing and code review be done rigorously throughout the project, and that test cases be meticulously detailed to help developers build the right things the first time around.

Perhaps the biggest drawback is that there’s no room in the waterfall methodology to cater to changing needs. In today’s changing marketplace, new ideas, technologies and competitors appear frequently, and users have valuable input. The inability to adjust to these on-the-fly can be the Achilles Heel of waterfall.

The agile approach

The agile development approach is quite different from waterfall. It’s open, flexible and suited for changing expectations. The agile methodology:

• Welcomes contribution of outside input along the way, shaping the final outcome
• Allows for correction during the course of the development cycle
• Uses a collaborative, team-driven approach
• Follows an incremental development plan
• Requires close collaboration with the stakeholders and the development team

Most people share the experience that agile can deliver faster results along the way, although final delivery can take longer. Where waterfall needs everything defined up front, agile fits best with projects where everyone acknowledges that all requirements can’t be known early in the process. Agile methodologies tend to be good for product builds and other projects where the overall usefulness of the final product is more important than a predefined set of features. Agile is also good for projects that have outside pressure — in these cases, showing forward progress often has its own benefit in helping customers or other stakeholders become comfortable with your efforts. Agile is almost a requirement for mobile apps, healthcare applications and other situations where technology, regulations or market conditions are rapidly evolving.

Remember, agile is really a group of methodologies, each of which have their own special focus and strengths. In general, benefits of agile methods include:

• A rapid kick-off process, which lets you start the project with what you know without waiting until everything is perfect
• Flexibility to adapt to new needs, additions, priorities or corrections along the way, because you define requirements “just in time,” before you develop them
• Ongoing testing throughout the process, instead of one big test cycle at the end — Quality Assurance teams are involved day-in and day-out, helping developers correct course quickly and minimize rework
• Ability to launch more frequently and get your application in users hands (generating revenue or at least app store reviews).

One of the challenges that the agile methods often face is the uncertainty around scope and schedules. While the flexible timeline is often seen as an advantage, loose timelines can also make stakeholders nervous that the project will run over budget.

Another difficulty in agile methods is measuring success. Where waterfall has a clear set of deliverables, agile projects have the risk of becoming never-ending, adding “just one more thing” ad infinitum. Agile projects require ongoing involvement of all key stakeholders throughout the project lifecycle to focus on true user needs, rather than on all the nice-to-haves.

Additionally, agile projects can suffer large impacts from mistaken architectural decisions if not a vision is clear. Because teams figure out requirements as they go, decisions can be made early on in a project that have a larger cost to change later on — and this is especially true when the mistake is in the underlying architecture. Some agile methodologies advocate a “Sprint 0,” a time before normal sprints begin when stakeholders collaborate on project ground rules to avoid major missteps.

Yes, but for [big thing that we don’t think can be done in a lean/agile way] it doesn’t work

This is the obvious and common objection. So far… It might sound like this:

Yeah sure, but when you’re doing a major roll out with a lot of systems/applications you cannot do that in small increments because of all dependencies.

To that statement I will now just add:

Yet. No you (we) cannot do that yet. Let’s see how we can get there.

Lean was invented by Toyota and a man called Taichii Ohno. All this work was guided by trying to shorten lead time through a faster and smoother flow of value. Famously summarised in this quote:

All we are doing is looking at the timeline, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the timeline (by reducing the non-value adding wastes)

Taiichi Ohno (and in turn Toyota) let their strive for a faster flow change things that were considered constants.

At the time (and still, I presume) you make cars from a roll of steel that then is stamped into the required parts for the model needed. These dies, of course, are very heavy and sturdy since you, quite literally, are stamping things out of steel. Also, they need to be extremely precise as smallest problem would replicate throughout all the parts stamped out.

Changing a die to stamp out another part was very time consuming and hard work. It took a full day to change them and that was considered a constant.

Now with the focus on higher flow and flexibility, required by the limited buying power and demands in the Japanese market — a day to be able to change die was not enough. So with relentless, and typical Japanese/Toyota, dedication Mr. Ohno started to improve the change mechanism.

After 20 years (!) it was down to just 3-minutes. Toyota could now easily switch dies back and forth to fast and smoothly create the particular car parts required. The batch size and inventory were kept to a minimum while flow was intact.

This is the famous Single Minute Die Experiment and illustrates my point. When Ohno started his journey no one would ever think about the 3-minute die-exchange. He totally changed the way they used and operated the dies. Much as agile has totally changed the way we do software development.

Summary

Waterfall is always wrong. It’s optimized for risk and failure. Please have a look at CHAOS REPORT for more data.

You are still using it because you have not found a better way. But a better way is there for you to discover. Go find it! You customers are waiting for you.