Big Blue dog learns new tricks: How IBM Software Group moved to agile

Turns out, you can teach an old dog new tricks. A really big old dog. A really big old dog that's been around for more than 100 years, with a globally distributed software development team made up of 45,000 people at 60 labs around the world. Thus follows the tale of IBM Software Group's transition to agile development.

It began with a simple mantra: short, time-boxed iterations with stakeholder feedback.

Sue McKinney

"The Agile Manifesto, I think people get, but we wanted to simplify it," explained Sue McKinney, vice president of IBM's development transformation. McKinney, former vice president of development at IBM's Lotus division, said at Lotus she had all teams at various levels trying to use agile software practices. She had success with the Sametime team, she said, "and they asked me to come over to the software group headquarters to help get agile more widely adopted."

"We were getting to the point where we were missing key shipping milestones because the iterations were so long," McKinney said. "When you get feature creep, you lose the sense of where you are tracking known deliverables."

So she asked everyone to live by that simple mantra, around which the first guideline was developed: "We like two-week iterations, but do not exceed four weeks. And we said at the end of the iteration you had to have code complete -- running code that you could demo to a customer and [the customer] would provide feedback. Just those simple thoughts really transformed the development team in how it was thinking about and providing code."

That was in 2007. McKinney said that prior to this there was a small grassroots effort within IBM to move to agile, but "it didn't have executive management support."

More on adopting agile methods Adopting continuous integration brings agility, other benefits Agile bridges software requirements communications gap Where does quality assurance fit in agile development?

McKinney said she started working at the executive level with her peers, covering five development brands. "I told them the success I'd seen, and asked for their support of their teams, and in some cases I asked if they had a team that was suitable or ready for transition. I wanted to start with quick wins and build off the quick wins rather than attempt a massive project and see [the team] struggle. Then I would look to demonstrate and socialize those successes."

First, IBM set up center of competency, working with Poppendieck LLC's consultants in lean and agile methods to set up a workshop to get the teams started. "We had them go through lean principles, agile, eliminating debt, iteration planning, and operational effectiveness." She said they asked class attendees if they planned to utilize any of the techniques within 30 to 90 days, and if so, how could they help attendees "scope something [they] can tackle"?

"We pushed tackling low-hanging fruit to get the benefit and to attack the major pain points," McKinney explained. "The coach would work with them for as long as the team wanted, maybe help to set up a build infrastructure or test-driven development environment. All the teams were different, so some needed different levels of help than others."

As far as choosing a methodology, McKinney focused on helping to make the team productive rather than on dogma. "Historically, we're so large and do so many acquisitions that you can't prescribe a one-size-fits-all. We wanted to give the teams choice, and depending on the situation there might be tools better suited [than others]. You can use XP or Scrum [or RUP]. We felt if we put the guidelines together they could make the right choice."

The best practice guidelines for things like continuous integration (CI) and test-driven development were based on patterns that emerged of what worked as the teams started focusing on shorter iterations, she said. "We didn't want to be theoretical in prescribing and advocating things; we wanted them to be around practitioners telling stories." Accordingly, they also created an Agile@IBM community for sharing best practices.

McKinney acknowledged that there are challenges to adapting agile to the needs of large, globally dispersed teams. "The teams prefer colocation, and I wish I could live in that world, but times have changed," she said. "Our average size is 150 to 200 people geographically dispersed, so communication is very important. Organizing work is very important, and we have made strides there."

For instance, she said, previously core IBM teams would do all the development work and outsource the testing to India, but she said the Indian teams would be disenfranchised. With agile, the entire team has ownership of a component, from architecture to design to test, "and we're getting great productivity and ownership out of these teams."

Getting agile to scale for large, complex products is also difficult, McKinney said. Continuous integration, in particular, has been challenging. "We had problems because our products were so complex that build breakages were commonplace. Some teams had breaks for weeks, so you can imagine the debt that was accumulating," she said. So they've worked on organizing builds and code dependencies differently to simplify, and trying different tooling. "Categorically every project development team has benefited from focusing on CI," she said. "Although they had problems at the beginning, they've gotten much better."

She advocates looking at what a project is trying to accomplish and applying agile accordingly. "Is it time to market? Quality? Predictability of milestones? Take a bit and try it; don't try to do everything," she said. "If our app server team of 800 people wants to do more around stakeholder feedback or reducing cycle time, I'm all for that. I think [scaling agile] can be done, you just have to know what you're going into, and put a plan in place to measure yourself."

McKinney said they have a saying: "Use a balance of agile for uncertainties, process for complexities." If market conditions change or a team gets feedback it didn't anticipate, the team can use agile to address those changes, she said. As projects get larger, more process may be required, "but you don't want to see everything driven through a process that stifles teams," she said.

To date, IBM has trained more than 7,000 individuals in the software group in agile practices, and McKinney estimates that about 80% of project teams are using at least one or more agile best practice. Progress is tracked with a yearly survey that measures 13 best practices, including user story development, continuous integration and stakeholder feedback.

"I don't know when I will declare victory," McKinney said. "My criteria for if it worked is if teams have gotten more productive."