Understanding the Cynefin Framework by Playing with Lego
Maurizio Pedriale & Alan Hortz introduced the Cynefin framework to the audience at the Agile Tour Brussels conference, using exercises with Lego. Cynefin is a sensemaking framework which can be used to understand situations in organizations and to decide how to approach them. The workshop is based on the HBR article a leader’s framework for decision making by Dave Snowden. Wikipedia describes the Cynefin domains:
The Cynefin framework has five domains. The first four domains are:
- Simple, in which the relationship between cause and effect is obvious to all, the approach is to Sense - Categorise - Respond and we can apply best practice.
- Complicated, in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge, the approach is to Sense - Analyze - Respond and we can apply good practice.
- Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.
- Chaotic, in which there is no relationship between cause and effect at systems level, the approach is to Act - Sense - Respond and we can discover novel practice.
The fifth domain is Disorder, which is the state of not knowing what type of causality exists, in which state people will revert to their own comfort zone in making a decision. In full use, the Cynefin framework has sub-domains, and the boundary between simple and chaotic is seen as a catastrophic one: complacency leads to failure.
Maurizio and Alan facilitated a workshop where multiple teams did 4 exercises in the cynefin Lego game. The purpose of the exercises is to get a first understanding of the Cynefin framework, and discuss how to use it in agile coaching situations. Each exercise matches to one of the Cynefin domains. A retrospective was done after every exercise, to evaluate how the team did the exercise and how they organized the work.
The first exercise that covered the simple domain was easy, everybody understood the outcome that was expected and people were able to start doings their work quickly. The second exercise helped the team to understand the complicated domain. The teams needed some more time to understand what is needed for this exercise, and to decide upon a way to reach it. Different approaches were taken by the teams, most leading to the needed outcome.
In the third exercise, rules were introduced stating how the work needed to be done, and the needed outcome was not fully specified. Teams tried different approaches to build something that would satisfy the needs. In the retrospective teams learned what had happened, and were able to think about different ways to do it. The last exercise involved changes to the teams, by having people switch tables. Initially some of the teams took an approach similar to the third exercise, but that changed when new people came into the team. People tried to cope with the chaos that they experienced by the team changes and the different approaches in the teams. They tried things, and used the feedback from other people to continue or changed their way of working.
The session finished with a short presentation of the different domains, where Maurizio and Alan explained how you can deal with situations in the different domains by adapting your coaching and communication style.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015