People photographed from above, sitting at a table.

If you think that Scrum values only help in the Scrum framework, you are very much mistaken. I like to ask a specific question in my training courses when we come to Scrum values: ‘Who knows the four Scrum values and can tell us what they are?’ I usually give the participants a little more time to answer. If no one raises their hand, then I continue: ‘Good. There are actually five.’

We start in the Scrum Guide with a definition, learn something about the theory and then move on to the Scrum values. How is it that so many read over this part of the guide? My colleague Karin already got somewhat to the bottom of this question in her last blog post. We probably want to implement Scrum too quickly and therefore make it too easy for ourselves. Today, we want to take a look at why we should make things harder for ourselves for once.

The Scrum values in detail

Applying Scrum successfully depends on whether people are getting better and better at being able to live out the five Scrum values: Focus, openness, commitment, respect, courage

It does not get any more direct than that. No Scrum values, no successful application. The Scrum Guide leaves us with many uncertainties. We have to find a solution ourselves using the values and framework.

Let us think back to the blog post on empiricism. Transparency, inspection and adaptation certainly go hand in hand with the Scrum values – they promote one another. You can scrutinise this for yourselves in the following text. To what extent are these values consistent with the three pillars of empiricism? I look forward to your feedback!

Focus

We use goals (including product goals or sprint goals) to set a focus – especially in the Scrum framework. When it is set, we pull together, have an end result in mind and know what we are going the extra mile for if doing so is necessary. By focusing on our goals, we create guaranteed added value.

We focus on our goals every day, in every meeting and in every conversation – on what should be achieved. And what should be achieved was not determined haphazardly, but rather was prioritised and thoughtfully chosen.

Openness

We probably find ourselves in a complex environment when we use the Scrum framework. This means that we neither know all the requirements nor have an answer to everything. We solve the problem by taking small steps towards the big picture. Therefore, we regularly have to wrestle with uncertainties as well as the unpredictable. This is exactly where openness comes in.

When we are open to new or different ideas or opinions, if we accept that we do not always immediately have an answer, that someone might contradict us or that we ourselves might be wrong in our assumptions, then we are acting openly. We should recognise that team intelligence and/or swarm intelligence can only develop through openness. We learn from one another and with one another. This is the only way we can solve complex problems.

Developers can use dailies to express their concerns at any time, for example, if the sprint goal is in danger. Reviews promote the exchange of ideas regarding the delivered increments and what should be developed next. Retrospectives are probably the most powerful means of openness. We inspect our cooperation, processes, tooling and much more and adapt if we need to. So, which pillar of empiricism arguably benefits the most from openness?

Commitment

With commitment, we express a promise to invest X amount of effort into achieving a goal without promising to achieve a result. And that is exactly what many people find difficult. Not promising to achieve a result may seem irritating at first. But if, in the agile context, we have accepted that things that we could not foresee will happen, how can we promise that we will achieve a result? Correct. We cannot.

In sprint planning, when we commit to the sprint goal, we have defined what we have to do within the Sprint to achieve it. Whether or not we actually achieve it depends on many unpredictable factors, which we will anticipate by means of the framework and values.

Respect

Dealing respectfully with and amongst one another regardless of role, gender, experience or origin sounds self-explanatory, but it is not. And that is exactly why there should be room for respect outside of Scrum as well.

Respect does NOT mean having to accept everything. Saying ‘no’ is perfectly okay. Being respectful of yourself is just as important as being respectful of your colleagues.

Courage

The more confidence we have, the more courage we find.

Having courage in a company, project or team and always being able to address problems promotes openness and helps us constantly improve. Courage does NOT mean taking advantage of responsibility, increasing pressure or making unrealistic demands. Courage means being transparent – being able to discuss your strengths and weaknesses.

Cherry-picking does not work

We should not fool ourselves: we cannot live out courage without openness. We cannot keep our commitment if we do not focus. Without respect for ourselves and our team, we need not expect the results to be good. The values must be lived out in combination with one another.

If you want to shape values and culture in a company, team or project independently of Scrum, you do not have to rack your brain or start a plethora of surveys to figure out which values make sense. Just start with the Scrum values, use the time set aside for discussions in the team and the rest will take care of itself.

In order for us to benefit from the values, we should truly understand them. We should also clearly understand why common values are needed in the first place. If you manage to do this, then you have created a good starting point for a productive, free and creative environment.

And does your team know the ‘four’ Scrum values?

You can find more exciting topics from the adesso world in our blog articles published so far.

Also interesting:

Picture Stefan Mönk

Author Stefan Mönk

Stefan Mönk is a Senior Consultant at adesso for the Line of Business Public at the office in Hanover. His passion is the topic of agility. As a requirements engineer, agile project manager, product owner and scrum master, the topic of agile software development has always accompanied him. In addition to agility, he is also interested in digital, scaling business models and their monetisation.

Save this page. Remove this page.