The Scrum values

Which value does the behaviour spend?

A values question is never "define openness". It describes somebody doing something and asks which value is at stake, and all four options are real values, which is what makes it hard. The test that works under time pressure is to ask what the act COSTS rather than what it claims. A Developer who says out loud, halfway through a Sprint, that the design everyone agreed last week will not scale is spending social capital, and courage is the value attached to acts with a social price: bad news, an unwelcome objection, admitting you are stuck.

Run the same test on the wrong answers and they collapse. Staying quiet to spare colleagues an awkward hour is not respect — respect in Scrum means treating people as capable of handling what you know. Withholding a change in company strategy so the team is not distracted is not focus: focus is about where attention goes, never about what people are allowed to know. Focus is the value most often misused to justify silence, and an option that uses it that way is offered for exactly that reason.

The values also reinforce one another rather than trading off, which gives a second test. A practice that buys one value by spending another — visibility bought with respect, focus bought with openness, a comfortable Sprint Review bought with transparency — is a warning sign in Scrum rather than a balance somebody struck sensibly.

Commitment does two jobs, and neither one is a number

Commitment is a value: committing to the goals and to supporting each other. It is also the word Scrum uses for the thing attached to each artifact — the Product Goal to the Product Backlog, the Sprint Goal to the Sprint Backlog, the Definition of Done to the Increment. Neither meaning is a promise to deliver a fixed quantity of work, and the exam has a favourite scenario built on people who believe it is.

A team selects eleven items, finishes nine, and meets the Sprint Goal. A manager calls that a broken commitment and wants the team held to its number. The answer names what the commitment actually was, and the Guide supplies the reasoning in one clause: although the Sprint Goal is a commitment by the Developers, "it provides flexibility in terms of the exact work needed to achieve it". The eleven items were a forecast made at the point in the Sprint where the team knew least.

Coaching the team to select fewer items so that it always finishes everything is the response that sounds responsible and is wrong. It buys the appearance of reliability with hidden slack, and it teaches a team to stop saying what it actually learned during the Sprint — which costs the organisation the only thing the Sprint was producing besides the Increment.

Openness has a deadline

Openness in Scrum covers the challenges as well as the work, and the exam tests it with timing rather than with sentiment. Developers who conclude on day three of a two-week Sprint that the Sprint Goal is very unlikely to be met, and agree among themselves to say nothing until the Sprint Review, have not merely been reticent. They have converted a problem with eight working days of runway into a report.

The framework is arranged so that a Sprint Goal in trouble is still something the Scrum Team can act on: the Developers adapt the Sprint Backlog, and scope can be clarified and renegotiated with the Product Owner while the Sprint is still running. Transparency that arrives at the last event of the Sprint arrives after every one of those options has expired, which is why "it becomes visible at the Review either way" is a trap rather than a defence.

Respect is a rule about who decides

Respect has a concrete consequence in Scrum rather than a sentimental one. Team members are capable, independent professionals, and a Scrum Team is self-managing: it internally decides who does what, when and how. A newly appointed Scrum Master who keeps assigning work to Developers "until the team is ready to do it themselves" is not being cautious, they are maintaining the exact condition they were brought in to end.

The same point answers the accountability that option is usually built on. A Scrum Master is accountable for the Scrum Team's effectiveness, and the way that accountability is discharged is by enabling the team to improve its own practices within the framework. Making a team's decisions on its behalf is a different activity, and its reliable product is a team that cannot make them.