Have you given any thought to “How to make a hybrid agile process work”? Some people claim that hybrid Agile projects don’t work at all. For example, 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 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. However, he/she might create an entirely new recipe that blends together some of the aspects of Italian food with some aspects of Chinese food
Creating a Hybrid Approach
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”.
When I talk about creating a hybrid approach, I try to avoid the words “Agile” and “Waterfall” if possible. Those words give 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”
Creating a hybrid Agile approach:
- Doesn’t mean that you’re trying to literally combine two very different methodologies by mixing them together
- 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
- However, 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“.
The Managed Agile Development approach:
- Does not attempt to literally combine an Agile methodology and a Waterfall methodology
- Instead, it wraps 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:
You might say:
- “That’s not a hybrid Agile-Waterfall model”
- “It’s only a standard Agile development process with a plan-driven layer wrapped around it”
And, that would be correct. There has been no attempt to actually mix-and match a phase-gate Waterfall methodology with an Agile methodology.
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”.
1. Project Planning
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 refine the plan for completing the project, and
Resolve any trade-offs that may be necessary to stay within the budgeted cost and schedule.
2. Managing Changes
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. 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. 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”.
You will find much more detail on this in my Online Agile Project Management Training.