What are the Scrum values?
Scrum is a very popular and well-known framework for Agile software development. Lots of people know about the roles, rules and rituals and Scrum. But a few years ago they added values. Not a lot of people know and understand these values. So this article will explain what are the Scrum values.
As you probably know, Scrum is defined in the Scrum Guide. This document has been around for a long time and gets updated every now and then. One of the major updates was in 2016. Ken Schwaber and Jeff Sutherland (the creators of Scrum) added Values to the guide.
This was the first major update in a while. I feel it was an important change. Values are an important part of the Agile Manifesto, so they should be in Scrum as well.
The Scrum values
So what are the Scrum values? Let’s go through them. They are:
- Commitment – People personally commit to achieving the goals of the Scrum Team
- Courage – The Scrum Team members have the courage to do the right thing and work on tough problems
- Focus – Everyone focuses on the work of the Sprint and the goals of the Scrum Team
- Openness – The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work
- Respect – Scrum Team members respect each other to be capable, independent people.
The Scrum guide doesn’t provide much of an explanation of these values. It says it is up to the team to “learn and explore those values”. Which is in the Scrum spirit of providing a minimal framework. Within which a team can learn and find their own way.
Here are my thoughts on these values, their importance and how they can be applied.
Commitment
This is a tricky and controversial one. The word “commitment” can mean different things to different people. Some people think it means that a Scrum team is locked into an iron-clad contract to deliver the planned work. No matter what.
That is a dangerous mistake.
Commitment here does not imply a contract – as in “you made a commitment to me, here!”. That view is a relic of old-fashioned command and control thinking. That type of thinking sees stakeholders and developers in opposition to each other. Where each is trying to gain an advantage in haggling over what was and wasn’t contracted to.
The word commitment here I think implies instead a mindset or an attitude. “The team is committed to making this work”. “I have a strong commitment to seeing this through”.
Remember, agile software development emphasises sustainable pace. No team should be forced or even encouraged to go on a death march. No matter if it is to meet a sprint goal.
The team are committed to the goal and care about it. And they should try their hardest to focus (another important value) on the goal and have the courage (another value) to see it through.
But they are not contractually obliged to do anything. And anyone who thinks they are has misunderstood this value.
The team is rather committed to delivering value, rather than just spinning wheels and pushing out random stories. They are committed to the principles of Scrum and continuous improvement. They are committed to the team and each other, rather than to individual achievements and heroics.
This commitment, when combined with other values, helps the team drive towards maximising value.
Fortunately, the Scrum framework includes things that encourage commitment.
- A clear, agreed Definition of Done encourages the team to complete quality work
- A specific sprint goal encourages the team to commit to a specific target, rather than just working randomly
- A new Product Increment every sprint encourages the team to commit to completing a valuable product every iteration.
Courage
Courage is an interesting value, and enormously important. Courage is essential to transparency and safety.
If the team does not have courage to admit mistakes, they can never learn from their experiments. If the team does not have courage to speak up, the team will be ruled by the HIPPOs (Highest Paid People’s Opinions). And that means poor decisions can be made with bad results.
It takes courage for a team to admit they are working in conditions of uncertainty. And that planning and estimating are imperfect things. It takes courage for a team to admit they are going down a wrong path and to change direction.
Most importantly, it takes courage for a team to build quality and pay down technical debt. There are often enormous “delivery pressures” put on teams to pump out work at a frantic pace.
This often results in teams leaving behind a mess of ugly crappy code, which is not their fault.
Courage is required for teams to say “no”. To insist that they have to go slower (which in the long run will actually result in going faster). To focus less on quantity and more on quality.
For Scrum to really work, teams need to be empowered, they need to manage their own work, and they need to be left alone and not be micromanaged. If those things hold true, then the team needs the courage to accept this and forge their own path.
Focus
Focus in important when dealing with complexity and uncertainty. And product development always has to deal with complexity and uncertainty, because we are always building something new for the first time.
Focus can help teams to get work done and reduce WIP. It does this by encouraging teams to zoom in on stuck or undone work. And swarm to get it complete.
Focus is essential for a team to prioritise work when there are multiple options. And there are always multiple options. Because there is always more work that could be done compared to the capacity of the team.
Focus is also essential to forming a clear product vision. And this product vision helps drive the team to clear sprint goals and valuable product increments. Product Owners must employ laser-strength focus to ruthlessly prioritise. And to maximise the value of the product increments.
In an interesting way, the Scrum value of Focus is related to the Agile principle of Simplicity (my favourite of the Agile values). That is, maximising work not done.
Focusing isn’t just about doing, it’s also about not doing. It’s about choosing what to do, and what to drop. What to prioritise, and what to de-prioritise.
And that’s because every decision to do something is a decision to not do something else.
And most importantly, focus is what enables a Scrum Team to ignore distractions and move in a coordinated fashion. And so to complete the Sprint Goal and deliver a Product Increment. A lack of focus is going to be a huge impediment to a team achieving this each sprint.
Openness
Openness is extremely important to success in Scrum because it is closely related to one of the three core Scrum pillars: transparency. Everything should be open and transparent in Scrum.
The team is open and transparent about the work they are doing. The product backlog and sprint backlog should be visible to anyone who wants to see them. Product Increments are regularly shared with stakeholders at Sprint Reviews.
The Scrum Team members are open with each other too. They discuss their work and progress every day at the Daily Scrum (ideally, face to face in a physically co-located environment). They should employ information radiators as much as possible. So physical boards and charts instead of digital ones.
Scrum encourages not just open information but an open attitude too. Through retrospectives, the team become open to new ideas and new ways of working. The team should ensure they have a mindset that is open to the idea that they could be wrong about things, and are always learning.
This means learning how to build better products, how to interact with each other better, and learning new approaches to problem-solving.
Sprint Reviews provide an opportunity for being open to honest feedback about the product that the team is building. And Sprint Planning creates openness around the team’s plan and scope of work for the sprint.
The organisation needs a spirit of openness, too. Being open to the ideas of Scrum and open to fundamental changes that is required for Scrum to really work.
Respect
Respect is completely fundamental to not just Scrum but any form of collaborative team-based work. In fact, Respect for People is also one of the core pillars of Lean (not much of a coincidence).
Scrum will only work if the people on the team respect each other. They need to respect each other as people, they need to respect each other’s diversity, and they need to respect each other’s differences.
They need to respect that they won’t always agree on methods but they share a common goal. And that goal is building a wonderful and successful product.
They need to respect the basic rules and practices of Scrum, while respecting that it is a limited framework. And that it is intentionally left incomplete, and that they can and should add practices and methodologies as they go.
They need to respect that people are trying their best and are always learning, changing and improving.
The overall organisation needs respect too. It needs to respect Scrum, respect the team and respect the pillars of transparency, inspection and adaptation. Without this respect, Scrum has little or no chance of succeeding. Or will quickly get turned into Zombie Scrum and Cargo Cult Agile, and nobody wants another sad example of that.
What values did Scrum leave out?
While this is a good set of values, there are two that I think should be in there. Those are craftsmanship and customer-value.
Craftsmanship
The Agile Manifesto doesn’t use the word but it talks about craftsmanship. It says “Continuous attention to technical excellence and good design enhances agility.”
A common problem with Scrum is that teams move quickly at first, but don’t put enough effort into quality and technical excellence. The end result is that we end up with applications riddled with technical debt.
The priority of work is set by the product owner, so unless they really understand the importance of software craftsmanship and paying down tech debt, the problem can run away and become almost insurmountable.
While Scrum talks about quality and Definition of Done, I think having an explicit value around quality and/or craftsmanship would help make this clearer.
Customer Value
The Scrum Guide could prioritise Customer Value better. Product Owners are often bullied by stakeholders into maximising the value of whatever metric or KPI they are tied to. Which might not be what customers want.
The most successful companies and products place the customer above all other interests, including shareholders (and ironically, usually end up maximising shareholder value anyway).
The Scrum guide says this: “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” So it only directs the Product Owner to maximise “value” – this could really mean anything.
The intention is presumably that the Product Owner can decide best what that means. In many contexts though, customer needs are not prioritised. This is especially the case in organisations with silo business units, each with particular KPIs and local optimised.
The best way to achieve explosive growth is for the whole organisation to ruthlessly prioritise customer value over all other priorities.
Conclusion
It was a brave and important decision of Scrum to incorporate these values into Scrum, especially for an organisation with a history of making very few major changes to its core document. When applied properly, the values help nurture and protect Scrum and give it its best chance of success. When ignored, Scrum will likely become a rote mechanical system of attempting to improve “productivity”, without understanding the profound changes required for it to work properly.
