Building Better Teams, One Rabbit at a Time

When a simple game can save you months of work.

Original artwork from Magic Rabbit by Fun Bot, modified with ChatGPT to include team roles and background iteration loop.

As a team leader and Scrum Master, I’m always looking for tools to help teams grow faster and better. Sometimes, a game is the fastest path there. Games are unique: they throw people into action, reveal dynamics instantly, and, best of all, you can’t fake your personality when you play.

When I discovered Magic Rabbit, I immediately thought: this is a perfect metaphor for how teams work, or fail to. The rules are dead simple. The game lasts less than three minutes, requires cooperation, logic, and reveals far more about team habits than hours of meetings ever could.

It’s perfect for newly formed teams to explore collaboration, for established teams to reflect on their dynamics, and for everyone to spot (bad) habits in interactions. And with a few tweaks, it’s also a playground for teaching key Agile principles.

The Rules of the Game

There are 9 hats and 9 rabbits. The hat numbers are visible, but the rabbit numbers are hidden. Players must sort both the rabbits and the hats in ascending order.

Magic Rabbit game instructions

Some doves are placed on top of certain piles, blocking them. Doves can only be moved at the end of a player’s turn.

Full instructions can be found here.

How to Use It to Understand Team Dynamics

There are many ways to use this game. Here are a few ideas.

Note: the official game limits the number of players to 4, but you can still try it with larger teams. It will be harder, but since the goal is to create the right conditions for discussion, that’s perfectly fine.

First, explain the rules to the team. Tell them they can speak while you shuffle and prepare the cards, but once the cards are laid out and the timer starts, speaking is no longer allowed. They will play three runs, followed by a debrief.

Start the first game. Most teams will stay silent and get ready, that’s fine. If your team starts discussing strategy already, you’re lucky! Listen to their discussion and perhaps shuffle a bit longer to give them time to align.

In most cases, the first game will be a flop, and the team won’t finish in time.

Shuffle again and observe. Are they blaming each other? Are they trying to set a strategy? Are they staying silent? Let the natural dynamics unfold, do not interfere. Like before, slow down the preparation slightly to give them time to think and discuss.

Then let them play the second game. In many cases, this will be either a near miss or a near success.

Shuffle for the last time. They should start to discuss now. If not, it might be time to coach them a bit and encourage them to discuss strategies. If they succeed in the previous run, ask what changed between the two runs, if they failed, ask why and what can be changed, did they put a strategy in place?. Give them a minute or two to align.

Ideally, the last run is a success. You can also play with the dove, add or remove them to adjust the complexity.

After the Last Run: Time to Debrief

Sample questions to ask:

• Did they discuss a strategy, or did each member find a solution on their own?
• Did they start blaming or fighting during the game?
• Did they share their strategies, or did one player dominate?
• Did they work well together to solve the puzzle?

Paradoxically, the most important time isn’t the game itself, but the discussions between rounds, and the debrief, this is where team dynamics start to reveal themselves.

In less than 10 minutes, you’ll already see shifts in team behavior. You can begin questioning the roles that emerge within the group.

In less than 10 minutes, your team probably went through the Forming, Storming, and Norming phases, each iteration helping them progress.

In less than 10 minutes, the team learned to trust others, care about the final goal, feel accountable for the result (or not — that one’s tricky), and maybe even experienced a bit of conflict.

In less than 10 minutes, they discovered the power of iteration, adaptation, and self-organization.

In less than 10 minutes, you’ve illustrated Agility, Tuckman’s stages of team development, and tackled most of Lencioni’s five dysfunctions of a team.

What happened when we tried the first time?

The first time I played Magic Rabbit with my team, things got interesting really fast. They managed to finish just in time on the second run, but what surprised me was that no one talked between games. So I asked them: “What was your strategy?”

That’s when the fun began. Turns out, everyone had been following their own plan all along! They started debating whose strategy was better, argued for a while, and eventually picked one to stick with.

Then came the third run… and it was a total mess. People tried to follow the new, shared strategy, but it wasn’t theirs, they got confused, made mistakes, and the whole thing fell apart. Frustration levels went through the roof.

We decided to give it one more go. This time, they agreed: everyone would stick to the approach they felt most comfortable with, as long as it didn’t mess up the others’ moves. And guess what? The fourth run was done in under two minutes.

That led to a great conversation about work habits, when it makes sense to adapt to the team, and when it’s okay to stick with your own way of doing things. It’s all about balance: sometimes you prioritize teamwork, sometimes personal efficiency. Either way, that round taught us more than a dozen meetings ever could.

Tweaking the Game to Deliver Specific Messages

Now that your team has mastered the basic game, let’s tweak it to convey specific messages. Here are three ideas, I’m sure you’ll come up with more…

1. Highlighting the Problem with Specialization

In many teams, members have specialized roles: front-end developers, back-end developers, QA, designers, etc. Let’s replicate that:

• The Rabbit Master can peek at rabbits and move columns.
• The Hat Owner can switch hats.
• The Dove Expert can move doves.

You can either force players to play in sequence or let them choose the order. Switching orders is more efficient but can get messy, so both options are worth exploring.

With more than 3 players, duplicate roles (e.g., two rabbit masters) or let the team self-organize.

Play at least two runs with specialisation and then one round with the regular rules. Debrief and compare the outputs.

• Discuss about the importance of communication when you have specialized team
• Discuss about blockers and idle time.

2. Demonstrating the Cost of Context Switching

This version shows the cost of multitasking and the importance of focus. You’ll need two copies of Magic Rabbit (I swear I don’t get commissions).

Remove the doves to simplify.

Tell the team they have two hourglasses’ worth of time to finish both games. Play three runs:

• First run: Start one game. When you say “switch,” they must switch to the other game — surprise them! Vary the interval unpredictably.
• Second run: Switch games at a fixed interval, say every 2–3 turns.
• Third run: Only switch to the second game once the first is completed.

Debrief and discuss the cost of context switching.

If you only have one copy of the game, replace the switch with another task that requires cognitive effort, like counting backward from 50 or spelling their last name backward.

3. Comparing Waterfall and Agile

Play two versions:

• Waterfall version: Players must peek at all cards first, then move columns, then switch hats. No doves. They can speak while peeking but not afterward.
• Agile version: Play with standard rules, with or without doves, but this time players must stay silent.

Debrief afterward:

• Which version was easier?
• How did sequential vs. iterative approaches impact progress?
• Discuss how Waterfall’s sequential steps compare to Agile’s constant feedback loops.
• Discuss about the handling of errors, of unplanned work.

If your team completes all versions successfully, that’s also a great discussion starter: in some projects, both approaches can work, depending on the team’s context.

Additional Tweaks

• If your team is sensitive to failure, replace the hourglass with a regular timer to reduce stress. This may reduce the learning impact but provides a safer space.
• Allow the team to speak briefly after each full round of turns but silence resumes when anyone touches a card. This simulates daily stand-ups.
• Add challenges from the game’s envelopes. The “forbidden to repeat the previous player’s action” rule is a fun twist. You can also remove a rabbit to simplify the challenge.

Conclusion

In under 10 minutes, your team has experimented with iteration, faced their (dis)comfort with conflict, adapted, and self-organized. Without slides, lectures, or fancy frameworks, they’ve lived the experience of Tuckman’s team stages and touched on the five dysfunctions of a team.

Magic Rabbit is no silver bullet, but its simplicity is its strength. It’s fast, logical, and just chaotic enough to surface the underlying patterns that make or break team collaboration.

Whether you’re leading developers, designers, or cross-functional squads, games like this create a safe, insightful space for growth.

And that’s what we’re here for, right?

I hope you had as much fun reading this article as I had writing it.

Note: This article is part of a 3-part series on Magic Rabbit:

[embed]Pair Programming with AI: What I Learned Coding Magic Rabbit from Scratch A practical guide to using AI-assisted coding and game logic to improve programming, teamwork, and debugging skills.medium.com

[embed]Cycles, Swaps, and Doves: The Hidden Math of Magic Rabbit A deep dive into the logic, probability, and strategy behind Magic Rabbitmedium.com

[embed]Building Better Teams, One Game at a Time When a simple game can save you months of work.medium.com