Why We Don’t Need the Hybrid Agile Label

In my several years helping organizations adopt Agile, I’ve seen the label “Hybrid Agile” pop up frequently. It seems to be used most frequently in organizations whose IT department starts to use stand-ups and sprints but does upfront deep requirements dives without a rapid feedback cycle and waits six months to a year before releasing anything.

I usually took the use of the label Hybrid Agile to mean that the organization had enough support to say it was doing Agile, but didn’t really understand what adopting an Agile mindset meant. I figured once organizations got a grasp on the Agile mindset the hybrid modifier to the Agile adjective would go away.

It hasn’t.

Spreading the use of the label “Hybrid Agile” (or “Blended Agile” for that matter) is unfortunate, and a sign of a bigger anti-pattern in the community.

Hybrid Can Become a Cop Out

I’m probably overly influenced by contexts where I have seen the label used before. Those contexts are organizations that limit Agile adoption to IT, and specifically to the development process. Those organizations miss out on the true benefits of adopting an Agile mindset such as delivering only things that lead to the right outcome, and rapid feedback and learning through cross-functional involvement.

In these organizations, development teams practice some of the techniques because that is what the “methodology says to do,” not because everyone truly understands why those practices make sense.  The people who most often refer to it as “Hybrid Agile” do so almost as an excuse, as if they recognize that their organization hadn’t really adopted an Agile mindset, and there was so much more they could do.

When you make Hybrid Agile (a combination of two adjectives) an actual thing, you take a transitional state and make it an industry-recognized (and one could say permitted) permanent state of being.  You give permission for organizations to aspire to stop halfway, potentially unaware of the risks they run by not understanding the deeper “why” of using certain practices in combination, and the need to continuously reflect and adapt.

I’ve worked with large financial services organizations and large product companies. I realize these types of organizations cannot flip a switch and have an environment where folks live the Agile mindset instead of just following a set of practices. Organizations may temporarily exist in a state that looks a lot like what will be described as Hybrid Agile.  But anyone in that state should not be satisfied about staying there.

Hybrid Agile is Just Another Label

I wish we didn’t have to call the stuff we do by a label.  But I’m also not too naive to know why we do it.  We need to call it something so we can sell it.

I don’t mean sell just in terms of commercial activity – though that is how these things end up.  You create a label so you can refer to a new idea with a crisp simple phrase that people understand.

Except that label becomes, in some sense, a model of the idea.  People begin to form their own ideas of what that concept is, and if there appears to be a way to profit from selling that idea, people do that as well.  What gets sold under that label very rarely reflects what the original concept was because the people selling learned about it in a game of telephone from the people who originally created it.

That is what happened to Agile.  That is what is happening to Lean. That is what will happen to whatever is the “Next Big Thing.”

The other thing that labels do, especially those around product development approaches, is give people something to promote. I’ve observed, but have not proven scientifically, that the louder an organization proclaims that they “are Agile” the more likely they are use the practices but not operate with an Agile mindset.

“Hybrid” Is Unnecessary

The post What is Hybrid Agile Anyway? describes Hybrid Agile as “the combination of Agile methods with other non-Agile techniques…” Every effort I’ve worked on since I’ve lived the Agile mindset would be described as Hybrid Agile by that definition.

The existence of the label Hybrid Agile presumes that Agile itself is defined as a specific set of practices. To put it bluntly:  “Agile is Scrum.”

Agile is a mindset, initially identified by the values and principles in the Agile Manifesto and refined since then as people applied those values and practices in real life situations and learned from the experience. A key part of that mindset (not explicitly expressed in the Agile Manifesto but one of the later clarifications) is to consider context.

Think about the environment in which you work and the people with whom you are working. Do what makes sense in that situation.  Learn from your experiences and adjust. In some cases what makes sense in your situation is to use a technique or two that doesn’t show up in one of the popular frameworks.

As long as you know why you are doing it and what risks you are addressing, go for it. There doesn’t need to be a label to describe that, there is already a word for it:  effectiveness.

Consider Context, Deliver Value, and Learn Frequently. Who Cares What You Call It.

I should be clear that the post I mentioned above does not suggest that people stop at Hybrid Agile.  It mentions two cases when what it refers to as Hybrid Agile is appropriate:  1) Fit for Purpose (i.e. consider context) and 2) As an interim step.  I agree with that premise.

I disagree with the need to stick a label on it. Not because of what the post says about the term, but what people who don’t consider what the post is really saying will do with that label.  It gives license for people to use some of the easier-to-adopt practices, proclaim success in their journey toward “Hybrid Agile” and still deliver the wrong thing to their customers. Or deliver nothing at all.

What do you think? Do we need a label called Hybrid Agile? Do we need to label any of this? Leave your thoughts in the comments.

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They may not represent the opinion or policy of Agile Alliance.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
Kent McDonald

Kent McDonald

Kent J McDonald writes about and practices software product management. He has IT and product development experience in a variety of industries including financial services, health insurance, nonprofit, and automotive. Kent currently practices his craft for a variety of organizations and provides just in time resources for product owners and business analysts at KBP.media and Product Collective. When not writing or product managing, Kent is his family’s #ubersherpa, listens to jazz and podcasts (but not…

Recent Agile Alliance Blog Posts

Meet the Agile2024 Program Team – Reese Schmit
Agile2024 is set for July 22-26 in Dallas! Behind every successful conference lies a team of dedicated individuals who work tirelessly to curate an unforgettable experience. We're going to share a short Q&A with each of those people here – this time with Reese Schmit.
Meet the Agile2024 Program Team – Reese Schmit
Agile2024 is set for July 22-26 in Dallas! Behind every successful conference lies a team of dedicated individuals who work tirelessly to curate an unforgettable experience. We're going to share a short Q&A with each of those people here – this time with Reese Schmit.

Post your comments or questions

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now