Games, like the ones described on TastyCupcakes.org, provide the opportunity for agile teams to quickly build on a shared experience, realize better ways of working and most importantly, to have fun!
Let’s Play a Game
Grab a pencil and paper, and draw a picture that you feel best depicts ‘trust’.
We’ll wait…
Got it yet? No? Ok, take your time.
How about now?
What did you come up with? Someone falling backward while others safely catch them? A handshake? A child holding their parent’s hand?
Whatever you drew, we are willing to bet that it was a depiction of some experience that you have had or witnessed that involved interaction with others. Trust is not something you learn from a book, or an article, or on YouTube. It must be experienced.
The Problem with Principles
Communicating and conveying something as complex as a principle or value is hard. This is just as true outside the world of software development. It is obvious that we all value principles such as trust, integrity, or loyalty. The challenge is when you try to implement trust amongst a group of people working together. The reality is that these are team and cultural norms that are expressed in behavioral examples of human interaction. These examples become our expectations of others and signify the person’s demonstration of the value, implicitly and explicitly.
Agile is about principles and values
There is not a single mention of process mechanics in the agile manifesto. The first statement in the manifesto is that we value people and interactions more than process and tools. This statement points directly at the hardest aspects of project leadership and management; the dynamics and complexity of human interaction on a software project.
Often, software development teams and organizations gravitate first to a methodology or practice assuming that by repetition of the mechanics, they too will be successful. Adopting agile is about changing a value system and this is really about changing people.
Changing People requires Self-Discovery
Reading the manifesto and listening to long-winded discussions about why agile is the answer will probably not go far in changing people. To really understand and internalize a concept people need to value it and the surest way to accomplish this is through self-discovery.
Self-discovery occurs when your audience reaches the conclusion for themselves, that agile is a better way of working. This is the most efficient and effective way to change beliefs and behaviors. Games create the experience for the group and set the context for reflection, dialogue, and self-discovery.
A Game Plan
As professional agile coaches and trainers we apply these games regularly. These games however are not just for the classroom or agile coaches. We have observed real teams leverage games throughout their agile adoption endeavors to communicate specific values while providing common team experiences. We understand that every organization and every team is different, and at TastyCupcakes.org, there is a comprehensive toolkit of games that touch on all facets of agile.
Below, however, we have outlined a series of games, a game plan if you will, to demonstrate how they may be applied to common situations that are observed in software development every day. This is not a roadmap for agile adoption, just some games that you might apply along the way.
Introducing Agile to Management, PMO, and Sponsors
Early on in a project, you may find yourself in a position where you need to justify to senior managers and sponsors that the team will be working in a different way. The implication for these stakeholders typically involves changing the way we report progress as well as budget and schedule forecasting.
We may also want to communicate the important point that software is not a predictable and linear activity like painting walls. It is, in fact, an empirical process with some degree of invention and reliance on speculation, experimentation and adaptation.
A game we often use to illustrate this concept is What Were They Thinking?. This game contrasts the difficulty in predictably describing something that is known, like a chair or a bicycle, versus a one-off, one of a kind product where no one word sufficiently describes it. This game can be run in 5 minutes and is often a good choice for senior managers who may not have the time to spend an hour engaged in a game.
If you do have more time, another popular game is Mr. Happy Face. This game is an excellent vehicle for explaining Kanban and Lean Pull mechanisms. It also can be used to illustrate the challenge and damage that can be caused with trying to be predictive about something you have no control over like the market or invention. By associating a cost with each ‘happy face’ produced, this game is a great illustration of the expense of waste and the importance of understanding the return on investment and cash flow.
Conveying Agile Values and Principles to The Team
When first starting a conversation about agile with the team the Manifesto is a common starting point. We typically will introduce it one of two ways.
The first is to have the team create their own manifesto. This is the basis of a powerful self-discovery game, Presto Manifesto. Before any discussion of agile, ask the team to draw from their experiences and develop a list of success factors for software projects. Interestingly enough, their lists always turn out a lot like the agile manifesto.
Another excellent game is Example Please!. This exercise starts by reviewing the Manifesto values and principles and asking participants to come up with examples of what it will mean for them and their interactions with the rest of the team. In addition to helping communicate the values and principles of agile, this game also begins to establish a new set of norms for the team.
Managing a Sprint or Iteration
A challenge with trying to communicate the value of Scrum and other agile implementations is that until people have tried it once or twice, it is nearly impossible to convey the rhythm and flow that is experienced from a well-run a sprint. Resort Brochure is a game that applies the core Scrum rules in a series of micro-sprints. Teams are given 6-minute sprints composed of 2-minute days to plan, organize, and implement a brochure. Along the way, teams build a backlog, plan for a sprint, create a Scrum board, sync up daily, learn from retrospectives, and demo their creation.
Estimation
One of the big changes with agile software development is the way planning and estimation is managed. Concepts such as wisdom of crowds, nebulous units of time (NUTs), planning poker, velocity, and burn-down/up charts may be appear very different to those used to Gantt charts, earned value, ideal time, and actuals. Games are very efficient in conveying these agile planning and estimating techniques since participants can apply them and recognize their value right way.
Doggy Planning is a quick game to get people used to planning poker cards and relative estimating. Participants are asked to agree on a point value for the smallest dog – a Chihuahua and then relatively assign points to all subsequent dogs by voting. Each dog has it’s own learning point.
People Polling is a powerful way to convey the wisdom of crowds by having each individual quickly and privately write down an estimate of something in the room (words on a page, ceiling tiles, your weight, etc.).
Gather all of the estimates and calculate the average. Then cross your fingers and unveil the actual number. The group average should be close to the actual and often closer than the closest individual estimate.
User Stories and Acceptance Criteria
Writing user stories is pretty simple so a simple analogy exercise typically works. One we often use is a doggy play-date service. Have your team dream up personas and stories for the service.
The problem for many people new to User Stories is in believing that simply writing terse statements on index cards is all the requirements needed. Many teams lose sight of the fact that stories are ‘markers’ for higher level requirements and that further conversation will be required. Details come out in these future conversations. Many of these details are captured as ‘acceptance criteria’ that define when a user story is done.
An excellent game to illustrate these concepts is 99 Test Balloons. Groups are asked to produce a balloon with a face on it but are surprised when their balloons are rejected because the faces were not exactly what the customer wanted. After drawing some correlations between the experience and software development, teams are given a few more iterations to improve on the requirement by identifying acceptance criteria.
Creating You Own Game
Games and simulations can be as fun to create, as they are to play, particularly when they work really well. A few tips for creating your own game;
- Identify the objective of the game. You need to keep focus on why you’re doing the game in the first place.
- KISS. Stick to your objectives and avoid trying to create a comprehensive simulation of software development.
- Remember, the game is only there to set up a conversation with the team about some dimension of agile.
- Borrow ideas from other games. We love to hear from people who have taken our games and changed them to suit their needs.
- Just do it. It will never be perfect the first time. Get feedback and improve.
- Submit your game to TastyCupcakes.org. Let others try it out and get feedback from them!
Final Thoughts
Games in agile are important:
- They are fun to play. Long lectures and dissertation might be fun for you but it can be a bit of drag if you’re on the receiving end.
- They typically involve some type of physical interaction with the world. People tend to engage more in the experience when their body is already committed. This helps with getting the skeptics to consider your message.
- Games are a powerful technique to achieve self-discovery and establish new norms and values for an agile team.
Don and Mike running 99 Test Balloons
About Author
Don McGreal is an active member of the software development community since 1995, Don is a popular speaker, agile consultant and trainer. As a consultant and Certified Scrum Practitioner, Don has fulfilled many roles while ensuring that the clients get the most from each engagement: developer, architect, business analyst, process coach, and mentor.
