Learn the Basics of Agile
After completing this unit, you’ll be able to:
- Explain the Agile Manifesto.
- Define the difference between agile principles and practices.
- Describe how to be truly agile.
Now that you understand why Salesforce became agile, let’s walk through how you can put agile into practice.
It sounds awkward, but there’s a difference between doing agile and being agile. Being agile means you know why you’re doing it, rather than blindly following a process. There’s a slew of best practices that can make your team agile. Ultimately, if you can answer “yes” to the following three questions, you're on the way to being agile.
- Do our activities focus on people?
- Are we continuously learning and improving in order to evolve our process and product?
- Are we frequently delivering value and delight to our customer?
Agile Values
We like to think of our agile process like a delicious ice cream sundae—layered with delight. So let’s start by talking about the base of our agile mindset: the ice cream sundae bowl!
Back in 2001, before the company adopted agile, 17 software engineers from across the industry drafted a set of foundational values called the Agile Manifesto. This manifesto was the result of large, expensive, and often-aborted or failed software projects that wasted time, money, and energy. They searched for an alternative to the document-heavy, design-it-all-up-front process that failed in the past.
Today, these values ground us, and give us an agile mindset. The manifesto was based on people and collaboration with the goal to create a successful and enjoyable organization.
Here’s a snippet from the Manifesto:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Now let’s dive into these four values.
Individuals and Interactions over Processes and Tools
Part of being agile means letting your teams dictate their own workflow, rather than let legacy processes dictate that. At Salesforce, we use a platform called GUS, which helps teams manage workflows and product development.
At a company our size, you can bet teams are dispersed across various buildings, states, and countries. Agile platforms allow us to maintain seamless communication at scale—regardless of our time zones.
Working Software over Comprehensive Documentation
So how do we confirm we’re making real progress? We rely on a tangible result: a software, service, or deliverable that is proven to work. In other words, a specification document in and of itself does not validate that we are doing the right thing, nor does it provide customer value.
Customer Collaboration over Contract Negotiation
Part of being a customer-centric company means we aren’t just assuming we know what’s best for customers—we’re actually implementing what they tell us is best for them. Our short sprints and continuous improvement processes help us respond to changes customers want—quickly. We use mechanisms like IdeaExchange (a forum where customers propose ideas for us) to understand what our customers find compelling, useful, and exciting.
Responding to Change over Following a Plan
The nature of the work we do at Salesforce is creative—and so is the process. We can’t be exact about every outcome, nor can we map every step of the journey in advance—there are always detours when you’re on an adventure! Not only that, but we need to respond to customer feedback quickly, which means changes happen, and they happen fast.
This is why we begin all of our presentations with a Safe Harbor notice, cautioning customers who purchase our services to make their purchase decisions based upon features that are currently available, not on forward-looking statements we make.
That’s not to say we’re doing things by the seat of our pants. Our teams plan regularly, from our yearly company-wide planning process to release planning, increment planning, and daily planning meetings.
Agile Principles at a Glance
On the next layer of that ice cream sundae are 12 agile principles that add flavor to our iterative process. Consider these your ice cream scoops in the bowl (assorted flavors, of course).
They include things like:
- Keeping things simple
- Embracing change to remain competitive
- Face-to-face communication is best
- Business people and developers work together throughout the project
You can read more about the principles here.
Frameworks
Now that we have all that ice cream in the bowl, it’s time to get crazy with the fudge sauce! Go ahead and douse your ice cream with a variety of defined frameworks to provide methods and guidelines for roles and meetings that help us put our mindset and aspirations into practice. A few frameworks used at Salesforce: Scrum, Kanban, Scrumban (a mixture of both), and eXtreme Programming (which is a set of technical best practices).
Practices
Like the colorful sprinkles on our sundae, there are many agile, lean, and technical practices that allow people to enact the frameworks in an agile and lean way. At Salesforce, these practices include the cadence of planning, how teams inspect and adapt, and what roles and responsibilities people have. Every employee creates annual planning documents and backlogs to manage and prioritize work. This is in addition to our hybrid engineering practices and automated test environments.
It’s these agile values, principles, frameworks, and practices that help us build on our Salesforce Ohana.
