Peter Goetz
& Uwe Schirmer

“Is this correct according to Scrum?” is a question that we get asked frequently. It usually follows a description of a concrete team practice, and the person asking wants to know if they are applying Scrum correctly (i.e., according to the Scrum Guide).

Although the question is valid, we try to understand why it’s being asked. Teams and organizations often focus on the mechanics of Scrum and forget about their real purpose, which is usually to generate and increase value for their customers, their stakeholders, and themselves.

Don’t get us wrong: the Scrum Guide is important to us. It describes the core elements for solving complex-adaptive problems and how they play together. We take it seriously, as it helps us focus on solving our problems collaboratively and creatively—something that goes beyond just reading and applying the Scrum Guide.

There is one reason for Scrum to exist: “delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint”. All the elements in Scrum support this. The roles divide and share accountability for the people involved in the work. The artifacts create the minimum transparency needed to iteratively and incrementally deliver a releasable Increment. And the events are opportunities to inspect and adapt according to the information collected in the artifacts and create a rhythm of feedback in various areas of interest. This rhythm improves the Scrum Team’s flow of work. The Scrum Values describe a shared mindset that is extremely helpful when continuously reviewing and improving our way of working together.

You can follow the rules as described in the Scrum Guide mechanically. You can appoint a Product Owner, Scrum Master, and Development Team. Install a Sprint and invite the team (and sometimes stakeholders) to the events. Set up a tool for Product Backlog and Sprint Backlog management and tell the Scrum Team to get started. If the why behind Scrum isn’t understood and lived, no real improvements will occur. The Scrum Team might even become annoyed by this new game, as they don’t see the point behind the rules. Worst case, they get burned out by the stress that those new elements create compared to their old way of working.

We therefore suggest a different approach. We encourage organizations to first talk about their challenges and where their current strategy to solve them isn’t helpful or needs to be improved. We can then think about ways to overcome those limitations and explore how Scrum might help. Only then does it make sense to start introducing Scrum.

Two questions should be the North Star in the ongoing journey:

1. Are we able to deliver a valuable and releasable product Increment each Sprint?

2. How can we improve our way of working together?

These questions shift the focus away from the mere mechanics of Scrum. We learn how to use them against clearer goals and problems. We will improve our skills and tools continuously to progress toward those goals. This will increase our motivation and lead to more happiness and a more humane workplace.

And—most probably—we will still be working according to the Scrum Guide. Not because the Scrum Guide says so, but because it makes sense.