Understand Why Salesforce Adopted Agile
After completing this unit, you’ll be able to:
- Explain why Salesforce uses agile
- List some benefits of agile
- Define Scrum
- Explain the “definition of done”
- Understand why agile processes work better for Salesforce
Imagine heading to Dreamforce, only to learn that there are no keynotes, no new products or service announcements, and no innovations or production-ready features available for the next year.
This almost happened to Salesforce in 2006, but we dodged that scenario by implementing a new workflow that revolutionized the way we develop and deliver products.
From 1999, when Salesforce was founded, our Technology & Products (T&P) team delivered like clockwork. Communication and collaboration among the T&P teams was always smooth and simple. But by 2006, we had experienced phenomenal growth—we had more customers, more revenue, more product, and a bigger company. And like with any growth spurt, it wasn’t pain-free.
All the things that used to happen with ease weren’t so easy anymore. As a result, we began to experience a slowdown in innovation.
Scaling communication, collaboration, and management, all while meeting our release dates had become challenging. It was clear we needed a new approach, one that was centered around a smooth product delivery process—one that would ensure no release delays.
So we did what we do best: We took a risk and reinvented our way of delivering solutions. We adopted a set of agile principles and practices.
Why Agile?
Much of the work we do at Salesforce is innovation-based and iterative. That is, the final outcome is not always known in advance, and the path to get there is a work in progress. It’s always a new adventure!
That’s not to say that all teams at Salesforce use agile processes. Some teams use the waterfall framework, which is a much less flexible project management process. Which process you choose depends on what you know—or don’t know when you start the work item.
Here’s a quick glance at waterfall practices.
- Everything is planned up front.
- Requirements are collected in detail before implementation.
- Each step must be completed before moving on.
- The outcome is determined at the beginning.
Plan vs. Adapt
If you’re trying to decide which process works best for you, consider this: If you’re painting a picture, and you’ve decided your colors, your setting, how much time you will spend painting, and what your final image will look like, then you’ve made little room to make changes along the way. That's not to say the picture won’t be a Picasso, but your process isn’t set-up to incorporate new ideas or feedback that can change the final image (for the better, of course). That’s when you might use a waterfall approach.
But when you paint iteratively, you can expect to make changes based on early feedback, new ideas, or even new learnings (those colors clash!) rather than painting in a planned, incremental, order. That’s a more agile approach.
Here’s a visual of those two painting processes:
Image based on Jeff Patton’s work, used with permission, jpattonassociates.com
Work Complexity
So now you know that different processes are better for different types of work. So how do you determine which process is best for you and your team?
When trying to choose a workflow process, ask yourself these questions.
- How much do we know about the project at hand?
- How clear are the project’s objectives and requirements?
- How clear and well-defined is the solution?
- What is the team’s and stakeholder’s experience with these methodologies?
- How complex is the work?
When to Choose Waterfall
Simple work:
- The work is simple and predictable.
- Anyone can determine how to complete the work.
Complicated work:
- The work is predictable, but requires expertise.
- The work can be automated.
When to Choose Agile
Complex work:
- The work is based on consistent feedback, risk, and innovation.
- You want to try something, see how it works, and change course according to new learnings.
- You’re making new products, software, and services, and you’re doing things that have never been done before.
Scaling Salesforce the Agile Way
At this time, Salesforce leadership embarked on a pilot to implement agile practices on various teams. There was some pushback, but Salesforce executives supported the concept, and in 2006, the Salesforce Technology & Products team reorganized into an agile development team.
What did that look like? Well, we did the following.
- Adopted a new delivery mindset
- Implemented standardized processes
- Embraced Lean principles (we tell you more about that later!)
- Standardized what “finished work” means
Our New Agile Mindset
What is this agile process exactly? To put it simply: agile is the umbrella term for various technical practices, processes, frameworks, principles, and values that call for flexibility with workflows and iterative changes to product.
It’s an iterative approach to work where teams build deliverables incrementally from the start of the project instead of trying to deliver one final product at the end. Agile helps alignment among teams, drives quality, and forces everyone to measure and manage progress to deliver more value to customers faster.
It worked perfectly for Salesforce, since we were looking to solve our communication and scaling growing pains.
Our New Agile Process: A Look from 50,000 Feet
One of the agile processes we chose to implement at Salesforce is Scrum, and we supported these with specific principles that defined how we work today.
What Is Scrum?
Scrum is a process, with defined roles, meetings, and deliverables that provides the framework to deliver high-quality value to our customers faster.
Why Did We Adopt Scrum?
Scrum provides us a flexible framework to find out what works and doesn’t work with our products and make changes accordingly. With Scrum, everyone has ownership and shared expectations when it comes to the work in front of them.
What Does the Scrum Process Look Like at Salesforce?
Well, when we adopted it, 150 people were organized into small, cross-functional teams, working in short iterations (we call them sprints). The goal was to stabilize delivery and organize our process. Currently, the majority of Salesforce cloud teams use some variation of Scrum.
What Are Lean Principles?
We also embraced Lean principles. These are seven statements that describe our workflow and delivery process. They reflect our Ohana culture, highlighting how people work best together to promote our structure for success. We look at them in more detail later.
The New Definition of “Finished” Work
Now that we had a new way of working, teams could successfully iterate their process as they learned new information about both their workflow and the product. But how did we know we were truly done with work items?
Easy. We created a standard definition of done (DoD) across Technology & Products teams, so that everyone can be explicitly clear when something is, well, done!
Here’s a scenario to consider: Imagine there’s a new piece of product functionality that you need to create. You assign this new task to your team and ask them to implement it this month. They do it, and move on. Fast-forward a few months, and the finished work item resurfaces with new problems. Perhaps there are customer complaints because integrations were not fully tested. Maybe security issues were not addressed, or performance was not up to par. The conclusion: The work item wasn’t actually finished, at least not enough to deploy.
Our definition of done is a set of guidelines that dictates everything a team is required to do before they can call the work truly done. Creating a standard for this is critical to upholding one of our core Salesforce values: trust.
In a Nutshell
We continually ask ourselves, “Are we making the right thing, in the right way?” This is how we ensure we’re keeping our customers at the center of everything we do.
The rigor of the Scrum process, along with the agile and lean mindsets, are core to improving our delivery and ensuring smoother releases. This is key since Salesforce has three major releases annually for our customers.