In today’s post, we are continuing the observation of Scrum through the lens of game design. In part 1, we discussed how having a short-term goal makes for a compelling experience. Let’s now look at the second factor defining a game, namely: the rules.

The rules in Scrum

When we talk about playing games in the 21st century, we tend to think automatically about video games. However in the broader realm of games, we can easily find examples that do not involve very complex or advanced technologies. Social games like Mafia or Werewolf only require a set of rules that define the number of players, the aim of the game and the kind of actions that should or should not be performed by players.

The same goes for Scrum: You can add fancy instruments such as dedicated software, but in the end all you really need to get started is to know the rules. These fit in a 16-page document not unlike a board game’s how-to-play manual, “The Scrum Guide”.

I will not go into detail here about all the rules of Scrum. I would just like to mention one example that I find quite interesting.

The roles

Roles are well-known indirect control methods; they are often used in games to drive behaviours in a desirable direction. Think of classic role-playing for instance, where we expect certain traits from each character: The archer is fast and vulnerable, the warrior has a big armor and can take a lot of damage, the wizard is powerful and relies on mana potions, etc.

A clear framework restricts our freedom, which forces us to focus our creativity on solving a specific set of problems; that’s how gameplay works. But it is also true in real life. Stepping into a role means that we are willingly limiting the type of action that we will be performing. It also drives us to fulfill the duties attached to what the role represents.

Being assigned a role gives us:

• A sense of agency, because we have control over our area of work (autonomy);
• A specific mission that we should fulfill for the good of the team (purpose).

In Scrum, there are 3 roles: The Product Owner, the Scrum Master and the Development Team.

The way the Scrum roles are labelled does not only give a clear idea of their functions, it also acts like a self-fulfilling prophecy, empowering team members to rise to the challenge.

For the two roles that must be played by individuals, the titles clearly indicate the extent of their power (‘owner’ / ‘master’) and where they should direct their efforts (the product vision / the application of the method).

The third role, “Development Team”, is played by several people whose individual titles are intentionally left undefined. It is up to the group to self-organize and decide how they should fulfill their purpose: To deliver whatever product the whole Scrum Team has set to create.

Spaces of freedom

There are other rules in Scrum that are purposefully left to be defined by every team. This is the case with what is called “the definition of Done” (= when a task can be considered completed).

This space of freedom within the framework makes team members the true owners of the rules and standards that they choose to uphold. A definition of Done is only valid for the Scrum team that collectively agrees on it, which makes it an important moment to align everybody’s visions. It is crucial that these criteria are defined and accepted by the team members themselves, not some external authority.

When teams become experts in Scrum and Agile, they start to interpret other aspects of the framework in their own personal ways.

If you like to play board games, you know that good ones have clear rules, but that players like to bend them when needed.

Once we know what makes a game fun, we can take some liberties with the rules.

Much like when I was playing Monopoly with my family as a kid, we would sometimes bend the rules when they were getting in the way of shared enjoyment. For instance the owner of a hotel on the infamous Champs Elysées or Rue de la Paix (the most expensive squares on the French board) would give a free passage to a loosing player; this would give the laggard a chance to recover on the next turn, so that we could all continue to play and enjoy the game.

Teams that have started to use Scrum will often say that that, although it is easy to understand the rules of the method, it can be hard to implement them. Perfecting the use of Scrum is an interesting challenge in itself. Like all good games, it is easy to learn and hard to master. And trying to apply the rules too strictly can ruin the fun.

In this aspect, the Agile Manifesto can be a helpful guidance to uphold the spirit of the game. One has to keep in mind that the Agile philosophy behind Scrum is even more important than the rules themselves. If a process or tool comes in the way of individuals and interactions, then it is an issue that should be addressed.

This is why teams that are mature in the use of Scrum will usually make their own rules, choose to remove some instruments or to add others, or mix it with other methods. However, it requires time and practice to know which elements can be safely removed, and which ones are essential to the experience.

In the upcoming post we will look at the essential function of feedback loops, both in games and in Scrum. Click here for part 3 or follow me on Twitter for the latest news!