In the past few years I had the opportunity to explore various uses and dimensions of Scrum. On projects working with Scrum and the Agile philosophy, I always felt more energized, accomplished and enthusiastic. The atmosphere in my team was better, we were more productive, engaged, and overall we experienced much less stress. To put it simply: Working on projects with Scrum was fun. I started to ask myself why it was so much better to run a project with Scrum than without.

Working in the games industry, and witnessing the incredible power of a good game to engage players, this got me wondering:

What if Scrum was so engaging… because it works like a game?

Behavioural science and game design can help us understand some of the key aspects that make it so much more engaging. In her reference book Reality is Broken, Game Designer and Researcher Jane McGonigal identifies 4 characteristics that all games have in common^[1]:

“When you strip away the genre differences and the technological complexities, all games share four defining traits: a goal, rules, a feedback system, and voluntary participation.”

Let’s draw a parallel and see how these 4 criteria could apply to the Scrum framework.

Part 1: The Goal

There are different levels of goals in Scrum. There is the ultimate goal, which is the delivery of the final product. This is not specific to Scrum and also exists in “traditional” project management methods and organisations.

As a project manager or participant in projects with massive plannings and detailed Gantt charts, one thing that I always found frustrating is that the goal often seemed so far away that it was hard to relate to it. Milestones seemed like gigantic mountains that we had to climb in unsettled weather, unsure of what we would find once we reached the summit – which oddly seemed to move further away every time we thought we were coming nearer.

Goals in Scrum

A second type of goal is what we can call “intermediary goals”. These are quite different from traditional project milestones, in the sense that intermediary goals represent one full loop of planning, execution and delivery.

Scrum has a great way to bring the goal closer: Sprints. Sprints are predefined time-periods in which the team commits to reaching a certain number of achievable objectives. At inaloop games, a startup that I cofounded, we settled for Sprints of 2 weeks, which gave enough time to reach 3 prioritized objectives and see significant results.

Each Sprint is like one game, where the goal of is to make the most accurate prediction of how many velocity points we will achieve. The trick is to predict an ambitious number of points, so that we beat our previous score, but not too ambitious either, because we want to be able to reach it.

Scrum changes the goal from “delivering this massive project” to “making the most accurate prediction of how much we can deliver in a limited time-period.”

To make a sports metaphor, we could say that Sprints are like individual football (soccer) games, and that the ultimate goal is similar to reaching the top of the league. At the end of each game, the team has a clear idea of their performance and how they are progressing in the league.

Removing Sprints would be like removing the football match instances and turning them into one single match that you would play for months.

As a professional football player, you would get up every day and resume the game with your team, trying to add points to your score; but you would still be months away from the end of the season. After a while you and your team would take a moment to look at your score, you would see that you reached 274 and everyone would be disappointed because you somehow assumed that you would be closer to your target of 1000.

So you would listen to a motivational speech from your coach, and for a moment you would feel energized to do better. Then you would get up on the next morning, committed to running faster and to scoring more points. You don’t want to let your team down in this long, boring and exhausting football match…

This doesn’t sounds as fun, does it?  Quite simply, if a goal is too vague or seems out of reach, it’s not motivating.

Game Designers, who are masters in methods of indirect control^[2]:, know the virtue of this principle:

If the goal of the game is clear and achievable, players will try and reach it in the most efficient way possible.

A principle that the inventor of the good old SMART acronym surely wouldn’t disavow.

To conclude on goals…

Besides her own criteria, McGonigal quotes another definition of “game” formulated by philosopher Bernard Suits: “Playing a game is the voluntary attempt to overcome unnecessary obstacles”.

In the example of Scrum Sprints, we can see how adding a goal that may seem superfluous or useless – “make the most accurate prediction possible of our collective productivity in a specific time-period” – is what actually makes the experience compelling. Overcoming the obstacle becomes an exciting challenge to take on; and once we have reached it, we feel empowered to take on more ambitious challenges in the next Sprint.

This is linked closely to the motivational aspect of achievements, which we will explore later in the section on feedback systems. But first we will look at the rules of Scrum, so head here for part 2!

You can follow me on Twitter to read the latest news about this blog.

—-

Notes:
1. ^ Jane McGonigal (2011), Reality is broken, The Penguin Press, p. 21
2. ^ See Jesse Schell (2008), The Art of Game Design, MK publishers, p. 283 ff