Cynefin Lego Game at Agile2013

/by

Our coaches Brad Swanson and Dave Sharrock are in Nashville at Agile2013 where they will present a workshop on August 8th titled The Cynefin Lego Game: Recognizing the Complexity Domain of your Problem.

The Cynefin Lego Game is a game to let you experience four of the five domains of Dave Snowden’s Cynefin framework and part of agile42’s management training for the Agile Management Framework.

From Dave and Brad workshop presentation:

We expect leadership teams to find innovative solutions to business challenges, and yet rarely give any consideration to how to solve these challenges. Current thinking is leading us to understand that different types of problems lie in different complexity domains, and require different ways of solving them. And the mix of solution types is shifting, meaning our traditional approaches to problem solving are not always suited to the new problems we encounter.

The Cynefin framework, introduced by Dave Snowdon, provides a simple model to understand the types of problems and how to solve them. Using Cynefin and complexity thinking can accelerate organizational learning by recognizing the problem domain for a particular situation and knowing what class of solution is appropriate. Recognizing the complexity of a problem is a behavior that will enhance learning, and failing to recognize it may restrict learning within the community.

As managers and leaders, we need to understand what types of problems we encounter, and which tools and approaches are best in each case. Using a series of Lego exercises, participants will experience each problem domain, from simple to complicated to complex to chaotic, and emerge different approaches to problem solving in each domain. Some will work, some won’t. You will experience the importance of choosing the right approach for each problem domain, and what happens when we use the wrong approach to solve a problem.

Expect to understand what type of system you are dealing with by recognizing when practices stop working, and learn to decode what is happening in terms of organizational structures and communication in that specific system.

Further information can be checked on our Cynefin Lego Game page: the game is licensed under the Creative Commons Attribution-Share Alike 3.0 Germany License and therefore can be played freely! Please let us know your comments and experiences.

Growing powerful agile teams

/by

Agile teams are the building block to any successful agile transformation. Without strong, self-sustaining agile teams, any change as a result of an agile transformation is very likely temporary. At agile42 we spend a lot of time helping our clients form powerful agile teams, and in the following we explain a little about our approach.

Characteristics of an agile team?

As well as small, 6-9 people, an agile team is: 

  • Cross-functional – the team includes all roles necessary to deliver the work (at minimum Dev and QA), and dependencies outside the team (e.g. UX) are understood and available as needed 
  • Dedicated – team members are dedicated, with any non-sprint work transparently tracked on the task board and the potential impact (decreased priority) agreed with non-sprint stakeholders
  • Co-located (preferably) – defined as sitting in the same space. Where distributed teams are necessary, ensure strong ties are created through virtual tooling and regular communication
  • Working from a single backlog – the team has a single product backlog, containing items prioritized by the business and ready for the team to work on, from which to pull work
  • Managing unplanned work – agree with the PO an agreed contingency or bug capacity to be removed from the sprint; manage this contingency to avoid impacting the sprint commitment

Getting started

We start with a conversation with the team around the +15TEAM assessment, a simple dashboard of 15 basic agile behaviors and practices that provide the foundation for an agile team. The +15TEAM acts as a seed for discussion and understanding about why each practice is part of the foundation of a successful team. 

But the +15TEAM is not enough. We need a team to develop new habits and skills, and to break old destructive habits. Any new agile team will pass through three levels of growth to become high-performing, predictable agile teams. 

Three stages of an agile team

Stage 1 – Predictable Delivery

Start by creating a habit of finishing work requests within the team. Many teams or developers working in a traditional environment quickly lose the habit of finishing a feature completely, perhaps as a result of silo’d delivery or high interruption levels. Quickly reintroduce this habit, before focussing on other agile behaviors. Without the habit of getting to done, a team will never progress.

Predictability is the ratio of the number of story points completed to the number of story points committed to. High predictability is above 90%, the target above 95%. Completing a story means meeting all the points mentioned in the Definition of Done, defined by the team itself.

Stage 2 – Build Quality In

Once a team has the habit of predictable delivery, the team turns their attention to quality. While learning to deliver predictably, the team has become more and more aware of technical ownership. 

With support from the business and the product owner the team have already taken on non-product related stories to improve their working environment or remove technical debt. Focusing on the technical standards the team works to, they raise the bar and build quality into their process. 

Tightening the Definition of Done constraints or measuring and making visible quality metrics and technical debt, such as bug counts and the results of static code analysis, contributes to a focus on quality, and in particular, building quality into a product, rather than chasing quality at the end. 

Stage 3 – Sustainable Delivery

Finally, once a team has mastered completing the stories they commit to while building quality in, they turn their attention to improving throughput. This is a delicate step because a traditional mindset might set velocity goals to increase productivity. But velocity is a lagging indicator, telling a team after they have reached a sustainable pace, rather than a leading indicator telling the team what more needs to be done. 

Think of velocity like weight. I can measure my body weight to determine how much I weigh today, but on its own my weight cannot tell me how my weight will change, whatever I promise to do.

Instead focus, through observation and frequent retrospectives, on aspects of the technical environment or team dynamics that prevent high performance. This might mean speeding up feedback loops for the development team through continuous integration and test automation, or using the retrospectives to enhance team work around a single story. 

Remember enhancements on productivity often have a negative impact on the predictability of the team. For example, challenging teams to take on additional stories to expose weaknesses in their development environments or team dynamic, means predictability will fall as stories are dropped. Set expectations appropriately, and make the work of the team transparent, to help mitigate concerns raised by variations in productivity.

In closing, growing powerful teams takes dedicated time and targeted effort. Changing team behaviors and practices requires the courage to recognize mistakes, and the honesty to delve into the root cause of the results, good and bad, the team delivers. But the rewards are impressive: A team that stands on its own, robustly handling organizational churn, and with the capability of predictable delivery of new features. Think about it – it might be worth it.

 

Cynefin Lego Game

/by

Context

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

Timing

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.

Instructions

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

Debriefing

  • 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

Debriefing

  • 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).”

Debriefing

  • 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).

Debriefing

  • 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.

Notes

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…”

Links

Cynefin framework: http://en.wikipedia.org/wiki/Cynefin