Tag Archives: Hybrid Agile Process

How to Make a Hybrid Agile Process Work

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:

How to Make a Hybrid Agile Process Work

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

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Managed Agile Development Framework – A Hybrid Approach

I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That excludes the possibility that there is a hybrid approach that provides the benefits of both approaches. The Managed Agile Development Framework is an example of a hybrid approach that is very easy to implement

Background

A few years ago, I was responsible for managing a large government project.

  • The project required meeting some defined cost and schedule milestones
  • However, the customer wanted to take an Agile approach to defining the requirements.

In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals. The framework consisted of two levels:

LayerDescription
Macro LevelThe “Macro” level was the outer envelope of the project. It was focused primarily on managing overall contractual requirements
Micro LevelWithin that “macro level” envelope, we were still able to implement a fairly flexible Agile development approach at the “micro-level”
Managed Agile Development Framework

How Does It Work?

There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.

  • The macro-level framework is a plan-driven approach. It is designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
  • Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile/Scrum approach. It is designed to be adaptive to user needs

Trade-offs to Consider

Naturally, there are tradeoffs between

  • The level of agility and flexibility to adapt to change at the “micro-level” and
  • The level of predictability and control at the “macro-level”.

It is important that both the client or business sponsor and the development team need to agree on those trade-offs. The framework provides a mechanism for making those trade-offs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.

Increasing Predictability and Control

Increasing the level of predictability and control requires:

  • Beefing up the macro-level,
  • Providing more detailed requirements at that level, and
  • Implementing at least a limited amount of change control

Increasing Agility

To increase the level of agility:

  • You can simply eliminate the macro-level altogether or limit it to only very high-level requirements
  • Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors

Change Control

A question that often comes up is “How do you handle change control?”. The answer to that question is that:

  • You have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level.
  • However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones.

General Approach for Agile Contracts

This general approach can be used on almost any project. Check out this article for more detail on Agile Contracts:

Agile Contracts

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.