How IBM’s Biggest Business Unit Got Agile

Share this post:

Transformation in today’s business is rarely easy. But when changes must be made within an organization of well over 100,000 employees, it can be downright hard.

That’s exactly where IBM’s Global Technology Services (GTS) unit found itself two years ago. With a rapidly expanding global ecosystem and mounting IT complexity, the unit needed a new, innovative way to manage the growth. With the task at hand, GTS turned to its Technology, Innovation & Automation group which set out to develop a new, agile methodology.

What it created was called, Agile for Services, a new way of doing everything from development to servicing clients. The approach focused on tearing down walls – literally – and building collaborative spaces, building diverse teams, and keeping a sustainable pace that allowed teams to work intensely and collaboratively. As the methodology was adopted, projects were getting done faster and faster, and with higher customer satisfaction.

But product development is only part of what large IT departments do. It’s not even the biggest part of what they do; not even close. For the most part, 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! 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 turn does not on a dime.

This “back office” or “run the business” work, including deployments for development teams, is services work, not product work.  CIOs need a way to deliver these IT services, including managed services, with just as much agility as the development teams deliver products, but not in a cookie-cutter way.

In this HBR-Analytic Services article, you can read about how the Agile@GTS team helped IBM’s largest business unit tackle this very problem, by transforming first their 115,000+ person internal IT services organization, and second, by helping several of their clients – large global Fortune 500 companies – do the same.

The Agile@GTS team developed Agile for Services™ to overcome this transformation challenge by working on a team-by-team and client-by-client basis to develop a “fit-for-purpose” framework that builds on multiple Agile practices and patterns, as well as Systems and Design Thinking. Read more in this HBR-Analytic Services article.