Scrum values – the basis for successful work with Scrum
The number of organisations using Scrum is growing continuously. For the approach to work, however, organisations must not only learn to apply the rules of the framework, but also develop an open attitude in order to fill the values with life. The following Scrum values exist:
The commitment of the team to achieve the agreed sprint goal, the commitment to quality, learning and doing the best together is essential to working together and building an agile culture.
Courage is important for the team’s success because it is about trying new things, admitting mistakes, asking for help when needed, saying “no” to some demands and challenging the status quo if necessary. Of course, the Scrum Master – e.g. when addressing unproductive behaviour – and the Product Owner – e.g. in dialogue with stakeholders who permanently demand new things at short notice – must also be courageous.
Openness is the basis for a learning culture, for feedback and new ideas. Openness as a value enables informed decisions, increases efficiency and builds trust.
Despite the openness for new ideas, it is important for the work in the team to focus on the realisation of the agreed backlog items, for example in the sprint. Timeboxing, a definition of ready and a definition of done are useful tools for focus. The focus is supported by the Scrum Master, who tries to keep disturbing influences away from the developers, and the Product Owner, who, for example, focuses on the “why” and “what” and not on the “how” in Sprint Planning.
Respect as a value is essential for the cooperation between the participants. It is important to respect the ideas, views and achievements of others. Respect is a central building block for successful and productive development.
Only with a mindset that lives commitment, courage, openness, focus and respect as values does the framework unfold its greatest benefits.
Scrum values in concrete application
The Scrum Guide, which defines the theory and values of the framework, describes five events, three responsibilities and three artefacts. The interaction of the people involved in the course of the events while working on and with the artefacts requires all values. Below are some examples from practice:
A sprint goal describes the Scrum team’s vision for a sprint. It defines the purpose of the sprint and is the basis for the selection of backlog items. The commitment of the developers is a prerequisite for the formulation of the goal. Accordingly, the Product Goal applies to the Product Backlog and the Definition of Done applies to the increment as an agreed commitment.
The continuous implementation of events, for example in the form of daily standups, sprint planning, sprint reviews and, last but not least, the sprints themselves, also requires a strong commitment. Nothing would be easier than, for example, only carrying out the daily standups every two days; nevertheless, sticking to them in critical development phases is an important commitment of the Scrum team.
Courage is required in many places in Scrum. A product owner, for example, needs courage to explain to a stakeholder why his wish cannot be implemented or can only be implemented at a later point in time. A Scrum Master needs courage to point out the rules of exchange to a manager who participates as a guest in a Daily Scrum. And the developers need courage to admit in the course of Sprint Planning that they cannot really estimate work packages. In addition, the Scrum Team has the courage to do the right thing and work on difficult problems.¹
There are several rules when sharing in the Scrum Team. One of them (the so-called Vegas rule) is: “What happens in Vegas, stays in Vegas.” Everything that is discussed in the retrospective stays with the retrospective participants. Meeting to improve teamwork and joint development performance is based on openness and trust. Especially when giving feedback to each other, this openness and trust is elementary.
All events are planned with timeboxes and ideally adhered to – this increases focus. In the sprint itself (ideally) no changes are made that could jeopardise the sprint goal. Quality goals are not reduced. And the developers independently eliminate possible impediments so that they can concentrate on their work. In addition, visualisation via user story maps or task boards helps to focus on important aspects of the implementation or the progress of the work.
It is important for teamwork that team members respect each other as capable, independent people. Together they have to overcome challenges and develop increments or products. Respect is an important ingredient, which is also formulated as the “Golden Rule”: It’s not about blaming others and knowing better, it’s about the team, in which everyone contributes with their best knowledge and skills. This becomes visible, for example, in the regular retrospectives. At the same time, the people who work with the Scrum team must respect it and each individual member.²
Scrum values in a nutshell
To summarise: “These values give the Scrum Team the direction for their work, their actions and their behaviour. The decisions that are made, the steps that are taken and the way Scrum is used should reinforce these values and not diminish or undermine them. Scrum team members learn and explore the values as they work with the events and artifacts.”³ Or put another way: Scrum values are essential for the successful application of the framework.
Impulse to discuss:
Does demanding courage mean that people should do something they would not otherwise do? In other words, should they behave differently than the organisational context tells them to? And wouldn’t it make more sense to eliminate fears instead?
The Scrum Guide mentions values a total of 25 times, from this alone their great importance can be deduced.
In practice it can be observed that Scrum principles are often spoken of synonymously or complementarily.
If you are interested in further explanations, we recommend the free Scrum Whitepaper.
And here you will find additional information from the t2informatik Blog: