Archive for the ‘Facilitation’ Category

The Onion method, or how to facilitate conflict solving without tears

October 31, 2014 Leave a comment

I was recently working as a coach for a client in the financial sector. Their ways of working were very traditional and the IT department was running on fear of failure. As a remedy, they had introduced heavy processes, rigid gates and strict approval procedures.

The proponents of Agile, me included, wanted to relax the rules and have less BDUF (Big Design Up Front). We wanted to follow work on the wall, not in an electronic tool. Backlogs could be in Excel, not in Quality Center. Decisions would be made in workshops and conversations, not in meetings and tools.

On the other side of the argument were Process Owners. They were highly respected individuals who had full authority over their process. Examples of processes were “Testing”, “Architecture” and “Project management”.

When the conflict turned so hot that no-one could ignore it, our Agile Transformation Team called together a pow-wow to discuss about the situation and steps forward. The meeting went extremely well and I want to share with you some tools we used to defuse the bomb.

Start off on the right foot

We started the workshop by asking expectations from everyone. To our surprise, the expectation was not to have own opinion winning but “common understanding about what is mandatory in the process and what is not“. This was a good start; “common understanding” was valuable currency in the discussion. Another important point was that we agreed there can be rules. Agile does not mean throwing everything into the waste basket.

Tool #1: Slicing

One root cause for the conflict was generalisation. When someone said “Testing” then everything about testing became under discussion (tools, methods, practises,documents etc). This made all discussions so huge, that common agreement about “this” over “that” was never possible.

We recognised four components related to any work:
1) Artefact: Document or other output
2) Process: Identifiable steps in the process (for example “Do X before Y” or “Create A during B”)
3) Working practice: How the activity is done (for example meeting or workshop, who need to be invited)
4) Tool: What tools are used and how

This helped to create structure in discussion. Instead saying “Financial Supervision (FiVa) requires that we have specification documents in ShareNet” we can say “FiVa requires that specifications are documented“. This opens completely different discussions.

Tool #2: The Onion

The Onion helps to break the Does/Doesn’t debate into more fruitful conversation. Most conflicts are caused by false dichotomies; arguments about “Always vs. Never” or “Black vs. White“.

The layers of the onion in our case were:
Mandatory: Has to de done every time using the pre-defined way of working
Alternative: Something you have to do, but you have alternative ways of working
Recommended: Not mandatory, but a recommended practise to avoid conflicts
Optional: Something you can do or leave undone and there are recommendations for good practises available

After introducing the two tools, the Process Owner created a list of items in their area: what Artefacts, Tools, Work steps or Practices there are and which level they are in the Onion Model. As you guess, most Mandatory items were Artefacts or Tools. However, there were great insights, for example proposing that a mandatory meeting would be replaced by workshop with less strict agenda.

At the end we had a very good list of well-argumented needs from each participant, for example:
– “Testing can be done using BDD, but in that case the tool should be JBehave” (Optional working practise with Mandatory tool)
– “In order to follow the Architecture Process, team must have discussion with Architecture Steering Group before projects starts. It is recommended to follow Architecture Process also in Agile projects” (Mandatory working practice with Recommended process)

Example of topics discussed with Onion Model

Example of topics discussed with Onion Model

My key takeaways from the workshop and the tools were:
1) People have a desire for common understanding. Having this said in a meeting helps to find a solution.
2) People have desire to hold on to their important things and anchor them into larger entities (“I need to have requirements in written form, therefore I command a tool and process for that”)
3) Creating alternative structure and “baskets” helps people let go things that are not really important (things that are just proxies to get something that is important)
4) False dichotomy is the enemy of conversation. Offering 3 or more alternative levels facilitates agreement.



Exercise to illustrate Deming’s 95/5 rule

July 24, 2013 3 comments

W. Edwards Deming has said that 95% of variation in the performance of a system (organization) is caused by the system itself and only 5% is caused by the people.

This sounds counter-intuitive and training attendees often argue that having great people would solve the problems. Or at least people have greater impact than mere 5%. Many also argue that we should invest in people, coach them, motivate team members and do other “people stuff” to get better.

Unfortunately that will not work. “People issues are not the point of intervention“, says John Seddon and I fully agree. System is the point of intervention. By improving the system, we improve not only results but also motivation and well-being at the work.

Here is an exercise that I use in my trainings to illustrate how Deming’s 95/5 rule applies in knowledge work. This is a quick one, takes about 10-15 minutes including set-up and wrap-up.

1. Context: I draw the following picture on flip chart and tell the context. Joe works for an IT department of a large company. The IT system is used by customers to place orders on-line as well as company internal functions to manage invoices, inventory, sales forecast and marketing. Joe and the team have Product Owner who gets requests from customer help desk and suppliers.

(click to enlarge)


I start drawing from Joe, then the team -> product -> Product Owner -> help desk -> customer -> suppliers -> logistics department

2. Case: I explain people that “help desk receives a call from customer saying that it would be nice to follow order status on the web-site, e.g. estimated shipping date. Product Owner thinks this is a cool idea and puts it to backlog, ready for next Sprint”.

3. Task: After explaining the context and the case, I ask people to pick a pair (or in their table groups) to think “What could go wrong?”. What could happen between customer requirement and Joe so that Joe can not complete the work on time, with agreed content and good quality. I give 2 minutes for the discussion.

I also explain that SW development is a team effort, but in this case we assume that we look at Joe’s work. For example, why Joe (or his boss) would feel at the end of the Sprint that things went wrong.

4. Collecting answers: After discussion I collect answers to flip-chart. Usually the list has something of the following

  • Unclear requirement
  • Conflicting priorities
  • Bad tools
  • Bad working habits in the team
  • To much work
  • Joe’s competency (lack of)
  • Misunderstanding customer need
  • Lack of testing
  • Interrupts
  • Poor communication with other teams
  • ..and so on

5. System or Joe: The last part is to ask people “Who’s fault is this?”. If we have two baskets, System and Joe, which is the cause of the problem. I write on the flip-chart on each line “System” or “Joe” based on what the participants shout. Pretty soon the list is full of “System” and very few “Joe’s”.

This is a powerful way to show what is the impact of work design: When things go wrong, it is because the system. The point of intervention is system, not individuals.

Credits go to Richard Moir at Vanguard System for telling me this exercise. I have modified the original story (about plumbing) to fit the IT industry.


Four shades of coaching

March 1, 2013 Leave a comment

Coaching is a way to help people reach their potential, get energy to pursue towards important goals and understand their life or work from a new perspective. The best coaches I’ve met, they only use questions to open up and clarify my thinking.

I struggle with this issue: I am not the best coach, I’ve only started my journey to become a great coach. And who says coaching (only asking questions) is the only way to help other people? Could I find something that fits my personal style, allows me to be not-perfect and suits in different situations?

I got the following model from Kati Vilkki at Nokia Siemens Networks some years ago. It has proven to be very useful for me, when I have been moving from (command-and-control) management role to a coaching role.

The model helps me to understand my behavior. I never impose this to people I talk with: I do not judge or evaluate people with this — I don’t even show them this model. This is a tool for me to plan a discussion or reflect the discussion I just had.

The model looks at discussion topics from two angles: (1) Do I focus on the process or solution and (2) how supportive or directive my approach is.


Click to enlarge the picture.

For any problem we can

  1. Tell the solution: This works best in a panic situation (“Fire! Evacuate the building“) or when people have really low competence to do what they are supposed to do. This could also work in simple one-off situations, for example telling a colleague how set display resolution for video projector
  2. Propose a solution (“Loaded” questions): If the person lacks only knowledge or outside view, proposing solution alternatives could help forward. This requires that people have motivation and are just short of new ideas
  3. Tell a way to solution (Process): This works in a case where goal or solution is clear, but the person does not have energy to think of steps towards the goal
  4. Ask open questions: The Real Coaching is here 🙂 Staying neutral on the process and solution, just helping people talk and think

There are couple of points worth mentioning with the model.

Different situations require different approach. Different approach gives different long-term outcome. Using lefthand and bottom corners increases dependency. Providing answers (process or solution) does not encourage people to that by themselves. People and teams will not develop to be self-organized. Ownership of the issue stays on advice-giver — therefore advices that you give may not stick and the the team falls back to old ways of working.

On the other hand, working on the righthand side and top may feel uncomfortable and increase anxiety. Imagine if a person comes to you asking for help (assuming you give advice) and suddenly you start asking questions? The person may feel ignored or even angry.

I have found out that whichever “box” you start the discussion, you can only move left or down. If you start advising or telling the process, the others will expect you to continue on the same lines. It will be very hard to “climb up”. That is helpful point for me: In every discussion I try to start as “high” as possible.

A corollary to the previous point is that you can move down or left. I use this if the situation is not suitable for top-right corner. Maybe people are exhausted and need more support. Maybe people feel there is not time for open questions and I help them find more time. Maybe the meeting invitation mentioned “a professional who will answer all your questions“. Whatever the reason is, I can move “down” in the model and provide more safety when needed.

As I mentioned earlier, this is a tool for self-reflection and developing as a coach. This model does not give you ready-made questions or structure to design discussions. I use this model simply to understand my style and how it may affect the people I am talking with.

I hope you find this useful.

By the way, which category in the model this blog itself post would fit in?

LKCE Day 2

November 14, 2012 Leave a comment

It took me one month to complete blogging about Lean-Kanban Central Europe. First day of conference is covered in previous blog post.

Morning keynote: “Science of WIP limits” by Don Reinertsen. I had high expectations for this session, since I had never seen Reinertsen “live” but had read his books and saw videos of his talks. Unfortunately, I had seen this talk before (in InfoQ) so the session itself did not offer much new. However, this was a good reminder of WIP and related issues.

My key takeaways from this session were: (i) Systems have tendency to drift to high-queue states and preventing queues has big impact on system behavior, (ii) even a minimum constraint on WIP improves the system without negative impacts and (iii) decisions about queues (WIP, priority, purge,…) should be based on transparent economical framework .. also make transparent if you don’t know the economics

Session 1: “Lean Meetings” by Jim Benson. He has earlier written book about Personal Kanban and now he is on tour advertising his new book. Jim started by misunderstanding Agile and was very American about bashing anything that was not his idea. Then he presented traditional org.charts and pointed out that silo-organizations were actually very effective during the era where (a) cost of change & cost of product creation were high and (b) cost of information was high. Things have changed, so is need for management, information sharing and meetings.

At the end of presentation I had not much to take away. Some new viewpoints: (i) discussion about status and goal are waste in meetings, these should be known by other means, (ii) Meetings should be shared experiences (e.g. working around same Kanban wall) and (iii) meetings fail the same reason projects fail: pre-planning does not work.

Session 2: “ChangeBan” experience story. I skipped this one after 10 minutes or so, I could not understand the point of presentation. I moved to hear Hermanni’s presentation about “System Conditions”. The video is available here ( System Conditions was the topic that had the most profound effect on me. It combined systems thinking with organizational reality and showed how (i) change sustains only if the system is changed and (ii) software development is not only software development.

Session 3: “Portfolio Kanban” by Mike Burrows. I was waiting this session since many people ask about “Large projects” and “managing portfolio with Kanban”. I was a little disappointed; I did not get the point of the presentation. There were three case stories and I did not catch anything regarding “portfolio” Kanban. Key takeaways anyway: (i) spiderweb graph to illustrate “depth” of Kanban implementation, (ii) portfolio Kanban is about alignment between managers / customers / peers / team / you.

Session 4: Lightning talks, short sessions without limits.

The first lightning talk was about  “Introducing the change” by Pawel Brodzinski. The trick of the presentation was to handle it through PostIt notes; Pawel pasted tens of postit notes while he was talking. I did not get much from the story itself: main point was (I guess) change is about trust.

Second speech started with annoying and embarrassing Star Wars intro. Talk was “May the Forss be with You” by Hakan Forss. He presented basic Kanban and systems thinking stuff through his trademark Lego pictures. Key takeaways were (i) Human brain needs visual management and (ii) Remember to Collect Data, Go See, Create Habit on Continuous Improvement and Experiment in Small Steps.

Third, and the most interesting, was Benjamin Mitchell “Little less action and a little more conversation”. He challenged Elvis Presley and many others by saying that we actually need to discuss more. He pointed out (very correctly) that Scrum & Kanban provide lot of room to discuss about Doing The Work. Then he listed other topics where a little more conversation would be useful: Purpose, Demand/Need, Work Breakdown, Prioritization, Work Distribution, Team Conversations, Possible Value Deployed.

Finally Gaetano Mazzanti presented a quaint idea of “visualizing” Cumulative Flow Diagram with alternative styles and even sounds. The idea may be more entertaining that useful, but he showed how graphs become more alive by illustrating e.g. age of ticket by different colors and state transitions by sounds.

Session 5: “Double-loop Learning” by Benjamin Mitchell. Again this was a presentation that I had seen before. Still it was interesting and I tried to follow it with fresh eyes. Benjamin presented several models for learning and change, including Double-loop Learning, Ladder of Inference, Mindset-Action-Result. We experimented a little with observation and interpretation. Benjamin’s session was inspiring and I still managed to get several takeaways: (i) Make low-inference interventions, sharing observations rather than advise or judgement, (ii) I see only part of picture and re-framing my approach can change the situation, (iii) make sure you see -> check what others see -> create a full picture from observations.

The conference ended with keynote from David Anderson. He presented very new ideas how to measure Kanban in teams. The keynote started with a very good introduction to Kanban, David has really created a nice 15 min package of Kanban basic idea. Then things turned really odd. David presented question: “Which of several teams should take work from queue? Which team is most suitable?”. He studied the question from financial perspective and created an interesting liquidity model for Kanban: each card movement contributes to “liquidity” of the team and the most liquid teams provide least risky and “correct” throughput.

While the idea was sound and internally coherent, there was a big trouble: I think David was asking the wrong question. It is not the point of “choosing teams” or “finding the most suitable team”. I would ask other questions: why do you have three teams? why do you need to choose? does the organization match the customer demand?

What makes a great trainer?

November 9, 2012 Leave a comment

I have had good fortune to work with some exceptionally great trainers. As I am working towards my Scrum Trainer Certificate (CST), I have been paying attention to training techniques and especially the what part of trainings. My insight is

A great training finds the core message, presents it with clarity and explains the message through several layers for understanding.

My model has three layers and all of them are needed in order to deliver a great training.

The topmost layer is artifacts: rituals, tools, templates, processes and anything else that you can observe at workplace. Many trainings limit themselves to this layer: goal of the training is to learn a new tool or process.

The next layer is stories: it is examples, anecdotes, metaphors and other stories that are used to illustrate the topic. I also include games and simulations in this layer. Stories are a powerful tool to get the message through. Trainer sharing own experience or participants playing a simulation game is a good way to highlight key points of the topic at hand.

The core – and my insight – is that a great training delivers a core message, key points that make the difference.

A good training may fill you with new tools and great sories but a great training connects all this into a meaningful core message.

As an example, Scrum trainings at Reaktor cover the layers in the following way.

Artifact layer is about Product Backlog, Scrum process overview, techniques for scaling Scrum. Anything that you could use as is in your organization after the training.

Stories are trainers’ experiences using Scrum and simulations & games we run during the training.

The core message in the training is clear. It answers the question What for is Scrum? All artifacts and stories link to the core message and core message becomes alive through artefacts and stories.

The core message must be relevant, focused and sufficiently unique to the topic at hand.

An example of a bad core message would be: Scrum is about better quality and happier customers. Well, Scrum is also about that, but so is any other method. Such core message lacks uniqueness and focus.

None of the layers alone are enough to provide a great training. Not even the core message is enough alone: The core message is not comprehensible without related stories and artifacts.

OK, so far I have been talking about a great training. How about a great trainer?

To  my opinion the most useful skill for a trainer is not creating a structure for a training session or how trainer is using her voice or how to make beautiful drawings on the flip chart. Those skills are needed, but those alone do not make the trainer great.

A great trainer finds the core message in the training he/she delivers. A great trainer understands the the topic – preferably through own experience – so thoroughly that the core message is relevant, focused and unique.

Unique and relevant core message creates curiosity and curiosity leads to exploration.

A great trainer balances between artifacts, stories and core message. Metaphors and stories make the core message more alive and artifacts show how the core message realizes in daily work.

On my way to become a better trainer and qualified CST, I use this framework in all trainings I deliver. As a training participant, I listen the training content through this framework, Most recently, I used this framework to understand conference presentations in Lean Kanban CE. Paying attention to content and layers hopefully helps me become a great trainer.

The surprising power of being nice

July 25, 2012 Leave a comment

Near my home in Helsinki, there is a children’s playground. It has the usual stuff: swings, slides, sandbox. However, there is one special feature: It has a toy box. A large plywood box full of spades, buckets, plastic trucks and anything a 2-6 year old can dream of.

The box is operated by volunteers: you pay small amount of money, get the key, can use the toys, collect toys & lock the box when you leave the playground.

There is one twist, though, and it led me to a learning about communication.

Once the box is open, every kid in the playground rushes to the box to see what treasures there are. It takes just minutes to see most of the toys disappear from the box and toddlers carrying them into the sandbox and beyond. Not everyone has the key, though, and most people probably have no idea why the box is open.

The problem comes when I need to go home. When I leave, I need to lock the box and I’d like to see all the toys back in the box. If they are left outside, who knows how long it takes before the next person with a key comes and collects the toys.

What can I do when I want to influence bunch of strangers? They are not my toys, but I feel responsible for keeping them safe.

My favorite line is the following

Does anyone have the key to the box? (pause) Well, I have and I will be leaving in about five minutes. If you want, please bring toys back to the box as I will lock it when I leave.

This usually causes quite a fuss. Parents rush their kids to return the toys and while doing that they come and thank me for letting them play with the toys. People are smiling, it is not common to ask “if you want“. Everyone seems happy and toys are returned to the box.

What is so special about this? I noted several points that are useful in any other communication.

– I may not be the king of the hill. Someone else may have a key, too, and he can take care of the toy box after I leave. Similarly at the workplace: when meeting with people I try to inquire rather than command. “Does anyone know about yesterday’s outage” is much better than “Hey guys, let’s have a quick brainstorming about the outages

– I want to be specific about my role in the situation and my expectations. In the toy box example, I tell people that (a) I have a key to the box, (b) I will be leaving soon and (c) I want to see the toys returned. Too often I find myself being vague, especially if I deal with strangers or situation is uncomfortable (e.g. taking toys from kids). It would not be useful to say “Could you maybe bring some toys closer to the box“. Being soft and vague is not nice. Being vague is almost impolite.

– I want to trust people. I could think that “people just want to steal the toys” . That would cause very different choice of words, probably confrontative and aggressive. Saying “If you want” is a way to express trust and create a feeling that I am equal with them. I am not the box-keeper of czar-of-the-playground.

– I can not control everything. What if one 2.5-year boy really does not want to give back the Lightning McQueen bucket? Shout, maybe, or take it by force? No, not really. At the end, it is about wanting to return the toys.

Seldom have I managed to create such a powerful statement, yet being nice and bringing smile to people’s face. I hope I could repeat this at home or at the office, when I want something to happen and fear that it may not be pleasant for others.

OK, you say, but it is not that simple. We can’t always be nice and ask, there are cases when direct orders are needed. Yes there are. In case of fire, I would definitely say “Hey, the house is on fire, exit this way, NOW“. But the point is: If you have a lot of life-threatening panics at your workplace, then it is not a communication problem.

Saying (unexpectedly) “if you want” is nice and pleasant, but it will become naïve if repeated. I would like to create an environment where I don’t need to say “if you want” — instead everyone in the situation would say “that’s what I want“.

No matter if it is about toddler toys, doing the dishes or fixing that tough SW issue, it is about creating intrinsic motivation to act. The way we communicate and initiate the situations, has tremendous effect on the outcome.

Categories: Facilitation, Team work

Understanding coaching: Iceberg metaphor

June 28, 2012 Leave a comment

During my most recent assignment I had to think about role of coach and coaching. I found myself in a situation where large-scale Agile transformation was pushed forward and “coaching” was seen as a tool “to harmonize working practices” and “deploy new ways of working in teams“. I had tough times with myself and my work — to me coaching was something else than “tool to enforce people follow same practices“.

Yes, coaching is something else. But what is it? How could I explain “coaching” to myself and people I work with?

I like metaphors, at best they are powerful visualizations and form a basis for storytelling. They create strong emotions and connections, if chosen carefully.

This time I went for an iceberg. I came up with my iceberg independently and alone, and only later someone told me it looks a lot like David Rock‘s coaching iceberg.

The Iceberg

Very often the expectation for coach is visible results: “Tell me how to empower teams?” or “What should we do to improve predictability of SW development?“. Closely related to results are actions and working practices: observable things we do (differently) in order to get the results. These are the tip of the iceberg.

Sticking with these is not what coach should do. In order to get the desired results and facilitate sustainable change, coach should work on the invisible (or not observable) part of work.

Submerged part is Values, Beliefs, Assumptions, Thinking patterns and Feelings. I will not create a comprehensive list and here you can see I am much less scientific than David Rock and others with their icebergs 🙂

The environment is the context or agenda. Some coaching wisdom says that coach should be completely agenda-free, i.e. have no pre-defined framework. I disagree with this; my agenda is Agile and Lean, I help people in that context (but not limited to that) and this agenda creates a framework to model and understand the situation.

(Click on the image to enlarge)

Role of coach

To my opinion, coach can do four things to improve work and get visible results. However, very few of these are directly related to daily work.

First, and not the most relevant, is to provide new ideas from the environment, i.e. explain the world from Agile and Lean viewpoint. This is usually the reason for hiring external consultant: come and tell us how things are done elsewhere.

Next, and more important, is to help people understand their thinking. It is helping the people to give words to their issues. Naming is important part of understanding. To me this also has a lot to do with cause-effect relations; asking “what happens if X” or “how does this action affect Y“.

The most important part for me is helping people to turn thinking into action. Coach helps people to find places for experiment and facilitates the needed agreements  that are required to change old working habits. Coach also helps people not to fall back to old routines and encourages when novel approach feels painful.

Finally, again very important, is to help people reflect their work. This creates a link between thinking and action: “What just happened?” is good question fox quick feedback loop. Larger and slower actions may require retrospectives or other “formal” reflection.

Hypothesis – Experiment – Validation

After drawing the picture I see there another pattern that makes sense from Agile and Lean perspective. Coach helps to build Hypothesis – Experiment – Validation cycles in the organization.

(Click on the image to enlarge)

Giving issues names, thinking about cause-effect relations and clarifying thinking is a way to build hypothesis. Trying the hypothesis in action is experiment and reflecting the results is validation.

Key to successful change is getting this cycle working: encouraging people to do small-enough changes consciously and reflecting the results together.