Agile Zone is brought to you in partnership with:

I am an organizational development coach and trainer, with a background in software development, graphic design, theatre arts, and team/groupwork facilitation. Inspired by (among others) Paulo Friere, Peter Block and Jesus of Nazareth, I have a keen mind, an anarchic edge and a passion for corporate enlightenment. Tobias has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

The Agile Playground #1

02.26.2013
| 2076 views |
  • submit to reddit
Agile Playground Index: [AP#1] [AP#2] [AP#3]

This is the first post in an intended series which will describe some interactive games, with commentary.

Scrum offers a completely different way of thinking about the work we do, therefore it seems appropriate that we explore completely different ways of teaching it to people. Playing physical, interactive games is a compelling way of introducing the core Scrum principles to individuals and organizations.  When talking to (sometimes at) participants with or without slides or whiteboards the information is one-dimensional, and tends to be taken in at a head level.  Playing interactive, physical games provides a richer experience and allows knowledge to be embodied by the participants.

Head knowledge tends to coat the surface of our minds, and it quickly fades, whereas embodied knowledge penetrates deeper and tends to stick.  The games and exercises described in the Agile Playground posts are all physical and interactive, and lend themselves to an increased awareness of Agile principals. The set of games described here are as a rough guide only, an introduction to the concept of game-playing for Agile learning purposes.  It is advisable to experiment with these games in a safe, supportive environment such as Open Space before applying them for training purposes.  It is necessary to understand the games for yourself, to appreciate the learning value, to really feel them, before offering them to others.

I see Agile games falling into two categories: 1) prescriptive games where the outcome is known by the facilitator and the game is guided towards that outcome, or 2) open games where the outcome is often unknown and the game takes on a life of its own, with participants drawing out meaning themselves.  It is the latter set of games that I am more interested in.

Go — a game for illustrating the Agile mindset
aka “Your Brain on Scrum”

Instructions Have your participants stand in a circle, evenly spaced.  Introduce the game like this: I shall point at someone; when I point the person will tell me to go, so I’ll walk over to take his space.  In order to take the space the person has to leave it, and the only way to leave your space is to point at someone else. When you point the new person will tell you to go, so you’ll walk over to take his space. And so on.  This will be a continuous exercise with no obvious end point. The game will find its own conclusion.

What Happens? At first the participants will really struggle with this.  They point and say Go , or when being pointed at they leave their space without saying Go, before realizing there is no new place to go to.  It is necessary to stop the game and restate the rules a couple of time. Other behaviors that occur include moving quickly and getting to your new place before the person who said Go has left it, and failure to pay attention thus not being aware when someone point at you.  After two or three stops, and a clarification of the requirements, the game is played smoothly and you can start to build up speed.

Additional Notes 1 I added these notes after witnessing the game being played and somewhat  misunderstood.  This is NOT altogether an open game, there is a very deliberate learning outcome… the recognition that Scrum is simple, but it is not easy.  I learned this game from Improv artist/actor Matt Smith.  Matt uses it to show the mindset shift needed to embrace improv ideas. Scrum requires a similar mindset shift (a paradigm shift if you like).  Go! illustrates the pain that comes with this shift.  It is difficult, but it can be overcome.  We need to re-train our minds to think differently about what we do. Ask people early on in this game why they are screwing up a game that has only (essentially) 3 rules.  What is going on… why is it so hard?  Help participants understand that the difficulties arise when they have to change ingrained patterns.  Scrum is simple, but it isn’t easy.

Variations After running the standard game for a while, try out some alternatives.  Replace the pointing gesture with one of an open hand.  This feels like more of a request than a command. Have no gesture, just use eye contact to give permission.  Play without permission at all, just walk to where you want to go and trust that the space will become available. 

Additional Notes 2 Go! can develop into a game about flow, patterns, respect, listening, team-awareness and all kinds of other good things.  But beware.  Mixing up many learning outcomes in one game can be confusing.  I recommend using Go! in its simplest form to illustrate the mind shift required to do Scrum.  Pick the game up again later in the session, (using looks, head-nods, etc.) to focus on the patterns/flow part of teamwork.  Or use a different game.

Debrief Explain that the Agile mindset is utterly different to a traditional mindset, and ask how the game gets that message across.  The participants have a lot to say, so listen and learn.  Some of the discussion centers around the importance of team work, and being aware of the needs of others .  Other times it will focus more on the difficulty of changing the way we typically do things.  If you have used and variations have the participants discuss the different dynamics.

Additional Notes 3 Having written this game, and then seen it played reminds me how hard it is to write these games down, for reproduction.  There is a great deal of skill required to run a game successfully, to notice the learning opportunities and seize them appropriately, without being overly prescriptive.  So again, please use these games with great care — and be prepared to acknowledge your own failure, and improve as a result.

Published at DZone with permission of its author, Tobias Mayer. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)