Why the 5 Scrum Values Matter

In 2016, 5 scrum values were added to the scrum guide, which can be found in its updated version (2020) here.

I will be the first to admit it; when I first saw these values, I thought they were gimmicky and a little cliché.

I should have known better.

After thinking about them over the last years, I have come to the opposite conclusion.

These values are representative of a decades-long conversation of scrum practitioners. The words don’t mean a lot until you understand the very long cultural conversation that happened to make them. To the experienced practitioner, they represent conclusions from each of those conversations. Unfortunately, if you haven’t been part of that conversation, you may miss it.

The rest of this article is me catching myself up to that conversation in hopes that you can learn something too.

Commitment

I’m starting this on a philosophical note so you can skip this if you need to, but if you understand this, you will understand why commitment is so critical to scrum. Scrum builds on the fundamental nature of the universe. It was derived from John Boyd’s OODA loop which decided who lived and who died in airplane dogfights over Vietnam. It has its roots in quality management, and is based on empirical process control theory, a constant flow and feedback of information communicated intellectually through standard instruction and physically through the actual products on the line. These all have to do with seeing a future state, and then aligning your reality such that that future state manifests, manifesting yourself at the same time.

The heart of scrum is commitment. The processes of scrum are made to enable a team to faithfully commit to a future state that is not yet created. The team in turn then gives the organization the confidence they need to know they will reach a certain state.

Scrum commitment is not based on blind promise, it is based on confidence in the mission of the organization, and faith that the team will create a better outcome than today. When a commitment is not met, instead of punishing the members for their failure, the team retrospects on what they need to do to create that better outcome.

Focus

There is always more to do than can ever be done. There is always more improvement than the team will ever get to. The world is a chaos of limitless work. Within the organization, that chaos is centered (theoretically) around the organization’s value proposition, but that constraint only limits, and does not preclude the maelstrom of work that comes from all directions.

The scrum team is a shelter from the storm. To deliver on the value proposition, the developers must have a clear target and a path to get there. This is one of the genius elements of scrum; unshackle the scrum team and they will be fantastically productive.

We give the team focus by following the scrum process, which compartmentalizes chaos and assures certain steps which are stable. Work flowing in goes through one person (product owner). That work is defined in user stories (not technically part of scrum but a technique that captures the spirit of how tasks should be in scrum), which are workable chunks of value. The sprint is an inviolate time where the team knows what they are working, on, have agreed to work on it, and can trust that they will not be interrupted (outside of certain rules of the work). In addition to these safe-guarding rails, the Scrum master, working with the product owner and managers, shields the team from outside chaos, and facilitates certain items so that the team can maintain their focus.

Scrum is a way of finding the most valuable work and working on just that. The scrum team upholds the value of focus by maintaining the integrity of the process, and by knowing that they are not here to do all the work; they are here to do the most valuable work. When a team follows this, they know that what they are working on is important, and in turn they understand better how valuable their contribution is.

Openness

The first pillar of scrum is transparency. Nothing in scrum will work until the members learn to see, then implement ways to process what they see through inspection and adaptation.

The third and fourth ceremonies of Scrum are the Sprint Review, which is transparency to the business on what was accomplished, and the Sprint Retrospective, which is transparency to the team on the working state.

The purpose of scrum is to create a framework that allows the flow and feedback necessary to make transparent and act on information constantly. Transparency is what makes this purpose possible.

Respect

In scrum, team goals, not individual goals and not even business goals, are the most important goals (the team goals should align to the business goals but the team is directly in charge of reaching team goals whereas there is not the same level of responsibility and obligation for business goals). Accountability is not to a manager, it is to the team, and the work comes together when people of various skills collaborate in a small setting. There must be mutual trust on the team that the team can do the job assigned (or otherwise find help). If a team is not self-motivated and mutually driven, the team falls apart.

Respect starts with oneself. When you join a scrum team, you are called to be a member of critical importance to the team and the company(see also how Focus adds to this). The team trusts that you have something of value, and so you should hold yourself that you have something of value to give too. It does not matter what your skill level is; whether a junior member or an experienced developer, do your part to make the team successful because you are that kind of person. If you don’t have certain skills, the ideal scenario is that you work with your scrum master, leaders, mentors, and other resources to obtain those skills, or optionally choose to work in a different niche and (honoring openness) work with the team or organization to agree on what that is. If there is a difference of expectation between what you can do and what the team or organization is asking you, then (once again honoring openness), work with them to reset expectations and potentially move around/out of the team/organization.

From the individual, respect expands to the scrum team. The team members need to mutually trust and respect each part that the individuals bring. Respect is not only crucial for the synergy of the team to work, but to implement adaptation, the team must have a level of psychological safety and mutual respect, because they will need to talk about difficult things. During the Sprint Retrospective, if the team members know that each respects the other, they can be free in managing improvements to the team work. When there is lack of respect, certain things will never get talked about and improvement stutters.

From the team, respect expands to the organization and to the product. Remember that you are building software to create value for the user, whomever, and where ever they are. You are changing the experience of customers. They are counting on you to make their lives better. With this in mind, we can respect the goal of our organization, the people who help our work reach the end user, the customer themselves, and the meaning our product brings to each of these stakeholders’ lives.

Courage

Of all the scrum values, Courage was the one that most surprised me, but, after thinking about my own experience, I realized how crucial this was for me, and how many other teams must have the same need. This value is the one that is most embedded in the scrum culture; you need to see the actual teams to know how critical it is. A team will always be constrained by resources and organizational factors. When one of those constraints hits the edge, the scrum team requires courage to do the right thing for the team, the organization, and the customer.

When the team knows it will not hit its sprint commit, it takes courage to both communicate this to the right people and to retro on what needs to change. When things go wrong, it takes courage to investigate, take responsibility and improve. It takes courage to tell customers or the business that the features they want will not be added to the sprint backlog or to the release (honoring focus). It takes courage to be honest what the team can and cannot do, and it takes courage to hold every team member accountable to their potential.

Finally, it takes courage to do the right thing whatever the external pressures, and to always maintain your integrity in your actions and in your code. Scrum has inherent ‘mores’ of empowering people to live their potential. To realize this mores, the team members need to honor it as well.

Conclusion

Scrum is a process that brings out the best in work. The Scrum values help bring the best in the people who practice Scrum so that they can fulfill their potential and bring out the best in work as well. I hope this article helps bring out the best in you.