Bimodal IT: Definition, Implications, and Dangers

What Is Bimodal IT?

These days, we commonly have two modes for developing and releasing software. Mode 1 is rigid and predictable but safe. Mode 2 is agile and fast but risky. Releasing software on these two paths requires special handling. This situation is called “bimodal IT,” and it’s common in today’s enterprises.

Let’s turn to Gartner for a definition of bimodal:

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.

Now let’s focus our attention on the two modes for software development specific to bimodal IT.

Mode 1 Is Predictable

The current mode, Mode 1, is optimized for predictability and well-defined areas. When doing software development using Mode 1, one needs a clear understanding of the requirements up front, as Mode 1 aims to deliver predictable and precise results. Many highly regulated industries rely on Mode 1 software development methodologies, such as waterfall or spiral. Systems supporting the finance, defense, and pharmaceutical industries operate in Mode 1 for most system development.

Mode 2 Handles Uncertainty

Mode 2 development is exploratory. It 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 the 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. This approach introduces additional risk and uncertainty, but it provides a quicker time to market.

Bimodal IT Implications

Successful bimodal IT implementations involve two seemingly conflicting concepts: separation and integration. To be more specific, I’m talking about the separation of resources and the integration of results. Software development resources include human (i.e., software development teams) as well as hardware (i.e., servers and Cloud resources). The results are the software deliverables.

1. Separate 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 by mode in order to allow your developers to fully focus.

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 the timelines and expectations. And handle any organizational changes carefully, allowing people time to digest them.

2. Separate Codebases

Codebase separation naturally follows team separation. 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.

3. Separate Schedules

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 and timelines allows the two software development modes to work independently toward accomplishing their common goal—releasing meaningful software.

4. Integrated Results

After separating your resources you can focus on integration at the release level. Once the Mode 1 system can accomplish A, and the Mode 2 system can accomplish B, you will integrate the results.

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. And, if you need help integrating release management best practices, consider partnering with Plutora.

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 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 A by entering data B and getting results 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. Otherwise, you should include people on your team who understand your users and your market very well.

Bimodal IT Dangers and Solutions

Anything that changes the existing process brings with it some risk and, for a lack of a better term, a mess. However, bimodal IT describes many organizations, especially in highly regulated industries such as finance, government, and medicine. These industries must deliver software that is always compliant with a myriad of standards, policies, and regulations. They cannot afford a “we’ll fix it after we release it” attitude. Instead, every release must be compliant and secure.

Human Dangers

As discussed above, implementing bimodal IT involves separating your development teams. While this is easy to talk about in a meeting. It’s more difficult to carry out in real life. The first danger comes up when choosing the members of your mode teams. Engineers who are left working on Mode 1 products often feel left out—like they’re not good enough to be placed on the company’s new projects.

In the mind of a manager, both mode teams deliver important value to the company. Therefore, how you present these organizational changes to the development team is very important. I haven’t found a good substitute for simply talking face-to-face with each team member when making such large changes. Suggestions such as “everyone can rotate from team to team to get exposure” typically don’t work well in practice. So don’t promise to implement something you know won’t work.

Testing Dangers

The development rhythm differs drastically from Mode 1 to Mode 2, so testing environments should accommodate this reality. When you must integrate deliverables from Mode 1 and Mode 2 into a single product, it’s crucial for your bimodal IT development that you have an integration testing environment. In addition to separate testing environments for each mode team, an integration testing environment will add the necessary quality assurance before changes are rolled out to your customers. And the more regulated your industry, the more crucial it becomes to add an integration testing environment.

What do I mean? When creating two development teams, it’s natural to have different test environments for each team’s deliverables. However, when two deliverables—or more—need to interact with each other and produce consistent results, then adding a separate testing environment for the integration of these different deliverables is also crucial to your teams’ success. We call this the integration test environment.

This separate testing environment must be concerned only with running the entire software product with deliverables from both teams. It should be as close as possible to what your customers are using. It’s the ideal environment for testing overarching user stories that touch points in deliverables from both development teams.

Requirement Scope

One of the difficult things in software development is creating a clear understanding about what it means to be “done.” When do you call a software requirement “complete”? Releasing software in a bimodal mode requires that you precisely allocate your requirements to the correct scope. Developing software bimodally demands that you create requirements you can allocate clearly to each team. For those user stories that span deliverables from both teams, you will find requirements that you can allocate only to the integration test environment. This means that while each team has their own requirements derived from an overarching user story, the entire story cannot be closed until it’s been tested in the integration testing environment.

Focus on the Big Wins

Bimodal IT describes the changes that might bring a mess into your software development organization. Therefore, you must pursue those big wins that attracted you when you first considered bimodal IT, and then use this mixed methodology to your advantage. Focus on delivering fast testing, agile product validation, and a quick time to market. Address the messy parts of bimodal IT through genuine communication and paying attention to the people you work with. And, finally, doing resource separation well and executing the integration of deliverables will ensure that you move your IT enterprise forward by making the most of both modes of software development.