Blended Agile is an Anti-pattern

In this segment, we’re going to get nostalgic. I posted my first-ever LinkedIn article in 2014. The topic was Agile methodology.

We weren’t the only company seeking regulatory approval, and we wanted to be first to market, so we didn’t have time for the overhead and up-front time sink of a typical waterfall project.

Minimum Viable Products

What this meant practically is that we had to have a core product ready at the moment the release was authorised, so the goal of the team was to create a Minimum Viable Product, otherwise known as an MVP and to iterate as many feature-function enhancements as we could manage until its release was approved.

But at any given time, the product had to be releasable. The product was a hosted solution, and we knew we’d have to be making enhancements often, as we’d be reacting to user feedback once the product was available. Our expectations were that we’d be getting approval in December or in early January, so extended Christmas-season holiday breaks were cancelled. We needed to be battle-ready.

We were at the mercy of the regulatory agency. January became February. March became April. We didn’t receive approval until May. But we were ready. We had not only created the core product, we had made over half a dozen enhancement cycles and had many more on queue.

The day after we got approval, the product released, and the marketing campaign blitz was underway. As it turned out, the product was well-received. The revenue we achieved was almost triple what we had anticipated, and we continued to regularly integrate the customer feedback we expected into our release cycle. This is how Agile is done.

What happened?

So, what’s been my experience since? Let’s find out.

Reflecting on the LinkedIn article, the central theme was to say that the versions of Agile implemented in most large enterprises, are not agile at all. Moreover, this particular flavour of Agile is an anti-pattern. This is still true today. Per Wikipedia, an anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. Back then, we called it different things. Blended Agile, Wagile, water-scrum-fall, and so on. It’s gotten worse. Now organisations that want to claim to be Agile peddle enterprise agile. One flavour of this is SAFe, Scaled Agile Framework for the enterprise. But, make no mistake. This is anything but agile.

No one can control how someone chooses to adopt or use a term, so those who want to falsely claim to be Agile are in their right, but their intent is to dupe the unwary. And their defence is that ‘we’ve adopted the principles’ or whatever. And Agile is just a loose framework. Except if you lose most of what makes Agile agile, perhaps you should call it something different.

You can call a cat a dog. No law prevents this, but the communication value is greatly diminished—except if you are selling dogs to people who don’t know the difference. And make no mistake, as far as these enterprise versions of Agile go, they are dogs.

Allowing me to vent for a few moments more, this is pure and simple jumping on the bandwagon by disingenuous actors, who hide behind the fact that most agile buyers have never seen Agile in practice, so they don’t know any better. They rely on the fact that most enterprise financial governance won’t allow agile, but they can get partial credit for adopting the agile brand. And this isn’t a case of perfection being the enemy of the good. This is you defending bringing a football to a cricket match. It’s not merely a little off. It’s orders of magnitude off. This choice increases your organisation’s risk exposure. Blended Agile solutions are anti-patterns.

12 Steps to Recovery

Remain with me for a few minutes more, as I stroll down memory lane for the duration of this segment.

I’m considering starting a 12-step program. Agile Anonymous. As usual, the first step is to admit there’s a problem: “I’m not using Agile.”

This point of view presumes that you have some familiarity with Agile and software development lifecycle management. Agile is a flexible methodology or framework, and it can be applied successfully in many situations, but it is more likely to fail than not in an enterprise setting.

Can Agile yield successful program outcomes in an enterprise setting? Undoubtedly, it can. The problem is that for Agile to be effective, one needs to have end to end commitment—from the business, as customer proxies, to delivery, via development resources. As a consultant with about twenty years of Agile experience, I’ve not seen this depth of commitment on any enterprise engagement, so perhaps this is only anecdotal.

To be fair, as I’ve already conveyed, I’ve seen Agile work in start-up environments, in situations where organisational weight doesn’t adversely affect outcomes. But this is not the situation for large public enterprises. They have weight. Mass. And they are encumbered by stricter fiduciary responsibilities. This shackles them. It hobbles them.

In the past decade or so, the most common defence I’ve heard is that “We do Agile in IT.” The company isn’t agile as a whole, but we’re agile in IT.

I’ll translate that for the uninitiated. “We don’t do Agile”. We adopt homoeopathic amounts of Agile, and we use some of the terminology. Perhaps even most of it. And we love the rituals—stand-up meetings where we sit. Retrospectives, where we vent and hope that catharsis will make the next sprint better than the last.

We’ve got product owners with no ownership, scrum masters whose mastery is more often project management and administration, and a team of dedicated functional experts. Self-forming teams are for losers, so we’ll tell you how to form.

But, hey, we’ve taken some training courses, read some material, and hired some Agile coaches. And you know what? We still don’t do Agile.” Management doesn’t get it, but they read reports and articles that claim their competitors are doing Agile. (Spoiler alert: They aren’t.)

Agile Bootcamp

Here’s another sidebar. I was working with a client who was just discovering Agile. Many of their staff had just returned from Agile bootcamp training. Within days, the attendees began populating their LinkedIn profiles with a new skill. Agile. Employees endorsed each other’s new-found Agile mastery, which created a positive feedback loop. But there was more noise than signal. The reinforcement of the coworkers gave the appearance that these people had been endorsed by other people also having agile skills. Except they didn’t. Where’s the anti-vote button when you need it? And this company is no more agile half a decade forward than it was prior to this training. I guess it’s the thought that counts, right?

Enterprise Agile

Okay. One attempt to rescue enterprise Agile is known as water scrum fall, a situation that blends elements of SDLC Waterfall and Agile. From this configuration, the expectation is to get the best of both worlds. We hope to get the planning benefits of waterfall, and the nimbleness and adaptation of Agile. It’s a win-win situation, right? And we’re just going to get the best of both worlds. What could possibly go wrong.

Here’s what can go wrong. We’ve created an anti-pattern. We’ve failed to grasp how these two methodologies interact. It’s a fallacy to believe that one can synergistically combine the best of Waterfall and Agile. Instead of yielding alchemical synergies, combining these frameworks yields the worst of both worlds. As depicted graphically on the BarcVox blog post for this segment, we can see that what was beneficial for Waterfall, from the perspective of Waterfall, becomes detrimental to Agile. And the primary benefits of Agile get left on the table. To add insult to injury, merging these methodologies creates additional complexity risk.

The current defence of water-scrum-fall, or my preferred term, water-scrum-fail, when I am having an off day, is the result of groupthink and a cognitive bias known as escalating commitment. But I am here to inform you, the emperor has no clothes. In any case, many step up to be Agile apologists.

But it’s good to remember Upton Sinclair’s statement,

« It’s difficult to get a man to understand something when his salary depends on him not understanding it. »

Upton Sinclair

Excuse Upton for not including women and transgenders in his quip.

Be wary of false witnesses

So, not to kiss and tell, but I had the pleasure of working with several top companies that were categorised as Agile shops (in some shape or form) in response to some Forrester Research surveys. These companies were claiming to be doing Agile—but it was not apparent. When I spoke to the Forrester analyst who published the piece, he told me that the surveys were self-reported by each company, so garbage in garbage out. The problem is that executives and managers would read and hear about these other notable companies using Agile, and they were being pressured to hop on the Agile bandwagon. If they adopted one of these knock-off flavours, one would be none the wiser.

One last client story before I end this segment. After spending a week with one client, I had a talk with a director. I told her that there was no evidence of agile anywhere I had seen. I suggested that they stop using the term because it was confusing its employees.

This company was having a lot of difficulty retaining talent. Some of the reason was the location of their offices, as there were a lot of more primo places to work, so the talented people were attracted to these better places, places that were a tad more hip. This place was more of a stepping stone, and the more competent people would leave if they got offers from these other opportunities. But there was more than this.

They would advertise that they were among other things, an Agile shop. But, if a person with agile experience or someone who had read a book on the subject, was hired into the company, it would be immediately apparent that this company was all talk. My advice was to either stop pretending to be Agile. Just communicate how you operate, and you’ll get the people who want to operate in that fashion. Or do real agile. Even some of that anti-pattern agile. But stop doing straight-up waterfall and calling it Agile.

The response was one for the ages. « If we tell our staff they aren’t doing agile, they’d probably leave. They really like paired programming. »

So instead of being honest and saying, ‘We’re a paired-programming Waterfall shop’, they chose to say they were an Agile shop. And they just did waterfall instead, adopted some of the terminology, and pulled a classic bait and switch.