Salesforce Enterprise Agile - Agile Turkey Summit
•Als PPT, PDF herunterladen•
3 gefällt mir•1,249 views
Salesforce Enterprise Agile, Scaling agile to large companies
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Salesforce Enterprise Agile - Agile Turkey Summit
Ähnlich wie Salesforce Enterprise Agile - Agile Turkey Summit (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Salesforce Enterprise Agile - Agile Turkey Summit
- 1. Agile Transformations that Stick: Lessons from salesforce.com’s Enterprise Journey Agile Summit Turkey, 2013 Nicola Dourambeis
- 2. Safe Harbor Statement Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for our fiscal year ended January 31, 2008, our quarterly report on Form 10-Q for our fiscal quarter ended April 30, 2008, and in other filings with the Securities and Exchange Commission. These documents are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
- 3. Nicola Dourambeis VP Agile Infrastructure Delivery Salesforce.com
- 4. Who We Are: Cloud Computing Driver, Catalyst and Evangelist Mainframe Client/Server Enterprise Cloud Computing No Hardware/Software Subscription Model Automatic Upgrades Constant Innovation 1960s 1980s Today
- 5. #1 in Cloud Computing and CRM #1 World’s #1 CRM Cloud Computing Innovation 2011, 2012, 2013
- 7. 3 Number of people in R&D
- 10. rapid success
- 13. 10 Billion transactions per quarter
- 14. and it was becoming more difficult to deliver
- 15. Days between Major Releases Features Delivered per Team 2000 2001 2002 2003 2004 2005 2006
- 16. Lack of responsiveness, lack of team alignment on priorities
- 17. Unpredictable completion of anything
- 21. What did we do about it?
- 23. What is ADM? ADM (Adaptive Delivery Methodology) salesforce.com’s flavor of agile Scrum project management framework XP practices Based on Lean principles
- 24. The Rollout
- 26. Figure out your team structure Projects Prioritized Backlogs Self-organized Scrum Teams
- 29. Create a dedicated, cross-functional rollout team
- 30. Position as a return to our core values
- 32. Create ScrumMaster and Product Owner communities
- 33. Experiment, be patient and expect to make mistakes
- 34. Transformation Results Features Delivered per Team Days between Major Releases 2000 2001 2002 2003 2004 2005 2006 2007
- 35. The Beginning (2006) 2006 25+ agile teams in R&D
- 36. This will work when your organization is small But when you grow large, you need more
- 37. We scale both deep and wide
- 38. Embrace Difference and be prepared to stretch Agility
- 40. One Codeline
- 42. ADM Release Cycle Release Feb Release Mar Apr May Planning cycle for next release Jun Release Jul Aug Sep Planning cycle for next release Oct Release Nov Dec Jan Planning cycle for next release Coordinate release planning with generic framework
- 43. Tools Help
- 44. But really, it’s the people that make things happen
- 45. And we make a big investment in collaboration
- 46. Maintain Technical Health Debt is the Enemy
- 48. Stop the codeline when test failures are too high
- 49. Strong Attention to metrics Status Metric Now (7/30) Potentially Releasable Metrics Release Criteria Feature Freeze Threshold Basic Ftest 100% 100.0% Utest 100% 100.0% Full Ftest 100% >99.8% Extended Ftest 96.86% >99.75% Basic Selenium 99.76% 100.0% Selenium 99.6% >99.5% 0 0 Unresolved Integrations
- 51. Hire for Values and Culture Fit
- 52. 2013 200+ agile teams R&D, IT, & Technical Operations
- 53. Lessons Learned
- 55. Get everyone aligned and committed
- 56. Always look for things to improve It’s ok to fail along the way
- 57. Stick to your principles Focus on values over mechanics
- 58. Agile does work at scale Let small successes give you confidence to push further
- 59. Questions?
Hinweis der Redaktion
- 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.
- 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.
- 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.
- 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.
- 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.
- But how did this all happen? So here is the backstory.
- 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.
- 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.
- And we saw success and like most companies we grew. We hit the tipping point 7 years later in 2006.
- Here is the scenario we encountered in 2006
- We had 47,700+ customers – big, small and lots in between
- We had over a million subscribers
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- So we knew we had to do something really radical as continuing down this path would lead to disaster.
- 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”.
- 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.
- 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.
- 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.
- 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.
- 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”
- Big Bang Rollout All teams embraced ADM Avoided dissonance between teams All teams on monthly rhythm
- 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.
- Positioned the rollout as a return to the Technology teams core values Leveraged the values when teams were stuck or frustrated
- 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.
- Help people help each other. Share best practices and experiences.
- 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..
- And here you can see that frighting chart again but the lines are looking much better as we reversed the trends
- So – in 2006 – this is where we were 25+ plus teams doing pretty well. And life was better
- 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…
- 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.
- 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.
- 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?
- 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.
- 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.
- 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
- 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.
- 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.
- And we really invest in that.
- 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
- 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
- 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
- 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
- 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.
- 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
- And this is where we are today. Over 200 teams are using ADM – but not all in the same way.
- 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
- i always think about things like this – people first, then process, then tools
- 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.
- 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
- 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.