Scrum beyond the Scrum guide

When we work with Scrum, we rely heavily on the Scrum Guide. This obviously makes a lot of sense. You need to understand the rules of a game before you can start playing it. And in a sense, Scrum can be seen as a game.

However, like with any game, the rules are only constraints. They do not tell you how to play the game. To be able to play the game you need to understand how the game itself works - the very game that is made possible by the constraints.

Think about any sport: Learning the rules is nowhere nearly enough to be able to participate competitively. Think about how Barcelona dominated football for a decade: They were truly great, but that had nothing to do with an understanding of the rules of football. It was their creativity and craftsmanship that made them great.

Becoming good at a game has everything to do with practice, experience, innovation and wisdom. Pushing the rules, even. And the same applies to Scrum. So herein lies the great challenge of adopting Scrum - the Scrum Guide doesn’t offer us much more than the rules, nor does it offer a clear idea on how to win the game. In fact, the Scrum Guide tells us this explicitly:

As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context-sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere. - Scrum Guide 2020

It is up to us to practice, experience and keep learning. As Ken Schwaber, the co-creator of Scrum said, the framework takes two days to learn and a lifetime to master.

In the rest of this article, I would like to present a way of looking at the Scrum Guide that provides interesting insights on how to play the game.

The Famous Scrum 3-5-3 Shorthand Technique

The 3-5-3 of Scrum is a shorthand for the 3 accountabilities, 5 events and 3 artifacts of Scrum. It is usually used as a handy way of remembering the basic parts of Scrum.

However, I find that it also allows you to look at the Scrum rules from a different perspective. It lets us step away from the details and see some interesting patterns. 

‍

Three Accountabilities

Let me start with the accountabilities. But first, let’s have a look at that word, accountability. Most of us use it interchangeably with responsibility, but there is a very important difference. Responsibility has to do with having to do something, while accountability has to do with reporting on that same something. Basically, you can be accountable for something but make someone else responsible for it. If that other person doesn’t live up to this responsibility, it is you who has to do the explaining, because you are accountable.

An example in Scrum is the way people usually look at the Product Owner as being responsible for the backlog. This implies that the Product Owner is the only one who should be writing, ordering and working out user stories. 

However, this way of looking at it is problematic. For example, it literally reinforces a waterfall approach where developers won’t do a thing until the Product Owner has prepared user stories to their liking. It often results in a bottleneck in the development process.

The line everyone seems to miss in the Scrum Guide is this one: “The Product Owner may do the above work or may delegate the responsibility to others” - Scrum Guide 2020.

This clearly resolves the conflict between the idea that a Scrum Team shares all responsibilities and the fact that we have three different accountabilities. The Scrum Team as a whole is responsible, but specific persons are accountable for specific parts.

This is hugely important because it maintains the flexibility of the whole team being able to do what needs to be done while at the same time it creates a division of power, a trias politica in the team that helps them to focus.

Basically, the Product Owner handles the what, a bit like the legislature works in government; the Developers handle the how, just like the executive branch; and the Scrum Master makes sure everyone follows the rules, just like the judiciary.

This creates creative tension in which the Product Owner can focus on what the customer wants - delivering value - and the Developers can focus on quality and technical excellence. Ideally, the compromise between these two results in the best balance of the two.

Looking at the accountabilities together reinforces the fact that they are never separate from each other. As a member of a Scrum Team, you are not your accountability. The accountability is like a mask you put on that allows you to play a part in a play. We become actors. It becomes a game. We create a setting in which we can have some fun, not take things personally, maybe exaggerate things. And this is a highly effective way of unleashing our creativity!

Five Scrum Events

Continuing with the events, Scrum defines five events, the Sprint Planning, the Daily Scrum, the Sprint Review, the Retrospective and the Sprint itself. I often notice that people experience the events as a lot of meetings. “Not another meeting!” 

I think people have trouble differentiating between the events. By looking at them together we can discover how they have different focuses and how each is an essential part of a feedback loop. This is the essence of Scrum:

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials. - Scrum Guide 2020

First, we have the Sprint itself. Often, people are rather uncomfortable about viewing the sprint as an event, especially if they think of the events as just meetings. However, the sprint is maybe the most important event because it functions as a container for the major empirical iteration in Scrum. All other events are only viable because they happen in the context of the sprint.

The sprint starts with the Sprint Planning. This is the moment when a plan is made for the whole sprint, basically setting up a feedback loop for the creation of the increment. From a scientific point of view, this is the moment a hypothesis is defined against which the efficacy of the sprint to deliver an increment can be tested.

In the Daily Scrum, the Scrum Team validates the sprint plan, taking a moment every day to look critically at whether things are going as planned, and tweaking the plan if necessary. 

What this means is that in Scrum it is not enough that we break up a project into sprints, but we go a step further, breaking up each sprint into iterations of one day!

At the end of the sprint, we have the Sprint Review. The focus of this event is very often just on the increment, ensuring the quality of that which is delivered. But the Review is actually meant to go much further than that. It is also the moment to validate the larger plan, the road towards the product goal, using the knowledge acquired during the sprint. 

In that sense, we are validating 2 different feedback loops: The sprint itself, and the overall plan for the product, which lives above the individual sprints.

The Sprint Review is also the moment to involve everyone in the empirical process. It is the moment that everyone participates in evaluating the feedback loops, but also in preparing the next sprint, the next feedback loop. By combining all of this in one event we provide a very efficient way for everyone to participate, and this allows the team to focus on the rest of the events without too much interference from those outside the team.

To summarize: one event to validate 2 different feedback loops, plus providing a platform to involve everyone, which makes the rest of the events more effective. Talk about efficiency!

Finally, the Retrospective focuses on the process and how the team worked together in the sprint. This may be the most innovative aspect of Agile, in which we focus on the way we deliver value, and not just the value that was delivered. 

This is called double-loop learning, in which we not only focus on what we deliver - stuff like quality, speed and efficiency - but also on the process used to deliver it. It is perhaps the greatest strength of Agile, that we take ownership of our process and have complete freedom to shape it.

Looking at Scrum this way, it becomes clear how it is focused on continuous learning. What seems like ‘too many meetings’ is actually a very efficient way of empirically working at different levels:

• How good are we at managing a single day;
• How effective are we at delivering an increment;
• How well are we working towards a product goal;
• How well does the process itself work.

Three Artefacts

And finally the artefacts. The artifacts are maybe the most abstract part of scrum. The word artefact for me brings memories of the black stone monolith in 2001: A Space Odyssey. The definition which I think is most applicable is the one used in software development:

An artefact is one of many kinds of tangible by-products produced during the development of software - Wikipedia

In other words, the Scrum artefacts are by-products of the process itself. They are not the purpose of the Scrum process, but they help achieve that purpose.

So what does this really mean? I usually ‘translate’ artefacts as deliverables. Each artefact is a specific deliverable for one of the commitments that drive a Scrum Team. It makes the commitments, which are abstract and idealistic, into something concrete, something you can look at and talk about together.

First of all, we have the Product Goal, the high-level vision of the work the team does. It is that which we aim to achieve when the product is complete. You can’t get much more abstract than that, I think? 

To make the product goal visible, we have the Backlog, which forms a roadmap for all the work that needs to be done. It breaks down the Product Goal into parts and prioritises them. Even though the parts may be very big and rough, it suddenly makes it possible to talk about the Product Goal. Just by translating the Product Goal into a Backlog, we can say something about how realistic the goal is.

The same thing goes for the sprint backlog, which is the deliverable that makes the Sprint Goal visible. A team may come up with a brilliant Sprint Goal, but it is the Sprint Backlog (also known as scrum artifact) that makes it possible to decide whether the goal is realistic or not. 

And finally, the Increment, that which is delivered, which makes the DoD visible. Basically, we are talking quality assurance here. The DoD forms the intention to guarantee quality, but that can only be tested against the actual delivery. 

Conclusion

The Scrum Guide is just the beginning of your Scrum journey. Becoming a master means you have to dedicate yourself to the game, making it your own. The only way you can achieve this is with wisdom and experience and looking beyond the rules. Masters have such a deep understanding of the rules that they are able to apply these in original ways and adapt ideas from other areas to better their chances of winning. A master knows how to bend the rules and sometimes even get away with breaking them.

If you look at the Scrum Guide, you will find nothing about User Stories or the Fibonacci sequence. Yet these are concepts that are so integral to Scrum that we assume them to be part of it, simply because they help increase your chances of winning the game.

I like the way Elon Musk puts it:

It is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, i.e., the trunk and big branches, before you get into the leaves/details or there is nothing for them to hang on to.