Games for what?

I reckon on the subject of games I am at the border of the agile community: agile games are very spread among my colleague coaches, more than what I use them, and, from a purely informal and statistically not relevant poll I made, it seems that many agile coaches…

• run games with their teams on a regular basis
• schedule games sometimes even every day at a fixed time
• take inspiration from several games books
• design their own games

but also

• don’t know why games “work”, i.e. why and how the team afterwards is “better” than before
• don’t know how to choose a game

The interesting point is that there seems to be no correlation between the quality of the coach and the fact that he/she uses games, so… what’s going on here? Here’s my take:

1. There’s game and game (and reality)

Just because there are plenty of games available, it doesn’t mean they are all equally suited for agile teams. And just because the coach likes them, it doesn’t mean they are suited either. I would classify agile games based on the mix of characteristics they have in four dimensions:

1. Do they have a procedural learning? Do they explain through metaphors or through analogy a certain process? Example: the ball point game explains how the team could improve by reflecting after each iteration. In this case the team is [typically, but not always] transferred to the “safe environment” of the game, where each individual can learn, in a simplified way, how to handle a certain situation. Depending on the game, the learning might be at the conceptual, process and procedural level or a certain mix of these.
2. Do they have a social learning? Teamwork is governed by so much more than just processes. Through games it is possible to explore and learn how to interact in new ways. Many of the games available in the team and business coaching area are focused on these aspects.
3. Are they motivational? Some games are intended to promote motivation and teamwork by trying to create a more friendly environment to work in. The difference between this dimension and the previous one is that here there is no skill learning but just more positive social interaction and emotional contagion.
4. Are they simply just for fun? Some games are just there as a break and variation in the daily business.

While all games might have a place, what is your goal when choosing one? I have to admit I am more inclined to use games with a strong focus on dimensions 1. and 2., but this says more about my attitude than being a truth.

2. Choosing a game is more than just gut feeling

Once we are aware that games have a various mix of characteristics, we have to face the problem of how to choose them. “Because it worked with another team” is no answer for me: it might still work with a different team, there are good reasons for it, and in most of the cases it will. But it might also not work!
Here is my way of deciding what to play:

1. What do I want to teach the team through a game? What is my learning objective? How is the game supporting this objective?
2. How should I frame the game in my explanation so the team can relate it to their reality? (pre-teaching)
3. How will I organise the de-briefing of the game to integrate the learning in the daily business?
4. Is the game organised in such a way to allow at least a partial team success and, anyway, a progressively increasing level of complexity, so the learning can proceed in small and frequent steps?
5. When is the right time and place to do it? I mean this in two ways:
   • Is it relevant for what the team is currently doing? If the learning promoted by the game is not aligned with what the team currently needs, most of the learning will not be retained for when it’s really needed.
   • Can the team afford to invest the time? Sometimes the team has other priorities and pressures from the organisation. Typical one is to work to reach the iteration’s goals. In this case I often let them work instead, as whatever learning they might get could be shadowed by the additional pressure as they need to catch up with the time invested for the game. This is typically a chicken and egg problem and while I’m all in favour of investing time to have the chicken somewhere in the future, sometimes a shorter term investment might be a better choice from a tactical point of view to avoid additional stress and strain on the team.
6. Does it have the right duration? I prefer short games, but too short games that are not brilliantly planned and executed might not achieve the right effect. Too long games might become boring, causing the team to disengage.
7. Is it compatible with the values and conceptualisations of the organisation? In some companies games are culturally not really allowed. Though there might be no explicit rule, in a lot of command-and-control organisations games are simply “not serious”. This is obviously based on the presupposition that in the workplace there is no such a thing as fun. While agilists know that fun is an important motivational aspect, going full steam against this mindset will cause useless resistance. (hint: introduce games slowly and progressively and take particular care in making them relevant for the team linking them to the daily business in the de-briefing!)

3. Running a game is more than just playing

I mentioned before the initial framing and the de-briefing of the game. Especially for games having a procedural or a social learning it is important to frame them properly:

• What is the game? A short description…
• What is the intention of the game? What will the team learn through it?
• What is the context where this learning is useful?
• [rules of the game here…]

Afterwards it is important to reflect on the game and integrate the learning in the daily life. I like to lead that through questions:

• What was good? bad?
• What was new? old? surprising?
• What parallels did you find with your reality?
• What do you/can you import into your reality?

4. And then there are other options as well

But… wait! I said I am not playing as many games with the teams I coach compared to my colleagues. So what am I doing instead?

Well, a lot of things, in fact. Actually I typically check whether it is possible to achieve the same learning in a different way before playing a game. Playing a game involves changing context, playing the game and coming back to reality to integrate the learning. If the system allows it, I rather prefer to skip the two context switches and act directly in the reality of the team.