salesforce agile transformation - agile 2007 conference

of 91/91
Large Scale Agile Transformation Chris Fry Steve Greene

Post on 07-Jan-2017

2.219 views

Category:

Documents

2 download

Embed Size (px)

TRANSCRIPT

  • Large Scale Agile TransformationChris FrySteve Greene

  • History

  • 7Age of Salesforce in years

  • from the beginning

  • 3Number of people in R&D

  • fastinnovativesmart

  • 4Number of Major Releases per year

  • 7 years later

  • rapid success

  • 30,000+Customers

  • 650,000Users

  • 100 Milliontransactions per day

  • 200+people in R&D

  • but

  • it was getting more difficult to deliver

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

  • 1Number of Major Releases per year

  • Why?

  • Lack of visibility at all stages in the release

    Late feedback on features at the end of our release cycle

  • Long and unpredictable release schedules

  • Gradual productivity decline as the team grew

  • What did we do about it?

  • Major enterprise-wide Agile Transformationin just 3 months

  • Transformation Results

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

  • Transformation Results

    January2007March2007November2007August2007Rapid Reaction for an Agile World60+ critical features delivered in < 9 monthsAverage Idea to Release rate: 2.2 quarters70% of Top 10 Ideas on track for delivery in 2007

  • Our customers are happy

  • Our teams are happy

  • Howd we do it?

  • Launched organizational change program

  • Everyone jumped in together

  • Created a dedicated, cross-functional rollout team

    Another key to our success was a dedicated, fully empowered agile rollout team built from a cross-section of the organization. Consisted of volunteer team members from Dev, QA, Program Management, Doc, UEUsed scrum methodology to run the teamMet daily for 6 monthsImplemented SurveyResponded directly to Survey

    Built trainingDefined DoneSetup Sprint Reviews, defined best practicesCoached teams, execs, functional managersGroomed BacklogsManaged external coaching

  • Positioned as a return to our core values

    Positioned the rollout as a return to the Technology teams core valuesLeveraged the values when teams were stuck or frustrated

  • Listen to your customersIterateKISS

  • Distributed Ken Schwabers Agile book

    Developed 2-hour Agile overview

    Bought Schwabers book for every Technology team memberAsked everyone to read prior to rollout

    2-hour ADM OverviewTrained all teams within a 2 week periodHelped teams understand why we were changing and why we chose agileCovered the principles of ScrumScrumMaster, Product Owner & Team Member rolesProduct & Sprint BacklogsDaily MeetingsDefinition of DoneBurndown, Retrospectives

    Strongest Objections during trainingCant build big features in 30 daysDont want to meet everyday (seems like a waste of time)

  • Sent 30 ScrumMasters to ScrumMaster Certification

    Sent 35 Product Managers to Product Owner Certification

    Key to our successTrained 30 ScrumMasters through publicly available CSM training with Mike Cohn and Ken Schwaber (locally)A must for anyone who will be a ScrumMasterNice overview but not sufficient to be a great ScrumMasterMike Cohn delivered Product Owner certification to 35 Product Owners on-site (definitely a plus)Covered User Stories

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

    Used the wiki as a centralized place to point teams for additional information or trainingLeveraged lots of information from the internetA primary training tool for new Technology team members today

  • What would we do differently?

  • Train Product Owners earlier and with more intensity

    Throughout our initial rollout we heard from many experts that the Product Owner role was key to the success of our agile transformation. Although we intuitively understood this we didnt truly understand the significant changes that the Product Owners would experience in their role.

  • Involve more individual contributors early

    Initially you may not get feedback from key employees. One great way to involve everyone in your organization up front is to run an open space meeting.

  • Get outside coaching earlier

    Several of the outside coaches we brought in were able to quickly recognize ways to more quickly enable and coach our teams. They also recognized common patterns that we could correct and brought in lessons learned from other organizations transitioning to agile.

  • Give key executives concrete deliverables around the rollout

    Executives were key to our success. Giving them small or large tasks related to the agile rollout brings them into the organizational change program and helps them stay grounded in what you are doing.

  • Be more clear about what the agile rules are

    Self-organization can mean anything to anyone. Self-organizing as opposed to assigned tasks is critical to real commitment and engaging the passion of team members. Avoiding partial credit by properly defining done is another aspect of self-organizing.

  • Keys to success?

  • Ensure executive commitment to the change

    Executive commitment was crucial to implementing massive change. Without executive support the transition might have failed. We had full commitment from Founder and SVP of Technology (although he didnt understand all of the details he was committed to the principles and end result)Some executives were convinced from the beginning, some had doubts and wanted to first see resultsSome executives were very outspoken both pro and con

  • Focus on principles over mechanics

    Focus on the principles of agile rather than the mechanics helped people understand why were moving to an agile process. Some teams/ScrumMasters attempted to execute the scrum methodology literallyWhen teams were frustrated we asked teams to stay focused on principles rather than the letter of the lawTeams will not get it right at first, be flexible. Better to execute imperfectly rather than lose confidence in the methodology from teams.

  • Focus on automation

    An extensive automation suite and build system existed already to support the transformation. This was extremely helpful because we had a base continuous integration system in place and a value system around automated unit and functional testing within the entire development organization.

  • An extensive automation suite and build system existed already to support the transformation. This was extremely helpful because we had a base continuous integration system in place and a value system around automated unit and functional testing within the entire development organization.

  • Provide radical transparency

    During our rollout, transparency in everything that we did was a key to our success. We held all of our daily rollout meetings in a public place so anyone could see how the rollout was progressing.

    Publish information early and often (even if it is not perfect)Push daily metrics to the entire team to gain instant visibility to the good, bad and uglyWhen in doubt give exposure to information to whoever wants itGiveaway your knowledge as soon as you gain it

  • Advice?

  • Create a dedicated, cross-functional rollout team

    This team will become central to managing change and communicating within the organization. They will provide accessibility to everyone in the organization when issues arise and responsibility to address them. We suggest using your new process to run this team. Make sure you over-communicate changes.

  • Get professional help

    External coaches have done it before and will see the roadblocks coming before you do. They can also help you learn from other organizations that have gone through similar transitions.

  • Focus on getting several teams to excellence

    Your intuition is often to focus on the teams that are struggling the most. By focusing on creating a few super successful teams you will build momentum and create examples of what you can accomplish with the new process.

  • Create a company sprint heartbeat

    We developed a one-month sprint cycle early on and had all teams in the same cycle.

  • Decide early on the right tool

    We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.

  • Scrumforce built on the Salesforce Platform

    We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.

  • Scrumforce built on the Salesforce Platform

    We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.

  • When the heat is on stick to your guns

    We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.

  • Encourage radical visibility and over-communicate

    Coming up with a tag line like radical visibility helps people overcome the inertia and fear of sharing information widely. Change is hard and often everyone is busy and not reading their email. So having multiple channels of information and providing the same message over and over helps. When you think that your teams understand a new method or process, repeat it.

  • Experiment, be patient and expect to make mistakes

    Encourage a culture of experimentation. You arent 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: dont create a punitive environment around making mistakes.

  • Dont be afraid to change the entire company all at one time

    Many people will tell you to experiment with a pilot project first then slowly rollout the process to other teams. It is possible to change the company all at once and this can lead to significant benefits.

  • Agile Roadmap

    JanuaryOctoberAprilOctoberAgile LaunchBig Bang RolloutExcellence, Sustainability & ExpansionExpanding Velocity, Expanding Intelligence, Expanding Influence GloballyJanuary144146July148150152RolloutAdoptionExcellenceExpansion

    Old is bad, new is good

  • Its not Process

  • Its ADM

  • Executive ProducerParker Harris

  • ScreenplayChris Fry

  • DirectorSteve Greene

  • Co-ProducerJenny Cheng

  • Co-ProducerTodd McKinnon

  • Executive ProducersSteve GreeneChris Fry

  • Story EditorsAndrea LeszekCatherine Courage

  • StarringSteve Graykowski

  • Eric Babinet

  • Rajani Ramanathan

  • April Oman

  • Guest StarringMatt Ho

  • Pete BehrensRob Myers

  • Special Guest StarsSteve FisherWoodson Martin

  • Co-starringPeter MorelliSiddhartha Singh

  • Rasmus MenckeAmy Farrow

  • WithAndrew Sandler

  • Scrum MasterProduct OwnerArt DirectorUE ProducerSTEVE GREENECHRIS FRYANDREA LESZEKCATHERINE COURAGE

  • Program DesignerRelease TechnicianSurvey DesignerAssistant ProducerAdaptation DesignerSTEVE GRAYKOWSKIAMY FARROWAPRIL OMANERIC BABINETRAJANI RAMANATHAN

  • Art Director of DoneTDD ProducerProduct Owner DesignerPhase 0 ConsultantCastingExtras CastingPETE MORELLISIDD SINGHRASMUS MENKEANDREW SANDLERSTEVE GREENECHRIS FRY

  • Scrumforce CastScrum MasterProduct OwnerArt Director & DeveloperDeveloperDocumentation DesignerERIC BABINETCATHERINE COURAGEANDREW WAITEFELIX SUKHENKOMYSTI BERRY

  • ADM Wiki CastArt DirectorEditorContent DesignersSTEVE GREENEANDREA LESZEKCHRIS FRYANDREA LESZEKSTEVE GRAYKOWSKICATHERINE COURAGEERIC BABINET

  • Special Thanks toMike Cohn

  • Rolled out entirely on location inSan Francisco, CaliforniaUSA

  • The characters and events depicted in this rollout are real. Any similarity to fictional persons, living or dead, is purely coincidental.

    Copyright 2007 Salesforce.com. All rights reserved. First publication of this rollout (process and overview): United States of America 2007. Salesforce.com is the owner of the copyright in this rollout

    This rollout is protected by the copyright laws of the United States of America and other countries. Any unauthorized duplication, copying, or use of all or part of this rollout may result in a serious dorking in accordance with applicable laws.

  • This has been a presentation of

  • Another key to our success was a dedicated, fully empowered agile rollout team built from a cross-section of the organization. Consisted of volunteer team members from Dev, QA, Program Management, Doc, UEUsed scrum methodology to run the teamMet daily for 6 monthsImplemented SurveyResponded directly to Survey

    Built trainingDefined DoneSetup Sprint Reviews, defined best practicesCoached teams, execs, functional managersGroomed BacklogsManaged external coaching

    Positioned the rollout as a return to the Technology teams core valuesLeveraged the values when teams were stuck or frustrated

    Bought Schwabers book for every Technology team memberAsked everyone to read prior to rollout

    2-hour ADM OverviewTrained all teams within a 2 week periodHelped teams understand why we were changing and why we chose agileCovered the principles of ScrumScrumMaster, Product Owner & Team Member rolesProduct & Sprint BacklogsDaily MeetingsDefinition of DoneBurndown, Retrospectives

    Strongest Objections during trainingCant build big features in 30 daysDont want to meet everyday (seems like a waste of time)

    Key to our successTrained 30 ScrumMasters through publicly available CSM training with Mike Cohn and Ken Schwaber (locally)A must for anyone who will be a ScrumMasterNice overview but not sufficient to be a great ScrumMasterMike Cohn delivered Product Owner certification to 35 Product Owners on-site (definitely a plus)Covered User Stories

    Used the wiki as a centralized place to point teams for additional information or trainingLeveraged lots of information from the internetA primary training tool for new Technology team members today

    Throughout our initial rollout we heard from many experts that the Product Owner role was key to the success of our agile transformation. Although we intuitively understood this we didnt truly understand the significant changes that the Product Owners would experience in their role. Initially you may not get feedback from key employees. One great way to involve everyone in your organization up front is to run an open space meeting. Several of the outside coaches we brought in were able to quickly recognize ways to more quickly enable and coach our teams. They also recognized common patterns that we could correct and brought in lessons learned from other organizations transitioning to agile. Executives were key to our success. Giving them small or large tasks related to the agile rollout brings them into the organizational change program and helps them stay grounded in what you are doing.Self-organization can mean anything to anyone. Self-organizing as opposed to assigned tasks is critical to real commitment and engaging the passion of team members. Avoiding partial credit by properly defining done is another aspect of self-organizing.

    Executive commitment was crucial to implementing massive change. Without executive support the transition might have failed. We had full commitment from Founder and SVP of Technology (although he didnt understand all of the details he was committed to the principles and end result)Some executives were convinced from the beginning, some had doubts and wanted to first see resultsSome executives were very outspoken both pro and con

    Focus on the principles of agile rather than the mechanics helped people understand why were moving to an agile process. Some teams/ScrumMasters attempted to execute the scrum methodology literallyWhen teams were frustrated we asked teams to stay focused on principles rather than the letter of the lawTeams will not get it right at first, be flexible. Better to execute imperfectly rather than lose confidence in the methodology from teams.

    An extensive automation suite and build system existed already to support the transformation. This was extremely helpful because we had a base continuous integration system in place and a value system around automated unit and functional testing within the entire development organization. An extensive automation suite and build system existed already to support the transformation. This was extremely helpful because we had a base continuous integration system in place and a value system around automated unit and functional testing within the entire development organization. During our rollout, transparency in everything that we did was a key to our success. We held all of our daily rollout meetings in a public place so anyone could see how the rollout was progressing.

    Publish information early and often (even if it is not perfect)Push daily metrics to the entire team to gain instant visibility to the good, bad and uglyWhen in doubt give exposure to information to whoever wants itGiveaway your knowledge as soon as you gain it

    This team will become central to managing change and communicating within the organization. They will provide accessibility to everyone in the organization when issues arise and responsibility to address them. We suggest using your new process to run this team. Make sure you over-communicate changes.External coaches have done it before and will see the roadblocks coming before you do. They can also help you learn from other organizations that have gone through similar transitions. Your intuition is often to focus on the teams that are struggling the most. By focusing on creating a few super successful teams you will build momentum and create examples of what you can accomplish with the new process.We developed a one-month sprint cycle early on and had all teams in the same cycle. We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.We are dog fooding our own platform to create an agile tool to manage development. Spreadsheets quickly became unmanageable and using our own product to build our product has great side benefits.Coming up with a tag line like radical visibility helps people overcome the inertia and fear of sharing information widely. Change is hard and often everyone is busy and not reading their email. So having multiple channels of information and providing the same message over and over helps. When you think that your teams understand a new method or process, repeat it.Encourage a culture of experimentation. You arent 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: dont create a punitive environment around making mistakes.Many people will tell you to experiment with a pilot project first then slowly rollout the process to other teams. It is possible to change the company all at once and this can lead to significant benefits. Old is bad, new is good