Project Management

Agile Practice Guide - What is Hybrid Agile anyway?

From the Agile in Practice Blog
by , , , , , , , , , ,
This blog is a conversation between the Agile Practice Guide Team and our PMI and Agile Alliance Communities to gain insight, support and collaboration around the creation of a usable and relevant body of work that supports transition to hybrid and agile in project work.

About this Blog


View Posts By:

Kristin Jones
Becky Hartman
Johanna Rothman
Mike Griffiths
Betsy Kauffman
Jesse Fewell
Edivandro Conforto
Horia Slusanschi
Karl Best
Stephen Matola
Stephen Townsend

Recent Posts

Agile Practice Guide Goes Global

Unveiling the Community Bridge – the Agile Practice Guide

Introducing the PMI Agile Practice Guide

Agile Practice Guide Launching Pad

Alignment of the Agile Practice Guide and the PMI Standards

Categories: Agile Practice Guide

Now that the agile movement has expanded to larger organizations in more industries, we’re seeing a lot of variation. Granted, we’re used to a variety frameworks, techniques, and methods in use, from XP to Scrum to Kanban to Continuous DeliveryHowever, lately we’re hearing more and more about the use of “Hybrid” approaches.

Maybe you’ve heard an executive say “we’re not agile yet, but we’re using a hybrid approach”. Or maybe you’ve heard some consultant proudly declare “unless you do lots of prototyping, you’re only hybrid agile”. And then at the meetup you hear another person say “Oh, we’re not hybrid, we use a blended approach”.

With all this chatter, it can get pretty confusing as to what people actually mean. Those of us working on the upcoming Agile Practice Guide have heard this chatter too, and we’re adding a dedicated section to the guide focused on this topic. Here are some of the initial patterns we’re seeing...


“Iterative” vs. “Incremental” vs. “Agile"

Project lifecycles live on a continuum, ranging from Plan-Driven on one end to Agile on the other end. To help us understand this continuum, let’s say two of the key aspects of agility are “Deliver Early and Often” and “Adapt to Change”. If we were to plot that on a two-dimensional graph, we would get something like this…

On the continuum from Plan-Driven approaches (lower-left) to Agile approaches (upper-right) there are different degrees of delivery (incremental) and degrees of change (iterative). Those techniques that achieve BOTH high degrees of delivery AND high degrees of adaptability are called “Agile”.


“Blended” versus “Hybrid”

But that’s just too simplistic. In the real world, we don’t just use one approach; we almost always combine different techniques together. To help us understand the different combinations, we’ve settled on some working definitions.


Blended Agile is the combination of two or more established agile methods, techniques, or frameworks.


That is,  adding some Kanban and wip limits to your Sprints would be a “Blended” approach.  Or maybe you want to “blend” an information radiator with your continuous delivery status. For many of agile practitioners, that’s easy to understand. We combine known adaptive-aggressive techniques to be better at what we do:


Blended = agile + agile = better agile.


But what about the rest of us who are mere mortals? What if we’re not able to use these various techniques just yet? What if there are either constraints or demands that require some non-agile elements to happen? Well, in those cases, you should consider the “Hybrid”:


Hybrid Agile is the combination of agile methods with other non-agile techniques


For example, a detailed requirements effort, followed by sprints of incremental delivery would be a “Hybrid Approach”. Likewise, frequent iterative prototyping of a design, followed by a single plan-driven implementation would be a “Hybrid Approach”. Here, the idea is to take a non-Agile approach and inject some Agile techniques to address a specific issue or opportunity:


Hybrid = non-Agile + Agile = something in between that makes sense


When should we use Hybrid approaches?

Just like anything else in the world, there is a right reason and a wrong reason to do something. To be clear, the wrong reason for mixing techniques together is to keep up with the Joneses. “Doing agile techniques” is not the goal. The goal is to deliver the right business outcome using the right techniques.

Here are two scenarios.

  1. Hybrid as Fit-For-Purpose: For projects that have a lower risk profile, use Plan-Driven approaches to look for lower costs. For higher risk projects, use Iterative techniques to repeat activities until issues are revealed and resolved. For projects needing aggressive delivery, Incremental techniques will deliver something sooner, to ensure customer engagement. Finally, in order to to navigate complex environments, Agile techniques may have a higher initial overhead, but it might be worth it for the overall outcomes. Each has their own strength. Mixing these together in the right way can fit your context better than just narrowly using only one of them.
  2. Hybrid as Transition-to-Agile: Many teams are not able to make the switch to Agile ways of working overnight. The larger the organization, the more move parts, the longer it will take to shift. If you’ve lived in a Plan-Driven world for several years, then agile methods will look and feel very different. As a result, your initial foray into the agile world will be a messy amalgamation of both.  That’s okay. You’re using specific techniques to move in a direction that you want to go to.

Every project has different needs. For those finding themselves in a mostly plan-driven environment, a hybrid approach can be a transition to more adaptability and delivery. For those already delivering and adapting aggressively, blending in some new techniques can raise your bar even higher.

Don’t simply declare “we’re Agile”; the reality is you’re almost always using some combination of different techniques already. Instead, a better strategy would be to stop and think which approaches would be the best for where we are, and what we want to achieve.

Posted by Jesse Fewell on: December 09, 2016 03:53 PM | Permalink

Comments (13)

Please login or join to subscribe to this item
Thanks for this article. High value, high relevance.

You're more than welcome, Andrew. Glad it was worth the read.

Is there an ETA for when the guide will be ready? Is it possible to get a draft copy?

Great article Jesse. Thanks for the clarification. This should help many people.

With all my due respect, there is a mistake when you write about life cycles (please sorry if I missunderstood). Agile is not a life cycle. With quality as a basement what you have is life cycle models (only two: predictive and adaptative), life cycle process based on those life cycle models (waterfall belongs to predictive for example and iterative belongs to adaptative for example) where you can apply modificators to those cycle models (incremental is a modificator you can use with waterfalll or iterative), you have methods based on those life cycle process (SCRUM is terative with modificator, SDLC is waterfall) and at the top of the pyramid you have tools (any type of tools) to support the methods. Agile, Lean, etc belongs to the basement (while some people still discuss if Agile is a qualty model or practice).

Thanks Jesse, great article!

@Demetrius & @Alaa, thank YOU for the positive words.

@CristopherHealy, the Guide is schedule for release in late August, early September 2017, in conjunction with the PMBOK 6th Edition

@Sergio you make a GREAT point. Agile is NOT a is a mindset that IMPACTS the project lifecycle.

The official definition of Agile is, which defines the Agile mindset with four values that can be paraphrased as: Empowerment, Delivery, Stakeholder Engagement, Continuous Improvement of every aspect of the project. The lifecycle gets a lot of attention, but it relates only to the agile value of Delivery.

Thanks for the comment

This is a nice article to help figure out what to call what we are using currently. Are teams are highly dispersed and our team members are not dedicated to the projects that we work on so we are shifting to a hybrid agile approach. We have found that even using 2 to 3 scrum type meetings a week has increased the velocity of our projects.

We still have a long way to go!

I meant "Our" Teams, not "Are" ....sorry for the typo.

A business has to be designed around whatever critical success factors are most important for the business and build an approach to achieve objective. To achieve that, the project execution approach should be adapted with right proportions of hybrid or blended agile (or as it fits)

Thanks for this article!

Please Login/Register to leave a comment.