By Peter Longini

There was a time – actually quite a long time – during which ‘IBM’ and ‘computer’ were synonyms.  It began well before computers got personal in the ‘80s.  And it continued for a number of years after PCs came into their own.  The company’s scope, reach and success was unrivaled for decades and its culture of rejecting ideas ‘not invented here’ was arguably justified.  After all, the company’s workforce included some of the brightest minds in the business.  Proprietary knowledge was central to its technology leadership.  And its management methods were among the most astute, particularly for organizations of its tremendous size. 

But there were tradeoffs.  And over time, the cost of those tradeoffs had become apparent both in the marketplace – where it began frequently butting heads with Microsoft – and within the ranks of the company itself.  During a recent Product Strategy Network forum, IBM Vice President Sue McKinney described how the company’s project management legacy grew to become a burden and how, despite its massive scale, the company was able to transform its product development process and become a much more agile organization.   

“Until the late 1990s, we were heavily driven by a waterfall approach” McKinney recalled.  “Our development process was very mature, because it was based on our mainframe approach to developing software.  It was rigid and inflexible.  If a change were to occur in the process, it was hard for us to adapt.  We got feedback very late in the cycle, so it was difficult to make changes.  We had a ‘rear view mirror’ mentality of measurement; at the end of the cycle or the end of the release we would always look and say, ‘well, how did we do?’” 

Starting to transition

“So, the late ‘90s, we went to more of an iterative approach,” she recalled.  “We started to introduce different development strategies; we started evolving our quality process to be more flexible.  And because acquisition was becoming more of a strategy for IBM, we had a lot of integration issues: how do you integrate these acquisitions into the rest of the Software group’s portfolio? 

“We also started to introduce a Steering Committee to oversee who was doing what and if they were following best practices.  It was a great idea, but the execution was poor,” McKinney observed.  “We made it more of a policing-type approach, which really was distasteful to the engineering community.  They wanted to have guidelines and best practices, but they didn’t want to always be called in for not following every detail of what the Steering Committee was asking for.  They wanted some freedom to interpret.” 

There were other issues as well, some resulting from the company’s increasingly bloated product portfolio, which were also nudging it in the direction of flexibility and simplicity.  However, scaling those methods to work in a company of IBM’s awesome dimensions required some special accommodations.  But, according to McKinney, the transition is well underway and has largely succeeded. 

Becoming Agile

“Today, we have very aggressive approaches to Lean and Agile,” she said.  “Through acquisitions, our software group is in over 60 locations now – and that’s just our core technologies.  We transitioned from a very headquarters-like, steering committee mechanism to more of a light-weight governance approach.  We define core principles and map them to a set of best practices.  We’ve tried to give some flexibility back to the development teams to accommodate or adjust to their situations, but they have to live under some governance that we put forward.” 

“When an acquisition comes in to IBM, they bring along specific tools they’ve been using for their development processes.  We have some that are home-grown, and we also have some from third parties.  We just have to figure out which are the right ones, look at where we should standardize and consolidate, but then give some freedom to the teams to choose their own tooling,” McKinney said.

“We have components that are reused within our middleware – over 2,000 assets are now being reused.  That helps with maintenance and helps reduce the overall engineering effort.  And we are trying to get stakeholder or customer feedback early on in the cycle.  And we really wanted to come up with an approach that if we had to comply with some IBM policy, we wouldn’t put the burden of executing that policy strictly on the development team.  We would inform them of the policy or the compliance issue and then provide them with a tool to help them be in compliance.  Too often in the late ‘90s we were just saying, ‘hey, you’ve got to follow this policy, you need to do it in 3 months.  Now tell me how you’re going to do it.’” 

Navigating the transition

Of course, getting the company’s 25,000 software development engineers all trained and onto the Agile bandwagon was a major undertaking, requiring both a top-down and bottoms-up approach, according to McKinney.  It also required selecting experienced leaders – people who had come into the company with a history that included familiarity with the principles of Lean and Agile processes. 

“Tooling was very important to making the team successful.  We had to provide the right tools; otherwise, they were going to fail,” she noted.  “We had to provide the right mentorship as well, because it’s not an easy thing to change the way you develop software.  You have to provide the guidance, the scoping, understand where to mitigate risk, how to mitigate risk, and how to enable the team to buy into the overall concept.  We had to watch out for a lot of waterfall-ish processes that were still in place.  And we had to make sure we could change the process along the way to be more Agile and Lean.  We should have done more of that upfront, but along the way, we identified where teams were being encumbered by the process and started making changes.”

Timed-Box iterations

“We’ve always talked about focusing on the essential – to have one guiding principle for the teams,” McKinney said.  “When you think about Agile and Lean it comes down to this: short, timed, box iterations with customer feedback.  Think about what that drives: it really sets the stage for everything else.  As soon as you say short, timed, box iterations, you’ve set a constraint.  And when you set a constraint, you are forced to look at how you’re going to be efficient and where you could do more automation.  Now you have to have running code and stakeholder feedback at the end of the iteration. 

“We saw that just by having a simple statement and short, timed, box iterations with customer feedback, it was really starting to transform the teams and force them to think differently about how they had to develop software.  That just naturally came when we started to talk about it in those terms. 

“The last thing is to empower and innovate through passive governance – getting away from heavy-handed edicts.  We learned the hard way through the late ‘90s that this doesn’t work, especially when we started to see more acquisitions.  We also wanted to take advantage of the vast knowledge of our workforce.  We have 25,000 pure engineers in our Software group.  There’s a lot of knowledge out there and a lot of it’s not shared,” she noted.  “So how could we utilize the knowledge that’s been grown and fostered in IBM and share and harvest it across the entire company?  Our solution was to leverage social software tools and Web 2.0 technologies.  That allowed us to create communities of interest within our engineering teams.  And it enabled teams to harvest and share information regardless of organization boundaries or geographical location.”

About the Author:

Peter Longini is the Managing Editor for Inside Product Strategy™. He can be reached at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .

To read our latest articles in Inside Product Strategy™ click here.