Editor’s Note: This story was written in partnership by Jason Kline and Jason Coppola from our Agile Coaching team.

Whenever we hire a new engineer, we immediately put them through our two-day training course on the way we use the Agile methodology at Salesforce. We do this for a couple of reasons. First, not everyone we hire has been part of an Agile culture before. And second, even if they have been, it was probably quite different from ours. A big goal is simply getting everyone speaking the same language. With so many different interpretations out there, it’s important that everyone understand what we mean by “Agile” at Salesforce.com.

Having done many of these two-day training courses, we’ve naturally developed a lot of depth around our implementation of Agile principles and processes, which we’d like to share with you now.

How We Define the Agile Methodology

The word “Agile” gets thrown around a lot, and it can mean a lot of different things. Over the years at Salesforce, it’s developed a very deep and specific meaning, and that’s partly because so much of it has been documented in our internal Agile methodology or ADM (Adaptive Delivery Methodology). Rather than focusing on a single method or school of thought, we’ve taken several different aspects of popular Agile methodologies and frameworks, and we combined them.

At the core is something called Scrum, a project management framework that promotes short cycles, iteration, learning, and team improvement, as well as getting and measuring feedback to ship the next increment of a product.

Alongside Scrum, we have methodologies to promote what we call “technical excellence.” For example, we follow several Extreme Programming (XP) practices such as pair programming, continuous integration, daily stand-up meetings and test-driven development.

More broadly, our overall product development, strategy, and decision-making behavior is governed by Lean principles, much as they’re described in 7 Key Principles of Lean Software Development. These practices are foundational to everything else we do, from the development methodologies we use to how we treat our engineers.

One key Lean principle that you’ll see repeated throughout our organization is our emphasis on optimizing the whole value stream, rather than individual functions or teams. We try to create self-sufficient and self-organizing teams — teams that have every role they need and don’t have to depend on other units. Staffing is fluid. Teams are organized into “clouds” in a hub-and-spoke model. Operations are geared toward empowerment, and decision-making is moved toward the lowest possible level in the organization. This is our goal, but clearly there are always areas for improvement.

One thing few outsiders would probably guess about Salesforce is the degree to which our internal engineering culture is founded on the core Lean principle of respect. It’s essential that our engineers feel respected and empowered to voice their thoughts without fear of retribution. We have an internal system in place that ensures transparency. Issues are easily discoverable, which makes it simple for people to broach difficult topics with their peers and management. Salesforce engineers don’t hesitate to suggest that a feature or entire system needs to be rewritten, even if the original author is in the same room — or happens to be their boss.

As we’ve sought to create a culture that builds trust and removes fear, we’ve created places where people can say difficult things and voice brave ideas. Our chat product, Chatter, is used extensively throughout the company and functions as an internal collaborative and social network. We have a group called “Airing of Grievances,” where employees can say whatever they want and it goes out to everyone. It’s a great place to make jokes and blow off steam, knowing that other people are listening, empathizing, and laughing or cursing right along with you. And some of those other people are leaders who watch that feed closely and are measured to make the top grievances better.

It’s incredibly important to us that our developers not only feel heard, but also stay engaged and interested, work at a sustainable pace, and thus do really amazing work. To support this objective, we believe they should be free to work on projects that interest them. In addition to supporting several Hack Days, Salesforce offers its employees a unique benefit called PTOn time, where employees are encouraged to develop their ideas and side projects on company time.

We foster organic change — change from within and from the bottom up. As our organization has matured over the years, we’ve built a lot of processes around Agile in order to scale. We’re proud to say we still operate according to core Agile values. But now we have an additional concern: How do we stay agile?

Part of staying Agile is fostering questions that lead to problem solving and process improvement. We’ve found that some of the best question-asking, problem-solving, and process-improving initiatives have happened organically, rather than as part of a top-down management initiative. An easy example of this is our internal Scrum Master Certification program, which was a direct result of this part of our culture.

How do we nurture that kind of change?

At Salesforce, it goes something like this. When someone has an idea for a change, it’s easy for them to let people know. The employee simply creates a work item on GUS, our internal engineering platform, and explains the idea. A key principle here is that the best ideas should have broad support within the organization. So after launching an idea, the employee then puts together a presentation and an internal “road show,” during which he or she introduces the idea to impacted stakeholders and receives feedback and buy-in. Over time, an employee might gather up enough information and support to present the idea to senior management. Change happens quickly from there.

At Salesforce we have a culture that prizes ideas and thrives on change. Agile impacts both what we do and how we think — it’s the combination of the two that’s made Agile so effective.

This is what works for us, but of course we’re always open to new ideas and change. After all, that’s what Agile is all about.