You Can Reconcile Bimodal IT with DevOps

Source – informationweek.com

Is it speed versus quality, or speed and quality?

I recently gave a talk comparing DevOps with Gartner’s Bimodal IT approach, which is somewhat controversial. I didn’t bash Bimodal IT, instead I demonstrated how to reconcile the modes Gartner proposes organizations take based on application types, with the spirit behind DevOps. To begin, I made my own controversial statement:

DevOps is a farce!

That’s right, I said this to all of the DevOps enthusiasts nice enough to come to my presentation. As you can imagine, in return I was presented with a roomful of blank stares. I played along, mocking some of the most important aspects of agile development and DevOps practices. For example:

• The development organization collaborates with users. “Are you kidding me?” I quipped. “You should never let your developers talk to actual paying customers!”
• Developers and your IT staff should collaborate. “That will never work! They should only go through formal channels of communication, such as a ticketing system,” I explained.
• Operations staff should be part of release planning. “All they’ll do is get in the way and slow things down. What do they know about software development?”
• Customer service should take part in releases so they know about new features before users do. “What good will that do? They just answer the phones.”
• You should adopt a test-first practice. For this one, all I did was laugh out loud for an exaggerated amount of time.

Obviously, I was joking, and no offense is intended for anyone in these positions.

My intent was to make two strong points: First, this is the way it really was for many organizations prior to the agile movement (or still is). This is a shame because I can say from experience that some of the best design ideas have come from IT staff I’ve worked with. After all, they understand what it takes to keep systems running. Along those lines, I’ve worked with customer service employees who had great ideas for new product features, because they were directly in touch with both the application and its users.

As for my second point, in many ways a Bimodal IT approach proposes putting the barriers back up between the groups for some projects. Let me explain.

Bimodal IT in a nutshell

With Bimodal IT, the assumptions are:

• That agile and DevOps are meant for new projects and startups that are nimble by nature
• DevOps is risky for legacy applications and established organizations
• It’s really a choice of speed (with DevOps) or quality (based on traditional approaches)
• You need to maintain these two separate modes of operation based on application

Mode 1 software development and release involves a predictable process, with gradual and eventual change made in well-understood ways. Bimodal suggests that this is a slower-moving approach you take for stable, legacy applications that are core to your business. Contrast this with Mode 2, which is exploratory, allowing you to take chances on solving problems with new, nimbler, yet more risky approaches. Bimodal suggests that this is where innovation happens, with a more modern approach to development, and a fast-paced environment.

Bimodal ups and downs

There are some positives to this approach. For example, Bimodal encourages pilot projects be started around newer areas of technology, with recent and past examples being cloud, the NoSQL movement, mobile application development, even the move to the Web and the PC years ago. In my experience, this is a good approach for many organizations. However, there are more negatives associated with Bimodal, in my opinion.

First, Bimodal requires different development processes, tools, and people, compared with DevOps. Next, it’s confusing to choose which applications are Mode 1, and which are Mode 2. Effectively, you need to ask which applications and customers deserve more attention? More innovation? Higher quality? More support? If you do make a distinction, do you tell your Mode 1 application users that they’re not getting newer features as quickly as those using your newer applications? Likewise, do you tell your Mode 2 application users that they can expect lower quality because the approach for them involves more experimentation and greater risk?

In my experience, backed by statistics, you don’t need to make this tradeoff, and these unfair decisions don’t need to be made. Studies by both Puppet Labs and InformationWeek (State of DevOps 2017) have shown that high-performing organizations — those with revenue generating products and happy users — regularly deliver both speed and quality, simultaneously.

Additionally, according DevOps experts such Gene Kim, 60% of transformation success stories involve legacy (what some call brownfield) applications. You can argue that Bimodal is unnecessary given that, in Kim’s and others’ experiences, a proper DevOps practice reduces errors, increases stability, and reduces failure and lead times.

Besides, most applications — including older ones — have so many interdependencies with other systems (new and old) that it’s hard to label one as strictly Mode 1 or Mode 2. For example, take modern web and mobile airline reservation and ticketing applications. While mobile application developers typically use an agile development and release cycle (based on update frequency), for airline apps, they’re likely tied into legacy and complex transactional airline reservation systems in the back end. Changes are likely required on either side to accommodate the other.

The Bimodal focus shift

As promised, here are some methods to reconcile Bimodal intent with DevOps results:

Focus on people instead of applications: Every organization has people who are more open to new approaches, regardless of application. Choosing an application for Mode 1 or 2 locks that application and its people into that mode, which is counter-productive. Choose people for a DevOps practice who are more likely to create success, then use this to build a level of confidence across your organization and share what’s learned.

Increase collaboration and feedback loops: Regardless of application, most organizations need more internal communication, and communication with actual users is often welcome on both sides. This helps regardless of application type.

Break down silos: Don’t create or encourage them. Although some people don’t like change, they don’t want to be in a dead-end job either. Offer them new roles and responsibilities that they feel comfortable with.

Embrace shadow IT: Some of the best innovation has happened this way, including the PC, web, mobile applications, and the cloud. Consider why groups undertake shadow IT and fix the problems.

Don’t focus on, expect, or enforce reduced schedules: Don’t think of DevOps as being “too fast” for legacy application. Focus on speed to value, not release cycles. Deploy the most important and requested changes sooner, in smaller release sizes (i.e. fewer enhancements per release).

Remember that DevOps is a misnomer: Expand it beyond developers and operations, to include quality assurance, customer service, business staff, and executive leadership if possible.

Conclusion

There’s room to combine the intent of Bimodal (stability, safety, recognition of differences in applications and people) with the benefits of DevOps. Remember that innovation can, and should, happen everywhere, regardless of application age. This inclusive approach avoids the risks of Bimodal (i.e. siloes, adversarial relationships within your organization, and lack of change) while providing more structure to an agile and DevOps practice. The result will be reduced risk, increased agility, and expanded customer focus that turns liabilities into competitive advantage. Make sure you use tools and processes that include truthful measurements to prove it.