Bimodal IT has lately become one of the hottest topics in the IT. In fact, if this is the first time you are hearing about Bimodal IT, you are more than a year late to the discussion.

There are lots of good resources describing what Bimodal IT is (E.g. this one, or this one) and likewise a plethora of flaming discussions why it is a good idea especially for digital or a bad one if not the worst.

I, on the other hand, see myself at the same distance to both parties. I believe, Bimodal IT is not a state you would be targeting nor a one you should avoid at all costs. Bimodal IT can be used as an interim model on the way to reaching IT nirvana.

IT organisations are large organisations consisting of numerous subunits which are constantly forced to change in all directions under the crossfire of new business requirements, changing market demands, emerging technologies, governance, risk and compliance concerns et al. It is therefore understandable, in fact inevitable, that each subunit of the organisation follows a different path, works with a different timetable and targets a different ideal state. In fact, I also find the similarity of the term Bimodal to Bipolar interesting, where Bipolar is used to describe a mental condition which is somewhat pertinent to what Bimodal states.

Bipolar Disorder is a form of major affective disorder, or mood disorder, defined by manic or hypomanic episodes (changes from one’s normal mood accompanied by high energy states).

Bimodal IT, in a nutshell, describes an IT organisation which organises itself under two modes. Mode 1 is the traditional IT organisation, where security, governance, compliance, and stability is the king and Mode 2 is the startup-like IT where innovation, experimentation, speed and agility is A1. Or, in a more informal way, Mode 1 is the guy who wears shirts and trousers to the office and works hard to send those financial figures to partners accurately and securely, whereas Mode 2 is the guy wearing t-shirts and jeans and works on a wearable tech for paying the beer with a brofist.

From the business perspective, Mode 1 is better suited for management of the organisation’s money whereas Mode 2 focuses on making even more money.

Surely Bimodal IT presents a formula to CIOs who are looking for ways to to enable agility and innovation while making sure business goes as usual, data is stored and shared securely, risks are handled properly, compliance is managed meticulously and so on. Bimodal IT tells CIOs to split IT into two sub-organisations and treat them differently. Basically, let Mode 2 be more free of the processes and methods Mode 1 has to follow and let Mode 1 be whatever it used to be.

At the outset, Bimodal IT looks like a way out for the CIOs, in reality it does not represent a stable IT organisation for multiple reasons:

  • Subtext: It is ineluctable that the subtext of Bimodal IT will read:  ”Mode 2, you are the cool kid and forefront of innovation, and Mode 1, you are now officially old school.” That is clearly an open call for tension between organisation units if not managed properly.
  • Mode 1, Mode 2,..Mode n: Most IT units are likely to be a mixture of modes and none of them would like to be tagged as not-that-agile or not-that-stable. There will always be in-between modes.
  • IT Bipolar Disorder: As one person cannot leave a healthy life with mood disorder, an IT organisation cannot survive with two modes, especially when there are strained relationships between the modes. It needs of all its subunits to work together towards the common goals.

After all, even if IT manages to work in two speeds, actual business cannot be delivered under distinct modes. For instance, a company cannot have a Mode 1 and Mode 2 type of sales processes. Customer experience must be consistent across all the channels and throughout the lifecycle of the relationship. A business needs all of its units to work in harmony and be agile and stable as necessary to enable innovation while increasing profits and maintaining its reputation in the market.

Bimodal Magic Cycle

In short, Bimodal IT is not a cure for an agile IT, but it is the diagnosis of the fact that some parts of your IT organisation are not agile enough, and when they are, they sacrifice on safety and accuracy.

Going back to what I said earlier, Bimodal IT is not an end state but an interim state on the way to Nirvana IT. It can help you identify which IT subunits need to change in what ways to become an agile yet stable IT unit. It can also serve as a map to flesh out agility and stability levels of IT subunits so you can investigate the options on how nonlinear, exploratory units can work with more traditional, linear ones.

It must also be noted that it is not always straightforward to avoid linearity and waterfall processes in some situations:

  • Bureaucratic Service Providers: Almost every IT organisation work with external service providers. Some service providers are sensitive on risk and might like to handle every simple request as a new project with statement of works and approvals etc, eventually causing large linear steps in project lifecycle.
  • Old School Technologies and Vendors: In some cases, legacy, non-agile-friendly technologies or traditional vendors can hold the teams back from being more responsive to changes with their lethargic product development cycles, sluggish support and perplexing licensing models.
  • Overutilised Shared Services: Shared services might be lacking the human power to meet desultory requirements coming from all directions and might prefer a waterfall approach in their response to sustain their resources.

However, in the grand scheme of things, the fundamental barrier to achieving IT agility is the IT organisation itself. It is

  • The culture it has cultivated over the years
  • The way it has structured its organisation hierarchy
  • The way of working organically developed throughout its lifecycle
  • The nature of relationships with business and other stakeholders (open vs defensive)

All these reveal the true medicine to achieving a stable and agile IT is a sincere, well-informed and determined change.

IT leaders must lead the organisation to change in an agile manner. Set long term target and transitional states and make the change a substantial theme to the everyday work.  They also have to maintain their tough-minded optimism as organisational change is certainly not a walk in the park.

The next vital step after acknowledging the existence of two or mode modes is to get these to work together efficiently and release the tension between the modes.

There are two prominent models in the industry:

Squadification

Squadification is a model developed at Spotify to enable agility while scaling up the organisation. It is based on the idea of self organising teams. Squadification introduces team structures such as squads, teams and chapters. Squads represent the smallest, autonomous team structure which is build around a common mission – as opposed to traditional team structures built around systems, business domains or common functions. Squads are a great opportunity for creating alliance between the modes around common ideas and goals (e.g. “let’s create the fastest, low-risk loan on-boarding process”.). Squads also provide an amicable atmosphere for people from different modes to appreciate their differences and the challenges they face. Most importantly, Squads allow the modes to innovate and get things done rapidly without the boundaries and restrictions put by the organisation culture and hierarchies.

Squadification also defines methods and structures for inter-dependency management and alignment to company’s higher strategic goals while empowering people to choose the methods and land on decisions easily.

Squadification

Check out these links if you want to learn more about Squadification:

Scaled Agile

IT leaders who would like to try a bit more closer-to-traditional-corporate, less-experimental models can also look into scaled agile methodologies. Bimodal IT points out the duration of change cycles as another difference between modes. In a mode 1 organisation cycle times are long where in mode 2 changes delivered in days or weeks. Scaled agile methodologies appreciate these differences and offer agile frameworks for aligning the change cycles in different layers.

Being the most known scaled agile methodology, SAFe® (Scaled Agile Framework) defines four different levels to deliver change along with the coordination processes between the levels. These four levels are Portfolio, Value Stream, Program, and Team. These levels and the coordination processes allows corporates to align  bigger transformation programs with strategy, budget and strategic architecture (Portfolio-level) and bigger transformations (Program-level) with smaller sprints (Team-level).  SAFe® also defines inter-level processes such as the architectural runway which helps identifying and managing the  dependencies between the modes incrementally.

Mode Resonation

Check out these links to find out more about scaled agile:

Photo by moonzig from Pixabay