Thanks to a referral by Mike Cohn (It’s great to have friends. Thanks Mike!), Pete Behrens was invited to guide the initial agile “transformation” at Salesforce.com’s R&D Organization. I put “transformation” in quotes as it was more like herding cats…

The Scene circa 2006

Having just ended another large scale transformation engagement, I was thrusted into the chaos in December 2006, a couple of months after the infamous “all-in” decision was made. I recall the call going something like “Hey, we just sent all of our managers to Mike Cohn’s ScrumMaster and Product Owner training, now what do we do?”. Don’t worry, I assured them. We’ll get this worked out.

20+ teams with only 2-day educational awareness by their “leaders”. I put “leaders” in quotes because these were transplanted ScrumMasters and under-respected Product Owners. The real power in the organization lied at the feet of the development managers and architects. This was a high-tech Silicon Valley startup were technology was king and the developers were in power.

The “Fix”

I put “fix” in quotes because when you are working with an organization, nothing is fixed, rather we experiment with changes and see how they work. I mentioned in our Geonetric Client Story that Scrum and Agile are not typically catalyst for change. That was true here at Salesforce.com too. They were “doing” Scrum across 20+ teams for two months with no significant impact. The catalyst was structural – changing the power of leaders and teams. Development Manager Power was cut in half as we did not allow them to direct work of their people. Product Owner Power was doubled as they owned and managed the priorities and backlog. We removed the capacity for any leader to assign work to any individual – all work had to be given to a team and put on the backlog.

Again, like at Geonetric, the power of Scrum comes through the visibility of work. When leaders are assigning work individually, it is like a gordian knot of priority conflict. If everything is high priority, nothing is. By using the backlog system, it exposed the work and forced leaders to make tough choices.

Likely the most impressive aspect of the transformation was our monthly heartbeat. Coming off one of my first transformation in 2005 we allowed each team autonomy on its Sprint rhythm. This was great for me as a coach, but leaders were confused by the lack of interconnectedness. I vowed to never do that again. On the other hand, I believe companies today often swing the pendulum to too much control, enforcing a shared two-week cycle and process every team must follow. This comes across as micro-management. Salesforce.com was Tops-Down sensitive. So we found a sweet spot in the monthly rhythm. We required every team to showcase their work each month, but gave them autonomy during the month in their own rhythms and process. They could choose 1-week sprints, 2-week sprints, a 4-week sprint, Kanban or simply a one-month waterfall. We didn’t care as long as they delivered value at the end of the month and could demonstrate it.

Sustaining and Growing Results

The initial impact on the Salesforce.com delivery engine was immediate. While they were unable to deliver a significant feature release in 2006, they were back on track in 2007 seasonal release cycle. They continued this reliable release engine for at least 8 years last I checked. We expanded agile ways of working into marketing, Dreamforce and development operations.

While my engagement at Salesforce was principally from 2006 through 2012, the Salesforce.com’s amazing journey continues today. Recently in 2017 I was present at a talk given by a Salesforce.com agile coach in Bangalore, India. I was amazed at how the agile culture and values that we put together all those years ago were present in her talk. This is after 50+ acquisitions, a global presence, and growth to over 30,000 employees!

In Their Own Words…

In their own words, Chris Fry and Steve Greene share their Salesforce.com Agile Transformation Story in 2007 in this paper entitled Large Scale Agile Transformation in an On-Demand World…

Salesforce.com completed an agile transformation of a two hundred person team within a three month window. This is one of the largest and fastest “big-bang” agile rollouts. This story shares why we chose to move to an agile process, how we accomplished the transformation and what we learned from applying agile at scale.

Salesforce.com is a market and technology leader in on-demand services. We routinely process over 85 million transactions a day and have over 646,000 subscribers. Salesforce.com builds a CRM solution and an on-demand application platform. The services technology group is responsible for all product development inside Salesforce.com and has grown 50% per year since its inception eight years ago, delivering an average of four major releases each year. Before our agile rollout we had slowed to one major release a year. The agile rollout was designed to address problems with our previous methodology:

• Inaccurate early estimates resulting in missed feature complete dates and compressed testing schedules.
• 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.

Our waterfall-based process was quite successful in growing our company in its early years while the team was small. However, the company grew quickly and became a challenge to manage as the team scaled beyond the capacity of a few key people. Although we were successfully delivering patch releases, the time between our major releases was growing longer (from 3 months to over 12).

Key takeaways from our Agile Transformation:

1. Have executive commitment to the change;
2. Create a dedicated rollout team to facilitate the change;
3. Focus on principles over mechanics;
4. Focus early on automation and continuous integration;
5. Provide radical transparency and;
6. Leverage external agile training and coaching.

1. Ensure executive commitment to the change. Executive commitment was crucial to implementing massive change. There were several key points in the transition where boundaries were tested. Without executive support the transition might have failed. For example a key executive decision was to stick to an aggressive release date, regardless of the content of the release. Although many teams argued throughout the development cycle for more time to add more features the entire executive management team stayed committed to the release date and the move to the new methodology. Their ability to hold firm reinforced the agile principles of delivering early and often, reducing waste and made it clear that we were doing a timeboxed release.

2. Create a dedicated, cross-functional rollout team. Another key to our success was a dedicated, fully empowered agile rollout team built from a crosssection of the organization. Each area of the organization nominated members for the group. We had members from quality engineering, development, program management, product management, user experience & usability, documentation and executive management. This team was empowered to make decisions, used the new methodology and held its meetings in a public space. This team provided accessibility, transparency and shared ownership of the transition. The team also reached out to industry experts and other similar software companies that had adopted agile techniques.

3. Focus on principles over mechanics. Focusing on the principles of agile rather than the mechanics also helped people understand why we were moving to an agile process. The principles from the lean movement [2] also were key to communicating the value of changing current behavior. If teams were feeling that something was not working “the way it should,” they could refer back to the values and reject anything they thought did not correlate with our core values. We focused on the following agile values: communication, empowered teams, continuous improvement and delivering customer value early. We published them on a handout that was distributed to the entire technology organization.

4. Focus on automation. An extensive automation suite and build system already existed to support the transformation. This was extremely helpful because we had a continuous integration system in place and a value system around automated unit and functional testing within the entire development organization. We improved this system during the rollout but did not have to create it from scratch. Everyone focused on code line health, driving down end-to-end test times and working together in a single, integrated codeline. We were required to make substantial efficiency improvements to the automated build system to allow much more frequent check-in/build/test runs. These quick runs were critical for the short development test cycles.

5. 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. We visually displayed our task board on a public lunch room wall where everyone had access to the information. We over-communicated vision, information, guidance and plans to everyone. We implemented “daily metrics drumbeats” sent to the entire R&D team describing the health of the release in terms of automation results, test execution results, system testing results, open bug counts, and deployment activities. This bias to sharing information with everyone was critical in our ability to adapt on a daily basis to ensure our success.

6. Leverage existing agile training and coaching. The last key contributor to our success was sending a large set of people (approximately 25% of the R&D organization) to professional training and hiring external, experienced consultants to assist team members, ScrumMasters, Product Owners and functional managers with the process. This provided a foundation in agile principles and allowed us to scale the rollout team to provide support for all the teams. The external training and coaching exposed everyone inside the organization to agile success stories, lessons learned and best practices from other companies. This exposure aided and drove adoption. Several teams started innovating on their own by moving to two-week iterations, focusing on team deliverables and experimenting with different physical and virtual task tracking methods.

This is an excerpt from the Agile 2007 Conference Case Study.

Additional Stories on Salesforce.com Agile Transformation

• Large Scale Agile Transformation at Salesforce.com (2007)
• The Year of Living Dangerously: How Salesforce.com delivered extraordinary results in a “Big Bang” Enterprise Agile Evolution (2008)
• A Holistic Approach to Scaling Agile at Salesforce.com (2010)
• Agile Transformations that Stick: Lessons from Salesforce.com’s Enterprise Agile Journey (2013)
• Comparing Agile transformation approaches at Twitter and Salesforce (2013)

 

Back to Client Stories