Agile transformation in action

An interview with IBM Software Group's Julie King

Julie King is the Vice President of Consumability for IBM Software Group (SWG). She is a Distinguished Engineer and the Chair of the Software Group Architecture Board – a body which forms IBM's technical strategy and works across product lines and across teams to achieve a common technical vision. Julie provided leadership throughout IBM Software Group's three year agile transformation. We sat down with Julie to learn about the challenges they faced and the results that SWG has achieved.

Julie King, Vice President of Consumability, IBM Software Group, IBM

author photoJulie King is a Distinguished Engineer at the Research Triangle Park, NC site and a Director in Software Strategy & Technology. She is Chair of IBM's Software Architecture Board, which provides architectural direction with a focus on product integration for the software product portfolio; Co-Chair of the Asset Architecture Board, and a member of the IBM Academy of Technology. She has been working in software product development for over 28 years, having held various Chief Programmer, Chief Designer, and Technical Strategist positions. She graduated from Duke University with a degree in Chemistry and the University of Oregon with a M.S. in Computer Science. She is married with two daughters, and resides in Raleigh, NC.

23 January 2012

Why did IBM Software Group decide to adopt agile practices?

When we took a hard look at our organization about six years ago, we saw that we had a lot of waterfall processes that were impeding our success. We were spending too much time defining requirements up front that we experienced a lot of wasted effort when requirements changed late in the process when they are very expensive to address. We felt that agile would get rid of some of that waste by helping us make course corrections earlier in the process.

We had some teams who were already doing iterative development. But we felt that we could do much to increase our customer responsiveness by adopting agile practices which would make us more responsive to market needs in general. And so we have started to promote the idea of agile development.

What did IBM see as potential impediments to adopting an agile approach?

The geographic distribution of our teams was a significant risk factor. At first, we weren't sure how to make an organization as large, disbursed, and geographically distributed as IBM into an effective agile organization.

We knew that we would have to make significant improvements in four key areas if we were going to be successful with Agile: improving our processes, team collaboration, tooling and asset reuse.

Let's talk about each of those areas. What process changes did IBM Software Group make?

We wanted to support the adoption of agile practices, but we felt that it was important to promote the benefits of agile, not force process mandates on our teams. We hired coaches to go out and work with individual teams on their projects, and established a Center of Competence to help groups learn some of the agile practices. By giving teams the support they needed, we had a strong adoption. Our teams were able to see the benefits of an agile development process first hand. They liked the idea of being able to develop quickly, see fast results on a project, and get rapid feedback from customers and stakeholders.

We chose three aspects of agile that were minimum standards for each agile project: short time-boxed iterations, regular ongoing stakeholder feedback, and using user stories to describe what was being delivered in each iteration. Beyond that, teams were free to adopt additional agile practices to suit the needs of their project. By giving teams the freedom to mold their agile approach, we got greater team commitment and better overall results. Five years into our agile transformation effort, 80% of our product teams employ agile practices at some level.

What did SWG do to improve team collaboration?

When you start to adopt agile, a lot of people just think well, agile is for these small co-located teams. They should all be in one office, and should all be able to get around the same whiteboard. Well, that's fabulous when that can happen, and I love it when we have co-located teams that can communicate using a whiteboard. But you can't always do that when you have over 50,000 people across the globe.

In larger organizations, you have to be more intentional about the way you communicate and collaborate. We determined that tooling was necessary to provide a way for our teams to exchange information and stay on the same page as if we were a much smaller team.

The key to collaboration is that teams want a way to collaborate and exchange information in a way that feels natural to them. You can't just post a bunch of information to a wiki and expect people to pay attention. It's got to feel natural to them and fit into the context of their work. We put in place technology that unified people beyond just the development team, including documentation, training, translation, and release management so everyone could see the status on complementary work activities that were taking place.

What changes did SWG make on the tooling front?

As teams began to learn about agile practices, we also realized that we had to put the right tools in their hands in order for them to gain the most out of these practices. So it was right about the same time when we started agile coaching work that we introduced Rational Team Concert (RTC) to our teams. Again, we did not mandate these tools, but we have seen viral growth of RTC within IBM. Today, we have 57,000 users of RTC across 346 product areas. And I think the fact that they have adopted this tool on their own is a very, very strong statement about the value of this technology for agile teams.

What capabilities did you find that the product teams were looking for in their tools?

One of the things that the teams really wanted was better visibility to overall team progress. When you have a transparent view of the work items that are complete, the items that still need to be done, and team visibility into how certain tasks are taking more effort than originally scoped, it helps the team get better at agile planning and drives conversations about whether the team needs to realign resources to stay on track. RTC consolidates a lot of information that often resides in different tool silos so teams can get a more complete picture of the project. We could see all the work items, build status, test results and defects resolved all within a single tool, so people didn't have to run around pulling all that information together from multiple sources.

And as a manager, I was able to create my own customized dashboard that would tell me what work was getting done and who needed help. It gave me the freedom to move people around to ensure that dates would be met, and it provided a single reliable source of truth about the health of the project.

Our teams could also customize their own dashboards so they could collaborate within the context of their work. Teams gravitated to the tool for that reason.

Tell me about the software reuse initiative. What was the purpose of it, and what challenges did you face?

Component reuse is one the holy grails of software development. Everybody knows that if you reuse code, you typically get better quality, you reduce the risk of your development effort, you get better productivity, and you get more consistency for your user experience. With all of these benefits, then you have to ask yourself, "What were the inhibitors, why don't people tend to share?"

You can try to mandate reuse, but again, this really doesn't work very well. If you have ever tried to dictate to a developer "I want you to use this component", then you know what I mean. Inevitably they say, "that component is too slow, it didn't perform well, it crashed my laptop, or the documentation sticks!" But at the same time, we have seen that our developers are readily willing to search the web and find open source components that could be leveraged.

The problem with using open source components in a large corporation is that they require a great deal of legal vetting. It's a very arduous process to make sure that it's an open source library that meets IBM's use criteria. So it wasn't that they were unwilling to use somebody else's code. They wanted to be able to go find it, find what they needed, see if it would meet their needs, and then use it.

So how did you solve that sharing problem?

We decided to create a site inside of IBM that would emulate an open source environment, and we called it "community sourcing". It's essentially open source within IBM where you can create your own projects; share it with others; gain access to the code; and make your own decision about whether it meets your needs. Using a combination of Rational Team Concert, Rational Asset Manager and Lotus Connections, we've provided an environment that is conducive to community and sharing.

So far, we have over 30,000 developers using the community source site with 4,800 uses of components out of community source in our products now. We have components out there which like for instance, a component which helps us in our installation which has been reused by 152 products. We have one which is for security which has been used by 175 projects.

What returns did SWG see from this reuse effort?

When you look at reuse on that scale that I just mentioned, you can really see the value that it provides to the organization. We measured the value of a single medium sized component that was being used broadly and estimated that 140 people years of effort has been saved through asset reuse – that's significant cost avoidance.

And one of the nice benefits of this type of community sourcing initiative is that it connects people in new and exciting ways. We've seen people reaching across divisions and functional boundaries because they were using a common component. With the community source site, this type of collaboration happens organically.

Conclusion: What are some of the gains and improvements that IBM SWG has seen from adopting Agile?

If you look at the improvements which we have across the board, those improvements are having a real effect on our bottom line. Our number of headcount per product that is required to create a product is coming down. We think we have saved over $300 million in cost by doing these kinds of things. We see a 15% improvement in our revenue-per-developer headcount. I mean these are very real and tangible benefits that we think we have gotten from improvements in our processes and approaches.

And IBM's not the only ones reaping the benefits – our customers are too. The quality of our products has improved significantly. You can look at things like reduction of the number of critical situations, to reduced number of problem calls coming in, reduced scrap and rework. We are improving in these areas by about 4.5% per year, and our customers can see the difference.

Overall, probably one of the greatest benefits in becoming a more agile organization is the collaboration and the community aspect of the way our teams work now. By building extended communities of diverse groups of people across IBM, we believe that we can realize some of the idea sharing benefits that small companies typically enjoy while still leveraging the scale and stability of a larger organization. In essence, we're becoming a network of hundreds of agile communities within IBM. And we believe that this will result in new innovations that will benefit our customers for years to come.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Agile transformation on developerWorks

Zone=Agile transformation
ArticleTitle=Agile transformation in action