Why Blended Agile Fails

I was introduced to Agile in 2003 and fell in love. I haven’t used it since. Not even close. Since this summer romance, I’ve been forced to use a blend. Like a watered down drink, it’s just not as impactful.

I’d used traditional waterfall software delivery lifecycle methodologies before that. I’d had great luck with JAD and RAD, but then Agile came along and got a lot of buzz. Word of mouth and a heavy PR push, and Agile gained a lot of traction. So much so that it elbowed RAD out of contention.

In the past almost twenty years, I’ve heard countless people defend that Agile is not set in stone and that it’s OK to take what works and modify it for a particular organisation or situation. This seems logical. We do that elsewhere. We have a recipe that works, but we know we can make it better by altering some ingredients. Perhaps we are just trying to make it healthier by swapping sugar for honey. Or we are exchanging the flour for a gluten-free or whole-grain variety.

If you’ve never done Agile, you shouldn’t be trying to blend it.

This is what’s happening in the baking scenario. You’ve made the cake and you know what to expect if you swap ingredients. With Blended Agile, I have never—let me repeat that—I have never met anyone who advocates blending Agile who has ever worked in a real Agile environment. This is like trying to swap ingredients without having mastered the original recipe. Even a seasoned baker is not likely to swap ingredients willy-nilly without having a grasp on the base recipe. Ratios change. Baking time changes. Consistency changes. Flavours mix differently. If you’ve never done Agile, you shouldn’t be trying to blend it.

But there’s more. Agile is not a recipe. I don’t mean to be the one to break it to you, but even if you have worked successfully in both, you can’t mix them. They are like oil and water. Even worse, it creates an anti-pattern. The path from Waterfall to Agile is not a straight line. It’s not a continuum. It’s what’s called a U-curve.

If we regard the relationship between Waterfall and Agile graphically on the X-axis and plot Outcome Efficacy on the Y-axis, we see Waterfall and Agile at approximately the same level. In reality, this efficacy depends on context. In some cases Waterfall will be more efficacious. In others, Agile should be preferred.

If you start at Waterfall on the left and move right slightly—blending small amounts of Agile, perhaps working iteratively—, the efficacy doesn’t suffer. Perhaps you’ve even managed a slight improvement.

If you start on the right at Agile and move slightly left, the result is similar. Perhaps you actually gain something beneficial to the entire system.

A more apt analogy might rather be to say you’ve mixed ammonia with bleach. It is not only distasteful, it’s toxic.

But if either strays too far toward the middle, overall efficacy diminishes. Necessarily. You’ve created an anti-pattern. In a nutshell, an anti-pattern is a counterintuitive outcome. You think that blending the best of these two methodologies will yield you even better outcomes. Instead, you’ve managed to mix vinegar with your coffee. A more apt analogy might rather be to say you’ve mixed ammonia with bleach. It is not only distasteful, it’s toxic.

Many people today have never seen a pure Waterfall project or a pure Agile project. They’ve been steeped in the blended world from the start. They’ve been fed the myth of blended Agile, and told that any inefficiencies stem from doing it wrong or that as bad as it is, it’s still better than the way it used to be. But the problem is with the system itself. The problem is thinking you can blend Waterfall and Agile in the first place. And these people can be excused. They don’t know any better and have been sold a bill of goods. Brute force always works, right? Brute force might work, but it’s hardly efficient.

Here’s my advice. If you have a repeatable process, choose Waterfall. Choose an iterative version, but choose Waterfall. If there are some configuration options, document them early and implement them at the appropriate time.

If you need a bespoke solution, choose a human-centred iterative solution, like RAD. If you want to document requirements as user stories instead of use cases, feel free. If you want to call your iterations sprints because it makes you feel better, have at it. If you want to name your product manager or associate product managers product owners, go for it. And you want to call your project manager a scrum master, no one’s stopping you. It’s what many places do today.

If you work in an enterprise environment, you almost definitely can’t do Agile without creating an anti-pattern.

If you work in an enterprise environment, you almost definitely can’t do Agile without creating an anti-pattern. It can’t be done. Mark my words. Just adopting a methodology that promises agility or has Agile in the name doesn’t make it Agile.

In the end, it’s important to remember that Agile is a software product development methodology. It is not a project management methodology. Adding project management to product development has a negative impact on output efficacy. If what you insist you need is the control that comes with project management oversight, then accept that it always comes at a cost.