The 2020 Scrum Guide includes five values that are important to every successful implementation of Scrum. These values are courage, commitment, focus, openness and respect.
These values don’t get much attention, but the longer I practice Scrum and coach teams, the more important I find them. This article will outline each value and provide examples of how they play out in the real world.
Focus
Focus in the context of Scrum means to focus on the work of the Sprint. Sounds easy, right? It’s not. Imagine that you are a developer working on delivering a Product Backlog item. You find something else that you could improve in the code (e.g. some technical debt, a part of the system that could be updated to be dynamic instead of hardcoded). It’s tempting to fix it right away, but that might be the wrong decision. Depending on the situation, attending to this work without consulting the Product Owner may undermine the Product Owner, who is accountable for deciding the most valuable thing to do next. Instead, a developer in this scenario should consider speaking to the Product Owner about adding this work to the Product Backlog. That’s focus.
When I use the above example in training, I get a lot of questions about the decision not to “fix” the code. Developers ask, “Isn’t that adding duplicative work if I have to open up the code twice when I could just make a small change while I am in that part of the system?” My response is to ask whether they have considered the testing implications of a minor technical change? Have they considered the long-term goal of the product and whether there might be something more valuable to spend time on than this particular item? Efficiency and lean are not just about making snap decisions about what to do next; they require dedication, discipline and a higher-level focus on the product goals.
The Product Owner provides focus to the Scrum team by ensuring that the Product Backlog order shows what the Scrum Team will work on next. The Product Owner is also accountable for ensuring that the Product Backlog contains a Product Goal. The Product Goal provides the Scrum Team with focus and can also guide the ordering of the Product Backlog. In complex environments using Scrum, delivery can falter if the team does not have a Product Goal.
Focus is also essential for the Scrum Master. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. There are many ways in which this accountability impacts focus. One of the most frequently overlooked elements of the Scrum framework is the Sprint Goal. During the Sprint Planning event, the Scrum Team should select a Sprint Goal that describes the primary purpose of the Sprint. The Sprint Goal creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
Courage
The Scrum Guide defines this value as having the courage to do the right thing, to work on tough problems. Courage is essential for those who work in complex environments where productive conflict helps discover creative solutions to difficult problems. It takes courage to engage in a dialogue about how to solve difficult problems. It takes courage for the Product Owner to make the right decisions for the product, and it takes courage for the Scrum Master to uphold the Scrum framework in environments where Scrum may be new or misunderstood.
Commitment
Commitment is the most misunderstood value in Scrum. A Scrum Team commits to supporting each other to achieve the Product Goal and Sprint Goal. Many believe the team must (no matter what) deliver every Product Backlog item added to the Sprint Backlog during the Sprint Planning event. That is not the case.
Because teams use Scrum in complex environments, they may not know how to deliver an individual Product Backlog item until they have delivered it. Also, the unexpected often happens during the Sprint. Sometimes delivery of the Product Backlog item takes longer than anticipated. Sometimes the test environment goes down, the lights go out, or we all get sent home to work remotely during a pandemic. When these things happen, the Scrum Team regroups to decide how to deliver a Done increment that meets the Sprint Goal. The Scrum Team is committed to achieving the team’s goals, and the purpose of each Sprint is to deliver a Done increment that meets the Sprint Goal. The commitment is not to deliver every single Product Backlog item and task originally identified in the Sprint Planning event.
As always, there must be a balance. The Scrum Team members are accountable for doing their best to deliver the Product Backlog items planned for the Sprint. But, they have to weigh this against the reality that Scrum is an agile framework used in complex environments where more is unknown than known.
Respect
A Scrum Masters that I used to work with would frequently say, “Assume positive intent.” And wouldn’t the world be better if everyone lived and worked in a place where that was possible? For example, imagine that you are a developer who has shared an idea in a brainstorming session. One of the other developers disagrees with you and proposes a different approach to the work. Rather than perceiving this as a personal attack, why not explore both ideas with curiosity? We have no reason to suspect ill intent unless proven otherwise. Everyone brings their individual experiences and knowledge to a problem, bringing value to the process.
Respect is critically important to the Scrum Team’s success. To have the productive conflict necessary to find the best solutions to complex issues, Scrum Team members must respect each other as capable, independent people. Working in complex environments, we have to have the courage to engage in open and honest dialogue to solve problems, but we must do so with respect.
Openness
Being open about the challenges facing a Scrum Team is difficult. It means being open to new ideas. It means being transparent about the problems facing the team. It can mean trying things that are not comfortable. For example, for Developers, this can mean being vulnerable. When I worked in a waterfall environment, developers sometimes suffered in silence for weeks because they didn’t want to admit struggling. I get it; it’s not easy to be vulnerable. Three of the scariest words to say are “I don’t know,” and being open to new ideas (or worse—harsh feedback!) can be just as hard. For a Product Owner, it can mean soliciting feedback from stakeholders at the Sprint review or conducting a brainstorming session with the Developers. For a Scrum Master, it can mean promoting self-management and being open to trying new processes. Being open is an invitation to growth, and growth is not always easy, but it is always a journey.
Conclusion
How can you better live the Scrum values as part of your team? I suggest you discuss it at your next Sprint Retrospective. On a shared whiteboard, place each Scrum value in a separate column. Then, ask the Scrum Team to brainstorm how to improve the way that the team members live these values every day. Next, vote on one or two ideas, and implement them as soon as possible. Reflect. Improve. Repeat.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.