I've recently come across a concept known as Bimodal IT. I couldn't stop howling with laughter. It's basically 2004 dressed up as 2014 and it is guaranteed to get you into a mess. So we better go through it.
I'm going to start with a map. Now, as we know the map of a business contains many components organised into a chain of needs (the value chain) with the components at differing states of evolution. As components evolve, their properties change (from uncharted to industrialised) and different methods of management become appropriate (see Salaman & Storey, the Innovation Paradox, 2002). Hence components in the uncharted space use in-house, agile techniques, quick release cycles, highly iterative etc. Whereas those more industrialised components tend to be six sigma, ITIL, long release cycles, heavily standardised etc (see The Sum of All Fears, Butler Group Review, Dec 2007).
When it comes to organising then each component not only needs different aptitudes (e.g. engineering + design) but also different attitudes (i.e. engineering in genesis is not the same as engineering in industrialised). To solve this, you end up implementing a "trimodal" (three party) structure such as pioneers, settlers and town planners which is governed by a process of theft. Ok, this is all old hat, circa 2005 and I've summarised it in figure 1.
Figure 1 - Map of components in a business
So lets speed on and discuss what's wrong with bimodal.
The problem with bimodal (e.g. pioneers and town planners) is it lacks the middle component (the settlers) which performs an essential function in ensuring that work is taken from the pioneers and turned into mature products before the town planners can turn this into industrialised commodities or utility services. Without this middle component then yes you cover the two extremes (e.g. agile vs six sigma) but new things built never progress or evolve. You have nothing managing the 'flow' from one extreme to another.
For example, you start off with a new platform designed for the future on top of which your pioneers build new things. But unfortunately pioneers aren't usually so good at making rock solid and mature products, they're more pioneering. Of course, your town planners won't want to industrialise something which isn't a rock sold and mature product, it's too uncertain for volume operations. You end up with this stalemate that the new thing never gets turned into an industrialised service. Instead what happens, is something even newer gets built on top of your non industrialised component. And this continues with new things built on layers of components that are not fully industrialised. It becomes kludge on top of kludge on top of kludge.
Eventually, after five years or so then this creates spaghetti junction. It is an environment which becomes unmanageable - performance sucks, reliability disappears and costs spiral. You get everyone to together and the new idea is always to build the new "platform for the future". You then spend vast sums of money, create the new platform and repeat this exercise all over again.
This has occurred in almost every company that I've seen in the last decade using bimodal approaches for any period of time. I've seen many billions blown on the same mistake of pursuing solutions which fail to cope with evolution (e.g. one size fits all, outsource everything, bimodal etc) - we will have R&D over here and shared services over here and it will all work! Think again. Its why people use alternatives such as a cell based structures or a trimodal system (e.g. pioneers, settler and town planners) or a combination of both.
The whole purpose of the settlers is to productise i.e. to take the early stage work of the pioneers, and iteratively mature it until the town planners can finally industrialise it. They are absolutely essential to the functioning of such structures. Remove it at your peril.
Of course, bimodal is still "better than the madness of one size fits all" (e.g. agile everywhere or six sigma everywhere). Maybe in the short term but you're still going to end up with SNAFU. So, think trimodal. Be a bit more 2005 than 2004, even though it's 2014. Create a virtuous cycle of theft (see figure 2).
Figure 2 - Pioneers, Settlers and Town Planners
Figure 2 - Pioneers, Settlers and Town Planners
On that note, I can't believe people are flogging Bimodal IT as something new in 2014, that's taking the piss. Next week Gartner researchers will be telling us they've just invented the "internet" or the "wheel". Be under no illusion, bimodal plus time can go horribly wrong - seen it, done it, bought the T-Shirt. Let me just reiterate that point. I'm telling you from the experience of having used both bimodal and trimodal forms over the last decade that bimodal is not what you want to do.
Apparently though Gartner's bimodal model has both pioneers and settlers in 'mode 2' group and Town Planners in 'mode 1' group. Whilst the language Gartner use - industrialisation, uncertain, non linear - is all familiar, the justification of combining these groups to form a bimodal is highly suspect in my view.
When I wrote my Butler Group Review Article in May 2008 on the need for use of multiple methods within an organisation (e.g. Agile and more "Waterfall"), we already knew back then that you couldn't organise by this bimodal fashion because of the problems it had caused. You need that missing middle (the settlers) that dealt with the transition.
Now, I haven't read Gartner's recent research on this subject (I'm not a subscriber) and it seems weird to be reading "research" about stuff you've done in practice a decade ago. Maybe they've found some magic juice? Experience however dictates that it'll be snake oil and you really need to separate out the three groups. I feel like the old car mechanic listening to the kid saying that his magic pill turns water into gas. I'm sure it doesn't ... maybe this time it will ... duh, suckered again.
--- Update 14th Nov 2014
One thing I haven't made clear in this post and need to is where did the idea of implementing a three party, trimodal way of working such as pioneer, settler and town planner come from?
From my perspective then the origin of deliberately implementing this structure was James Duncan, now a CTO within UK Gov. It started all those year ago, back in the days of Fotango when I was CEO. I was frustrated by several things - how the organisation worked, the lack of any competitive map to describe our environment , the compete blah of what was called strategy etc. I'd shown James my work on mapping and evolution. We worked together on this to refine the whole Fotango plan. It was a time of exploration for me and James was my cohort in this (which is why I use the term Wardley-Duncan Map occasionally. Well, credit is due).
However, it was James (who was the CIO) that proposed to me a three party structure within IT. It sounded right, I couldn't say why but I was happy to go with it and I was delighted by the outcomes that resulted. I then started to fold the rest of the company into this model. Now, I'm not saying others didn't have a similar model just from my perspective it was James Duncan who started this particular aspect of my journey. Sometime around 2004.
It's also true that back then I couldn't fully explain why the trimodal approach worked so well - in fact many of our successful experiments were hard to explain. All we had was the practice and the result. It took a bit longer for all the aspects of mapping and evolution to become clearer before the reasons why it was a good move stood out. I mention this because mapping, the use of multiple methods, the work on ecosystems, open source and organisations - all started with practice & observed outcomes first. Understanding why came a bit later.
--- Update 14th Nov 2014
One final thing to mention, my disapproval of bimodal IT assumes that CIOs are trying to use it to fix a problem by using a flawed approach. I've now come across an example where it is more being used to "bolt on innovation" in much the same way that some companies are not adapting to digital but instead "bolting on a CDO". This is akin to adding lipstick to the pig.
I'd argue that this indicates an additional organisational need which is removal of its technology leadership. In such cases, a CDO is not only needed but should replace the CIO. But how do you now?
Well, next time you have the chance to chat with the CIO, just ask what they think of the Bimodal IT approach. If they're positive, that's fair enough it's not too deadly a sign. But use the vernacular and ask "When our Sprinters have created something new, then overtime it'll become like the stuff the Marathon runners provide. How are we going to manage that?"
If the response is "they'll just hand it over" or you get hand waiving warble or you get any sign of confusion then you know you probably own a well lipsticked pig.
-- Update 8th March 2015
A bit of digging in the old memory banks, brings me to Robert X. Cringely's book, Accidental Empires reissued in 1996, page 235 - 238. Copying some quotes from that book (which I recommend people go buy and read), the ideas of pioneers, settlers and town planners are all there. I knew it had come from somewhere.
Think of the growth of a company as a military operation, which isn't a stretch, given that both enterprises involve strategy, tactics, supply line, communication, alliances and manpower.
Whether invading countries or markets, the first wave of troops to see battle are the commandos. Commando's parachute behind enemy lines or quietly crawl ashore at night. Speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware they exist. They make creativity a destructive art.
[Referring to software business] But what they build, while it may look like a product and work like a product, usually isn't a product because it still has bugs and major failings that are beneath the notice of commando types. Or maybe it works fine but can't be produced profitably without extensive redesign. Commandos are useless for this type of work. They get bored.
It's easy to dismiss the commandos. After all, most of business and warfare is conventional. But without commandos you'd never get on the beach at all. Grouping offshore as the commandos do their work is the second wave of soldiers, the infantry. These are the people who hit the beach en masse an slog out the early victory, building the start given by the commandos. The second wave troops take the prototype, test it, refine it, make it manufacturable, write the manuals, market it, and ideally produce a profit. Because there are so many more of these soldiers and their duties are so varied, they require and infrastructure of rules and procedures for getting things done - all the stuff that commandos hate. For just this reason, soldiers of the second wave, while they can work with the first wave, generally don't trust them, though the commands don't even notice this fact, since by this time they are bored and already looking for the door. While the commandos make success possible, it's the infantry that makes success happen.
What happens then is that the commandos and the infantry advance into new territories, performing their same jobs again. There is still a need for a military presence in the territory. These third wave troops hate change. They aren't troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale.
What Robert called Commandos, Infantry and Police is what I later called Pioneers, Settlers and Town Planners. The two are identical except Robert was there much, much earlier. In fact 1993, a good ten years before I implemented the tri-modal structure and 21 years before Gartner came up with this rather lame bimodal concept.
I owe Robert Cringely a debt of thanks.
Apparently though Gartner's bimodal model has both pioneers and settlers in 'mode 2' group and Town Planners in 'mode 1' group. Whilst the language Gartner use - industrialisation, uncertain, non linear - is all familiar, the justification of combining these groups to form a bimodal is highly suspect in my view.
When I wrote my Butler Group Review Article in May 2008 on the need for use of multiple methods within an organisation (e.g. Agile and more "Waterfall"), we already knew back then that you couldn't organise by this bimodal fashion because of the problems it had caused. You need that missing middle (the settlers) that dealt with the transition.
Now, I haven't read Gartner's recent research on this subject (I'm not a subscriber) and it seems weird to be reading "research" about stuff you've done in practice a decade ago. Maybe they've found some magic juice? Experience however dictates that it'll be snake oil and you really need to separate out the three groups. I feel like the old car mechanic listening to the kid saying that his magic pill turns water into gas. I'm sure it doesn't ... maybe this time it will ... duh, suckered again.
--- Update 14th Nov 2014
One thing I haven't made clear in this post and need to is where did the idea of implementing a three party, trimodal way of working such as pioneer, settler and town planner come from?
From my perspective then the origin of deliberately implementing this structure was James Duncan, now a CTO within UK Gov. It started all those year ago, back in the days of Fotango when I was CEO. I was frustrated by several things - how the organisation worked, the lack of any competitive map to describe our environment , the compete blah of what was called strategy etc. I'd shown James my work on mapping and evolution. We worked together on this to refine the whole Fotango plan. It was a time of exploration for me and James was my cohort in this (which is why I use the term Wardley-Duncan Map occasionally. Well, credit is due).
However, it was James (who was the CIO) that proposed to me a three party structure within IT. It sounded right, I couldn't say why but I was happy to go with it and I was delighted by the outcomes that resulted. I then started to fold the rest of the company into this model. Now, I'm not saying others didn't have a similar model just from my perspective it was James Duncan who started this particular aspect of my journey. Sometime around 2004.
It's also true that back then I couldn't fully explain why the trimodal approach worked so well - in fact many of our successful experiments were hard to explain. All we had was the practice and the result. It took a bit longer for all the aspects of mapping and evolution to become clearer before the reasons why it was a good move stood out. I mention this because mapping, the use of multiple methods, the work on ecosystems, open source and organisations - all started with practice & observed outcomes first. Understanding why came a bit later.
--- Update 14th Nov 2014
One final thing to mention, my disapproval of bimodal IT assumes that CIOs are trying to use it to fix a problem by using a flawed approach. I've now come across an example where it is more being used to "bolt on innovation" in much the same way that some companies are not adapting to digital but instead "bolting on a CDO". This is akin to adding lipstick to the pig.
I'd argue that this indicates an additional organisational need which is removal of its technology leadership. In such cases, a CDO is not only needed but should replace the CIO. But how do you now?
Well, next time you have the chance to chat with the CIO, just ask what they think of the Bimodal IT approach. If they're positive, that's fair enough it's not too deadly a sign. But use the vernacular and ask "When our Sprinters have created something new, then overtime it'll become like the stuff the Marathon runners provide. How are we going to manage that?"
If the response is "they'll just hand it over" or you get hand waiving warble or you get any sign of confusion then you know you probably own a well lipsticked pig.
-- Update 8th March 2015
A bit of digging in the old memory banks, brings me to Robert X. Cringely's book, Accidental Empires reissued in 1996, page 235 - 238. Copying some quotes from that book (which I recommend people go buy and read), the ideas of pioneers, settlers and town planners are all there. I knew it had come from somewhere.
Think of the growth of a company as a military operation, which isn't a stretch, given that both enterprises involve strategy, tactics, supply line, communication, alliances and manpower.
Whether invading countries or markets, the first wave of troops to see battle are the commandos. Commando's parachute behind enemy lines or quietly crawl ashore at night. Speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware they exist. They make creativity a destructive art.
[Referring to software business] But what they build, while it may look like a product and work like a product, usually isn't a product because it still has bugs and major failings that are beneath the notice of commando types. Or maybe it works fine but can't be produced profitably without extensive redesign. Commandos are useless for this type of work. They get bored.
It's easy to dismiss the commandos. After all, most of business and warfare is conventional. But without commandos you'd never get on the beach at all. Grouping offshore as the commandos do their work is the second wave of soldiers, the infantry. These are the people who hit the beach en masse an slog out the early victory, building the start given by the commandos. The second wave troops take the prototype, test it, refine it, make it manufacturable, write the manuals, market it, and ideally produce a profit. Because there are so many more of these soldiers and their duties are so varied, they require and infrastructure of rules and procedures for getting things done - all the stuff that commandos hate. For just this reason, soldiers of the second wave, while they can work with the first wave, generally don't trust them, though the commands don't even notice this fact, since by this time they are bored and already looking for the door. While the commandos make success possible, it's the infantry that makes success happen.
What happens then is that the commandos and the infantry advance into new territories, performing their same jobs again. There is still a need for a military presence in the territory. These third wave troops hate change. They aren't troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale.
Robert X. Cringely, Accidental Empires, 1996 (the reissued, I don't own the original).
I owe Robert Cringely a debt of thanks.
