Waterfall-Agile Hybrid Project Management

Waterfall-Agile Hybrid Project Management 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 might be agile, but they are still working to a waterfall milestone and phase gate.

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 minimise time.

  1. 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. 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 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.

The big advantage is that the method 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.