Archive for the ‘Team work’ 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.


Respect for people or improve the system?

October 2, 2012 2 comments

Last Sunday (Sep 30) my local newspaper, Helsingin Sanomat, published an article about well-being business. Specifically the article was about motivation and how the business of “motivational speakers” is increasing in Finland. Various celebrities travel around speaking about motivation, many companies organize funny or crazy get-togethers to improve well-being at work.

I felt confused after reading the article. As if motivation and well-being could be purchased and brought in by inviting a famous person to give a presentation.

No, you can’t buy happiness in a box.

As W. Edwards Deming said: “A bad system will beat a good person every time“. If the problems arise from system (as they almost always do), it does not help to bring in a motivational speakers, no matter if they are ice-hockey stars or certified circus clowns.

Some time ago I got a link to an interesting video (thanks @hemppah for the link). It is a panel discussion with extremely distinguished members, including John Seddon and Jeffrey Liker. I took an excerpt from the video, added Finnish subtitles and published in YouTube.

In the excerpt, John talks about interventions. He points out that solving “people issues” (for example motivation) can not be solved by intervening “people issues”. Reason is that “people issues”are caused by the surrounding system. Therefore more effective approach is to intervene the surrounding system and create environment where people can feel Autonomy, Mastery and Purpose (as Dan Pink describes in his book “Drive“).

(Full 50 min video of the panel discussion is available at

Having said this, and having published Seddon’s video, there is some value in having motivational events or well-being days. I can think of three situations

1) Spending relaxed time together can give people experience of being together. Potentially this helps people also to work together, provided that system does not prevent collaboration

2) Highly competent speaker can bring new ideas or new perspective to work, provided that system allows experimenting with new thinking.

3) Seminar or a respected speaker is a way of rewarding. It can give a signal that company cares; company allows people spend some time away from burning work issues. Provided that the motivational events are arranged bona fide and without hidden agendas.

Note: I am working in consulting business. Part of my value is to motivate and inspire people and help them improve their work. By doing this work I see how impossible it is to improve work without changing the system. Respect for people is empty promise if it does not include understanding and improving the system.

Categories: Team work

Focus on what you want

September 10, 2012 Leave a comment

Here is a great speech by Russell Ackoff about systems thinking. The video is “old” (from 1994) but the message is still relevant.

The video features several classic quotes, e.g.

The system is not a sum of its parts. It is the product of their interactions.

I would like to highlight another message in the video: Ackoff talks about importance of the correct motivation for improvement.

Defect is something that’s wrong. Now this should be perfectly obvious: when you get rid of something you don’t want, you don’t necessarily get what you do want. And so, finding deficiencies and getting rid of them is not the way of improving the performance of the system.

Take a look at the part from here and enjoy his great story about TV programs and “fixing” that problem.

I share Ackoff’s opinion about quality improvement programs: they tend to focus on unwanted behavior (defects, waste, cost) rather that desired outcome. And by doing that, they are doomed.

Focusing on the system, its interactions and customer need is much better starting point for an improvement.

You can see the full video in YouTube (about 12 minutes).

Categories: Agile and Lean, Team work

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

Priority, urgency and focus

June 19, 2012 Leave a comment

Today I saw an excellent blog post by Merlin Mann, about priority: Mud rooms, red letters and real priorities. The post explains why A priority is observed, not manufactured or assigned. The claim is bold but I have to agree with Merlin Mann’s thinking (note: he slightly confuses priority with urgency, both examples in blog are both urgent and high priority).

Here’s my favorite part of the blog post:

An item is either unique or it is not. A woman is either pregnant or she is not. An item is either the priority or it is not. One-bit. Mutually exclusive. One ring to rule them all.

This reminded me of a recent blog post by my colleague, Sami Honkonen, about act of prioritization: Setting priority is selecting and letting go. In order to have any useful priority, you need to choose what not to do. Act of prioritization, as Merlin Mann puts it, is about saying: no, no, nope, not today, no, later, sorry not this time.

Priority is observable, you can not “set” priorities. Look at the things you need to accomplish. Are the post-its on the wall moving according to “priority”? Are people talking “priority” or doing priority? Are “priorities” changed, arbitrarily or based on office politics?

Having several priorities is nothing but cheating yourself. Having more than one priority means you have none. Juggling between priorities is entertaining, but does not help you or your work. I like the new definition of Scrum Product Backlog: it is no longer called a prioritized list, it is an ordered list. Subtle but significant change.

Priority must not be confused with urgency. One consultant asked team “What is your most important thing to do today?” and once he got answers he continued “Did you complete that before you brushed your teeth this morning?“. Priority is not the thing you do first: it’s what you do all the time. Sometimes the priority requires changes in plans or dramatic & immediate action and that is the most observable part of priority.

Priority is not about rushing or doing things hastily. Nor it is about panic action or adrenaline-driven primitive reaction (well, sometimes it could be but hopefully not always). Priority is about making sure the most important thing gets satisfactory completed. Note: satisfactory here does not mean “minimum acceptable level”, it means satisfaction.

Focusing and selecting not-do’s is painful. That’s why “priority” is a great excuse. Instead of doing something I can say “It has priority”. As a manager I can stay high on adrenaline running between high-priority meetings all day. “Priorities” is a good alternative for real decision making.

We often call priorities things that are just to-do lists. At worst (as Merlin Mann points out) “priority” can be emotional obsession: something that gives us satisfaction as long as it is not done.

Merlin Mann says priority is observable and unexpected events make priorities visible (sudden illness, accidents etc). I make even bolder claim: it is the usual and expected events that also tell priorities. Family member does not need to fall ill to make your priority visible. Customer does not need to complain to make “customer first”.

The real priority is visible on how you organize your life and work. Do your priorities come in naturally? Does following your priority feel like gliding downstream or swimming upstream? Do you have the needed resources (time, competency, information, money) to follow your priority? In general, do feel like living with or fighting for your priorities?

If you have to “set” or “communicate” or “enforce” priorities, you are doing it wrong. If you feel content with your priorities, you most likely get things done. And if you get things done, you probably got your priorities right.

Having only one priority sounds harsh. Yes it is and it is supposed to be. We as human beings are capable of doing only one thing at one time. That’s why the priority is so strong. And that’s why priorities kills the idea completely.

Note: Not everything has to submit to the priority. If the important things (priority) in my life or work is going well, I definitely do and think “lower priority” (sic!) things. Imagine a pilot on an commercial airplane: her priority is safe flight and as long as everything goes according to that priority she can have a nap or read book or chat with other crew members. Priority does not mean staring at monitors and squeezing the controls as hard as you can. In addition to taking action, priority is also about making things visible and making sure you can take action immediately when things go the wrong way.

Categories: Agile and Lean, Team work

Timeline done right

February 10, 2012 Leave a comment

I am really lousy at remembering the past. You know, in the movies, when the police asks “Where were you on April 17th at 5:05 pm” I start thinking that I could not remember where I was yesterday at that time.

Being not good at remembering the past makes me uncomfortable to run Timeline exercise in retrospectives. I feel for those who can write down only two things and I envy those who ask for three extra packs of PostIts to write down their memories. I did not find timelines useful, I did them hastily and could not use the data during rest of the event.

This was bugging me: everyone else was doing timelines and people were happy with those. What’s wrong with me?

Then I got it. Second pass. Walk through the timeline, create collective memory of events.

I tried once more. This time I prepared for an explicit Second Pass.

First, I asked everyone to write notes alone. As usual, after 5 mins that seemed to be done and PostIts were pasted on the wall. Instead asking everyone to walk the timeline alone, I gave more specific instructions: Everyone take few PostIts and a pen, then walk the timeline together and discuss anything you find there. If something new comes to your mind, write a note and paste it on timeline.

Something extraordinary happened. Walking through the project timeline (4 months) took 45 minutes instead the usual 10 min. Lot of new notes appeared on the wall, there was laughter, walking back and forth. And most importantly, people saying “Hey, I think I’m getting somewhere with this“.

I’ve repeated this a few times since, always asking people to walk the timeline together with pen and paper. Often the group needs a little guiding  (“How about moving on, what do we have here next” or “Not so fast, I think we missed something” or kick-starting a quiet group with a provocative question). I am starting to be very happy with this style.

Having people walk together and discuss on the events helps to create shared, collective memory of events. It creates common ground for further discussion and helps to reach consensus later on when team needs to make decisions.


Note: So far I’ve used the explicit Second Pass technique only in (large) project retrospectives. There timeline covers longer period (2-12 months) and all participants don’t work closely together, i.e need for discussion and sharing is bigger. I have not yet checked how this would work in Sprint retro.

Categories: Facilitation, Team work