Let's talk about the Agile rollout, at Salesforce. Salesforce started as a small team, and they, just normally did very quick releases, four weeks. And then, they found as they grew, that became six weeks. And, by 2007, they were having a lot of the dysfunctions that you get from a company, or team, that's implementing a waterfall process that isn't a good fit for them. So they would release and customers weren't finding the product content relevant. Nobody knew what to do about it, everybody was sort of blaming each other, stuff like this happened, and their product cycles were so long that at any given time, they would have lots of employees that were in development that had never actually done a release. And the employees, the developers felt like they couldn't see their content working. There was a lot of the confusion and hedging. And conservation you get with big long cycle releases. So, they decided to take a look at Agile and after some examination, they decided to do it all at one time across the whole company. I think they call it the big plunge or the big bang. And this is unusual, I think most practitioners would recommend a more organic roll out, but by most counts they made it work and they made it work pretty well. They rolled it out across, We've roughly 200 people in the development organization, over a period of months and I think they measured that 80% of their teams felt that they were self organizing and it was going pretty well after they'd gotten their practice under way. And there are few resources here where you can read about this and more detail if you're interested And I will point out a few high points from both the lessons learned and the kind of things that they would do differently if they did it again. So let's talk about the outtakes of things they thought were really important. One is that they saw how important it was to have the executive commitment that they had and the example they give is that. They created a fixed date for their Agile release that they were going to do. And so when you fix a release date in Adgile the content is the thing that has to provide the slack. So if we don't get everything done, we're still going to release and may not be everything. Well there were certain parties that didn't want to do that. They wanted the content in and some others felt that it was important to keep the dates so that they were starting to get quicker releases. This is going to be a hard adjustment and if the team overall, the executive team, isn't behind it, it's probably going to be really hard for everybody to make a decision and avoid arguments and too much turmoil. So, they found that was important. They created a Cross-Functional Rollout Team. Now remember, it's important to keep in mind, this is for a massive all at one time roll out. So this, we talk about the importance of whole teams, interdisciplinary teams, in Agile and that is important. Do you need a cross functional Agile roll out team? Well, if we're going to do it at this scale I would say it's very likely that you do. And if you're going to get a whole bunch of testers for instance to do Agile all of the sudden, well you probably need people who have really looked in a lot of detail, talked to their peers, read up, practiced to be able to take that to other testers and explain what that's going to mean. Because if you're going to do it all at one time across such a big company, You probably need a pretty specific idea of what you're going to initially try that you can communicate and coach a lot of different people on it. They found that was important. They found it was important to focus on principles over mechanics and I think what they mean by this is. The didn't oblige the teams to very specific Agile practices. They left them a certain amount of discretion. You'll see later, they also found that they wished that they'd provided more rules around Agile. And by that, I think that they mean from what I gathered, that they wish they'd delineated more carefully what are the essential things like for instance making sure that the software at the end of an iteration is potentially shippable. This is a thing that if you're doing Agile, you gotta do it. Whereas certain other practices they wanted to leave open to the team's discretion about whether they practice them or not. A focus on automation, they mention that they already had a very extensive automation for building and testing and they regarded that as an important thing. And the team that wrote this paper and was the executive leads on rolling out Agile mentioned that they feel like this created a major tailwind to help them along with the Agile process. That the degree of automation they'd achieved made this transformation a lot easier for reasons that you've learned about and the importance of short cycles, continuous integration. They provided radical transparency. The rollout team the senior rollout team would have open meetings and anybody can come and hear about what they were grappling with and what they were working on and. They use professional training. So to do it this quick at this scale, they used outside training and outside coaches. Though they mentioned that they did bring in their own two-hour module that they gave to the individual team members that didn't go to outside training. Now we're onto lessons learned. So these are things If you read the paper that the executive leads wrote. These are the things that they wish they'd done differently or things they wish they'd emphasized a little bit more as they went through the process of rolling out Agile. They wish that they'd involved more contributors early. So that they brought more people in and asked them how things are going. One example of this that they give is the use of unconferences. Now, you may or may not know what these are. This is a format of meeting or conference where the attendees come in and they present things they think would be good to work on and talk about in a meeting or workshop and then the entire audience has a chance to vote on those. And if you have a threshold kind of like or backlog of things you're going to present, say five and there's ten things, well the top five things with the most votes are the things that you end up working on. This is a very self organizing way to figure out what's important and what you should be. And they wish that they did more of this early with the individual contributors, things like this. They found that they wanted more training for the product owners. They wish that they'd gotten more of the product managers and program managers, primarily the people that they put into these roles, they wish that they had gotten them to more training earlier. They found that for product managers who's used to working in a waterfall environment, the immediacy and the amount of guidance and day to day work with the development teams that they needed to do was really different than the way that they were doing things at their old jobs and that they wished they'd done more training to prepare them for that. They found outside coaching valuable and they wished they'd prioritized this test infrastructure even more, which I think is notable just to kind of flog this even more, the importance of automated testing because this was already a really big asset for them and a thing that they had, to a certain degree. They found that it was useful too and they wished they'd done more of giving the executives actual deliverables. And what they mean is not providing deliverables over to the executives, but instead asking the executives to help them in certain specific ways to really bring them into the process in a hands on way where they're involved. And I mentioned this earlier, they wish they were more clear about the Agile rules. So this is kind of the envelope of standardization that they put around the Agile process. So they, from what I understand, This is their view of the things that they said. Look these things are intrinsic to agile, you have to do them. These are agile techniques and practices that you can decide whether they're making sense or not for your individual team. So they wish they were. More clear about those. So those are some notes on the role out at Salesforce. Different situation than Spotify, less organic in the sense of happening over time with growth and kind of interesting though for a company that wants to do agile quickly over a large group of people. That big bang recipe may or may not be the right thing if you're in a big organization, but If you are and you're interested I would certainly read the supplemental materials that are available here about how things went for the folks at Salesforce. And it remains a really interesting example of agile practice at a large firm.
