Wet agile, the Agile-Waterfall hybrid, Water-scrum-fall — there are numerous formats for hybrids of Agile development and traditional Waterfall methods.
Some hybrids are good. The product of dedicated thought, they adequately preserve the main benefits of more pure methods. Other hybrid models are pure accidents. They're commonly the consequence of:
- An unsuccessful Agile transformation that hit the brakes somewhere between Waterfall and Scrum.
- A compromise between promoters of different ideologies (often management on the Waterfall side, developers on the Agile side).
The result of the latter two can be tough to witness. But it's even worse to experience — regardless of whether you're in the development organization or on the receiving end, waiting for the product.
However, I do not believe the frequent occurrence of poor Agile-Waterfall hybrids should give anyone good reason to consistently argue against mixing the two arts (as many Agile purists do).
Rather, these cases highlight the need to bring successful, proven versions of Agile-Waterfall hybrids into the light and reserve a place for them among their purer counterparts.
A Successful Agile-Waterfall Hybrid Model
Founders of more successful hybrid versions often come from product development companies that deal with both software and hardware.
The driver behind the method mixing in these cases is, if we simplify to the extreme, the realization that many aspects of hardware development benefit from Waterfall processes, whereas software development has much to gain from an Agile approach.
The Agile-Waterfall hybrid described by Erick Bergmann and Andy Hamilton from Schneider Electric is a great example of a model that merges Agile and Waterfall in a good way — without compromising the core principles of each too much.
Here are several key points:
- Their model allows software teams to adapt Agile practices, while hardware development (and overall product management) use a traditional Waterfall approach.
- The overall PMP process has a well-defined interface to Agile software development. It's continuous — from the start of the concept/feasibility study through validation and production. The interface has the format of close collaboration for all activities ranging from definition of requirements and scoping to continuous software deliveries and feedback.
- The model accommodates development in instances where the same or similar software is used in several products with separate product owners.
- The resulting (and very challenging) backlog management situation for teams in is well-addressed by the model. In short, it accommodates swift product releases by attending to feature-release planning on the software side
- Compromise is critical. Just like any other hybrid model, this Agile-Waterfall hybrid compromises some of the principles of non-hybrid methods. The Waterfall side of development lives with flexibility regarding software requirements. Likewise, Agile teams must commit to time-fixed delivery dates, cost forecasts, and risk assessment.
[RELATED BLOG: How & Why to Mix Gantt Charts With Agile Methods]
Back to top
Use the Agile-Waterfall Hybrid The Right Way
Agile-Waterfall hybrid development models face many challenges. It is not easy to combine the dependency tracking and clarity of waterfall with the flexibility and openness to change of agile development without diluting the benefits and create complex work processes. However, examples like the one referred to above prove it's possible. As the industry need for these types of models is evident, I hope to see more of these being published in the future.
Want to Mix Methods?
Try Helix Plan, a free Agile planning tool for up to 5 users.