2-speed IT is Dead: Agile for Services is the New Normal

Seven years ago, enterprise CIOs got the memo that all the cool kids were becoming?agile.??Not only that, but their previously downtrodden and chronically grumpy developers seemed to love it, and be more energized and engaged when working on “agile” teams.??Even better, projects seemed to be getting done, sometimes faster, and with a lot more customer satisfaction.??All of that sound great, and so CIOs flocked?en masse to embrace agile for product development.

But.

Product development is only part of what Fortune 500 IT departments do, and to be honest, it’s not even the biggest part of what they do… not even close.??Mostly, IT departments keep the lights on, and keep?already-developed business systems chugging along. What does agile do for this part of a CIO’s IT burden???Up until recently, the answer was “not much.”

Agile for product development is synonymous with?iterative development, made famous by methods like XP, Scrum, and FDD (feature-driven development), and popularized into startup cultures by books like The Lean Startup, which made MVP- minimum viable product- a business meme.??

Iterative development relies on gating the incoming work, allowing the team to focus on a small subset of tasks.??This is called focusing on finishing.??Teams are small, usually less than 10 people, and include all skill sets necessary to (theoretically) go from feature idea through development, and all the way to production deployment.??Every two weeks or so, the team picks a handful of items to focus on, and then they “sprint” to a finish line.??At the end of the two weeks, they perform a “show and tell” of their progress to their customer (internal or external), and get immediate feedback on whether they’ve delivered what was asked, missed the mark completely, or somewhere in between.??The next week, they sit down with their customer to hear what the current priorities are, and then estimate which aspects they can complete in the time allotted for their sprint.??Once all are agreed, the team commits to the work, and begins.

Problem is, this doesn’t work for most IT departments, who must field daily trouble tickets, customer requests, security threats, network outages, infrastructure builds, maintenance, monitoring, plus large-scale projects, upgrades, and many small and medium-sized projects, often with the same staff!??This “back office” or “run the business” work, including deployments for development teams, is?services work, not project work.??CIOs need a way to deliver these IT services, including managed services, with just as much agility as the development teams deliver products.

Exacerbating the situation is the demand from fast-moving agile development teams to deploy their MVPs quickly to production, in order to get fast customer feedback.??But huge global enterprises were not built to be lithe production speedboats;??they were built to be safe production aircraft carriers.??The USS Nimitz does not turn on a dime.

Previously publishers like Gartner reassured CIOs that "two-speed IT" was perfectly fine. No one could expect stodgy old IT departments to keep up with the young, agile, hotshots in the product development teams.

Apparently, Wall Street did not get that memo. If IT deployments are a necessary part of the equation for development teams to deliver their products to end users (and they are), then IT too, had to become agile. Oops! All 5,000 books and training companies seemed to have avoided that thorny issue. So, just how do you turn a giant, battle-hardened aircraft carrier into an at least relatively nimble speedster?

In?this Harvard Business Review article, you can read about how I helped IBM’s largest business unit tackle this very problem, by transforming first their 100,000-person internal IT delivery organization, and second, by helping several of their clients- large global Fortune 500 companies- do the same.

To do so, we draw upon the wisdom gained in the manufacturing industry some 50 years ago, which we have been shamefully slow to apply to modern IT environments. But we also look to giants of the Scientific Revolution like Francis Bacon, who coined the term experiments of fruit versus experiments of light. While esoteric, these great thinkers laid the foundation for systems thinking, which is at the heart of both the operational and financial improvements we help teams make.

Major enterprises, and especially enterprise IT departments, are actually far more complex than even most CIOs appreciate. Their teams don't deliver dozens of services, they deliver hundreds, even thousands of discrete services, sometimes to millions of users across the globe. Thus, the first step is to actually understand- at a quite granular level- what services IT provides.

Next, we help leaders understand what could (or must) be better about their service delivery. Are customers generally happy, but find the service too expensive? Is it an affordable but unpleasant experience? Is high-quality customer experience cost prohibitive for the CIO to produce? What specific areas fall short? Is the issue responsiveness, quality, or aesthetics?

Finally, we address how to make things better. Sometimes this is a simple matter of policy change, training, or staffing. Other times, it is more complex process redesign, or automation of long poles in the pipeline. Usually it is some combination of all of these, plus improving communication with the end customer (technologists are smart, but they spend most of their day talking to computers, not people).

If all of this sounds straight-foward, it is. Its simple, but not easy. However, for a CIO or COO determined to help their organization respond more quickly to market demands and hold on to customers they already have, it is absolutely essential to discard two-speed IT- the notion of a fast product development organization dragging an IT boat anchor- and get the entire organization to be light on their feet, and pedaling at the same speed, direction, and quality that modern customers demand.