Feedback is a decisive aspect of human interactions. Be it in education, games, management, design or in interpersonal relationships, the way we communicate to people if they have met our expectations can have a strong impact on their future behaviours. Well-designed feedback loops are thus crucial for crafted experiences, and one of the  main reasons behind the success of Scrum as a method. 

After looking at the goal (part 1) and at the rules (part 2), we are continuing the exploration of the fun in Scrum with the third trait defining a game: The feedback system. 

What makes a good feedback system?

We could list a number of things that characterize solid feedback systems; for the sake of clarity we will group them into 3 main principles.

A system should be designed so that feedback is:

1. Rich – each action triggers a direct response and, whenever possible, an abundance of responses;
2. Unambiguous – we are able to easily interpret if the feedback is positive or negative;
3. Instructive – it helps us see the consequences of our actions and shows us how to improve.

Rich feedback

Last time you stepped in an elevator and pressed a button, you probably expected a light to turn on, or a floor number to be displayed. Haven you ever taken an elevator that displayed no light or floor indication when you pressed a button?  This happened to me recently, and I can tell you that I was immediately annoyed. So I did what many modern humans, bottle-fed with rich feedback, would have done: I started pressing the button frantically until the doors of the elevator begun to close.

You can find similar cases everywhere, as it is now good practice, in all fields of design, to indicate in one way or another that the action of a user has been acknowledged. And one condition for these acknowledgements to be effective is their reactivity.

Feedback needs to happen as close as possible to the action performed, otherwise it will create frustration.

In video-games as well, Designers need to make sure that the game reacts immediately to the player’s action, lest it becomes quickly annoying… like a broken elevator button. Jesse Shell gives a rule of thumb for it: “If your interface does not respond to player input within a tenth of a second, the player is going to feel like something is wrong with the interface”^[1].

Take a game like Mario Kart – if you are not familiar with it, you can view an example here. Like all Nintendo games, it is very reactive and the little kart responds promptly to any action that you perform.

Observe also the density of sounds, explosions, shakes, bumps, funny character faces, flames, coins, stars, etc. Even if you are really bad at racing, the sheer quantity of in-game interactions makes this game an exciting experience.

Next to the immediate feedback, you also have regular reminders of the bigger picture: remaining laps, position of competitors, items in your possession. And at the end of each race, a leaderboard indicates your progression in the overall ranking.

When it comes to feedback, quantity does matter.

Looking at Scrum, we can see that it includes a lot more feedback loops than traditional project-management methods. Short, medium and long feedback loops are interweaving, which logically increases the frequency of  feedback.

Like in a game system, Scrum takes the smallest level of significant action performed by the team (= a task) and makes sure that each of these actions triggers a systematic feedback.

Tracking tasks in loops of various lengths makes it possible to visualize the consequences of our actions more easily:

• The movement of tasks across the board, from To-do, through Doing, to Done, happens several times a day.
• Then comes the daily count of the team’s velocity, with the stand-up meeting and the update of the burndown chart.
• A the end of each Sprint, the Demo and Retrospective meetings close the longer loop that gives feedback on the intermediary goals.
• Finally, the comparative overview of all previous Sprints allows the team to constantly reassess their ability to reach the ultimate goal.

Compare these loops with the situation in many organisations, where the only moment to formally assess if an employee’s performance is on the right track is during the yearly performance review. Of course, a good manager will give informal feedback regularly; but there is just one feedback loop that is formally included in the system, and it closes once a year!

Unambiguous feedback

Not only does feedback need to be given frequently, it should also be easy to interpret.

To start from a simple example, let’s take an early-learning game like the shape-sorting toys for toddlers. Because the focus is on the development of the kid’s problem-solving and motor skills, and because their cognitive abilities are limited, the toy should tell them in a direct and straightforward way if they are doing it right. Shape-sorting works very well for this, as it is easy for the kid to see if they placed the shape in the right hole. The toy is the feedback.

It is also a great tool for parents and educators, who can spot the level of mastery of the child, and support them with encouragements or reinforce the kid’s achievements with “yays” and claps.

The same goes for feedback in general: It needs first to be simple and clear. We consider it “unambiguous” when we are able to intuitively place it at some point of a bipolar spectrum (good/bad, fast/slow, etc.).

A well-designed feedback system manages to track the progression towards a goal, while also giving an evaluation of the actions performed.

This is why the board is so important in Scrum, as well as in other Agile methods.

Moving a card to “Done” is a satisfying moment, acknowledging the good work that has been accomplished: It acts as a form of positive reinforcement. By moving the tasks across the board, the Scrum team is also able to visualize if its efforts are bearing fruits: It is a practical progression-tracking device.

Instructive feedback

On the other hand, once we become aware that we are making mistakes or acting in suboptimal ways, we are able to learn from it.

When tied to a specific frame of reference, feedback helps us situate ourselves and  gives us pointers on how to improve.

If you move to a new city for instance, it will take you some time to be able to build a frame of reference in your brain that will allow you to find your way instinctively. When you want to learn to locate your position in different places, you will usually proceed through trials and errors. You will go somewhere, try to picture in your mind where you are, and then compare your guess with real-time feedback — either by checking on a map or by asking a passer-by.

This is also true for abstract frameworks, where we want to situate ourselves in relation to pre-established standards and criteria.

In the case of Scrum, burndown charts serve as a useful complement to the task-cards. They allow to visualize any dents in the team’s progression, by judging the progression against a time/velocity matrix.

For instance, in the case of the chart below, we can immediately see that there was an issue on Day 7.

In this example, we can see that the team temporarily failed at the ‘game’ – remember that the goal was to “make the most accurate prediction of how much we can deliver in a limited time-period”. However this failure is not dramatic. Like in a game, failing in Scrum is not depressing, because it is just a learning opportunity.

Like the good old Mario Bros platformers, Scrum is based on experiential learning; the method always makes sure that there is an opportunity to address negative feedback. If an impediment arose, it will be mentioned in the following stand-up meeting. And if this is related to a bigger issue, it will be addressed during the Retrospective at the end of the Sprint.

With the ability to detect discrepancies as soon as they arise (rich feedback) and to identify quickly that something went wrong (unambiguous feedback), Scrum takes the pressure off, so that the team can focus on learning. Risk-free learning is something that our brains loves to do. Or, as Raph Koster famously wrote^[2]:

“Fun is just another word for learning.”

I would like to conclude this post on the importance of celebrating successes. Positive feedback, especially when based on data that is clearly related to the goal and the rules, plays a big role in reinforcing the belief in our chances of success. Each intermediary goal that we reach makes us more confident in our skills as individuals and also as a team, reinforcing our sense of mastery.

In our next step of this exploration of Scrum, we will tackle the tricky topic of voluntary participation. Head here for the fourth and last part!

—–

Notes:
1. ^ Jesse Schell (2008), The Art of Game Design, MK publishers, p. 231
2. ^ Raph Koster (2005), A Theory of Fun for Game Design, Paraglyph Press, p. 46