salesforce com large scale agile transformation.doc

8/18/2019 Salesforce com Large Scale Agile Transformation.doc

1/7

Large Scale Agile Transformation in an On-Demand World

Chris Fry and Steve GreeneSalesforce.com

[email protected] [email protected]

Abstract

Salesforce.com has recently completed an agiletransformation of a two hundred person team within athree month window. This is one of the largest and

fastest “big-bang” agile rollouts. This experiencereport discusses why we chose to move to an agile

process, how we accomplished the transformation and what we learned from applying agile at scale.

1. Introduction

This report describes our successful agiletransformation. In three months we have moved thirtyteams from waterfall development to agiledevelopment. We have focused on creating self-organiing teams! debt-free iterative development!transparency and automation. This report covers the

bac"ground of the pro#ect! the results! lessons learned!advice for others and conclusions.

Within the last si$ months we have benchmar"edour progress! completed two ma#or releases andcontinue to deliver potentially deployable code eachmonth. In our latest organiational survey %&' of our technology staff believe that their scrum team is self organiing and %(' believe that our new developmentmethodology is ma"ing their team more effective. Weare continually trying to improve our organiation andagile has provided a framewor" for continuousimprovement.

2. Project ac!ground

Salesforce.com is a mar"et and technology leader in on-demand services. We routinely process over %)million transactions a day and have over *+*!(((subscribers. Salesforce.com builds a C, solutionand an on-demand application platform. The servicestechnology group is responsible for all productdevelopment inside Salesforce.com and has grown)(' per year since its inception eight years ago!

delivering an average of four ma#or releases each year.efore our agile rollout we had slowed to one ma#or release a year. The agile rollout was designed toaddress problems with our previous methodology/

• Inaccurate early estimates resulting in missed

feature complete dates and compressed testingschedules.

• 0ac" of visibility at all stages in the release.• 0ate feedbac" on features at the end of our

release cycle.

• 0ong and unpredictable release schedules.

• Gradual productivity decline as the team grew.

efore the agile rollout the ,12 group leveraged aloose! waterfall-based process with an entrepreneurialculture. The ,12 teams are functionally organiedinto program management! user e$perience! productmanagement! development! 3uality engineering! anddocumentation. 4lthough different pro#ects andteams varied in their specific approaches! overall

development followed a phase-based functionalwaterfall. 5roduct management produced featurefunctional specifications. 6ser e$perience producedfeature prototypes and interfaces. 2evelopment wrotetechnical specifications and code. The 3uality teamtested and verified the feature functionality. Thedocumentation team documented the functionality.The system test team tested the product at scale.5rogram management oversaw pro#ects andcoordinated feature delivery across the variousfunctions.

7ur waterfall-based process was 3uite successful ingrowing our company in its early years while the team

was small. 8owever! the company grew 3uic"ly and became a challenge to manage as the team scaled beyond the capacity of a few "ey people. 4lthough wewere successfully delivering patch releases! the time

between our ma#or releases was growing longer 9from: months to over ;


2/7

the organiation. 4 reduction in releases meant fewer opportunities to learn. This had a detrimental affecton morale and on our ability to deliver 3uality featuresto mar"et.

". Our Transition A##roac$

4n original company founder and the head of the,12 technology group launched an organiationalchange program. 8e created a cross-functional teamto address slowing velocity! decreased predictabilityand product stability. This cross-functional teamredesigned and rebuilt the development process fromthe ground up using "ey values from the company>sfounding/ ?ISS 9?eep it Simple Stupid=! iterate3uic"ly! and listen to our customers. These values area natural match for agile methodologies.

It was very important to position the change as areturn to our core values as a technology organiation

rather than a wholesale modification of how wedeliver software. There were three "ey areas thatwere already in place that helped the transition/ ;= theon-demand software model is a natural fit for agilemethods@


3/7

• 5roduct 7wner 1 Scrumaster wee"ly

special interest groups 9SIGs=

• 4 time-bo$ed release on the heels of our

biggest release ever

• ,eduction of ;)((H bugs of debt

• 5otentially release-able product every :( days

4lthough we are still learning and growing as anorganiation! these benefits have surpassed our initialgoals for the rollout. Some areas that we are stillfocusing on are/ teamwor"! release planning! bug debtreduction! user stories and effective tooling.

%. W$at &e learned

The "ey ta"eaways from our rollout were to/ ;= havee$ecutive commitment to the change@


4/7

inside the organiation to agile success stories! lessonslearned and best practices from other companies. Thise$posure aided and drove adoption. Several teamsstarted innovating on their own by moving to twowee" iterations! focusing on team deliverables ande$perimenting with different physical and virtual tas" trac"ing methods.

'. W$at &e &ould do ne(t time

4lthough we have achieved many of our initial goalswith our agile rollout 9time bo$ed releases! self-organiing teams! automation! visibility=! we thin" other teams could benefit from doing certain thingsearlier than we did. These things are/ ;= involve moreindividual contributors early@


5/7

• e inclusive

• e patient and e$pect to ma"e mista"es

These topics are e$panded below.

!reate a dedicated, cross-functional rollout team.

This team will become central to managing changeand communicating within the organiation. Theywill provide accessibility to everyone in theorganiation when issues arise and responsibility toaddress them. We suggest using your new process torun this team. a"e sure you over-communicatechanges.

ont be afraid to change the entire company all at one time. any people will tell you to e$perimentwith a pilot pro#ect first then slowly rollout the processto other teams. It is possible to change the companyall at once and this can lead to significant benefits. Itreduces cross-tal" between teams functioning in the

old way and the new way and helps move the entireorganiation to the new process.

'et professional help. A$ternal coaches have done it before and will see the roadbloc"s coming before youdo. They can also help you learn from other organiations that have gone through similar transitions. They can provide new areas for you toconsider adding into your process li"e user stories or estimation and planning.

ncourage peer to peer coaching. 2iscover who onyour teams has the ability to master agile methodsearly or has e$perienced success with them in other organiations. These people can provide invaluablecoaching and will see obstacles that you may miss.

"ocus on getting several teams to excellence. Kour

intuition is often to focus on the teams that arestruggling the most. y focusing on creating a fewsuccessful teams you will build momentum and createe$amples of what you can accomplish with the new

process. We witnessed many of our lagging teamsimprove tremendously #ust by improving the other teams around them.

!reate a company sprint heartbeat. We developed aone-month sprint cycle early on and had all teams inthe same cycle. This allowed all of our sprint reviewsto be coordinated on monthly boundaries! allowing our sta"eholders and teams to be present at all of thereviews and feel the momentum building across theentire product line each month. Since! many teamshave adopted shorter


6/7

+igure 1, Our internal agile tool Scrum+orce

Figure ; illustrates our ScrumForce tool which every

Scrumaster! 5roduct 7wner and team member use tomanage their wor". Functional managers use built-inreporting to manage their teams and releases.

The tool itself is built using the Salesforce.com platform and gives every developer a reason to use our application every day. It provides drag and drop

prioritiation of user stories! user story management!tas" management and burndown chart creation.

ncourage radical visibility and over-communicate.Coming up with a tag line li"e Dradical visibilityEhelps people overcome the inertia and fear of sharinginformation widely. Change is hard and ofteneveryone is busy and not reading their email. Sohaving multiple channels of communication and

providing the same message over and over helps.When you thin" that your teams understand a newmethod or process! repeat your communication.

*e inclusive. A$tend invitations to reviews to your entire technology teams. Sometimes help comes from

people you don>t e$pect but have a passion for acertain area. y casting your net wide you canencourage visibility and participation.

*e patient and expect to ma)e mista)es. Ancourage aculture of e$perimentation. Kou aren>t going to geteverything right! so set the e$pectation that you aregoing to ma"e a few mista"es. ,eward everyone onthe team for e$perimentation/ don>t create a punitiveenvironment around ma"ing mista"es.

/. 0onclusion

This report places on the record a large! successful! big-bang transformation from waterfall to agile. If you are considering transitioning your organiation

consider moving all teams at the same time rather than staggering the rollout.

. Ac!no&ledgments

We would li"e to than" i"e Cohn! 5ete ehrens!5eter orelli! 4ndrea 0ese" and Tom 5oppendiec" for providing comments on drafts of this report. They


7/7

improved the original version! any mista"es are theauthors.

. 3eferences

B; Schwaber! ?.! gile #ro/ect 0anagement with Scrum!icrosoft 5ress!

salesforce com large scale agile transformation.doc

Documents