Bimodal Explained

*From a Release Management Perspective

“The Hare and the Tortoise” is Aesop’s most famous fable. In it, we find two characters: one fast (the hare), and one slow (the tortoise). They run a race against each other, both hoping to get to the finish line first. However, they run in different ways.

The super confident and super fast hare is all over the place, bragging and taking naps along the way. The tortoise, on the other hand, is steady, predictable, and persistent, even though he’s slow. In the end, the slow, persistent tortoise wins the race. But the fast hare shows us that even in a race, speed is not the only important factor.

Oftentimes in software development, we have two modes for releasing software. Mode 1 is rigid, predictable, and safe; Mode 2 is agile, fast, and risky. While it’s certainly not a race between the two, releasing software on these two different paths requires special handling. This situation is called bimodal IT, and it’s common in today’s enterprises.

Gartner defines bimodal IT like this:

Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability.

In this article, we’ll explore bimodal IT from a release management perspective and see how to make it work for your organization.

Mode 1 Is Safe and Predictable

Mode 1 isn’t bad. It’s neither obsolete nor unnecessarily slow. This mode is optimized for predictability and well-defined areas. It focuses on building on what is known and maybe renovating a legacy IT environment into a more modern state.

Mode 1 software development and release requires a clear understanding of the requirements up front, as it aims to deliver predictable and precise results.

Many highly regulated industries rely on Mode 1 software release methodologies, like waterfall and iterative. Systems supporting the financial, defense, and pharmaceutical industries operate in Mode 1 for most system development. Why? Because Mode 2 introduces new risks and doesn’t guarantee predictable results.

Mode 2 Is Agile and Riskier

Mode 2 is neither the only option nor is it magically fast. It is, however, exploratory and allows experimenting to solve new problems. It’s also optimized for areas of uncertainty. These initiatives often begin with a hypothesis that’s tested quickly. When test results are good, they’re implemented in short iterations.

Mode 2 is called agile because it allows for software requirements to change as the software development progresses. It’s a more fluid process that can respond quickly to pressures from the market and development efforts.

Many times, Mode 2 software development releases include functionality that’s based on a particular theory that isn’t fully defined. This means that validating and testing the requirements is passed on to the user. This approach introduces additional risk and uncertainty, but it provides a quicker time to market.

Now that we understand what bimodal software release is, let’s take a look at some common scenarios that exist in bimodal organizations.

Bimodal Scenarios

Many organizations operate using a Model 1 software development and release model when development must be steady and predictable. This is especially true in highly regulated industries like defense, pharmaceutical, and financial, which require clearly defined requirements at the beginning.

However, your organization may decide to add Mode 2 software development to explore and integrate new technologies into your Mode 1 product. Another possible reason for Mode 2 operations is to eventually replace an existing Mode 1 product with one that uses new technologies.

In these two scenarios, you’re mixing both modes of software development and release in order to move your organization further. So let’s take a look at how we can start a bimodal software development operation.

Clearly Define Objectives and Expectations

Before adding a new mode to your organization, you must clearly define the objectives. Everyone needs to know what the organization is trying to achieve.

Let’s say your organization has been working in Mode 1 (slower and predictable) for a while, and you need to add Mode 2 (faster and more agile) to explore new technologies. Here’s where you need to spend some time: Why do you need this new technology? Do you want to integrate it into the Mode 1 product you’ve been selling? Do you want to create a new product that will eventually replace the existing product? Or do you want to offer both products to your customers?

Certainly, time and business climate changes will also change your objectives. Therefore, clear communication is very important every time such changes happen because they will affect people’s daily work habits. Sharing the main development metrics you look for will go a long way toward making things clear. Having a unified place to track and share release details will also bring your development efforts together.

The keywords for making bimodal software delivery work are separation and integration. These may seem like opposites but bear with me as I make my point. In order to make bimodal software releases work, we must talk about separating resources and integrating results.

Separate Development Teams

Changing context is one of the most difficult things for software developers to do. It takes a while to switch your mindset from one project to another. So it’s almost impossible to have one person working in both modes simultaneously. Therefore, you should divide the development teams to allow your developers to focus easily.

This doesn’t mean you can’t have a transition period during which people on the new team continue helping your initial team work on existing products. However, you must clearly explain timelines and expectations. And handle any organizational changes carefully, allowing people time to digest them.

Separate Codebases and Timelines

Codebase separation naturally follows team separation. And this step is necessary because the two modes involve different testing and software release cadences. Separating software codebases for Mode 1 and Mode 2 products allows your development teams to operate independently. And creating separate code repositories is an easy way to create different workflows.

Obviously, time is a crucial resource. So it goes without saying that separate teams require separate timelines. You must allocate time differently to Mode 1 and Mode 2 releases. With Mode 1, predictability and risk mitigation drive the release process, whereas quickness to market and gathering feedback drive it for Mode 2.

Separating your resources allows the two software development modes to work independently toward accomplishing their common goal: releasing meaningful software. And then you can focus on integration at the release level. Once the Mode 1 system can accomplish X, and the Mode 2 system can accomplish Y, you integrate the results, X and Y, in this specific way.

Let’s talk about integrating bimodal software releases.

Integrate Releases

The most complicated bimodal scenario is when Mode 2 releases deliver new functionality for your existing Mode 1 products. As we focus on this specific scenario, let’s zoom in on release management.

When operating bimodally, you must focus on planning detailed features for each release. This is the only way to plan for integration between the releases of two different modes of software. So once you have software development running in two modes, release management becomes your focus.

How do you determine which features go into each release for each mode? This is the million-dollar question in every software development project.

Before starting Mode 2 releases, you must be able to envision the final product with the new functionality working in your existing Mode 1 product. How does your improved Mode 1 product look when you integrate Mode 2 functionality? What will your users be able to achieve? Answering questions like these will give you a clear vision of the finish line. Or at least the first finish line you have to cross with both Mode 1 and Mode 2 release models.

When you focus on the releases produced in both modes, clarity comes along. So developing user stories that focus on integrating features will help you plan your releases.

A release-focused user story might look like this: “The user will be able to accomplish X by entering data Y and getting results Z. The user can use Z results for accomplishing goals A, B, and C.” You must ensure, however, that these requirements are end-state requirements and not development details. This kind of thinking requires that you understand your users. Or you should include people on your team who understand your users and your market very well.

Bring Both Modes to the Finish Line

You must never portray the two modes and the teams that support them as being in a race with each other. You need both software release modes to move your enterprise systems forward. So to ensure that your bimodal software development doesn’t become a fable, remember that your organization only races against time, budget, and its competitors—not each other.

This post was written by Vlad Georgescu. Vlad is senior system architect and full-stack enterprise software developer with almost two decades of experience in the development lifecycle. He also has experience as a SCRUM master, agile coach, and team leader. On the communications front, Vlad is also effective: he’s created online communities and worked on social media marketing strategies.

Relevant Articles