As a tech company, we're constantly walking a fine line between stable and reliable development and experimenting with new, innovative features. We've learnt that the ability to master both these development modes is extremely valuable for our partners. That's where a bimodal IT model comes into play. It's the practice of managing two different styles of work; one focused on predictability, the other on exploration.
Lets look at these development modes in more depth. Mode 1 is your typical house builder, who builds a brick and mortar house in a predictable way. He improves and renovates the house in well-understood areas using well-tested methods. Mode 2 is your mad scientist builder. She is an explorer to the nth degree. She loves tinkering around with new and innovative technologies. She might even build a shower that automatically turns on to the perfect temperature depending on the weather.
When it comes to software development, mode 1 companies can deliver reputable services that work reliably and quickly, working from established procedures and processes. On the other hand, Mode 2 companies are able to explore what was previously unexplored terrain. Ensuring you have the capability to create predictable and reliable tech while exploring the unknown is the crux of a bimodal IT structure.
CTO's and CIO's can often feel restricted when it comes to innovating. The business' resources are tied up maintaining their current system, making it impossible to develop new software and pursue other goals. That's where a bimodal model can work in your favour. You can use your internal development team to maintain the current software in a reliable, mode 1 fashion. You can then outsource the new project to an external development team (like WorkingMouse). By separating the two projects - internal maintenance (mode 1) and external innovation (mode 2), businesses utilise the bimodal model. It also means there are two dedicated teams with a clear focus, helping you achieve your goals.
We practice what we preach. At WorkingMouse we've separated into small project teams who can be used in different development modes. We ensure we have the right processes in place to support our internal projects while delivering reliable software to customers. Download our Bots that Code book to see how our Codebots platform allows us to utilise a bimodal model.
Implementing a Bimodal Structure
It is important to note that bimodal is a style of work describing how to deliver projects. It does not dictate who should be working on what type of project. It is possible to have decentralised units that operate solely in a Mode 1 fashion, with other dedicated decentralised units operating in a Mode 2 capability. Alternatively, these IT units could function so that they cover both modes of development. Bimodal is not contingent on how the organisation operates, whether that be with a centralised, decentralised or federated manner.
Bimodal Goes Beyond Software Development
Even though the term bimodal is commonly used in the software development industry, it is not confined to development alone. Mode 2 initiatives may have little or no development involved. For WorkingMouse, our Mode 2 initiative (Codebots) is predominantly centred around a process, rather than development.
Mode 2 and Agile
Mode 2 projects can be difficult to grasp. The way in which you achieve your end goal can change constantly. As a result it's beneficial to start small, iterate and get quick wins on the board. You can't spend long periods of time explaining a project. People need to experience the mode 2 method. This is where the agile methodology comes into play. Agile is centred around building lean, learning and iterating. The build, measure, learn cycle makes it easy to adapt on the run. Given the uncertainty of a Mode 2 project, adaptability is an essential characteristic. Mode 1 projects are usually more predictable. Because of this, a waterfall approach can be taken (if desired). WorkingMouse supports both methodologies. This allows our partners to decide how they want to develop.
Entry Points
Gartner provides that there are three main entry points for a Mode 2 project.
IT Driven
This is where the CTO unilaterally decides to create or grow a Mode 2 capability.
Business Driven
An example of this is where an executive (CEO) mandates that the IT organisation or a specific part of the department, respond to an opportunity that requires a Mode 2 style of delivery.
Vendor Driven
This is where a competitor's offering drives Mode 2 changes.
WorkingMouse has adopted a bimodal structure to pursue our internal projects while also working on customer projects. We've implemented the necessary processes to cater for other businesses who are looking to develop Mode 1 or Mode 2 projects (or both).
