Is Agile-Waterfall A Good Thing

Is Agile-Waterfall A Good Thing 150 150 CloudGovCo

Hybrid project management methods merging waterfall and agile on larger projects are becoming common, as people struggle with resistance to wholesale change.

This is not very effective.

There are two main issues:

  1. The waterfall process will always be the longer pole, so projects will not take less time. Activities in a phase such as Development might be agile, but they are still working to a waterfall milestone and phase gate.

This doe not improve time to launch. Time to launch is the most important KPI because it incorporates all cost factors. (We used to use time to market for the same reason.)

Research has shown that the cost of time is greater than the cost of effort, so project methods with concurrent activities are best because they minimize time.

  1. The second problem is that Agile methods don’t scale. Large projects cannot be chunked successfully across a large number of agile teams. Putting aside administrative issues, the core problem is the train wreck of managing the many code branches and merging back into the main trunk.

Note that CI/CD pipelines do not use branching.  (They can but they shouldn’t.)

Research is also finding that an over-reliance on Agile can impose a 20% non-productive burden. Critical Chain method (not critical path) can be better. Six Sigma Lean/Kanban is perhaps best.

lean kanban with late start
Late start date reduces cost and time to launch

A counter-intuitive method is shown in the attached graphic from a presentation I did last year. This was developed by Toyota. Instead of using early start date as you would in critical path method, it uses the late start date, which is more like Critical Chain method. This pushes all activities up against the project deadline, with no slack time or buffers between activities. Everything is on the critical path.

This goes against everything project managers (PM) are  taught. PMs try to keep things off the critical path.

However, Toyota puts a buffer at the end of the project; thus guaranteeing finish on schedule. In the best cases this will give an early delivery for the project. Russian defence projects are successfully delivering on Finish Before Planned.

The big advantage is that the Lean Kanban method shown in the graphic defines requirements as late as possible, so they reflect the latest needs, and the project uses the most recent technology, so it is efficient. It also reduces change orders.

It is also massively parallel (concurrent) so it reduces time to launch, thus providing faster feedback and releasing people for other projects. Because it’s parallel it uses multi-discipline project teams, which are usually more innovative and goal driven.

A lot of this has been known in continuous improvement process for decades, but it hasn’t trickled into project management. Concurrent development, for example, emerged in Japan in the 1990s. Waterfall, developed in the 1950s for the USA military, has really acculturated people to linear step-1 step-2 thinking.

At its worst, people think they can’t plan step 2 until they complete step 1. It also infects Agile developers who can’t estimate work until they have completed it.