 I'm going to explain IDM on this topic. It's a mobile platform. It's not even an IDM one. So thank you. I don't know how I can thank everyone in the community for having me participate today, but it was a pleasure to have you. I don't know if I can call it out, starting with an IDM presentation. It's very dense. It's very technical, so I hope I can keep you guys awake. I've been in this for about 24 months, and I hadn't seen for that year. I came out of one of the brands in the software group where I led about 1,300 people in the local community doing software development. And they asked me to come to headquarters and talk about how to figure out how to start getting our teams to be more productive, building higher quality software. And so I said, sure, I'll take great development and figure out how we can do this within the idea of software. So I'm going to talk about some of the things that we've done, successes, the failures, and when we're taking our transformation story. So I want to get started. In general, under IDM, and I don't think this is much different from most corporations, you have a lot of common business dynamics you have to deal with. For us, it's always been about innovating to differentiate ourselves. We have some very key competitors that are consummate and have skills. They've been more responsive to our customers and to the market, and to play on release cycles from anywhere from 18 months to three years. We need to tie our links to our customers to the global IDM where we had dominated the market with main trends who were trying to expand out. And again, we had a lot of competition. We had to really fill the relationship of our customers and not just assume that they'll buy anything that we put out there. With time to value, our software is very flexible. Some people will say it's complex. It takes some time to configure and deploy. So we really had to work on improving the time to value from our customer's perspective to just be able to think of the value that can build their applications and structure our values. From a development perspective as a VP, I've really had to think about several things. Improving the predictability of our schedule to often with waterfalls. We didn't know until right at the end if we were going to shift. The quality of our products, we build a mission for the whole middleware and that's core of our business. And we actually put the quality of our products in the middle of the stage. As a VP, with a lot of resources, I had to maximize and use resources to invest in my ability and improve cycles. So I was constantly under pressure and constraints to improve these things and how would I go about doing it? So the story wasn't an agile now. The agile for us wasn't, you know, something that we looked at in 1991 or 1992. It took us a little while to react and look at what we're trying to do as an industry. So with that said, those dynamics, I want to give now to map that to what software we look like. It's only one division out of four with an idea, and I'll focus just on software repair. If you look at the size of software room, there's 26,000 engineers that develop software in the division. Our total size is about 43,000 pages. That's marketing sales, shopping sales and so forth. And we're very dispersed. We originally, I'd say about five years ago, had 161 development sites. We consolidated it down to 84. One of my teams, which was what's her core, had nine different sites. 350 people. So that's typically what we're up against within a development team. Very rare that we have anyone co-located anymore. Everything is very diverse. On top of just the geographical distribution and our size, our strategy has shifted to be more acquisitions to fill portfolio gaps or technical gaps. And so we average about 10 acquisitions per year. And since 1994, we've done over 84 acquisitions. And that adds to the complexity of building our software because you have to integrate the technology with the teams that hold the support. So that's just something else that compounds our complexity. So as I said, complexity is big within software. The multiple locations, multiple time zones, the acquisitions, and just there's a lot of productivity tendencies when we build our software. So we have to factor that in and we put ourselves in a product development sector together. So we really wanted to start to figure out how to transform ourselves and our journey was going on for quite some time. The most relevant and most successful point was when we started our agile transformation, but we learned over the course of moving through Waterfall. We had to move away from that because we couldn't deal with the three-year development cycles. The other thing that Waterfall was doing to us was that six months before we were shipping, we were doing our data testing and we get great requirements to feedback from our customers. But we had to tell them we can't incorporate this in current leads. So we put it in the next release and customers were not getting new features for almost six years. We had to move away from that. And in the 90s, we really wanted to go to iterations and we were being successful with the iterations but we still had a Waterfall mentality being that six months before we were getting ready to ship, we get feedback and we tell the customer again we can't incorporate it to this release. We were not getting feedback and we were still getting it in the release. So we were not satisfying our customers' needs. When Ansel came along, that really gave us the opportunity to get feedback and have more transparency throughout the release cycle. So we were getting to our quality certification checkpoints six weeks before we ship and figuring out what our notice state was. We had the transparency along the way so we were able to address our technical debt. We were able to address customer needs in the release and we were building things that were higher quality, faster time to market. So we started to see that and that's when in small pockets we said we need to do something more globally and more at a larger scale. So we came up with three principles which we tied to this transformation. Agile to deal with the uncertainty and market dynamics and the team dynamics and so forth. Being able to be responsive. One concerning act where my sponsors had at the senior executive level was agile is not discipline. I had to prove to them that it was discipline. I said well look, agile allows to deal with the uncertainty and we will put process in place the complexities being what are the business control that we deal with, what do we do with outsourcing, what are we doing with the geography of this first team. We married it to make sure that we had this discipline in place. The last thing we did was really to focus on the great best practices. Let's see if we can put tools around those best practices to accelerate or enhance and encourage the adoption of the best practices. That was another mantra that came about is that we always wanted to tie tooling to the best practices. Our agile journey really started in earnest in 2006 so it takes a little time to move the ship in the right direction and it actually in 2006 was not very successful. We had small pockets of experts but they had a hard time encouraging their teams to take risks and try to patch them out. So I came in in 2007 and I said okay I'll get the sponsorship I'll give you the right value so we started to figure out how to make this really happen. So our coach was basically 3-fold and you'll see a lot of 3-fold. Educate, enable and empower the teams. So create the materials, teach the materials, enable the teams to be successful with the tool around best practices and empower themselves to continue to self-sustain their adoption and that can be warrior-covered to be more education just helping them through their murals. So the way this started to get really up to scale at IBM for a women's soccer group is that you really got a lot of excitement the rest of it as well and I saw that because now we're starting to train the teams and start to feel really excited about it and it really started to create a demand for more education and for more teams to start to pick this up but they came to me and said I'm too scared I don't want to talk to my exec about this because he has a certain way of doing things he's not going to support this he's going to shut it down and so I promised to them as transformation execs that I would go to them and say look here's some success stories I need your support I need your encouragement to let these people try I'll provide the safety net we won't introduce more risks into the system and by having these few successful women taking them back to the senior execs and their teams talking about their success and the fact that they like this really got the bottoms up and the tops down support for us to really start to transform the 26,000 individuals so over the course of 18 months we've held, based on this workshop material that we put together with Mary and Tom Pockeby we've educated trainers now we've held over 230 workshops and trained about 7000 people in the course of 18 months and now with our surveys we do yearly we have 70% of the project teams and we have about 500 teams using one or more best practices so now we're starting to see that we're starting to sustain it because of grassroots movement and collider behind it and the user stories and case studies have really supported the success of the teams so that's been great now to sustain it I also looked at creating a center of competency and what I really wanted to come out of this when I think about transformation I think about how do I measure success is that I first started with a push line but I really thought this would be successful and self sustained I had to create the pull and so we started to see the pull come in and request for coaches to come out and to scale this and be part of their teams and to scale it out to large portions and so we started to see that that would occur in the mid to late 2008 time frame so we started to see that this was really a sustain itself the other thing that I wanted to make sure would not happen is the bottom we looked at too often people are afraid of especially when you come from headquarters I'm not here to help because I'm looking at a mandate change people just shy away from anything that's mandate so I just thought so what we what I always tell my team it's like no one's a mandate change or to measure or to motivate when the agile movement is all about motivating inspiring teams to change I did not want to go in and mandate because I knew people would just be turned off by that because no one likes to be told what to do and so that was the other element that I think made our transition and transformation really start to stick is really going from on the motivation side now we're working back to how we measure and how we continue to sustain this so that's the model that we're trying to use so far so now that I've been in business for a couple of years started to see some success my aunts is asking my state of government has shown me some business results showing me how this is really working and I haven't come up with a set of metrics that we don't do this without being measured so we wanted to go up with some core lines that would increase the values and also have value to just understand more and more so we looked at team productivity the quality of our products the quality of the releases getting better the release have to release we're looking at whether we're satisfying more of our stakeholders feedback and incorporating current release and we're just looking over all cost development this is the basic starting point that I wanted to start to measure across the portfolio I also established a framework called e-square which is really effectiveness plus efficiencies efficiencies to be gained by the lean elements in eliminating ways effectiveness is really measuring is already providing enough business value and I wanted to measure both it should be efficient but might not fill so I wanted two dimensions to really look at how to increase the revenue profitability so we put this framework together and started now you can see here we did some trend analysis really what this is saying is that team sizes have gone down what we've done is we haven't eliminated those people we've reinvested them and what we'll see with the the document lines is that we've actually made more products per year and that again to the business we're just showing how we're reinvesting and putting our product and putting more out per year the other thing is that our team size has decreased and what we did is we reinvested those resources and building newer products so our average team size I would say seven years ago was in the 500 to 600 range for now in the 50 range so we've really dramatically reduced team size and that helps reduce complexity in the rest and so forth and so that has really allowed us to go into new workspace opportunities and we also measure on bottom line growth so we're looking at headcount revenue per headcount and that's something that's the finance guys to see so we're showing us there's been a positive trend of revenue dollars per headcount so that's kind of the core metrics that I actually get back to the business to show how we're improving we're being more effective so this has been going on as I said for about 18 months now so it's really the agile is helping us so we're starting to see other things start to move so we have to address the key one is that leadership roles evolve with the agile adoption I had so many people coming to me saying the gear box is broken but the project managers don't know how that's what their role was in this and so the first line manager or the director of development what role am I playing now is how do I facilitate to help my teams because they seem to be self-organizing and seem to be handling a lot of stuff but what is my role now the other thing that we learned along the way and I think everyone experiences this especially in this economic challenge downturn is that we're dealing with more constraints we have less flexibility but we're still told to innovate we're still told to hold to our development so with the evolution or the change in the leadership roles and the fact that we have more constraints I really wanted to start to say to the next turn the crank as far as education and teaching and propagating to continue to have this movement move forward so I asked two questions over the course of October 08 till about March this year tell me what's not working I surveyed approximately a hundred a little over 200 people on this leaders in the and they said and I wasn't quite surprised what came out poor planning lack of vision things keep changing our processes our legacy processes are absolutely killing us there's no flexibility we can't seem to modernize anything that's slowing down and there's too much micro-management lack of ownership within the teams the leaders perspective so they weren't feeling empowered the other question I asked is what do you need from your leaders and that came up with some very interesting things as well which I don't think a lot of people would be surprised about but you know it was good to see it on paper some of the things we trust peers trust each other but they never trusted that was consistent so I would talk to a second line manager team and they said you don't need to trust my peers trust them to tell across the table and then I would I said do you trust your manager well I kind of trust my manager so you know above that we didn't really have any trust and then I would bring their bosses in and ask the same question they'd say at the peer level they're fine but then they'd kind of go well do you trust your VP yeah but how would your general manager and not so much trust them they also felt they needed an open environment to be able to share their ideas freely and not feel penalized or feel like this was a very clear career of limiting so that is where we're at over and over again a fed for a more you know hands off or a step in back approach I don't mind if you set the constraint I don't mind if you set the budget but let me figure out how to do my job don't tell me how to do my job as well they wanted more communication they felt when information was held back it fostered the lack of trust and the lack of having an open environment so we really are starting to think about how to over communicate and how to foster that information sharing teams want to take more risks we want the leaders to support them taking the risk and you know if they fail not to be completely relaxed about what they're going to learn they want support from their senior executive teams it's really really important and they need to be overcome the other thing is they needed a clear vision and strategy they wanted to be part of that as well because it was just too hard to explain to their engineers what it was and how to move forward and be able to construct the right project and the last thing is just being empowered being empowered to make decisions being empowered based on the information they had to self-correct or make course corrections throughout the project so those are the top things that the engineers wanted from their leaders like I said it was very consistent as we went through the engineering process off the line nothing changed it was very very consistent so now we're at the point where we're involving the leadership role based on that criteria and so some of the characteristics that are really trying to encourage and try to put a workshop together around this around some critical things here can reinforce the leadership to the teams don't tell them how to do their jobs allow them to take ownership and to run with it as a leader we have to create this culture of trust you know make it safe make it so that they feel that they can trust each other very critical making better decisions was last term I don't know how it is in some of your enterprises but we get a lot of plan change to request to run a release cycle I counted in the nine months release cycle what was for the world drive we had 600 plan changes we spent more time arguing over plan changes than writing code so we took a lot of charge and the reason why we were having that charge is because we didn't have good decision filters we couldn't map back to the strategy we weren't sure what the strategy was so we argued we argued with these plan changes and we just wasted a lot of team it was very much productive as a leader and I admit it was the best of this when should I step up what's the red flag of our team that's counting to help provide guidance without cycling and innovation that they're trying to do we get classified with different characteristics I always like to get my hands dirty help teams out now I'm trying to take a different approach when do I step in and just keep the focus there so that they can go into their jobs not telling them how to do the jobs another thing is just removing obstacles we have a ton of obstacles in IBM just getting travel approval takes about five levels of approval so how can I eliminate some of that or how can I take that on and not keep them distracted working on getting travel approval requests but just removing those barriers and influencing versus being dictatorial especially in this role I have now where I don't have 1,300 people working for me how do I influence and inspire another bay of people to guide them to the right set of decisions versus telling them what the decision is having them do more to their experiences so we created this workshop really about collaborative leadership and with help from the Excel and OVA helping group we started to put a workshop together and we really feel that collaborative leadership will allow us to innovate will allow us to deliver more value and have our teams be more productive the key thing that we're teaching the leaders is that the answers are in your organization you really need to stand back and let them deliver and we're teaching them how to do this with a set of tools the other thing is, let's assume what I did with just the admin movement is I'm creating tag lines and I'm branding this people can identify with that so we're coming up with something that we're anchoring with a smart planet notion that is very strategic for our VM work smart lead smart, collaborate and allow you to innovate allow you to engage with talent we're starting to spread this out with a website to talk about how we can do this so we've been at this now for about three months and we're starting to see some success and I'll share with you some of the few things that we've started to see leaders are very much now empowered to change things that are going to go through this it was an interesting story when I was bringing this up to my manager he was just coming in the organization and I was trying to give him over a core delt on what happened to me and I showed him the results from the surveys we were taking and I said well trust, open fire and he said she can't fix that I said well I'm glad that you can't but what we need to do is tell or encourage people to fix what's in their scope and people can feel more comfortable about that versus just saying well I don't know how to fix trust and so people just back away and give up so with the tools and with the techniques of cloud leadership we have started to see teams taking more control of what's in their control and that's been very empowering to them wow okay I understand that trust is basically an issue how do I fix trust with my team how do I fix trust across teams are the teams that I have to work with and we're starting to see teams actually step up and do that we're seeing lots of time saved on doing planning because we're using decision making tools and creating decision filters the productivity of our teams because of less churn has gone up tremendously that's been a great time saving for us building trust is another thing and how do you build it across and especially when we can't travel on a German team they pride themselves on having face to face discussion about how they instantly build trust so now we have very limited travel across teams so how do you now build the trust across the specific teams we gave that to them the problems on and they figured out how to use collaboration tools and technology to start to build that trust albeit if it happens a little more slowly they're still starting to build the trust across the teams we're starting to see teams now collaborate together in their silos to set goals and objectives when we release and that's really helped because then they can transform them into something that's meaningful to their engineering team and that just makes it clear on what to focus on focusing on essentials focusing on what is really needed for that and we're starting to do more about asking questions and focusing on discovery through questions instead of just telling people what to do and as I said this is hard for me to do and we're very busy the last thing I want to do is ask six questions when you know the answer and so we started pattern this and tried to teach teams how to go about doing this and the fact that they may learn they know they applied their experience and they know the next time how to solve this problem some experience is said I'll just be wrapping up now using some of the decision making schools we have found that our plaintiffs like to say that we just do not we have a product of a transaction service called KITS they're released like for every two years but they're actually doing an action while their planning support release takes about three months and they have to sift through I think anywhere about 10,000 apartments they have gotten down to release planning cycle time in those three months down to three weeks because they now have better decision filters and understand what your customers have had discussions and dialogues on what's really important and what's essential that's one experience this experience was my own personal experience because I came into this organization and I knew just from my own experiences as a VP of development that our quality management system was broken and I tried to have discussions with my peer VP who owned the process and said Bob you really need to get out there and talk to the VP because they're just gagging over and they seem to we seem to have impacts think everything is wonderful but when you talk to the development they think it's a piece of crap so I said why don't we get together and try to have success it's fine but I really don't think there's anything wrong we got in the takeout first we started trading emails and emails were quiet at first we really need to change the quality management template what did you mind considering that and then we just got some from the quality so the emails sort of escalated and we're not as pleasant so I said ok let's get in the room because somehow we have to resolve this and it's just a whole rise amongst a few here and I was talking to Paulina I said look I don't know how to resolve this because it's just there's such an impact and every time we try to share facts it doesn't become a fact she goes to me and she said you have sticky notes IBM exists they like to argue they like to insult each other they don't like to quarrel I said well you're a bitch because that's what you're getting she doesn't want to try and so I said so we got in the room and I wasn't going to do it so I first said ok let's sit down and try to start the quality accepted sound once I'm on the table, the dub accept sound this is going to be a problem so it's ok who wants to who wants to throw up you know some of these things have to happen so one of the dubbys sort of leaned across the table and said this dog is quack and I said ok let's do sticky notes so we actually did the sticky notes and I said what's working and what's not working we grouped everything we got five big issues that everyone was in agreement had to be discussed and we actually signed those work writers out and we've actually made a big change now granted this took over a year or two I've been sticking up the session for four hours but we all came to the table and had a what's going to be very confrontational we've had a very emotional discussion and called out things and people didn't realize that we're going to and so now we've made that transformation by actually incorporating those changes into the process and the teams in the example with the dog but the collaboration and the fact that we used these sticky notes in the military really worked well to deal with confrontations so the two main examples here is one using the collaboration to deal with the conflict and using tools to help speed up and create appropriate decision filters so that they prioritize so that's really helped out a lot Part of the thoughts I think this is again, we're in the journey and I think the journey started with just trying to implement it and implementing it with tooling and best practices we're now evolving off from that because I think we've had some kind of sustainability looking at what's the role of a leader how do you introduce more business value into the releases so you really improve that time of value to do this when we do this transformation to now saying what is the leaders what does the leaders look like in IBM I have to part the problem right now, besides just grading the workshop materials on the leadership we're partnering with our corporate HR team to see how we can get integrated into the basic learning in education for our managers for our executives and we're also working with our learning teams to make this a full line of clients and we have some of the IBM values the IBM values team just trying to incorporate this so we have a very consistent message on what leadership is in this new world and that's helpful so we're getting a lot of support across IBM this is just not now soft for you IBM is coming back and the other thing with anything that's either new potentially computational you have to figure out how to get the support for the senior leaders so that they give the right air cover and they give the right safetyness to their teams to try to experiment maybe fail but to work in this village and to move forward so that's the story of where we are right now it's been quite an exciting journey and when I first took the job my god said you failed the IBM chance because I don't know how you're going to get a chance for 26,000 people there I've really enjoyed where we've taken it whereas you can really see that Azure this doesn't apply to small teams, political and KDA teams we've actually started to see Azure in the enterprise quite exciting I have to say that I've learned a lot from the conferences that I attended in many people how to apply this in the context of IBM so thank you and I'll take a couple of questions productivity and why is it worth majoring productivity can be a couple of things we look at in simple terms people will disagree with me but it's how many user stories we can do within a generation another productivity tool is we're starting a productivity mechanism we're coming in our weekly cycles we're getting shorter we're coming down from 18 months to more or 12 to 9 months release cycles and so those are the two major ones that we focus on and then we're seeing that our team sizes are getting smaller our organizations are getting wider so we're really pulling those resources to work on white space so those are some of the productivity measures the capacity measures that we're applying to measure we're getting back you mentioned the decision-making software can you talk about that a little bit we're working with Excelanova on this purpose alignment tool and just a business value model and it's very straightforward I have to say we teach it in a couple of hours you can start to use it so I can talk a lot about it to Excelanova and the other clients is they're really teaching us how to use it but it's a straightforward quadrant with some simple little things of when you decide on differentiating requirements versus parity requirements versus when you partner and who cares and that has helped a lot you know, in terms of aligning the purpose with the strategy and then use it and then define those decision filters that align with what's important in the release and they can go into more detail on that I don't want to have to steal their blender yes you run your business analyst and you're through the same yeah, we're starting to so the question was do we have our business analyst go through this we're starting to do this it's going to be more on the leadership side they make more of the business decisions so we're taken through that element we're part of the development teams and we learn along the way we all offer our education to everybody but they don't typically go to those workshops they tend to be more learning on the job and they don't have any issues with that but we will take them through this collaboration training chairs so I think it has more value to them yes you mentioned some of the executives who are nervous about risk what kind of safety can we really offer them in terms of reducing their risk the question was they were nervous about this how do we mitigate risk by safety there were two ways of doing it at first some of your teams are really excited about this by the way it started I'll provide a coach and then we'll put together an approach and identify pain points within the project of what best practices are most suitable and most likely can be applied to that project so we're very prescriptive in the study we did the analysis and determined the readiness of the project to even adopt a best practice instead of teams just going off and trying to figure it themselves the other thing is that we took low risk products through that effort to get the success and so that was the safety and the care there wasn't a lot of loss from failure so that was the other way of doing it so we didn't take our big corolla project there were a thousand people in the organization we did not put those terms first yes what do you see as your speaking points inside your teams now you mean like what obstacles what are you running into with them now well it's still cultural so what are some of the speaking points or obstacles that are still part of the transformation activities I think on the leadership front there's a real angst about I'm asking I'm telling you is that their style is obsolete I'm not going in saying hey you're a bad leader we're saying here's some things that you can do to improve your leadership capabilities but still they think that's right so that's the big thing I'm coming up against now especially when I'm going to talk to my want to assume reports into the CEO they're not going to want to hear that approach it's not threatening just to say hey your teams like this just support them I'm not telling you to change so that's the one thing the other thing is on the just the the whole average transformation response is getting enough tools and consistency in the application of the best practices you're looking to use a team for their problems it's um I'm not saying it's it's different for every team you know I have one team that tried to do agile and they didn't know what continuous integration was and they didn't automate any test cases so that was you know they were just a trainer there's other cases where they love the notion of no documentation so I had two teams one did not document a detail they didn't fix it neither they just involved in saying that's huge backlog how big is that one they didn't document a detail so the thing is the idea is so big everyone interprets things differently so you always find different snags within organizations so I just have these worst arrays of them it's just amazing and they argue let's see okay they argue it gets to the dog you're not agile enough stop don't have this like but they would go back and forth saying well this team, so did you know this team's not agile but they're doing something with that that's all I want so you get into these these wars and that's who most is coming it's all up to the interpretation of the personality of the leader really kind of screws things up any other questions you had this slide where the you said how do you how do you tell them to motivate you have to give them tools you have to give them they have to be able to so the question is how do you inspire or motivate change the change and we really have to provide these sports but I have to say everything now I did rounds yesterday I did create a very safe environment for them to learn and make mistakes and not to penalize for so that's most of the difference what did they specifically change so that people would become motivated before they weren't motivated now they are because they felt they had the questions what specifically changed it was really just feeling that it was an open environment for the state to understand that and they weren't going to be penalized for that is there one more question sorry so the question was what problems have I seen with interdependencies between products well this is not one of the this is one of the lessons learned I can't even put purple on this page it's so bad there are times when you start to combine our products so if you combine our app server with our navies we can't have even a number of interdependencies and we counted up to 266 which is something huge and that's not even about the IPI that's just all the pre-rex the co-rex, the fixed pass the IPI system that you haven't done on the ADA IPI we really were not doing very well either because teams were getting guys and not a lot of people and so we test cycles exploded because we did not so we have an architecture board now in place that puts certain governance and guidelines in place around deprecating API's around what versions of job to use, what versions of clubs to use and trying to mitigate our fixed dependency between the places between the processes I don't have this on my title but my real title is transformation and integration so I have to deal with reducing the complexity of the prior formation there's no more questions I really appreciate the time sorry because it's difficult