Exclusive Interview: VP Sue McKinney on IBM's Agile Transformation
If there were ever any doubts about agile's ability to scale within large organizations, Sue McKinney might have some encouraging words of advice. The VP of Development Transformation within the IBM Software Group spearheaded what is perhaps one of the largest agile transformations the industry has known -- successfully moving over 25,000 people from traditional develoment approaches to agile. In this exclusive interview, recorded at the Agile 2009 conference in Chicago, Sue talks about some of the communication, tooling and technical challenges she faced during the project along with the new leadership skills that teams must encourage and nurture to build a successful agile enterprise.
The complete transcript of the interview has been provided below.
DZone: Sue, can you tell us a little bit about yourself?
Sue: Sure. One of my responsibilities as the Vice-President of Development Transformation is I work in the CTO’s office out of Software Group, where I'm focusing on improving the effectiveness and productivity of our development community. Roughly, the development community in Software Group is about 26,000 individuals. I was asked to come over from the Lotus division, where I was the VP of Development there, to see if we could build on the success of doing Agile development in Lotus to see if we could scale it out to 26,000 individuals.
We started back in 2006, and one of the interesting points that happened back then is that we had a lot of grassroots excitement. However it was very ad hoc, so you couldn't get critical mass. You couldn't get it to scale. I came in 2007 and said, "How can I help? I had some success with doing Agile. I'd like to see how we can scale it out."
So we started putting some formalized education together and getting a couple of practitioners to train, not necessarily 26,000, but pockets of people who were very interested in Agile. And so over the course of the last 18 months, we've done about 200 workshops, and we have trained over 7,000 people.
DZone: This sounds like it could very well be the largest Agile transformation in the history of our industry.
Sue: It could be. I don't know for sure. I know there are a lot of large corporations out there like IBM that are trying this out. We've had some success. We have probably 75% of our development teams using one of the best practices out of Agile. They get to pick what they want to work on based on their paying points. We go through an assessment with them on what's the right thing for them to pick up first. Then they go about, and we give them some guidance along the way and some coaching along the way to make sure they are going to be successful. So, is it the largest? I think we had some very large distributed development teams that have done it, up to a size of 350 over nine development sites. From that perspective I think those are some of the larger ones. When I go to these conferences, I hear some great stories, as well. I want to learn from them as well.
DZone: What were some of the initial challenges in undertaking such a large project?
Sue: Well, I think there's a couple. One is providing the right tools and the right education and the clarity of the message. What I mean by the clarity of the message is everyone knew about the Agile Manifesto. They were all excited. You know, people over process, working code over documentation, and things like that. Well, in an IBM world, you even have to synthesize that more crisply so that people don't get into these arguments of, “What did you really mean?” So we took the time to actually simplify the manifesto into one sentence, and it took us six hours to do that because we were arguing and deciding what are the right words to put in there. We basically made it come down to, "Short, time box iterations with stakeholder feedback --working software." The reason why we did that was we wanted to implicitly drive change without me telling people to change.
So when you start to look at those words and then you say, "OK, we recommend an iteration to be two weeks or four weeks, no more than four weeks." Some teams were actually doing one week.
Things have to change. You have to now think about automated test suites. You have to think about continuous integration. You think about being more careful in your check-ins and so forth. So I didn't have to tell the development teams what to do. Just by that one sentence they knew that they had to change in order to be successful. That's the type of change we were trying to drive. That was very critical for our success, to get to a very crisp of what we were trying to do.
DZone: What were some of the communication challenges you encountered?
Sue: Well, yes, we are very diverse. As a matter of fact, we have 126 different development sites. So that's a lot of land to cover to try and get the message out. But we would make a point of going to the different sites, spending a week there, specifically if it was China or India where we had to spend more time, to make sure that they understood the message. We would have follow-ups with them. We would also bring coaches over there to help them get started. The one thing we didn't want to do, or I didn't want to see, is people fail and go back to the old style. I wanted to avoid the trough of disillusionment. So providing the coaches, providing the ongoing feedback. I would even, after a workshop was done in China, follow up two months later by going over there and asking, "Where are you getting stuck? What have been some of your successes? What else do you need from me to make you successful?"
I'd understand those breakages. I'd understand those obstacles, and then I'd go work on them. One of the lessons learned was that I got a lot of success at the engineering level, but then the corporate processes were getting in the way. They were just old, outdated, inflexible. I said, "Oh, my gosh. What am I going to do? I have all this excitement. I don't want them to get frustrated."
What we had to do is start to modernize the corporate processes, to move them away from being rigid, [with] no transparency, very waterfall-ish, into something that allowed some flexibility. That was probably one of the first things, when I was traveling around the labs, that I was constantly hearing: "You've got to fix the processes." I had really not anticipated that being the immediate thing that I had to fix.
The other thing that we heard from the teams is they wanted executive buy in. Because I had the grassroots really taking off like wild fire, but then said, "Gosh, I don't know. My boss is a little uncomfortable with this. They are not sure if we should go and do that."
So while we had the momentum at the bottoms up perspective, the grassroots level, I worked from the top down. I was coming out of headquarters. I was talking to the execs saying, "Here is some success. Your teams are clamoring for this. They have been successful. They are hitting their dates now in a more reliable way. They are working on their technical debt."
So the execs, it didn't take much for them to buy in because they saw the improvements. They saw the moral improve as well. They just blessed it and said, "OK, Sue. Just keep them on track and make sure we don't derail. I trust that you're going to take care of these initiatives." So, we had to work those two major issues to kind of get things started.
Continuing on the communication thought, we also made Agile a branded thought. Getting Agile at IBM or being Agile at IBM. We created our own little branding logo, a whole world wide communication around it. Every quarter we'd have an expert come in and talk about their experience and where they've been successful and what they'd do differently if they had the opportunity. So that's kind of how, when you're trying talk about 120 different sites, trying to get people started. That's kind of how we worked on going forward.
DZone: So, some of the ingredients it sounds like are to develop grassroots interest, wherever that's easy.
DZone: Start small. Show success at a smaller level.
DZone: Then demonstrate that to decision makers in other departments, and that is a way to scale Agile, potentially, across multiple departments and organizationally.
Sue: Absolutely. That's really how it worked out because historically you would see that most initiatives are top-down, pushed out. We actually created this push and pull mechanism. So I knew success was starting to happen when people were coming to me saying, "I need your help. I'm really interested in this." I would be worried if it was constantly a push mechanism where I'm just pushing things out, where people are just saying, "Oh gosh, another initiative coming out of corporate." It was good to see the momentum had switched to be more of an opt-in, I'm really excited, a pull mechanism. I saw that something was working, and let's take it and continue with the momentum.
DZone: Did you notice any differences in the dynamics between how small teams of say 30 people adopted Agile versus larger teams in excess of 700 people?
Sue: Well, yes. One of the things that we did was we didn't prescribe that everyone had to do it. We said, "Look at your pain points. We'll provide a coach to you. We'll do like a health check or a readiness assessment to see if you're ready to do Agile." Based on your pain points, we'd say, "OK, you want to focus on your debt. OK, here are some of the things that we give as best practices and techniques. Or if you want to focus on continuous integration, here are the things that you would need to do to be ready to really work in two week iterations or four week iterations." So those were some of the things we had to do to get the teams ready. Now, team size, yes, I think that makes a difference. We, I would say categorically, have no collocated teams anymore - maybe a handful. Most of our teams are distributed. Some of them can reach up to 800 people. Communications are critical when you are dealing with very diverse and geographically dispersed teams. Those are the things that they are focusing on the most.
Also, they focus on the different handoffs between the organizations or between the teams, making it as crisp as possible and compartmentalized as possible so that you can show the accountability as well, just organizing in such a way that you minimize those handoffs.
That's probably been the biggest challenge, and that's where the role of the manager changes to focus on addressing how you optimize your team, make them more effective by how you organize the work and how the work is scheduled within the iterations. I think those are some of the initial changes.
DZone: So, obviously there were a lot of front line team leads and people who were in leadership positions to affect such a wide change. In an ideal world, what qualities should an Agile project manager possess?
Sue: Well, it definitely changes. That was one of the biggest things, I think, that people had concerns about. The role of the project manager changes. The role of the architect changes. The role of the first line manager or middle manager changes as well. We found that because the leadership styles have evolved, we are now injecting a whole new workshop on the role of the leader. It is a one day workshop that we are putting together that is customized to be what we call collaborative or participatory leadership where you empower your teams to make the decisions. You push the decisions down as low as possible because they are working in the bowels. They understand what the issues are. You have managers and leaders step back.
I had to change my own role as well. The way that I started to do it was that one sentence statement: short time box iterations. That forced the behavior change. I didn't have to tell them, "OK, you're going to have to look at continuous integration. You're going to have to do automated testing." That just came about.
What I would look for is I would have my own mental red flags of when the teams were struggling. Instead of just stepping in, I would watch for those red flags and then come in and ask questions. So, it was a completely different style for me because I was always a problem solver.
Now, I was trying to step back and let the teams solve the problems. Let them gain their own experiences and catalogue their own experiences so that they could be more successful in the future.
It was hard at first, and it's definitely a different way of managing. So, we are spending a lot of time now over the next year to talk about how you lead and manage in this environment. I think it's helpful because it really is walking away or moving away from command and control.
I think most people or employees don't want a command and control approach because you don't have ownership anymore. You just feel like you're just doing what you were told to do. There is no sense of satisfaction there, per se. So, that is where we are shifting everything.
DZone: Offshoring you mentioned was a big challenge. Beyond communication, were there any other issues related to such a distribution of people working on these projects?
Sue: Well, it was their skill level. In one of my projects, we had our functional test done over in China. That was a good starting point for them. It also was compartmentalized to some extent. But in that one release, they learned a lot about the inner workings of the product. The next release, we started giving them more work. The key thing is that we had to make sure that there was line of sight on what they were doing and what they were accountable for, and that they had ownership of things. If you don't have ownership, you're just going to get sloppy work because you can blame a bad check in on almost anyone. We made sure that they felt they were a part of the team. That they were a part of the problem solving and a part of the iteration planning, even though they had an entry level type job.
Now, they understand the product more, so we are giving them more work. So, that's how we've been dealing with the offshore. As that skill base gets more experienced, we are giving them major responsibilities for now architecture and design and development.
DZone: So collocation isn't necessarily a requirement for successful Agile adoption?
Sue: No, and it's just not in our nature. It's just, I would love to have a co-located team. I don't, you know. I have a lot of frequent flier miles. It's just not going to happen with our acquisition strategy and so forth. So we're always going to be highly distributed. We try to optimize around that. We're always looking at optimizations, because you think about all the IT infrastructure that you have to deal with and so forth. So we look to do better, but the first thing is we organize the work and the management hierarchy in a way that eliminates all the hand-offs and all the task switchings and things like that.
DZone: Were there any particular tools that you used to help facilitate the transformation?
Sue: Well, what we tried to do in a lot of cases is whenever we created some education, we always tried to create a tool with it. Or point to a tool. And it was open source, or it was a Rational portfolio. So we do rely a lot on what comes out of our Rational team, for the development life cycle. And we've had successes around Rational team concert. We've had successes around Build Forge and RSA. So we put a cookbook together for the teams to go and look at. And based on what they're trying to resolve or improve or optimize, we have this list of products, open source or within our own portfolio, that we would recommend to the team. So we've had success across the board.
You know, every team is different though, so it's not like it's one size fit all. I don't tell a team, "You've got to go and do this with this product." You do what's best for your pain point and for your situation.
DZone: Now you had set up what's known as an Agile Center of Competence (COC) as part of the project. Can you talk a little bit more about that?
Sue: Sure. This was again to create the pull mechanism. But the other thing that when I first came into the organization, there were a lot of evangelists out there that were theorists. And so I knew when I was back in the brand teams doing development that I really didn't need a theorist to tell me how to do my job. I was the practitioner. And so what I wanted to do was create a Center of Competency around practitioners. People that had been through the wars, have the scars, and they can tell you or help you resolve or overcome an obstacle when you're trying to adopt Agile. So I wanted a very credible group.
I also wanted it to be very small, because I didn't want a heavyweight approach. So I already have a team of five experienced practitioners that go out, and work with teams either through the entire life cycle from concept to ship, or they come in and they work on specific pain points that the team wants them to work on.
And I'm very selective on that. We want to work with teams that are willing to change. So if we come in and say you need to change, or you need to adopt continuous integration, and they go "No" – well, you know, we can only go so far. You can bring a horse to water but if you can't make it drink, there's not much we can do about it.
So we created a small team, but in the meantime, we also -- within the different brands -- created coaches. So this is how we were scaling out. We want to keep the centralized headquarters team very small, and work to create the viral adoption and the scale-out within the brand so they have ownership.
DZone: So there's one coach for each of the different five product divisions?
Sue: Yes, five product divisions. And they had a good understanding of that division, because every division is different. If you think about working on database servers versus working on instant messaging, it's completely two different worlds and two different ways of developing software. So we had subject matter experts for the brands. And then we have other people within the server group that saw what was going on and saw the success and said, "Hey, can you help us get started?" So they really took our assets, and we're helping them jump-start it so they can apply it to the hardware side of the business.
DZone: If you could go back in time on this project, would there be anything that you'd do differently?
Sue: You know, I wish I had anticipated that for every team that I got started, some of the process changes that had to happen. Because people were just getting frustrated. I wouldn't say that we were about to lose the momentum, but it was something that, to make a process change, it's pretty significant. And so I wish that I had anticipated that a little earlier. Other than that, the things that keep me up at night, I wouldn't change anything, but I would say, "I want to make sure it's self-sustaining." And my goal was within the Software Group by the end of 2010 it was self-sustaining. So I really didn't need a COC or the COC would now focus on leadership.
And so that's what I'm trying to look at next. Where is the pup next? And I think it's around the leadership capabilities and improving that. And in looking to make sure that we are improving the overall productivity and effectiveness of the team. So I'm refining it from just being. The Agile gearbox is in place, and I think it's almost self-sustaining, so I'm not worried about that as much. I think the teams are powered to keep that going. But where do I have to focus next?
But I would probably emulate, or replicate what happened as far as getting the grassroots started, getting the tops down, buy in, but not the meddling, and then try to replicate that with any other transformational initiative that I need to bring forward.
DZone: What advice would you give to companies looking to scale Agile across multiple departments, larger groups of developers?
Sue: Well, I would say the journey is still continuing. I will never declare victory. Because everyone does implementation differently. But for most, anyone who wants to get started, don't give up. It's going to be hard. I think follow-up and having the senior executive support is critical. So someone's that going to always be out there saying, "If you have a problem, come to me. I'll make sure that we get through it."
And I would always tell people, be responsive. If someone has a simple little question, make sure you answer it quickly. Because you don't want to build that disillusionment. Because it's easy to go back. And so you've got to create the momentum.
It can be done. I think when you start to get people through successful projects, so you build up those successes and you have them write about it, they actually feel good about that, and they're happy to share that. So take advantage of that, or leverage it, when you're trying to scale it out.
Because people do want to contribute. And no one wants to write bad code. No one wants to be in those death marches. And so if you can bring anything, if you can show a ray of hope at the executive level, people will really feel comfortable about it.
But you do have to get that executive buy-in. And scaling out takes time. And don't set your goals to be too lofty. Work on just getting a couple small successes and building off those. And you'll be surprised, I think you'll get the momentum.
DZone: Sue, thank you very much for your time today!
Sue: Thank you!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)