Salesforce Enterprise Agile - Agile Turkey Summit

Editor's Notes

• #2: Good morning! The name of my talk today is Agile Transformations that stick: Lessons from salesforce.com’s Enterprise agile journey The photo here is of San Francisco – has anyone been to San Franciso? Ok a couple – well most people are familiar with the golden gate briedg. We have a second large bridge called the bay bridge – which is this – and this is the Ferry Building which is a pretty famous building. This over here is my office.
• #3: Before we get started, because salesforce is a publicly traded company on the new york stock exchange I am required to show this by law. It simply says – please do not make any stock purchasing decisions based on what you hear today. But before we get started – first a brief word from our sponsor, the US government…SFDC is a publicly traded company on the NYSE. Our ticker symbol is CRM. If for some reason you cannot read the entire safe harbor statement here, please visit our website. Don’t make purchasing decisions on the basis of this presentation.
• #4: With that, let’s start. My name is Nicola Dourambeis. My title is Vice President Agile Infrastructure Delivery. I have been with salesforce 5 ½ years and the first 5 of those years, I ran the agile program for the company. About a year ago, we decided to do a large transformation in our technical operations organization to really role out a devops model. 6 months ago I joined that organization to lead the transformation and run about a 20 person team of scrum masters and project managers. I got my start in agile in early 2004 at ThoughtWorks and besides working with their many clients, spent a year and a half in London with British telecom and ran the agile program at Yahoo! For a short time.
• #5: Before we get into it – how many people here have heard of salesforce? For those of you who are unfamiliar, salesforce is the number one enterprise cloud computing company in the world. We were founded in 1999 to revolutionlize how enterprises used software in the cloud and have a suite of products including CRM, service, platform and marketing. For fourteen years, salesforce.com has been a driver for enterprise cloud computing. With cloud computing, we are helping the world shift from mainframe and client-server to cloud computing. Cloud computing is a delivery model that allows you to access any application over the Internet. It provides enterprises the fastest path to success. Unlike client server and mainframe, you don’t have to buy or manage hardware, software or infrastructure. With a subscription model, you pay fixed predictable monthly payments with no large, upfront capital expenditures. And with automatic upgrades, we automatically upgrade you three times a year. These means that you are always getting the latest innovation so you can focus on your business, not technology.
• #6: We have been recognized as Forbes’ most innovative company three years in a row and I will argue that innovation is in a large part because we use agile to deliver software and can deliver without fail, three times a year. Our customers have responded to our offerings with lots of enthusiasm. Our customers and their success have propelled us to be the #1 enterprise cloud computing vendor according to IDC and Gartner. And while we’re excited about our business momentum, our ongoing focus is grounded on a firm commitment to innovation and leadership. This is why in addition to being pleased with industry analyst recognition from IDC and Gartner, we’re particularly excited to be cited by Forbes Magazine as the world’s most innovative company for three years in a row. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Additional Context on accolades: Forbes “Most Innovative Companies in the World” is awarded to the company offering the most “Innovation Premium” - The Innovation Premium is a measure of how much investors have bid up the stock price of a company above the value of its existing business based on expectations of future innovative results (new products, services and markets) . Members of the list must have $10 billion in market capitalization, spend at least 1% of their asset base on R&D and have seven years of public data. The FORTUNE World’s Most Admired Companies study surveys top executives and directors from eligible companies, along with financial analysts, to identify the companies that enjoy the strongest reputations within their industries and across industries. In Dec 2012, the Economist awarded salesforce.com and Marc Benioff the award for innovation in the process and service category Forbes “Best Companies to Work For” – salesforce.com was awarded #22 for 2013. The ranking of the top companies was determined by taking cumulative average ratings from the half-million employees who responded to the 18-question survey between Nov. 24, 2011 and Nov. 13, 2012.
• #7: But how did this all happen? So here is the backstory.
• #8: We were founded in 1999 with Marc Benioff our CEO asking the question – why can’t all enterprise software be as easy as amazon.com? With this vision, we had three people building the software in R&D and it was easy to get things done.
• #9: Those people were smart and really took advantage of Cloud as a platform and released the product four times a year to customers. Now to enterprise customers who were used to getting on premise upgrades every couple of years, this created remarkable innovation. For salesforce, it made it easy to give customers what they wanted since we were releasing 4 times a year and could respond to feedback.
• #10: And we saw success and like most companies we grew. We hit the tipping point 7 years later in 2006.
• #11: Here is the scenario we encountered in 2006
• #12: We had 47,700+ customers – big, small and lots in between
• #13: We had over a million subscribers
• #14: We were running over 10 billion transactions per quarter. To give you an idea of further growth – we currently run over a billion transactions a day
• #15: And we had about 200 people in R&D. It was our last waterfall release and it was getting really difficult to coordinate that many people and get things done.
• #16: Here is a chart that illustrates what was occurring Firstly – this line represents features by team. As you can see, in the early days, even though we were small, we were delivering a lot of features to our customers. As we got larger, we started delivering fewer features by team And now let me show you something else – here I am charting days between major releases. As I started in 1999, we were shipping 4 releases a year, which is pretty radical for enterprise software. But we slowed down as we added people and complexity. In fact, in 2006, which was our last waterfall release we only shipped one time. And the huge competitive advantage that we had as being part of the cloud diminished.
• #17: So what was going on? Why was this occuring? Firstly, we had many priorities that people were working on at the same time and they were not aligned. Classic waterfall does not assign teams together at the same time. We add resources when you need them so many times people work on multiple projects at the same time. This meant people all had priorities, but they were not the same and it made it difficult to collaborate.
• #18: Once of the things I like best about agile is that you are either 100% done or 0% done. This was not the case for us in 2006. Because we deferred testing until the end, it was difficult to know if something was really finished or whether there was more work to do. At salesforce because we are in the Cloud, we consider customer trust to be our number one priority. We will not shipp buggy code because it impacts this trust. Hence, it was difficult to hit dates because we needed to fix defects.
• #19: Again, the visibility of work was poor. Teams were not working together – they were all working on their pieces and it was difficult to collborate.
• #20: We were hitting resource bottle necks. So essentially, we were relying on specialists to do certain things at certain times. If they took longer, the resources became unavailable to do other things and people were waiting. No one else could pitch in, they had to wait for the resource to free.
• #21: And our customers were probably waiting to see all of the great stuff we had built because in the year it took for us to ship, their business environment could have changed quite a bit.
• #22: So we knew we had to do something really radical as continuing down this path would lead to disaster.
• #23: So we turned to agile. Our brand at agile at salesforce is called ADM – which stands for adaptive development methodology (in 2008 we changed the “d” to delivery as non software teams came online). This is our logo. This animal is a fossa – (and I always recommend branding your agile with something fun). We found the animal fossa which comes from Madagascar by typing in the work “agile animal” in the google search engine and hitting “I’m feeling lucky”.
• #24: What ADM is is our flavor of agile. It is primarily scrum based – which has been helpful as we rolled it out beyond software. We use certain key xp practices like contunous automation and a very heavy investment in test automation – and we base it on lean values and principles.
• #25: Now I want to turn to talking about how we rolled out ADM – because there is a formula that I have honed over the years with some success as we have had new acquisitions. So if you have not rolled out agile in your company, you can consider this a playbook.
• #26: First and foremost gain executive alignment. I will say it again – gain executive alignment. gain executive alignment I honestly believe this will make or break any agile implementation. For us, Parker Harris, one of our founders was behind this and supported it. I have seen many teams try to roll out agile and try to prove to execs that it was worthwhile. That is very painful. You need someone very senior who will accept that teams need to slow down to speed up and it will be hard.
• #27: The second key is figure out your structure and your teams. --most organizations are organized functionally, we have development over here, quality assurance over there, project management somewhere else. This will not work. Every time there is a project, they take some people from each group and form a team that disbands at the end of the project Key to making agile successful is creating cross functional teams. These teams persist over time and projects are now backlogs which go to teams. Going through this exercise, we inevitablly find that the organization is not staffed correctly – usually we have lots of developers but very few quality engineering and there are not enough of them to go on every team. You have to deal with that problem. Don’t do what we tried – which is assigning them to 5 or 6 teams. Never assign anyone to more than 2 teams and accept that some teams will not have QE so developers will have to write their own test automation.
• #28: Train everyone. Not just scrummasters or product owners. Really, it is simply too hard to take a 2 day course and then know enough that you can teach others. One of the first things I did when I started salesforce was roll out a two day scrum training and put the entire organization – from executives to team members – through it. And while the course taught mechnics – it really focused on culture and the “why”
• #29: Big Bang Rollout All teams embraced ADM Avoided dissonance between teams All teams on monthly rhythm
• #30: During this period, there will still be a lot to figure out. How do you get people to sit together? How will teams show quality? What do functional managers do in agile? The best way we know to deal with these questions is to form a cross functional scrum team to roll out scrum. This is the role model team – with a big scrum board, public stand ups, well written user stories etc. Also, if someone important is against scrum – try to get them on the team so they help solve problems.
• #31: Positioned the rollout as a return to the Technology teams core values Leveraged the values when teams were stuck or frustrated
• #32: This might be self serving because I used to be an agile coach but I have a strong belief in the power of coaching help. Teams will struggle or mimic mechanics. A good coach will really get people to understand the why and help them improve. It will also help the exec team feel comfortable when things feel difficult.
• #33: Help people help each other. Share best practices and experiences.
• #34: Encourage a culture of experimentation. You aren’t going to get everything right, so set the expectation that you are going to make a few mistakes. Reward everyone on the team for experimentation: reward people for trying, experimenting and improving..
• #35: And here you can see that frighting chart again but the lines are looking much better as we reversed the trends
• #36: So – in 2006 – this is where we were 25+ plus teams doing pretty well. And life was better
• #37: But let’s be honest, if you are successful, you will need to scale. I joined salesforce in 2008 and we had around 600 people in technology and products. And things were ok. Teams were doing very by the book scrum – 30 days sprints, some mini waterfalls… And then we kept growing and hiring…
• #38: At salesforce we have scaled both deep and wide. When we refer to deep, we mean that we have embedded agility very deep into the enterprise and have tackled and continue to face some of the more difficult enterprise scaling issues. Most of out talk today will be focused on specific areas where we go deep. However, before we get to that, we wanted to touch on organizational breadth of our agility. At salesforce our Technology and Products organization is 100%. That means that over 2000 people and more than 200 teams actively use ADM. There is no other methodology in use to deliver work. In fact, ADM has gained such a strong reputation inside salesforce that we are now starting to see other parts of the organization apply ADM—with Marketing being the most recent case.
• #39: Working with TechOps has caused us to stretch our understanding and application of ADM. TechOps is infrastructure and operations (software and infrastructure) Not only is the work in TechOps different than other parts of the org but also the culture is different.
• #40: Just like in 2006, we talked about a return to our values – keeping ourselves honest by looking at every process we add and determining if it helps or hinders is important. Are we keeping it simple? Are we adding just enough but no more?
• #41: We have some key practices that are important – we have a single codeline in our core codebase. Yes, one codeline for hundreds and hundreds of developers. While this has required a lot of tuning to maintain developer productivity – one codeline means we do not defer integrations or have big merges ever. It also means we have to have a highly responsible development community as everyone impacts everyone else.
• #42: As you grow, you need to add more structure to organize people. For example – I now have programs with as many as 40 teams so I need a way to coordinate them. So we have things like scrum or scrums and workgroups and program managers. But we always seek to wait until something is needed and then add it. Let things get a bit difficult and then add a process because it is too easy to stifle a bottom up culture with heavy weight processes.
• #43: Our release cadence which is key --three times a year all teams have to bottom up plan – whether they deploy tri-annually or not. Our core codeline releases three times a year but other non core teams like mobile for example can release much more frequently. Nevertheless, everyone plans together – in case there are dependency or priority discussions which are needed --also on a monthly cadence all teams do shared sprint reviews – which provides feedback and really keeps teams delivering iteratively
• #44: Yes, tools help. We built a custom tool on our salesforce platform originally over three weeks --we have a small team that is constantly adding to this tool which integrates user stories, bugs, test automation metrics, check ins etcs. It is also the place where we first release all of our new versions of the software so we can test it on ourselves first.
• #45: But it’s all about the people. We really believe in the importance of face to face collaboration. Even though we have remote teams, we fly everyone in together for release planning three times a year. This is super important to build relationships, align and work through issues.
• #46: And we really invest in that.
• #47: At salesforce Trust is our number one value. We only have a single version of our service and we cannot risk our customers’ success with low quality software. We have ensure that debt – both is quantity of bugs and test failures as well as quality and maintainability of our codebase – is avoided at all costs, by an ever increasing number of teams
• #48: One Dod but it is comprehensive --code checked in and no P!s or P2s --security checked --performance tested --usability tested --user documentation written --done is done
• #49: And this was radical. We have very high test pass rate requirements --99.9% --if a team falls below threashold for 48 hours, the line is locked and they can only check in fixes. No new code. --originally introduced as a single lock
• #50: Tools: GUS built internal tools for automation and scrum with robust reporting. These reports are reviewed daily—by all teams. -our standard is 99% plus and it graduates throughout And its crucial to our success. Potentially releaseable, continuously releaseable You care about what you measure. We do not measure on velocity – we measure quality metrics --we know teams want to build features --we want them to ship high quality code
• #51: People: maintain the autonomy and integrity of the team. We resist resourcing changes to stabilize and ultimately optimize teams. Make it easy to understand priorities globally and build relationships with dependent teams.
• #52: Raw talent is not enough. Hiring process has a heavy focus on cultural alignment. This is only successful if everyone – executives, managers and team members have the same value system. We look for people who are learners, empirical, how do they adjust to change Don’t want debt
• #53: And this is where we are today. Over 200 teams are using ADM – but not all in the same way.
• #55: If we had done pilots, it is unlikely we would have had the right outcomes For us, because we are very clear that we are using agile, people have to make it work
• #56: i always think about things like this – people first, then process, then tools
• #57: Think of it as a journey and always continously improve, refine your process to make it better --also remember – in order to innovate, you have to take risks. Make that ok.
• #58: Make sure you focus on what matters --ship high quality --build great teams --do not worry about how much you ship – these things will work if your culture is correct
• #59: It can work, but it is hard. I am still doing it after 5 years, but you have to find areas which work and use them to teach you how to make things work.