Cynefin Lego Game

A game to let you experience four of the five domains of Dave Snowden’s Cynefin framework

25 December 2011
Training, Lean Management
cynefin, game, leadership, management


The Cynefin Lego Game is part of agile42’s management training for the Agile Management Framework. 

It is licensed under the Creative Commons Attribution-Share Alike 3.0 Germany License.

What It Is

A game to let you experience four of the five domains of Dave Snowden’s Cynefin framework.

Cynefin Framework

Using Lego, you go through four exercises where the problem to solve and the context you work in is designed to create a simple, complicated, complex and chaotic system. While it does not introduce you to the full potential of the sense-making framework, it is well suited to get a first impression and raise interest in learning more about it! Although Cynefin is at the heart of this excercise, the debriefing focuses on outcome that is not necessarily part of the model.

Why You’d Use It

When leading or managing agile transitions, it is important to know what type of system you are dealing with. Playing this game shows you how to decode what is happening in terms of organisational structures and communication in that specific system. Once you are able to do this, you can appreciate the consistency of your communication style with the related system, as well as choose more appropriate tools to set direction and coach.

Cynefin Drawing


The game shouldn’t take more than 60 minutes.

Material and Environment

Tables for groups of three/four, about 200 bricks of Lego in 6-10 colours in different sizes with about 10% special bricks (flowers, wheels, ...) per table.


Draw the diagram above on a flip chart. Only draw the lines in the middle, you will fill the diagram on the way (people should experience the four domains before conceptualising them with you). 

You play one exercise for each of the domains, as described below. For each exercise:

  • Explain the rules until there are no questions
  • Start the exercise on all tables
  • Track the time (but do not set a timebox)
  • Capture smallest and largest time-to-completion 
  • When all teams are finished, give them 2 min for in-team reflection
  • Share the findings, use debriefing questions.
  • Draw the details for this domain on the flip chart and connect to the teams’ findings.
  • Draw the communication structure and decision making structure observed during this exercise.

Exercise 1: Simple

The Challenge

“Sort the bricks into colours, as quickly as possible. Create one heap for all special pieces. Decide in your team which pieces you want to treat as special.”

Simple Sorting


  • How much time did you need for planning?
  • How was the communication? How many leaders/followers were in your team?
  • You will notice that common Best Practices arise from different groups
  • Analyse the communication structure and the way people took decision and agree on what to do, you should notice the Top-Down Communication pattern, where one person proposed “the” way of solving the problem and the others just followed. Not much peer-to-peer communication will be going on during the exercise, at least not about how to do things, but more operative.

Exercise 2: Complicated

The Challenge

Build a structure, as quickly as possible, according to the following rules:

  • At least 20 bricks high
  • Regular colour pattern
  • Every new block that you add to the structure can’t be bigger than the one below it

Complicated Structure


  • What felt different compared to the simple problem?
  • How much time did you need for planning?
  • How was the communication? How many leaders/followers were in your team?
  • In this case you will notice that possibly every team adopted different practice, producing different results. There is no Best Practice but many Good Practices.
  • Analyse the communication structure and the way people took decision and agree on what to do, you should notice the Expert Communication pattern, where everyone tried to propose a possible solution. Some teams at this point may enter in analysis-paralysis, consider this as an invitation to retrospect on the role of one member facilitating the group.

Exercise 3: Complex

The Challenge

“Decide in 30 seconds to build either an animal or a vehicle. After that you work according to the following rules:

  • As in exercise 2, you need to create a regular colour pattern.
  • Each colour of bricks must only be touched by one person in your team.
  • You are not allowed to talk.
  • Every minute, you need to switch tables, taking your unfinished work with you (but not the material).”


  • What felt different compared to the simple/complicated problem?
  • How was the communication? How many leaders/followers were in your team?
  • What kind of feedback did you have to guide you towards a solution?
  • Would it have made a difference if you had had five minutes to talk and plan before you started building?
  • Here you should notice a clear emergent behaviour, many people end up surprised on how the ban of verbal communication—obviously it is a game—actually keeps them from entering long discussions, while the probing in building something together turned out to spark new ideas and inspiration at every step. Consider comparing the time with the previous exercise, normally it doesn’t differ too much, despite the fact that the challenge is complex.

Exercise 4: Chaotic

The Challenge

“Your task is similar to the last one, but now you need to create a building or a plant. At random times, the facilitator will touch a team member’s shoulder and indicate another table. That person then immediately joins a different team.”

Chaotic—half a house

They are still not allowed to talk. For a lost teammate they might get someone back, but not immediately. (That leads to them thinking they miss a person dealing with a certain colour, which is actually not true, if you read the rule. You do not tell them it is not true).


  • What felt different compared to the complex problem/situation?
  • How was the communication? How many leaders/followers were in your team?
  • How did it feel to loose a team member? How to join another team?
  • Why does this small change make such a big difference?
  • Here you should be able to appreciate that communication was mostly inexistent after a while, that people gave up trying to communicate, they rather start doing and get stopped by others (Act and then Probe). In particular people will feel - as opposed to the previous exercise - completely demotivated and frustrated.


The simple exercise typically gets a quick and easy solution. One player suggests something obvious and the others follow.

The complicated exercise needs a bit of planning, typically everybody suggests something, a quick decision is made and process is adapted according to feedback during the build.

The complex exercise doesn’t get better with more planning. The right process emerges and is continually adapted. The sooner teams start to build, the sooner they feel comfortable. It helps if all team members know what the animal/vehicle they want to build actually looks like.

The chaotic exercise leads to quite surprising, sometimes not very good solutions (see the building without roof in the picture). People feel uncomfortable all the time, the solution takes longer than before. Especially for managers, this is an aha-experience: “So this is how it feels to change a team...”


Cynefin framework:

Dave Snowden’s blog:


Subscribe to new blog posts

Did you find this article valuable? To be promptly noticed of new blog posts by agile42 you can subscribe to our notification system via email.

Discussion 9 Comments

Wow! This looks very cool. Thank you for sharing. I want to try this game out real soon.

Let me know if you would like to post a game reference to

- Michael

For the complex case, isn't there a degenerate solution that demonstrates an anti-pattern? A rule states that each color can only be touched by one member of the team. There doesn't appear to be a limit to how many colors a single team member can control. Therefore, complex becomes simple if during the 30 seconds all team members elect one person to do the whole build. This is, of course, doesn't represent a team effort, other than the effort to get all but one team member to abdicate responsibility.

If you get a team to spot that possibility to game the rules (there are more), then you have an amazing starting point for a discussion around what we perceive as complex, what we assume to be complex and what actually is complex.
You could always add more rules to make the game more "secure", yet we feel that this just adds another bit of uncertainty...
Take care, and have fun playing!
- Olaf

Let me start with ... AWESOME! Thanks for sharing!

I've wanted to understand the Cynefin model better for some time now - just reading the game, and having a little thought experiment in my head has helped me understand the Sensing Framework much better!

Would you clarify the intent of the Exercise 3 Complex rule "Every minute, you need to switch tables, taking your unfinished work with you (but not the material).”

Assume they are building a truck, this means that ever minute (do you time this - you mean every 60 sec - not every little bit of time - correct?) the whole team moves to a different table taking the unfinised truck with them but not the raw building blocks. Upon arriving at the new table they proceed to finish the truck with the raw material (blocks) at the new table.

In Exercise 1 Simple - You had everyone sort by color. I would imagine I would have groups just sort - giving no criteria - in fact encourgaing different sorting criteria by suggesting in the large group that there are many different criteria (color, size, shape, number of brick holes, length ignoring width/hight, etc. This would encourage different sorting criteria, leading to more diverse table orginization - which would lead to more chaotic environment when switching tables.

So this is what I imagine I would have done... but I've never facilitated the game - could you clarify the intent of the rule? Did I misunderstand something.

Hi David,

looks like you are on spot with the interpretation of the rules. We are still looking for a better representation of both unordered domains, the fear we have they will be interpreted just as more constrained domains, rather than just domains in which it is not possible to predefine an order of action because the environment and dependencies change makes it impossible. So maybe we should stop telling people that every 1 min of time they will have to change place, and just do it?

We are also having a hard time imagining the disordered domain, where ideally one would have to through pieces in the air, and in full darkness apply the same constraints as in the chaos case... that would be more of a hopeless and very frustrating experience... we are looking forward to have Dave Snowden give us more feedback :-)

Ciao & Thanks for your comments

Hello Andrea

great game. Facilitated the game twice now. Firstly a group from differeent organisations secondly from the same organisation albeit diffreent services.
In exercise 4 is talking allowed?
Feedback suggested changing the teams after exercise 3 as the teams had bonded and become comfortable. I will try this next time.
Thanks for this game Paul


Did a french translation here :

i just want to say thank you! i use legos extensively when coaching/training and this is wonderful!

i just want to say thank you! i use legos extensively when coaching/training and this is wonderful!




Refresh captcha


Latest entries

LeSS and DevOps

Large Scale Scrum (LeSS) not only accounts for DevOps, but also builds it into the approach, ...


Scrumtisch October 2017

Scrumtisch Berlin October 2017


Scrumtisch Berlin: August 22nd, 2017

August 2017 meeting of the Berlin Scrum User Group, facilitated by agile42 coaches Noel Viehmeyer and ...


Certified Agile Leadership comes to Vancouver

First part of the Scrum Alliance Certified Agile Leadership (CAL) program will be available in Vancouver ...


Survival Tricks for Remote Developers

Video and slides of the talk presented by Alessio Bragadini at PyCon 8 conference in Florence, ...