Cynefin Lego Game

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

Tips and Tricks for the beginner Product Owner

Most people are afraid to fail. Shame is at the core of the fear of failure, psychologists say (see Dr. Brené Brown @TED). The problem with fearing failure, though, is that it does nothing but help you fail.

In our western culture, shame is a driver to get others to do things. By using shame and guilt as tools, we do not only burden us with an emotional baggage that is wearing us down emotionally, but we also create a lot of dysfunctions as we hide mistakes in order not to be blamed.

Transparency and courage are values shared by most of the agile approaches, Scrum in particular, the opposite of shame and guilt. We can choose to try to live our lives on our own terms: either by trying, failing and learning or by remaining in the swamp of shame and guilt and not improving. When you feel guilty and ashamed, you behave accordingly. Your mind will keep thinking about what happened and will not allow you to change anything as this would mean acceptance of the failure.

If all went well the first time we tried, we would never ever get any better. As we strive for perfection, we should embrace failures as they give us the chance to grow. Inspection and adaptation require reflection on things that could have gone better. From my experience, once people accept that they basically constantly „fail“ in the way of retrospectively not having chosen the best approach for what they wanted to achieve, they harness the incredible power of creativity and courage and gain the intrinsic motivation to do better at every future step (see Drive).

Shame is a tricky concept and a very useless one too. It has been rooted deeply in our society for maybe longer than a millennium, and that is by far too long a time. As eastern (buddhist and hindi) cultures show us, there is no need for that concept. So stop seeing yourself as a bad person because you did something wrong. Consider yourself lucky that you were given the opportunity to change your future behavior.

So accept that you could have done better, every second of your life, If you had had your current knowledge. You did the best you could, and given the situation at hand, that‘s all you could have done anyway. Wouldn’t it be awesome if we recognized a few of these „failure moments“? Wouldn’t they be an evidence that we have learned something and we can harness the power of learning to improve?

Throwing the concept of guilt and shame overboard is the first step in the direction of good agile risk management. We know that all of us could have done better constantly. So after we accept that fact, we can think about ways to make the biggest mistakes transparent.

So why should we embrace to fail fast? When diving into a new project, I am often confronted with a situation where the management fixed the time and release date, the scope of what should be released and also the quality in terms of SLAs. The first question that I ask under such conditions is: „When do you want to know how badly you are going to fail?“

While the question might be a bit confrontational, the discussion thereafter is awakening most of the time. If the „iron triangle“ (scope, time and quality) is fixed, than it is better to know as fast as possible if the plan is off or not, so that we can react and soften the damage.

As a manager, the worst thing that can happen are surprises for which expectations management is key. Agile methods are the best tool I know to get the most trustable and fast results. Worse than having bad results is having bad results late.

From my practice as a Product Owner, you need a tool to manage releases, not only Sprints. So what I do is to set up a release map and give the developers some overview about the planned high level requirements. In return, I ask them to give me a rough relative estimation about the effort of each of those requirements. Once the first requirements get broken down to little pieces, and the little pieces get estimated, I start knowing more and can do recalculations. With every completed Sprint, I gain knowledge about the progress and even in very large projects, it does not take long to get a good idea about: when it will be finished, or if we need to tighten the scope. This helps  significantly when dealing with multiple stakeholders. Particularly, conversations tend to get way more concrete when I am approached to enlarge the scope. It is easier and faster to forecast the impact of any given change.

So embrace failing fast and don’t fear to be ashamed! Every failure is a new learning opportunity if you accept it as such. Once it is there, you cannot change it anyway, but you have the chance to make the best out of it—learn something from it.

man holding incandescent bulb

Tips and Tricks for the beginning Product Owner

Envision a vision for a better PO

I want to point out that a vision is a necessity. The Product Owner is not going to do a good job without one. The product vision is not part of the Scrum framework. Nonetheless it is often mentioned in the Scrum literature as something that is a prerequisite.

In my experience, most companies lack a vision for their products. On rare occasions,  there existed a product vision, but it led a gloomy existance in a dusty drawer.

A good product vision is short, concise, broad, understandable and most important – engaging! With a good vision in place, everybody in the company will be aligned to the same goal.

Make it clear what you build, what your target audience is, what is the single uncompromiseable feature and what are other features that distinguish your product from your competitors’. Make every sentence and word matter, not longer than an abstract. The book from Geoffrey Moore “Crossing the Chasm” is a great source to learn how to write a vision statement properly.

Why is the product vision a vital tool and not just a toy for esoteric trainers? Imagine the perfect Product Owner. She has the authority to substitute the customer directly when facing the development team when a question arises. This can be accomplished if she has a very good relationship with the customer and knows his wishes, the product and the environment very well. – Even without a product vision.

Now imagine that this Product Owner has more than just one customer. She would need a split personality with a shared knowledge and understanding. And the stiuation gets even worse with three or more customers. And now keep in mind that building a product does not just mean to fulfill the customers‘ wishes. It is about building a product with many other stakeholders like development and marketing as well as juggling with internal requirements and restrictions.

The product vision is the shield for the Product Owner. Many dysfunctions in companies arise because there is no product vision. The common tragedy that follows is that many opportunistic moves undermine the product integrity. The product loses its identity. Nobody knows anymore what makes it stand out, what makes it different, marketing does not know what to advertise about the product, developers are not proud of their product anymore and stop taking care of it. In the end you have a bunch of people who try to hold it all together until there is no more money to squeeze out. The end of the product life cycle is reached. The vision is the tool to align the goals of all stakeholders and allow the Product Owner to challenge and also motivate the team.

So help yourself and the team and forge the tool you need to motivate and keep the integrity of the product instead of whining because it all falls apart.

Agile Strategy Map – Mapping at ACCUS

Two weeks ago, Olaf and I had the pleasure of participating in the AgileCoachCamp US (#accus). We played our brand new Kanban Pizza Challenge on the Games Day, and hosted multiple open space sessions. One of my sessions got exceptionally good feedback, so I decided to provide a little more information on the agile42 Agile Strategy Map

Dave in Full Flow

The opening question was how to effectively manage the work of the leadership or transition teams in large enterprise agile adoptions. The group quickly identified two scenarios: one in which the traditional backlog and task board approach worked extremely well; and one in which the backlog and task board lacked sufficient cohesion to lead an effective adoption, perhaps a result of lack of commitment or discipline.

In the latter case, we discussed the impact of using an Agile Strategy Map. This tool is used to visualize the strategy gap, the link between a corporate objective and the tactical actions taken to achieve that objective. As the following diagrams show, the Agile Strategy Map has 3 distinct components.

ASM Objective

First, the center of the map is the objective of the transition. Ideally, this objective will tie directly to delivery of the corporate goals or mission. In all cases, the objective needs to be clearly stated (rather than wooly management-speak). Preferably it describes what success would look like, to help bring clarity to the purpose of the transition and allow the team to measure their progress against the aims of the transition.

ASM Success Factors

Second, as a leadership team we elicit the possible success factors that, together, will contribute to the successful accomplishment of the objective. In this case, we want to keep in mind all the possible success factors, rather than aim to pick a limited number of critical success factors. Things will change, and part of the value of the Agile Strategy Map is that it visualizes a lot of choices that can be made to deliver on the objective, rather than only showing the current plan with a limited number of success factors.

ASM Full Map

Finally, for each possible success factor we want to brainstorm as many necessary conditions required to deliver on that single success factor. These actions and deliverables should be comprehensive, before we apply conditional thinking to bring the large number of possible actions to a minimum number of necessary conditions.

For more complex situations, any of these components can be considered hierarchically. For example, a single objective might be split into a further 2-3 objectives in different areas of expertise. In this situation, it may be possible that different objectives share some possible success factors.

The outcome is a visual representation of the many different conflicting and shifting priorities that have to be managed to deliver a complex, enterprise transition. The leadership or transition team can use the Agile Strategy Map as a starting place to prioritize actions, which are than managed through a traditional just-in-time backlog and task board.

The value of the exercise is less to do with addressing the underlying issues of commitment, discipline, or poor systemic prioritization (fire-fighting) and more to do with the value of a big visible chart that clearly outlines the connection between the actions that are taken and the achievement of the objective.

Thanks to all who joined the conversation, which was lively and informative.

 

 

 

Awesome Coach of the Week: Andrea Tomasini

I’m pleased to put forward Andrea Tomasini as our Awesome Coach of the Week!

I’ve been fortunate to know and work with Andrea for over three years. First, we brought Andrea into our company as a consultant, having bought into his vision for how we could turn our product development team around. Andrea is a a passionate advocate for agile, and an intoxicating communicator. The workshops, training and coaching sessions often attract observers and impromptu visitors. People just have to find out what is going on? Why is everyone moving around, building lego cities, running back to their desks? Basically anything but sitting and taking notes. In two days, Andrea some how imparts a huge level of understanding, not just information, through shared discussion, experience and insight.

Having observed Andrea at close quarters, I see two key characteristics that make Andrea an awesome coach.


First, Andrea understands what makes a great coach, and lives this in everything he does. Andrea has an ability to build rapport and influence with executive leadership, to get his message across, and challenge entrenched thinking and hidden assumptions. At the same time, Andrea is at ease with the development teams, using his own practical experience to melt the ice and understand the situations unique to each company and team. Finally, Andrea has a deep understanding of and passion for agility, and this comes across in every response to a question and approach to a problem.

Second, Andrea has incredible energy and a presence about him. If you want things to move forward, get Andrea on your team. Andrea can certainly find time to relax and enjoy time with friends, and in addition brings his energy and presence to everything this does. He moves at a rapid pace, keeping people moving with him and achieving results quickly. At the same time, he channels this energy very effectively. Andrea understands the need to challenge and question, to advise and educate, to nurture and coach, and which situations to use each very different skill.

Since first meeting Andrea, I’ve changed companies and continents, and still work closely with Andrea. As with all the awesome coaches we honour, there is something remarkable inside that strives to express itself. So hats off to Andrea Tomasini, our Awesome Coach of the Week.

Scrumtisch with Lyssa Adkins 2011

The February Scrumtisch Berlin featured a talk by Lyssa Adkins, famously known for her publications on Coaching Agile teams. A mixture of fifty developers, scrum masters, coaches and product owner as well as one project manager followed Marion Eickmann’s invitation. Thanks for organising the event, as well as thank you to Hypoport, Berlin for providing the venue.

In her one-hour presentation she mainly focussed on two core topics: On the roles agile coaches have to fullfill as well as on the skill set needed by agile coaches. Being an agile coach (as well as being a scrum master, really), entails four very basic roles:

Being a bulldozer…

…that is getting impediments out of the way. That can be as easy (or hard) as getting appropriate equipment for your developers or teaming up with the product owner to communicate with anyone trying to break the sprint.

Being a servant leader…

…for a coach that means to work for the team, to ask the right questions and enable the team, to listen during dailies – instead of asking for additional reports: Most tools are already within the Scrum toolbox. The hard task is to identify them and use them correctly and efficiently.

Being a shepherd…

…that may be as easy as getting people to attend the dailies, or as complex as communicating common values, a common goal.

Being the guard of quality and performance…

…as a coach that means making degrading quality visible – and letting the Scrum team take the decision on how to deal with it.

However in reality each team is different, each sprint is different. So coaching really is similar to bing the river guide: Each trip is different. It is your task to make the team succeed and adapt to differing situations. To get to team to high performance – over and over again.

When talking about coaching what people need is a very specific skill set:

  • To become a successful agile coach it helps to have coaching skills to be able to understand the client, to see their impediments and help the team become better by listening and asking powerful questions.
  • Be a facilitator who organises sessions, meetings, conversations and may mediate in meetings.
  • Have business domain expertise – that is to know process designs, figure out a companies strategy options.
  • Be a great teacher to help people understand the basic concepts. That entails knowledge on course design, most likely design of exercises.
  • Have mentoring skills to guide a team in the process.
  • Know about lean and agile processes and stay up to date.
  • Have the technical skills on what makes development successful, know the extreme programming techniques to help team excel.
  • Have transformational skills – that is be familiar with change management, transformation leadership, knowing how to change organisations.

However being a coach remember that people are influenced not only by what you teach – but mostly by what you do. Most of what being a good coach means is invisible to the uninitiated outsider. It’s about living the process you teach, staying true to the principles you want others to implement.

To get there it helps to get inspired, to talk with others in local meetups (just as with any coding practice: Try to find a common forum to exchange ideas and get fresh input). It may help to keep a value journal – not only to track your accomplishments and be able to prove them to higher management, but also to track where to improve yourself.

The talk provided several interesting starting points for exploring further. However with an added exercise sixty minutes covered only the very basic ideas. Especially for the skill sets needed to successfully coach teams it would be very interesting to learn more on what books to read or what courses to attend to learn more on each topic. Ultimately not only agile coaches benefit from being great teachers, mentors or facilitators.