1. LARGE
S C A L E
AGILET R A N S F O R M A T I O N
Steve Greene | Chris Fry
How Salesforce.com revolutionized their R&D
development methodology in a Big Bang way
29. What is ADM?
ADM is a modified Scrum/XP style of product development
that is specific to Salesforce. It employs Scrum project
management framework and adopts certain XP
practices.
30. What is ADM?
Re-factoring
Self-organizing
Predictable releases
Transparent
Ftest - Selenium
Continuous integration
Debt free
Just-in-timeIterative
Always Potentially Releasable
Time-boxed
User stories
Agile
Lean
Early feedback
Code Reviews
Collective Code Ownership
Self-correcting
93. Art Director of Done
TDD Producer
Product Owner Designer
Phase 0 Consultant
Casting
Extras Casting
Photos
PETE MORELLI
SIDD SINGH
RASMUS MENKE
ANDREW SANDLER
STEVE GREENE
CHRIS FRY
iStockPhoto
Flickr
Google Images
94. Scrum Master
Product Owner
Art Director & Developer
Developer
Documentation Designer
ERIC BABINET
CATHERINE COURAGE
ANDREW WAITE
FELIX SUKHENKO
MYSTI BERRY
Scrumforce Cast
Head of the R&D technology group launched an organizational change program
Big Bang Rollout All teams embraced ADM Avoided dissonance between teams All teams on monthly rhythm
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, UE Used scrum methodology to run the team Met daily for 6 months Implemented Survey Responded directly to Survey Built training Defined “Done” Setup Sprint Reviews, defined best practices Coached teams, execs, functional managers Groomed Backlogs Managed external coaching
Positioned the rollout as a return to the Technology teams core values Leveraged the values when teams were stuck or frustrated
Bought Schwabers book for every Technology team member Asked everyone to read prior to rollout 2-hour ADM Overview Trained all teams within a 2 week period Helped teams understand why we were changing and why we chose agile Covered the principles of Scrum ScrumMaster, Product Owner & Team Member roles Product & Sprint Backlogs Daily Meetings Definition of Done Burndown, Retrospectives Strongest Objections during training Can’t build big features in 30 days Don’t want to meet everyday (seems like a waste of time)
Key to our success Trained 30 ScrumMasters through publicly available CSM training with Mike Cohn and Ken Schwaber (locally) A must for anyone who will be a ScrumMaster Nice overview but not sufficient to be a great ScrumMaster Mike 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 training Leveraged lots of information from the internet A 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 didn’t 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 didn’t 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 results Some executives were very outspoken both pro and con
Focus on the principles of agile rather than the mechanics helped people understand why we’re moving to an agile process. Some teams/ScrumMasters attempted to execute the scrum methodology literally When teams were frustrated we asked teams to stay focused on principles rather than the letter of the law Teams 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.
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 ugly When in doubt give exposure to information to whoever wants it Giveaway 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 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: don’t create a punitive environment around making mistakes.
Old is bad, new is good
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: don’t create a punitive environment around making mistakes.
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: don’t create a punitive environment around making mistakes.
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: don’t create a punitive environment around making mistakes.
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: don’t 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.