In Two Minds About Bimodal IT

Gartner’s Bimodal IT approach has been gaining momentum for the last 18 months. It promotes the adoption of a twin track approach to methodology selection. In Gartner’s words “Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.”

On the one hand I applaud any approach that helps bring the benefits of iterative methods and increased collaboration to organizations, especially those that have previously resisted them. On the other hand, I have some reservations with a model that polarizes guidance, categorizing projects into either traditional/sequential or exploratory/agility, when projects exist on a spectrum and the best approach is likely a smart mix of techniques.

It’s a Continuum Not an “A” or “B” Decision

If your project is simple, visual and being undertaken by a small, co-located team then an agile approach is likely a good fit. However, big, complex, embedded systems undertaken by large and distributed teams also benefit from an iterative approach to the early identification of risks, confirming true requirements and surfacing gaps in understanding.

Also, given the complexity of large systems, the chance of getting something complicated done right through a sequential process is very small. Likewise, we cannot expect a project manager to understand all the technology portions, project dependencies and estimation outliers. Engaging the team more through collaborative practices to better estimate, plan and identify risks produces much more robust plans. Then through the iterative approach of developing real, executable slices of the application, the validity of these estimates can be checked and refinements made to model the likely outcomes.

These benefits coupled with others around an increased sense of ownership and accountability by the team for having been involved more in the planning and ongoing steering of the project, I believe large complex projects need agile techniques more than small simple projects.

I am not saying large projects should be run purely with agile methods, they need additional layers of rigor and communication, but there are some great scaling frameworks like Disciplined Agile Delivery (DAD) that do this without losing the benefits of iterations, adaptation and empowered teams. However, Bimodal IT steers companies away from many of the tools ideally suited for large projects.

“Bargaining” is the Next Step after “Denial” and “Anger”

Change acceptance, like grief, goes through stages. The first stage is Denial, we refuse to believe this is real, is happening to us, or applies to us. Traumatic loss or change is often accompanied by a surreal, outside-observer feeling as we struggle to accept what has happened or is happening. At a level of significance down from trauma, denial is expressed as rejection. “Agile does not apply to me!” Next comes Anger “You can’t make me use agile! I have been managing projects with a sequential process for 30 years, and I will not change now.”

The next stage after Denial and Anger is Bargaining, where people try to avoid or minimize the impact of a change by making some highly visible or not really substantive bargains. For example, “OK, I will use an iterative approach, how about I make my iterations 6 months long?” Here, the resistor is negotiating or bargaining terminology “I will use an iterative approach when…” for an excuse to continue operating pretty much as they were before.

This is where I feel Bimodal IT resides and in part it explains its gain in popularity. It appeals to organizational leaders who do not really understand or believe in the benefits of an agile approach, but are under pressure to keep up with the times, offer agile projects to their teams, appear responsive to their business community. By publicly adopting Bimodal IT, they can push the small, trivial projects through an agile methodology - appeasing critics while clinging to their more comfortable traditional, sequential model. Since most organizations have significantly more small projects than large ones it may even appear that half or more of the projects being undertaken are Mode 2, agile projects when this represents only a small proportion of the project work being undertaken.

Simplicity Sells

People seem to like simple rules, even if they represent a suboptimal solution. The Atkins diet was very popular because a rule like “No Carbs” is simple and people liked that. Ask a nutritionist though and they will do two things, first they will explain that while it has some truth to it, the real makeup of good nutrition is more complex and varies depending on a large number of factors. The second thing they will do is to start explaining the large number of factors and either confuse you, send you to sleep, or make you wish you never asked them in the first place.

The same is kind of true for the best approach for developing software. Simple rules like Mode 1 traditional and Mode 2 agile-ish are appealing since they are easy to follow. However, like any restrictive diet, they are at best an over simplification and at worst are potentially harmful.

As an example Gartner states their Mode 1 approach that is traditional and sequential emphasizes safety and accuracy, but I would feel much safer and confident in a system where the highest priority features were developed first and have been reviewed and tested in every iteration since, than an approach that had lots of careful planning and then testing performed towards the end of the project. Iterations drive use and uncover missed requirements and defects. You can plan in detail and analyze requirements with reviews and tools – I spent 10 years of my software career working on very formal military projects – but, I believe the best way to discover if software works is by working the software.

Gateway Drugs

For me there is just too much wrong with Bimodal IT to recommend its use. It polarizes project selection when we should be looking more at hybrid models for large projects. It promotes more of a bargaining adoption of iterative methods and empowered teams than a serious acceptance of where these approaches can help all project types. Finally, it propagates dangerous sequential process models for large and complex projects that really need iterations more than small, simple projects.

If it has a redeeming feature it is that it could lead to the introduction of some iterative based projects, that then open the door to more agile projects, in organizations that had up until then resisted agile methods. I think Gartner should not end with the Bimodal framework, but use it as a foot-in-the-door primer for the Next Steps of continued evolution. So, while it currently has some use as a gateway or stepping stone to deeper thinking about project approaches, it should not be considered a destination for IS policy as it stands today.