The Scrum Values: Why They Matter More Than the Practices

Scrum is deceptively simple. The framework fits on a few pages. The ceremonies are well-defined. The roles are clear. And yet most organisations that adopt Scrum struggle to make it work. Teams run all the ceremonies and produce all the artefacts and still feel like the framework is not delivering what it promised.

The reason is almost always the same: the team is running Scrum but not living the values. The mechanics of Scrum are the visible surface. The values are the foundation. Without the foundation, the mechanics are hollow.

The Scrum Guide identifies five values: Commitment, Focus, Openness, Respect, and Courage. Here is what each one means in practice — and what its absence looks like.

Commitment

Commitment means the team dedicates itself to achieving the Sprint Goal and to supporting each other in doing so. It does not mean committing to a feature list without room for learning. It does not mean promising stakeholders that everything on the backlog will be built. It means the team is genuinely invested in the outcome of the sprint, not just the completion of tasks.

Absence looks like: developers who disconnect after their own tasks are done, a Scrum Master who treats the daily standup as a status report to relay to management, and a team where "I did my part" is considered a complete answer.

Focus

Focus means the team concentrates on the work of the sprint and the Sprint Goal. It means resisting the pull of ad hoc requests, side projects, and the constant interruptions that are endemic in most organisations. Focus is what makes the sprint timeboxing meaningful — if the sprint is treated as a container for whatever comes in, it is not a sprint, it is just a two-week block on a calendar.

Absence looks like: team members handling urgent "priority one" requests from outside the sprint every few days, a backlog that gets new items added mid-sprint without trade-offs, and a retrospective where every problem is traced back to interruptions.

Openness

Openness means the team and its stakeholders are transparent about the work, the progress, and the obstacles. It means the sprint review is an honest demonstration of what was built — not a polished performance designed to manage stakeholder perception. It means the retrospective is a genuine conversation about what is not working, not a scripted exercise in positive framing.

Absence looks like: teams that hide problems until they become crises, retrospectives where nobody mentions the elephant in the room, and sprint reviews where the demo is rehearsed to avoid difficult questions.

Respect

Respect means team members recognise each other as skilled, capable professionals and treat them accordingly. It means the product owner respects the development team's technical judgment. It means the development team respects the product owner's domain expertise and prioritisation decisions. It means the Scrum Master is respected as a facilitator, not ignored as an overhead.

Absence looks like: stakeholders who speak directly to developers to bypass the backlog, senior engineers who dismiss estimates from junior team members, and managers who sit in the daily standup and make it a reporting session.

Courage

Courage means the team does the right thing and works on difficult problems. It means the development team tells the product owner when a requirement is underspecified rather than guessing. It means the Scrum Master raises process problems with the organisation even when doing so is uncomfortable. It means the product owner says "we cannot build all of this in this release" rather than making commitments the team cannot keep.

Absence looks like: developers who implement what they are told without raising concerns, a product owner who says yes to every stakeholder request to avoid conflict, and a Scrum Master who facilitates ceremonies without ever challenging the organisation's impediments.

How a Scrum Master Coaches Values Without Lecturing

The worst way to introduce the Scrum values is to present them in a kickoff meeting and then move on to the sprint planning. Values are not a slide deck. They are demonstrated through behaviour and reinforced through facilitation choices.

A Scrum Master coaches values by creating conditions where the values can emerge. In the retrospective, they ask questions that invite openness: "What is something we have been avoiding talking about?" In sprint planning, they help the team commit to a goal rather than a task list: "If we achieve one thing this sprint, what should it be?" When a developer raises a concern about a requirement, the Scrum Master amplifies it rather than smoothing it over: "That sounds like an important question — can we spend five minutes on it before we estimate?"

Warning signs that a team is running Scrum but not living the values are visible in retrospective outputs (the same issues appear sprint after sprint), in sprint reviews (demonstrations of partially completed work are hidden rather than shown), and in daily standups (team members give the same update three days in a row without anyone asking why the blocker has not been resolved).

The Scrum ceremonies are not wrong. They are well-designed for what they do. But they only work when the people participating in them are actually practising Commitment, Focus, Openness, Respect, and Courage. A team that has the values can make almost any framework work. A team without the values will struggle with Scrum regardless of how faithfully they follow the ceremony schedule.

XNM Consulting supports organisations in building high-performing agile teams, including Scrum adoption, coaching, and delivery governance. Learn more about our .