From Chaos to Collaboration: Scaling Agile at Salesforce

Nearly two decades ago, Salesforce wasn’t the SaaS giant it is today – but an agile transformation across a 350+ person R&D organization helped point the company toward its current position of more than $34 billion in annual revenue.

An instrumental part of that transformation was Agile Leadership Journey’s Founder and CEO Pete Behrens who stepped in to guide Salesforce’s R&D department from chaos to collaboration.

The Situation at Salesforce

In 2006, Salesforce was growing – fast.

The heroic startup mentality to product management that they built the company on was quite effective when teams were small, but the scaling pains were numbing. While teams continued to deliver patch fixes, they hit a wall with their major release schedule from what had been a reliable seasonal four-month cycle to failing any delivery for over a year.

This is where Salesforce’s R&D leadership made the bold decision to go all in on an agile transformation. Initiated by internal change agents, the shift to agile was meant to unkink the hose that had stopped the flow of value delivery.

The Solution? A Culture Transformation

At that time, Salesforce’s decision to pursue an agile transformation at that scale was an audacious one. Remember, this was before Spotify or Scaled Agile Framework (SAFe) were introduced.

There were simply no existing frameworks for scaling other than to start small and grow incrementally through learning – and Salesforce leadership didn’t think small. If it was the right thing to do, they were all in.

Illustration of a group of people working on gears together.

The R&D department dove headfirst into the transformation by sending Scrum masters and product owners to a brief two-day training course, quickly kicking off Scrum across more than 20 teams. However, this initial excitement fizzled back in the real world of the office with a complex software architecture and cross-team interdependencies. It quickly devolved into departmental chaos, with R&D leaders realizing that things were not going to be as easy as “educate and go.”

As the team at Salesforce realized, learning Scrum was like learning a new recipe. Sure the meal might be edible, but that hardly makes you a Michelin-star chef. Even if one team had gotten the hang of Scrum, the broader system was still broken.

Late 2006 is when Pete Behrens was called in to assist leadership in navigating the agile transformation, and most importantly, to help make it effective.

“We worked with leaders, to help them understand which levers to pull within the organization that would allow Scrum to work,” says Behrens. “A key learning for leadership was how it was less about the Scrum framework than it was about their overall system. It was essential for them to understand how their collective structures, policies, measures, and mindsets shaped their values and value delivered. And then tweak them.”

“They were willing to trust me, to bring in scaling concepts to enable agile ways of working that were still in development at that time,” explains Behrens. “Looking back, it was our experiments at Salesforce that eventually became Agile Leadership Journey.”

Through Behrens’ guidance, guardrails, and advice, Salesforce made the transformation their own. They charted their own path. They developed their own vocabulary. And they grew in collaboration and confidence.

“We intentionally began shifting them from a mostly competitive toward a more collaborative team-based culture. Not only was it an agile transformation – it was a culture transformation,” said Behrens.

Making Doubters Into Believers

Despite the progress being made in the early days of the transformation, there were naysayers lurking not so quietly within the organization. Some outright refused to accept that agile ways of working might be the solution to their problems and refused to participate in the transformation. They dismissed Behrens’ guidance and claimed that he couldn’t possibly understand their technical complexities and requirements as he was an outsider. They weren’t wrong on the latter part – he couldn’t understand the complexity of their system – however, he could impart more effective ways of working.

“What I modeled – and what I was so proud of Salesforce’s leaders for fully owning – was a monthly showcase. Every team was required to attend and demonstrate accomplishments and challenges. Teams were sharing wins and struggles, both large and small. There were standing ovations!” says Behrens. And as teams struggled, leaders held firm to their new values and guidelines.

“The showcases became a turning point for many naysayers. After a few months of seeing other teams receive recognition and those holding back receive criticism, the doubters took notice. This time, instead of sitting with arms crossed, they presented a surprising technical development. Despite their insistence that the tech was incomplete, it lit a spark in them. When backed into a corner, they got creative. Sometimes creativity requires a few constraints alongside an audacious goal.”

Focusing on the Right Goal

A red and white target with an arrow in the center.

The problem with many transformations is that teams focus on the wrong goal. With agile transformations, the wrong goal is focusing on agility itself. Behrens explains, “Where others follow the process, we encourage leaders to follow the values. Agile is, in fact, about values in service to the improvement of value delivery.”

For Salesforce, this meant that the agile process and practices were less important than delivering value incrementally. This allowed teams more flexibility in their agile practices without lessening leaders' firm stance on aligning with the values.

While many organizations argue over the “right” processes, Salesforce simply looked past that to the value they were delivering. This flexibility allowed those who shunned specific practices to creatively explore others that led to the same outcomes.

Immediate and Ongoing Results

The impact on Salesforce’s delivery engine? Immediate.

Recall that in 2006, their number of major releases had dwindled down to zero. By the first quarter of 2007, they delivered their Spring release, and for six more years, they never missed another seasonal release target – even as they continued to scale.

With their newfound agility, Salesforce was able to flex their muscles again that had bulked up too quickly, allowing them to get back on track with on-time seasonal releases.

“All transformations are hard. There’s no easy path. But the bigger the challenge, the more satisfying the outcome. What we did all those years ago was scalable and stuck with them as the company continued to grow.”