Bimodal IT isn't anything to aspire to

Bimodal IT is a term created by analysis form Gartner, to describe an increasingly common pattern in enterprise development. It's where you have one part of the organisation working in a very traditional, governance-focused manner using lots of process charts, documents and explicit signoff, and one part working in a more agile way with frequent release cycles and less of the paperwork for the sake of it.

It's commonplace, and I think it's a good piece of analysis by Gartner to identify this and give it a name. Where I disagree is this being sold as a solution. Bimodal IT is not anything to aspire to. It's the disease, not the cure.

Where the problem lies

The odd thing about bimodal organisations is most of them don't want to be bimodal at all. Maybe they pay lip service to it but that's not the feeling deep down, encoded in the way people act and the goals they strive for. What they really want is comfort and familiarity: to work entirely in the same old top-down, heavily controlled style they're used to... but market forces demand that some things are done faster and more responsively than such structures allow. That's what I see time and again with bimodal IT structures: they boil down to, "agile where the competition forces us to be".

What you're getting is a resigned acceptance that the market is destroying plodding, process-bound companies who fail to listen to their customers. But there's no real desire to be something better; only a weary trudge along the bare minimum required to survive. These are companies who approach agile delivery with the same enthusiasm as a teenager taking out the bins. That's the problem I have with bimodal IT being sold as a packaged solution; the companies doing it are not aspirational targets. It's a philosophy of, "let's be inefficient where we can still get away with it". That's no solution at all - it's just a way to feel comfortable about your problems.

Operational Agility

I think this all comes down to the age-old Agile development trouble: it's not a trendy word for flying by the seat of your pants, but too many organisations think it is. The result is that departments tasked with operational stability end up rightfully terrified of running on the same arbitrary, undocumented and guesswork-based methodology that their pants-seat development teams employ.

This is a shame, because it's an opportunity lost. If there's one department that could benefit from an agile process done well, it's operations. Imagine an ops team who know exactly what the top priority is, know what the progress of everything is, and scrum together to get things completed rather than having that nightmare service desk with 1000 tickets awaiting feedback. A team that strives every day to make things better in some way than they were the day before. A team focused on delivery of working systems.

Bimodal IT says this is too good for your operations team, even if your developers can do it. Bimodal IT says operations should concentrate on following process (even if the process is stupid and harmful) and doing things just as badly as they were done yesterday. Prioritising, measuring progress, understanding what your customers liked and didn't like - that's only for the people who make us money. Ops is a cost centre; why should they get the time, effort and new hires required to create a collaborative and enjoyable environment?

The curse of DevOps

There's something people miss when hailing bimodal IT as an easy silver bullet to save them spending effort on improving the lives of their operational teams. It's that developing new products and running operations are not isolated activities. It doesn't matter whether you follow Waterfall, Scrum or alien orders to create software - that software needs to run somewhere. In the case of the web, that means boxes, firewalls, load balancers and networks: classic operational territory.

What you see in bimodal organisations is that operations (in the "slow but stable" world) are unable to support the frequent delivery cycles of development (in the "agile" world). Teams get frustrated at the large amount of waste building up at the border between modes, and if they're a good agile team they do what comes naturally: eliminate that waste. This is where you start to see development teams who operate their own hardware and infrastructure. The operations team gets doubly screwed by the bimodal pattern; day-to-day they're increasingly relegated to patching desktops and replacing broken mice, but you can bet when a developer makes a mistake in their cloud setup ops will suddenly be on the hook for the system failure.

Effort, not silver bullets

I always seem to come back to this theme when talking about agile organisations: real transformation takes great effort but returns great reward. In other words: no pain, no gain. It takes a lot of work to walk into your operations dungeon and start spending money and time on education and cultural change. It's a lot harder to hire the key players. People who can work with a team and help them to become self-organising and in control of their destiny are much, much rarer than those who'll sell you a few cheap platitudes and a nice binder. The reward, though, is a company that is more responsive all-round. A company which doesn't have the resentment divide between the fun stuff and the stuff that keeps the lights on. A company where teams work together because delivering the top priorities more efficiently than yesterday is everyone's job, not just the task of a chosen few.

If you don't want that effort or reward - then fine. But don't claim bimodal IT is anything but a nice name for running away from your problems.

_{Image by Carole Raddato CC-SA 2.0}