The original version of the Scrum Guide didn’t contain a section on Scrum values. But now it does, because the authors listened to feedback on the Scrum Guide User Voice forum. Adding a Scrum values section was the most popular request, so they wrote it into the latest version of the Scrum Guide.
Why was this considered such an important addition to the guide?
The bottom line is that successful Scrum depends on the entire team embodying specific values: commitment, courage, focus, openness, and respect. Without relationships built on these values, the Scrum team can’t sustain productivity.
Because Scrum isn’t only about delivering quality software. It’s about creating a great place to work—a place where people can take pride in their job and themselves.
In this post, we’ll take a closer look at what these Scrum values mean, personally and professionally.
Let’s start with a quick overview of the culture they enrich.
Navigating Scrum relationships
The Scrum Guide describes a problem-solving framework that’s well suited to the demand for continuously improving software. It lays out the various roles of the Scrum team and Scrum events, which help the team break down large projects into manageable steps to “optimize predictability and control risk.”
Scrum teams are typically made up of five to nine members, including the product owner, development team, and Scrum master. These folks are independent and cross-functional, meaning they decide among themselves how to get the work done, and they don’t need outside help to do it.
Their work is divided into sprints, typically one to four weeks long. During the sprint, the Scrum team plans, develops, and delivers a usable product increment. Regardless of the skills and contributions of individual members, when it comes to the end result, the entire Scrum team is accountable.
You can see there’s got to be a lot of trust involved—both within the team, and between the team and the company at large. In Scrum, managers aren’t leaning over one another. Individuals manage themselves.
The benefits to this kind of self-organization are numerous. But things can go sideways if people aren’t aligned.
I’m not talking about healthy disagreement. A little debate comes naturally to any community trying to solve a new problem together.
I’m talking about the base-level values people need to share to collaborate meaningfully. While a shared belief system can help any team work together, it’s pretty much a lifeline for Scrum.
The 5 Scrum values
Scrum represents a clean break from traditional “command and control” management.
The Scrum team makes its own decisions and sets its own goals. For both those things to happen means living the five Scrum values I mentioned above.
Says the Scrum Guide:
“People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.”
Scrum teams are small and they have a lot to get done quickly. Each person needs to feel confident in their ability to the fullest. Here’s where values are key.
The Scrum framework helps each member determine what to contribute. Scrum values help each member determine how to deliver that contribution with an eye toward the long-term health of the team.
As you can see from the Scrum Guide excerpt, Scrum values solve the paradox of Scrum: how to get a group of independents working together.
Living the 5 Scrum values
Scrum values are easier to talk about than they are to live, but paying lip service to any kind of value isn’t enough.
Think about being on hold while a pre-recorded voice drones, “we sincerely value your time.” Yeah, okay.
The truth is that values are more than words or abstract ideas. If they don’t lead to concrete changes in behavior, you may as well not have them. What follows is a short description of each Scrum value, along with examples that will help you incorporate them into team interactions.
Both the macro and micro integrity of the sprint are completely dependent on the commitment of each cog in the Scrum machine.
In sprint planning, the development team has to commit to a realistic product increment. At daily Scrum, they must be accountable for yesterday’s result and committed to taking the next step.
But commitment isn’t just on the part of one cog: the development team. The whole company needs to commit to Scrum. Outside the team, commitment means things like vowing to keep a distance and letting the team accomplish its own goals.
Consider the alternative. Maybe the product owner is more committed to stakeholder satisfaction than the quality of the product. Backlog adjustments happen at the whim of non-specialists and the team finds itself playing catch-up after wasteful detours. How is that supposed to inspire trust?
There are other important dimensions of this value as well. For example:
- A Scrum team needs to commit to a definition of “done” for the sprint increment—and to delivering it. Nearly done won’t do.
- The Scrum master needs to commit to guiding the team toward its goals.
- When the sprint is over, the team needs to reflect on what they did through a retrospective, and commit to improving processes moving forward.
Folks outside Scrum can’t necessarily gauge the team’s progress, yet they depend on the team to produce vital increments. The entire company relies on them to be honest about their work and the challenges they face. This requires courage at every turn.
Bad-news suppression is a killer. Problems that could have been dealt with aren’t even uncovered until too late if people are afraid to speak up.
It takes courage for a Scrum master to deliver bad news to stakeholders outside the team. Even more nerve to keep those stakeholders from blocking the team’s progress. Of course, this is all predicated on each member’s honesty about their progress with themselves and their teammates.
And it’s not said enough within the agile community: improvement takes courage too. Like the products they deliver, Scrum teams have to improve continuously.
Routines are comfortable and it takes courage for individuals to push past “the way we’ve always done it.” If the team has the assurance that they are committed to one another, and knows the company is committed to them, it’s easier to make courageous decisions.
Complexity and uncertainty are two staples of the software development landscape. It’s important that Scrum teams maintain a clear product vision to stay laser-focused as user needs and priorities shift.
Think of it this way. If there are 100 things to do, would you rather do 10 of them well, or all 100 passably?
Even with the best-laid sprint plans, Scrum teams can quickly feel overloaded. Or can lose track of what one another is doing. Figuring out what to tackle first and minimizing waste takes the whole team thinking as one and hammering out how each activity moves the sprint forward.
So, for example, the product owner needs to ensure the product backlog is focused on the features that deliver the most value to clients. The development team needs to divide the work so that each individual can focus their energies on best-fit tasks and knows exactly how their piece of the puzzle fits with others’.
As a Scrum value, openness has two important facets.
The first relates to transparency, one of the three core pillars of Scrum. To inspect and adapt products and processes, Scrum teams need to be open about their progress. Team members need to feel comfortable sharing their work and fears about what’s coming next.
When running a Scrum of Scrums, for example, you’d need to coordinate integration. Imagine if activities weren’t communicated freely. Best case scenario, you get redundancies and work overlap. Worst case, serious problems that threaten a feature’s usability or shippability aren’t uncovered until it’s too late.
The other aspect of openness relates to acceptance and receptivity. Everyone needs to be open to change, asking for help, and providing it. They need to be able to admit when they’re wrong and open to feedback and collaboration.
A perfect example of this is during the sprint retrospective. The team needs to be especially open about addressing successes and failures. And most importantly, open to each other’s ideas—however weird or wonderful. They’re all valid.
Everyone is coming from a different place in life, and they bring different experiences and identities with them. To work as a team, they need to respect each other’s differences. Better still, celebrate them!
Take the development team. It’s made up of cross-functional individuals. They may not share skillsets, but they do need to work in concert. Each person has to assume that others have good intentions and are doing their best to reach the same goal.
I’ve found that Scrum masters can do a lot to encourage this kind of respect simply by ensuring that every member who needs to be at a sprint event is there, on-time, and engaged.
Show people that their time is valuable and their contributions essential. Give problem owners a chance to speak for themselves. Be a model for respectful dialogue and support team opinions regardless of your own.
Final thought: Make your own contribution to Scrum
There are so many other ways these values can manifest. The above examples are only the beginning. And your own matter more than you think.
Remember where the Scrum values came from? How the community pushed for including them in the conversation?
As you implement Scrum at your company, or develop products with your team, why not make a suggestion to improve the next iteration of the Scrum Guide based on mistakes you’ve learned from or a new best practice that’s working for you?
Log on to the Scrum Guide User Voice website. Give your feedback. See what others are saying. Never stop improving.