The document summarizes the transition of salesforce.com from a traditional waterfall development process to an agile development process called ADM (Agile Development Methodology) over a 3 year period from 2006 to 2009. It describes how salesforce.com grew rapidly initially with a small R&D team but faced challenges in on-time delivery as the company scaled. To address these challenges, salesforce.com underwent an enterprise-wide transformation to ADM which resulted in a 61% improvement in release frequency and 38% increase in features delivered per developer. The transformation process involved training employees and overcoming resistance to change, with continuous improvements made over several years.

1. UNLEASHING the FOSSA Scaling Agile in an AMBITIOUS CULTURE Agile Leadership Summit Orlando, Florida November 2008 Steve Greene, salesforce.com

5. History

6. from the beginning

7. 3 Number of people in R&D

8. fast innovative smart

9. 4 Number of Major Releases per year

10. 7 years later

11. rapid success

12. 47,700+ Customers

13. 1,100,000 Subscribers

14. 10 Billion transactions per quarter

15. 500+ people in R&D

16. it was getting more difficult to deliver

17. 2000 2001 2002 2003 2004 2005 2006 Features Delivered per Team Days between Major Releases

18. 1 Number of Major Releases in 2006

19. Why?

20. Lack of visibility

21. Resource Bottlenecks

22. Unpredictable completion of projects or initiatives

23. Lack of responsiveness, lack of team alignment on priorities

24. Unhappy Customers

25. What did we do about it?

26. Major enterprise-wide Agile Transformation to ADM In just 3 months + another 18 months of continuous improvement

27. I knew we needed radical change to get us back on track to regular releases and agile delivered. ” Parker Harris Founder and Executive Vice President, Technology Salesforce.com “

28. Transformation Results 2000 2001 2002 2003 2004 2005 2006 2007 Features Delivered per Team Days between Major Releases

29. ADM has delivered total visibility, total transparency and unbelievable productivity… a complete win! ” Steve Fisher Sr. Vice President, Platform Product Management Salesforce.com “

30. On time delivery? Last waterfall release

31. Simple is better. With our agile approach to product development we've put our amazing people in charge. They work as a team to do the right thing for the customers, their fellow employees and our shareholders. ” Todd McKinnon Sr. Vice President, Research & Development Salesforce.com “

32. + 61 improvement in “mean time to release” for major releases in our first agile year %

33. + 38 Increase in feature requests delivered per developer in our first agile year %

35. 88 of respondents believe the quality of our products have improved or stayed the same %

36. 89 of respondents are having the “best time” or a “good time” at Salesforce % * Improved from 40% 18 months ago

37. 94 of respondents would recommend ADM to their colleagues inside or outside Salesforce %

39. What is ADM? ADM is a modified Scrum/XP style of product development that is specific to Salesforce. It employs Scrum project management framework, adopts certain XP practices and is based on lean principles.

40. What is ADM? Re-factoring Self-organizing Predictable releases Transparent Ftest - Selenium Continuous integration Debt free Just-in-time Iterative Always Potentially Releasable Time-boxed User stories Agile Lean Early feedback Code Reviews Collective Code Ownership Self-correcting Scrum of (Scrum of Scrums) Seasonal Planning Rhythm

41. The Rollout

42. Created a dedicated, cross-functional rollout team

43. Everyone jumped in together

44. Positioned as a return to our core values

45. Listen to your customers Iterate KISS

46. Distributed Ken Schwaber’s Scrum book Developed 2-hour Agile overview

47. Sent 30 ScrumMasters to ScrumMaster Certification Sent 35 Product Managers to Product Owner Certification

48. Created weekly ScrumMaster and Product Owner forums

49. Created internal, wiki-based website as a reference for team members

50. Just get started. (the rest will come later)

51. Change isn’t easy. (get ready to be hated)

52. “ In many ways, scrum seems like an inflexible, bureaucratic process akin to something at the Department of Motor Vehicles.” “… ditch the stupid annoyingly dumb excel spreadsheet.” “ Scrum doesn't account for the fact of the reality of the waterfall. You cannot deny this by superimposing scrum over it.” “ Management is not proactive as we wait for decisions from management. Scrum gives me the feeling that Big Brother is watching and monitoring everything we do…” “ It seems like we spend more time talking about scrum…than we spend time talking and working on salesforce.com.”

53. They don’t like us. (and may never like us again)

54. “ Stop trying to implement scrum, and look at how many releases we can really do in a year.” “ The lingo is ridiculous” Team is effective but productivity is lower “ Scrum does not meaningfully affect the team's effectiveness; it is structure and process that often distracts the team from their goal, and can be used to micromanage the team.” “ We've managed to take a lightweight process and attach enough … to it to make it just as bad as our previous process, good job!” Lack of innovation. No innovation. I can't innovate. I am at the mercy of my product owner, who cares not for innovation, only the chirpings of customers...

55. But, they got over it.

56. And. Finally. The rollout is over! (but we’re not done)

57. Now for the later stuff.

58. Continuous Improvement “ Agile Launch” Big Bang Rollout January October April October January July Rollout Adoption Excellence Expansion April 144 146 148 150 152 154

59. Continuous Improvement “ Agile Launch” Big Bang Rollout January October April October January July Rollout Adoption Excellence Expansion April Scrumforce Office Hours Release Management Sustainable Velocity Virtual Architecture System Testing PTOn Open Space SoS Cross Team Impact Dependencies Release Planning

60. Continuous Improvement – Excellence & Expansion October April January July 2008 April October July 2009 IT Rollout Customer & Partner Agile consulting Technical Operations Rollout

61. Don’t be like us. (or what would we’d do differently)

62. Involve more individual contributors early

63. Provide team members more training earlier and with more intensity

64. Get outside coaching earlier

65. Key executives should take concrete deliverables around the rollout

66. Keys to success?

67. Ensure executive commitment to the change

68. Focus on principles over mechanics

69. Focus on getting several teams to excellence

70. Provide radical transparency

71. 16332 5752 2656 27967 Automation

73. When the heat is on stick to your guns

74. We failed. (all along the way)

75. Experiment, be patient and expect to make mistakes

76. You can’t afford to NOT change your organization to deliver growth