Nemawashi – Decisions by consensus without compromise

Decisions by consensus


One of the Toyota Way principles is « Nemawashi », take decisions by consensus.

Building consensus is a slow process, but it’s necessary to get everybody on board before taking a decision. Otherwise, the implementation will be delayed and (unconsciously) sabotaged by those who didn’t agree or weren’t involved.

It’s not just about building support for your ideas. The consensus-building process solicits ideas and review from everyone involved so that the final idea is usually a lot stronger than the original.

But there’s one big misunderstanding about consensus.

Consensus doesn’t require Compromise

It’s tempting to dilute our idea to reach consensus, ensure that everyone gets a bit of what they want, so that they’ll agree to go along.

It doesn’t have to be this way. In “Extreme Toyota” the authors show how Toyota embraces conflicts and doesn’t settle for compromises. They identify six contradictions that are central to Toyota’s way of working:

  • Moving gradually and taking big leaps
  • Cultivating frugality while spending huge sums
  • Operating efficiently as well as redundantly
  • Cultivating stability and a paranoid mindset
  • Respecting bureaucratic hierarchy and allowing freedom to dissent
  • Maintaining simplified and complex communication

“This AND that” sounds better than “This OVER that”… I want to have my cake and eat it too 😉

Enter the business consultants

A few years ago I worked on a project that automated the whole value stream of a business unit. The main challenge was that the different departments had conflicting needs. No surprise there.

One of the conflicts was between the production department that did the work on customer demand and the sales department that sold contracts for doing the work to the customer . The production department needed standardised products with little variation so that they could work efficiently, predictably and hit their Service Level Agreements; the sales team needed customised products so that they could tailor their offering precisely to what the customer needed.

This is a classical conflict. The business consultants on the project called this “Operational Excellence” versus “Customer Intimacy“. And the consultants said we had to choose. It’s one or the other, you can’t have both. It’s like Henry Ford’s saying: “You can have any color car, as long as that color is black.”

Examining the conflictThe Logical Thinking Processes

It’s clear, you can’t have both standardised and customised at the same time. There’s a clear conflict. But we have a tool to deal with conflicts: the Conflict Resolution Diagram. Let’s apply the tool:

Product Variability CRD
The diagram says:

  • To have a growing, profitable business unit (A) we need to sell what the customer needs (C) and deliver it reliably and cheaply (B).
  • To produce reliably, predictably at low cost and to hit the Service Level Agreements (B) we need products with little variety (D).
  • To create an offer that responds to the customer’s need and to grow our market (C) we need to vary our products per customer (D’).
  • Conflict: we can’t have little variation (D) and a lot of variation (D’) at the same time, but we need both.

Questioning assumptions

We deal with the conflict by questioning the underlying assumptions. Can we find fault with our logic? Bill Dettmer recommends to restate the relationships in “extreme wording”. For example:

  • There’s absolutely no way to have both low and high variability at the same time! Well, duh!
  • The only way to be profitable and reliable is to have low variability! Well, it was hard to fault this reasoning as this company operated on large volumes with low margins and tight competition.
  • Customers always need special cases! Not always, but customers were no longer satisfied with one-size-fits-all offers. If this company couldn’t offer customised products, the competitors would be more than willing to get a new customer.
  • We could have low variability and yet vary per customer if only we didn’t have so many customers! Going niche wasn’t an option for economical and legal reasons.

We looked at it every way possible and couldn’t find a fault with the reasoning until…

Finally, some clarity

The Logical Thinking Processes have a set of “Legitimate Reservations”, a set of critical questions we should ask. The first one is simply called “Clarity“: is the meaning of every word and sentence clear to everybody?

Now, we had already noticed that the different departments seemed to have different definitions for the same word. There were even differences in the way they described the different products to us. Were we talking about the same thing?

The breakthrough came when we asked “What do you mean by ‘Product’?” A product for the Production department wasn’t the same thing as a product for the Sales department. And the accounting & finance department had another definition of product. But… That’s not a bug; it’s a feature: if a Production-Product is different from a Sales-Product, can we have Production-Products with low variation and Sales-Products with high variation?

After a lot more work we came up with a way to standardise Production-Products on a small set of “building blocks” and let Sales create Sales-Products by mixing and matching the building blocks according to customer need. Then we mapped Production-Products onto Accounting-Products. And everybody got what they wanted: Operational Excellence AND Customer Intimacy.

Embrace conflict

We didn’t settle for a compromise, but spent the time to really think through our conflicts and come up with a solution that satisfied all needs. A conflict can be an opportunity to come up with an innovative solution.

You don’t have to settle for compromises if you think about it.

Picture of Bonsai by A. Marques. Thank you.


Real Options – One question

How do you see the future?

Like this?

Future 1

Like this?

Future 2

Like this?

Future 3

How would you like to see the future? You can choose.

Freedom Evolves


Who’s afraid of estimating?

Embarassing moment #239: Turning up late to teach an estimating and planning course.

Hurry! Hurry! I'll be late!Danger: Estimator at work!

Estimation is (sometimes) useful, but it has its dangers. Estimation provides us with useful information, to base management decision on. This information and the way we get it can be misused. Maybe that’s why so many people are so afraid of estimating and look for ways of avoiding it.

What are some of the problems?

Appearing too certain

We all feel uncertain when we have to estimate something, so how can we appear too certain?

If I ask you to estimate how long something will take, what do you answer? If you give me one number, my immediate reaction will be “Wrong!” If I think about it, I will ask you “Are you certain? Which factors influence that estimate?

A number is always the wrong answer to any estimation question. Are you so certain that this work will take exactly so long? What about all risks and the myriad variables that influence that work? How much do you know about the customer, the project, the team, the technology. Admit it, at the start of the project you don’t know a lot.

Cone of uncertainty

The “Cone of Uncertainty” show us how the uncertainty range of estimations changes as we learn more. It teaches us to always quote a range when we’re asked to estimate. The more uncertainty, the larger the difference between low and high estimate. That’s the good news. The bad news:

  • These Cone of Uncertainty ranges are best case values. The two lines show how badly good estimators can estimate. The shaded area shows how the ranges converge for bad estimators.
  • The X axis isn’t time. Your estimates don’t improve with time, they improve with information, knowledge and experience. The X axis should display your level of knowledge.
  • The cone isn’t symmetrical. Most of us tend to underestimate the amount of work required.
  • For some reason, we tend to use ranges that are too small to adequately cover the uncertainty, even when nobody pressures us to do so.

For estimation purposes, remember these two definitions:

  • Accuracy: how close to the real value a number is. “I estimate this blog entry will take me between 2 and 4 hours to write.” Not bad: it actually took me a bit more than 3:30 (based on the timestamps of the edits).
  • Precision: how exact a number is, independently of its meaning. “I estimate this blog entry will take me 4 hours, 45 minutes, 23 seconds and 860 milliseconds to write.Wrong! And I don’t need to know about seconds and milliseconds!

Mistaking estimation and commitment

We don’t need a range, we need one number, one date, one deadline to communicate with other parties!” Right, but that’s not an estimate, that’s a commitment.

Given that we estimate the product to be delivered between D1 and D2, which delivery date do we commit to when we talk to our customer? That’s a management and commercial decision, based on the confidence we have in the estimate, commercial pressure, deadlines, how much risk we want to take, the cost of failing to deliver as committed…

Developer: This project will take between X and Y days to complete.
Salesperson: I sold the project based on 2/3 of that number of days. You’re responsible if we don’t deliver in time.
Developer: I think that’s your responsibility. We’ll deliver the project as fast as we can, but we can’t guarantee it’ll take less than Y days.

Spending too much time estimating

Estimating takes time and we want to get that estimate just right, because we’re afraid of what might happen when we get it wrong. So we do some more investigation, another spike, try another estimation method… In the limit, we could just do the project, that would give us a perfect estimate.

Estimates are information to base management decisions on. What kind of decision? Depending on the type of decision, we need more or less accuracy, we need to spend more or less time. In any case, estimating shouldn’t take more than a few percent of the team’s time.

Manager: I want to know how long <some project> will take. Give me an estimate.
Developer 1: Yes boss! I’ll get right to it!
Developer 2: What kind of estimate do you need? What’s the required accuracy? What information do you have? How much time can we afford to spend on this?

Not looking at the big picture

Many tutorials on estimating give the advice to break down the work in small bits and then estimate those. The advice isn’t bad because, as we’ll see later, having an estimate based on estimates of smaller pieces improves our accuracy. But breaking down the work in too small pieces has a lot of drawbacks:

  • All that breaking down takes a lot of work and then you have to manage all these small pieces. If you do this too soon, you’ll have the wrong pieces anyway and you’ll have to carry them along until you discover they’re wrong.
  • You could break down the work below that which can be usefully validated with acceptance tests. I tend to avoid estimating tasks, because there’s often no clear and independent way to verify that the task has really been done. What’s the use of estimating something nobody’s waiting for? I prefer to estimate deliverables and user stories where a “customer” can meaningfully say “This is (not) done.”
  • Nobody wants to know when a specific story will be done. We want to know when a Minimal Marketable Feature will be done, when the release will be ready, when the deliverable is ready to hand over to another team. If we break down the work too far, we’ll waste time tracking that detail and lose sight of the real goal. If we keep looking at the big picture, the law of large numbers will work to our advantage.

Destructive negotiations

Developer: We estimate the project will take between X and Y days to complete.
Manager: That’s too long! Your estimates are wrong! Redo the estimation and don’t come back until they’re right!

Those who estimate are often faced with people who are a lot better negotiators than they are: managers and salespeople. Moreover, the estimates are often based on quicksand and the estimators have a poor track record, so there are few facts that can be used in the negotiation. The only way to win this game is not to play: estimates are not negotiable. Project contents are negotiable, approaches are negotiable, resources are negotiable, commitments are negotiable. Estimates aren’t negotiable, but up for review and improvement when we get new information.

Developer: I understand that we need to make a commitment that’s earlier than the worst case estimate. Can we have a look at the project to see if there’s a way to change it so that we can deliver upon that commitment?

Playing with models

Some estimation techniques are based on models with several variables. For example, we could have some parameters that increase the estimate if we work with an inexperienced team, new technology or in a new domain.

On the one hand, the models and their variables allow us to tune the estimation methods and be aware of the many variables that influence our projects. On the other hand, these variables can be manipulated to come closer to an expected outcome. Because the number “came out of the model”, they gain undeserved authority.

Project Manager: The model predicts this project will take between X and Y days.
Manager: Can I have a look at your assumptions? Why do you rate your team as “Inexperienced”? Those guys we brought in last month are very experienced! Let’s change that parameter. And why do you say that this is new technology? Surely, web applications are almost the same as the mainframe applications we usually make? A consultant told me so. Let’s change that parameter. Ah! The estimate looks a lot better. Still  a bit on the high side, though.
Project Manager: … (Stunned silence. Thinks: I still have Y days to get out before the shit hits the fan. Those estimates are really useful.)

We also play with Mental Models, models of how others will act. For example:

Manager: I always halve the developers’ estimate, because I’ve noticed a tendency to pad their estimates and then I get blamed because we’re outbid by our competitors.
Developer: I’ll best increase the estimate, because our manager has this tendency to cut our estimates and then we get blamed if we don’t deliver in time.

Where do these mental models come from? Probably from some small dysfunction a long time ago which has grown into a serious vicious cycle. And we’d best not talk about these mental models, because that might cause all sorts of nasty conflicts!

Corporate amnesia

Once a late project is (finally!) done, the team is disbanded and everybody tries to forget this awful experience, the death marches to reach impossible deadlines, the daily re-estimations, the frayed tempers and the shortcuts that will haunt the maintenance programmers.

And then another project comes along that’s quite similar. So, we estimate by analogy: if our project is similar, the effort required should be quite similar. But nobody knows (or wants to admit they know) how much effort the project actually took. We use the original, documented estimate as our estimation basis. Result: another late project, by design.

Developer: Wow, this estimate with your new estimating technique is too high! We can’t present these estimates to our management!
Estimator: Why not?
Developer: They’ll never believe these estimates. Previous’ projects estimates are much lower.
Estimator: And did you deliver these projects as planned?
Developer: No. Never.
Estimator: And then what happened?
Developer: We just continued developing until it was done.
Estimator: I wonder why your estimates aren’t believed…

Is it all bad news?

With all of these dangers, it’s a wonder that any project actually delivers as planned.

If you have anything to do with estimations (either as a consumer or producer of estimates), read Software Estimation: Demystifying the Black Art. It not only contains the bad news, but also very practical advice on how to deal with it and become a more successful estimator.

There are ways to become better at estimating. But that’s the topic of a future entry.


Les cinq premiers pas pour devenir vraiment agile

Les cinq premiers pas…

Aujourd’hui, Portia et moi présentons une nouvelle session, “Les cinq premiers pas pour devenir agile” au XP Day Suisse à Geneve. C’est une présentation courte et interactive (les participants jouent 5 jeux) qui introduit cinq “outils” que nous utilisons quand nous commencons à travailler avec une équipe.

Plus de nouvelles après le congrès.

Cinq outils… et plus

Si vous voulez apprendre ces cinq outils et plein d’autres pour aider votre équipe a réaliser plus de résultats, devenir plus agile et s’amuser plus, la formation “Agile en Pratique” de Zenika est toute faite pour vous.

Vous aimeriez appliquer les méthodes agiles. Comment les appliquer dans votre équipe, sur votre projet ? Comment faire la transition vers les méthodes agiles? Cette formation répond à toutes ces questions. A travers des exercices, des jeux et des simulations vous expérimenterez les techniques agiles. Vous saurez comment, pourquoi et quand les appliquer afin d’améliorer la qualité du résultat et du travail de votre équipe.

Rendez-vous les 21 et 22 Avril à Paris!

The five first steps to become really agile

Portia and I present the “Five first steps to become really agile” at the Swiss XP Day. This new session presents five simple “tools” that we use when we start to work with a new team.

This is the first session that we developed first in french. We’ll translate it in English and do a tryout soon. Then we’ll publish the session on our Agile Coach site with the other games we’ve made.

More about the session when it’s published.


Book Club

Starting up a book reading group

J., the manager of the Financial systems IT department, came to me for advice. He wanted to expand his developers’ knowledge and responsibilities. He wanted them to grow beyond pure development: to get more involved in architecture and analysis, interact with customers… We looked at several options and finally decided to start up a book reading group.

In a book reading group, a number of people get together to read and discuss a chosen book. To set up a book reading group:

  • Invite participants. Participation isn’t mandatory.
  • Select a book that interests the participants.
  • Get enough copies of the book, so that everyone can choose when to read.
  • Define a suitable reading pace. For example one chapter per week. Keep the iterations short.
  • Agree on a fixed meeting schedule, time and place to discuss the book. The discussion is often scheduled during a lunch break, with lunch provided by the company.
  • Moderate the discussion and record the main insights, so that there’s an output and those who miss a session can catch up.

The quiet team

There was something unusual about this team. They were so… quiet. You probably don’t want your accounting, invoicing and ERP systems maintained by a bunch of party animals, but still. These developers rarely talked to each other, they all worked individually on their own part of the systems. I was a bit worried: would they come to the discussion meetings? Would they say something?

What would be a useful book for this team? They all had different backgrounds, worked on different applications and used different technologies. I proposed we should start with something that would be useful as a basis for further study. We chose “Quality Management I: Systems Thinking” by Gerald Weinberg. I’ve found Systems Thinking to be a useful tool to make sense of a lot of situations, but would the team find it interesting? Would a book about “management” be useful for developers? The manager and I decided it was worth the risk.

We’ve noticed that some people will find or create the time to read books to learn more, but they are the exception rather than the rule. Many people are so busy at work that they don’t have the time to read books. Reading a book isn’t “work”. And the principle of “sustainable pace” surely means you shouldn’t be spending time reading work-related stuff outside of work.

The reading group has a number of advantages:

  • Reading becomes part of “work”.
  • Peer-pressure and the short timeboxes ensure that participants create the time to read one chapter every week.
  • The discussion sessions ensure that participants read more attentively and hear how others interpret the material.
  • The discussion regularly leads to ideas for improvement actions or people getting together to try out some new idea.
  • Reading the book together improves team cohesion and (cross-)team communication. Even if participants work on different applications or work in different teams, they’re doing something together and realise that they face the same issues.
  • A reading group reveals strengths, weaknesses and skills in individuals you wouldn’t usually notice about one another working together day-to-day. This discovery could lead to increased appreciation among team members which, in turn, leads to increased respect.

Group learning

The first couple of sessions required a lot of facilitation to get participants to speak up and give their opinion. The participants didn’t see the relevance of systems thinking. And why were we reading a book about management? They weren’t managers. They were developers.

Luckily, they kept coming to the book group, they didn’t give up. Gradually, they started to speak up more; discussions started; they debated different viewpoints. They started to see things in their environment, things that had always been there. But now they saw the world with different eyes. They started to see the connections between things. They started to understand why things happened as they did. They started to realise how they could influence their environment. They started to generate ideas to improve the way they worked. The group required less and less facilitation: two participants emerged as leaders, they kept things going. I didn’t have to say anything; I just acted as their scribe. The team was no longer quiet; they were full of energy and ideas.

When starting up a reading group:

  • Ensure that there’s enough support and encouragement from the coach, a manager or some team members to get the group going. The first two chapters of a book are often not very exciting; the group needs to get to know each other and the format.
  • Small signs of company support like paying for the books, providing a place to meet and buying lunch shows participants that they and their growth are taken seriously.
  • Provide facilitation to get the discussion going and to keep the meeting on track. As the group gets more experience and self-organises, they will require less facilitation.
  • Take notes and publish them so that those who weren’t present can see the outcome. Publishing an output raises the importance of the meeting.
  • Ensure that the book is relevant to the work of the team. Let the team describe what they want to learn. The coach should have enough experience to suggest books that fulfil the requirements of the team.
  • As with iterations, a regular pace with short iterations is crucial. We recommend weekly sessions, to discuss one or two chapters.
  • Ensure you always meet in the same room at the same time. Don’t reschedule the book group meetings because someone can’t attend. They can always catch up.
  • In a larger or more heterogeneous team you can create two groups who read a different book. Discussing the two books together gives everyone some insight into both books. Maybe the participants will find interesting links or contradictions between both books.
  • Try to find books that contain questions or exercises for the reader. Participants must answer one question or perform one exercise per chapter. The group facilitator can set up questions or exercises for the group.
  • If participants are uncomfortable during discussions, the facilitator can use techniques like a clustering exercise to elicit everyone’s input.
  • The discussion will often result in ideas for improvement and action. Handle these like you would at a retrospective: prioritise them by value and include them as part of the team’s delivery iteration.