• January 24, 2017

Modern Adaptations: The Business Sense of Bimodal IT

Don’t choose between waterfall and agile development; have them both with bimodal IT. 

By Joe Hill, Analytics Chief Technologist, Analytics & Data Management, and Fellow, Enterprise Services

You hear a lot of talk these days about agility and how it can transform businesses. In fact, 88 percent of organizations say that they have adopted agile development, citing the many benefits of embracing this more flexible and iterative approach to IT. Chief among those benefits are lower costs, a greater ability to meet end-user needs, and increased velocity.

The problem is that some organizations appear to believe that they should be using agile development to the exclusion of traditional waterfall development. That’s a mistake. No matter what you’ve heard about the debate over bimodal IT (this article from Forbes helps illustrate just how much opinions diverge), the reality is that if you’re not bimodal, you’re limiting your chances for success.

That’s because when it comes to using traditional IT and agility, it should never be a question of either-or. There will always be a place for both, at least on some level. Those IT organizations that realize this and use the right approach at the right times are the ones that will be best positioned to meet their customers’ ever-evolving needs. On the other hand, any organization that believes it can survive and thrive using just waterfall, or just agility, is setting itself up to fail.

Making the Case for Agility and Waterfall

Agility is a great approach for IT development, and one that can yield impressive results. In fact, in most organizations it makes sense for agility to be the predominant approach to development. It’s fast, it allows you to be much more iterative, and it generally enables you to deliver high-quality outcomes in realistic time frames. In spite all of that, let’s be clear about one thing: That doesn’t mean that traditional IT should be overlooked. Waterfall has an equally critical role to play in every organization, including yours.

To see what I mean, let’s look at a simple example.

Imagine for a moment that you’re building a skyscraper. While the individual offices that wind up going into the tower can be built dynamically, iteratively, and in rapid fashion—leading to great results in some cases and potential failures in others—would you really want to take the same approach for the construction of the building itself? Of course not. After all, who would feel confident moving into a building if they knew that you were learning on the job while you built it and were experimenting with lots of different ideas that may or may not have worked?

When it comes to developing foundational pieces of IT architecture, it’s a similar story. You need to take your time doing it so that you can get things right. Two-week sprints that give you the speed and flexibility to turn on a dime when developing an app are also precisely what can inhibit IT organizations from making thoughtful decisions about the underlying architecture needed to support that app.

The internet is a case in point. I think that we can all agree that it’s a tremendous platform for agile development. But how easy would the development be if there weren’t some basic architecture in place to support it? In this example, I’m talking about hypertext transfer protocol (HTTP) and hypertext markup language (HTML), two standards that create a consistent framework for how we build things online. Both were thoughtfully developed using waterfall and we should all be thankful that they were. They’ve given us some much-needed stability and standardization, thus paving the way for everything that we’re doing today.

Striking the Right Balance Is Critical for Achieving Scale

While the vast majority of your IT projects may be moving toward agility, just remember that architectural standards need to be developed more slowly and carefully if you want to get them right. That’s particularly important for any organization that’s trying to achieve enterprise scale.

Why? Because taking a strictly agile approach doesn’t allow you to get big enough. It forces, or at least allows, you to build everything from scratch and to rebuild solutions for every project. That’s neither cost-effective nor scalable. Rather than reinvent the wheel with every new project, you need an architectural foundation that you can build upon. That foundation has to be reliable and provide the guideposts developers need to do things in a standard way that makes sense.

The key to succeeding in IT is to make sure that you’ve got a strong, architecturally based solution. Once that’s in place, it’s a matter of adopting agile approaches everywhere else as appropriate. While in all likelihood that will mean that the vast majority of your IT team is in fact agile, there should always be a place for traditional IT in your organization.