Have you given any thought to “How to make a hybrid agile process work”? I recently saw an article on LinkedIn entitled “Why Hybrid Agile-Waterfall Projects Fail” that caught my eye. I’m not surprised at this article. It takes some skill to make a hybrid Agile process work successfully and anyone who would literally try to combine an Agile methodology with a Waterfall methodology to create a hybrid methodology is asking for failure – that’s not the way to do it.
Blending Two Recipes
This should not be a matter of literally combining an Agile methodology and a Waterfall methodology. That would be like trying to take a recipe for Italian food and combine it with a recipe for Chinese food and literally trying to mix the steps and ingredients from the two recipes together to create “Italian-Chinese” food. A good chef would never even attempt to do that but he/she might create an entirely new recipe that blends together some of the aspects of Italian food preparation with some aspects of Chinese food preparation.
It takes a lot of skill to create an effective hybrid approach and doing it effectively is like the difference between a “chef” and a “cook”. If you presented a “cook” with a recipe for Italian food and a recipe for Chinese food and asked him to combine the two, I’m not sure what you would get if he/she literally tried to combine the two recipes. It just doesn’t even make much sense. A “chef”, on the other hand, would take an entirely different approach to create a hybrid of the two. A chef might not need recipes at all because he/she understands the art at a deeper level.
Creating a Hybrid Approach
When I talk about creating a hybrid approach, I try to avoid the words “Agile” and “Waterfall” if possible because it gives people the impression that you are literally combining two different methodologies together like combining two food recipes. I prefer to think of a hybrid approach as the appropriate blend of an adaptive approach and a plan-driven approach. The words “adaptive” and “plan-driven” convey an entirely different meaning than “Agile” and “Waterfall”.
- It doesn’t mean that you’re trying to literally combine two very different methodologies by mixing them together
- It means that you’re creating a blended approach with the appropriate amount of emphasis on being “adaptive” versus being “plan-driven”
An Example of a Real Hybrid Approach
Some years ago, I was responsible for managing a very large development program for a US Federal Government agency. It had a fixed-price contract associated with it and a fairly aggressive delivery schedule but the customer wanted some level of flexibility in the details associated with defining requirements. I created an approach for this situation that was very successful that I have called “The Managed Agile Development Framework“.
- It does not attempt to literally combine an Agile methodology and a Waterfall methodology
- It is simply a matter of wrapping a plan-driven layer at the “macro” level around a standard Agile/Scrum process at the micro level
Here’s a diagram that shows what it looks like:
How To Make a Hybrid Agile Process Work
This is a very flexible model – that is why I call it a “framework” rather than a “methodology”.
- You would start out a project by at least developing high-level requirements with estimates of the costs and schedule for completing the project. Those estimates can be as detailed as you want them to be – that’s what makes this model so flexible.
- You can have a relatively “thin” layer of planning with very high-level requirements and less-detailed plans or
- A “thicker” layer of planning with more detailed requirements and planning
The most important thing is that there has to be a common understanding between the development team and the customer about how detailed the requirements and plan are.
This model will not work without a spirit of trust and partnership between the customer and the project team. The customer and the project team must agree to working collaboratively as the project is in progress to further elaborate requirements, continuously refining the plan for completing the project, and resolving any trade-offs that may be necessary to stay within the budgeted cost and schedule.
- As the project is in progress, any changes to the project requirements made at the “micro” level need to be fed back into the planning at the “macro” level. By agreement with the customer, there should be enough slack built into the plan so that minor changes can be absorbed easily without a change to the overall plan and only more significant changes might require trade-offs and adjustments. When trade-offs are needed to stay within the budgeted cost and schedule, the customer may need to either:
- Adjust the planned cost and schedule as necessary, or
- Reduce the scope of some of the requirements if necessary to fit within the planned cost and schedule.
This is a fairly simple model but it works and it can be easily adapted to a wide variety of projects; however, note that this is not a simple step-by-step cookbook approach with detailed checklists of what to do and fill-in-the-blanks document templates that some project managers are used to. It takes some skill to make this model work successfully.
Matching the Level of Uncertainty in the Project
A good strategy is to match the design of the hybrid approach to the level of uncertainty in the project:
- A project with a lower level of uncertainty might lend itself to a more plan-driven approach particularly if predictability is important to the customer of the project. That would mean putting a higher level of emphasis on developing a “thicker” layer of planning at the macro-level
- A project with a higher level of uncertainty would probably require a more adaptive approach to further elaborate the plan as the project is in progress. That would mean that the level of planning at the macro-level would probably be much “thinner”.