Bimodal IT and Agile - flaw or opportunity?

Blog post
By Anders Larsson | 5 February 2018

Gartner has provided us with the Bimodal IT model, which gives us the opportunity to choose between waterfall and Agile. First, let us take a look at a brief definition.

Definition of BiModal IT

Software product development efforts or IT-related projects are classified into two modes. In short, if you're risk-averse and want reliable software and predictable projects, you should stick with traditional IT and be placed into Mode 1. Mode 2, on the other hand, is for you who adhere to the new-style Agile and other buzzword laden IT. Mode 1 keeps the lights on, while Mode 2 goes off and does all the new, fun and innovative stuff. So what's the problem with that?

Criticism from an Agile point of view

First of all, we might ask ourselves whether any “predictable” or “reliable” projects actually exist anymore, as questioned in the blog post written by Pamela Ashby on this common topic. I guess you could say that some projects are more predictable and reliable than others? Anyway, what the model actually says is that agility stands against reliability.

But wait, who said Agile isn’t reliable? And is waterfall really that reliable and predictable? Actually it has proven to be the other way around. Quality is built in from the beginning within an Agile process, and maintained through continous delivery. While within waterfall processes quality is often sacrificed until the end of the project, when in most cases this is too late.

”Never compromise quality” is for example a principle of DSDM / AgilePM. And quality is also addressed among the Agile Manifesto principles:

Agile Manifesto principle #9
“Continuous attention to technical excellence and good design enhances agility.”

Next thing that seems peculiar from an Agile point of view is the "thinking" metaphor of Sprinter vs. Marathon Runner. Actually the Sprinter metaphor has no relevance withing Agile. The name "Sprint" of a timeboxed development iteration in the Scrum framework might confuse us here. Agile requires long-term thinking and promotes sustainability, in fact rather like the Marathon Runner. Are the two modes really all about moving fast or slow? But who wants to constantly move in a slow pace? Regardless of mode, shouldn't we rather move forward in a constant sustainable pace?

Bimodal IT modes Who's moving within a sustainable pace?

Once again, lets refer to the original definition of Agile:

Agile Manifesto principle #8
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Based upon this reasoning you might question whether Gartner has understood what Agile really is about. Actually Mode 2 smells a lot like what once was called Rapid Application Development (RAD). Solutions to these kind of problems were what DSDM aimed to solve in the mid 90’s. Also, as pointed out, one of the founding principles behind the Agile Manifesto. And frankly speaking, it did not take long before the Agile community began to criticize the Bimodal IT model. Regardless of Gartner's misconception of Agile, you might ask yourself whether Mode 1 and traditional projects present the right solution where additional rigour may be needed?

Jason Bloomberg, the man behind the book Agile Architecture Revolution, and also a frequent columnist at Forbes, goes even further in his criticism. He calls Gartner’s Bimodal IT a recipe for disaster. Based on the fact that large enterprises have a lot of their challenges within legacy modernization, the Mode 2 modernization efforts might never take off without support from the slow-paced Mode 1 legacy maintenance team.

On the other hand, his fellow Forbes columnist Kurt Marko believes the Bimodal model is a bit misunderstood as well, and only considered harmful when oversimplified. The dichotomy of old and new, development and maintenance, and sustaining vs disruptive technologies, has been around since the dawn of IT, he says.

The Agile way - no matter what!

In the end it might boil down to sustaining versus disruptive technologies, and not really a battle between Agile and waterfall. There is a new disruptive market where demands for speed and adaptability are high. Which of course isn’t the case for all organisations. For instance, the Lean and Kanban communities do in a way criticize Agile coaches in driving organisational change and Agile transformations too hard. Statements like ”start where you are”, respect for people, continous improvement, and standardization are words of honor within Lean that fits better with the sustainability mode.

Predictability doesn’t really exist, but some businesses might perhaps be more predictable than others? And innovation and exploration activities also takes place in more traditional organisations. The fact is, both BAU and innovation activities exists within any organisation. Within the same organisation, or even within the same program or project, you might need to execute within those two modes. But you can’t really do BAU and innovation apart from each other. You have to innovate, improve and maintain your solutions continously.

The good thing is, there’s no reason for NOT being Agile regardless of what mode you’re in at the moment. And even better, you could use tools and practices within the Framework for Business Agility in doing so.



The material published in the Blog area of this website, is provided independently by our bloggers and any opinions expressed are those of the individuals and not necessarily of the Agile Business Consortium. The Agile Business Consortium does not accept any legal responsibility for any content or opinion published in the Blog area of this website.