theory of constraints « Thinking for a Change

Jun

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 conflict

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:

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.

Apr

The Theory of Constraints’ “Five Focusing Steps” in action

Where do we intervene and what do we do?

When we first start to improve processes, the situation is daunting: we can see so much that can be improved. Where do we start? What will have the biggest effect? And when we’ve done that, what do we do next?

The “Theory of Constraints” gives us a simple and powerful framework to guide our process improvement: “The Five Focusing Steps”.

Step 0: What is the goal?

The first and most difficult step is to determine (and agree on) the goal of the “System”.

Before we can do that we must determine what the System is. As a rule of thumb the System equals the “Sphere of Influence” of our Client: everything that our Client has the authority change.

To determine the goal of the System, we must ask ourselves “Who uses the results the output of the System and what do they value?”. We try to find metrics that measure the amount of valuable output we produce. The Theory of Constraints calls this the “Throughput” of the System.

On the “B” project, our goal was to release valuable features that were actively used by our users. Our measurement was the “Business Value” estimate that our onsite customer put on each User Story.

What is your system? What is its goal?

Step 1: Where is the bottleneck?

The fundamental insight of the Theory of Constraints is this: “the output of any system is determined by one bottleneck.” A chain is as strong as its weakest link. If we want to make the chain stronger, we need to work on the weakest link.

At the start of an improvement process, the bottleneck is easy to spot. A bottleneck resource is:

Always busy. But busyness isn’t the only (or even a good) criterion by which to recognise bottlenecks. Many systems are mistakenly optimised to get high utilisation (or rather busyness) out of all resources.
Work piles up in front of them.
Downstream resources are regularly idle.

The development team was the bottleneck. We had a list of features that was piling up in front of us. It would take us several releases to implement our backlog. Users were getting impatient for features to be implemented and deployed.

Where is your bottleneck?

Step 2: Exploit the bottleneck

If the output of the system is constrained by the output of the bottleneck, we must first try to increase the output of the bottleneck. Any idle time of the bottleneck reduces output of the system. What can we do?

Remove any non-value adding work.
Remove or limit interruptions. Remove impediments.
Let the bottleneck resource work at a steady pace.
Provide high quality tools and materials.
Carefully prioritise the bottleneck’s work so that they always work on the most important tasks.
Ensure that there’s always enough work to do for the team (the backlog), so that they don’t become idle through lack of input.

As team lead, I received and prioritised all incoming requests and questions. As I could deal with most of them, the team wasn’t interrupted.

Production issues needed to be handled quickly. All issues were handled by me and one developer. The bugfixer role rotated after every bug. This provided a nice balance between keeping the team focused on developing the current iteration and ‘feeling the pain’ of production issues.

I made sure that everyone worked at a sustainable pace. No more overtime!

Warning: don’t shield the team from useful information like input from the customer, production issues, installations and feedback from users.

We start by fully exploiting the bottleneck because this type of improvement is relatively easy:

It requires no extra cost or investment.
Only one resource is involved.

How can you exploit your bottleneck?

Step 3: Subordinate every other decision to the bottleneck

When we’ve fully exploited the bottleneck, we must subordinate every other decision to our decision to exploit the bottleneck. All the resources that aren’t bottlenecks have, by definition, some slack. Use that slack to support the bottleneck. We can subordinate by:

Letting the non-bottlenecks help the bottleneck or take over some required but low value adding work.
Everybody works at the pace of the bottleneck, no faster no slower, to avoid overloading the bottleneck with work in progress.
Those in front of the bottleneck ensure that the buffer of work for the bottleneck is always filled, but not too much.
Those after the bottleneck ensure that they have some slack to deal with variations in output of the bottleneck.
Non-bottlenecks ensure that only high quality work in progress handed to the bottleneck.

As team lead, I subordinated all my work to the team: whenever there was a request for the team, a production issue or an impediment, I dropped all my work and supported the team. I quickly learned that I shouldn’t commit to delivering stories. My contribution to the team was less in contributing to its throughput and more in protecting the throughput of the rest of the team.

The onsite customer performed acceptance testing on completed stories every week, so that the developers got rapid feedback on the quality and fit of their development.

The onsite customer and I prepared stories for the next iteration and release, so that the team always had something to work on.

Subordinating is still relatively easy:

It requires no extra cost or investment.
Only a few resources, typically those that interact directly with the bottleneck, are involved.

However, there is one aspect of subordinating that won’t be accepted easily: whereas the bottleneck resources should be fully loaded, non-bottleneck resources must have slack time to be able to support the bottleneck and deal with variations. Most managers are evaluated on the efficiency and not the effectiveness of their people. Deliberately making people work below their capacity goes against their goals. We can solve this problem by fully loading the non-bottlenecks but ensuring that a part of their work is ‘discardable’, “nice if it gets done, but not essential or time-critical”. Whenever the non-bottlenecks need to support the bottleneck, they can drop the non-essential work to free up time.

Which decisions do you need to subordinate to the bottleneck?

Step 4: Elevate the bottleneck

This is the step most people will intuitively apply first: add more people, more machines, more training, more tools, more of everything. We only take this step when all the ‘free’ improvements have been performed. We can elevate by:

Adding more people or machines
Training and mentoring
Better tools, faster machines
Switching to a different technology

My manager asked me about every week if I wanted some more developers, if I “wanted to elevate my team by adding more people”. I declined, because we had plenty of room for improvement left with exploit and subordinate improvements. I asked if we could get faster computers instead. He told me we couldn’t because the hardware budget was exhausted. But there was budget for extra developers if I needed any…

Elevation improvements are more difficult because they require an investment. Elevation improvements are dangerous because most of these improvements take some time to produce results. Results might even worsen until the improvements start to have a positive effect. For example, when we add people to a team we lower the team’s velocity and accept less work while the team members help the newcomer get up to speed.

Don’t elevate yet. I know you can apply so many more exploit and subordinate improvements. 🙂

Step 5: And again!

When we’ve applied one improvement and have seen a positive effect, we go back to the beginning:

Is our goal still valid? Is our measurement of throughput still correct?
Where’s the bottleneck? After some improvements we may have solved our worst problem. As there’s always a bottleneck, our second-worst problem gets a promotion. We now need to focus our attention on the new bottleneck.

And the result was…

The team got better and better by repeatedly going through the five focusing steps. After a while, they started to develop stories faster than customers could write them. That’s when we needed to apply focusing steps six and seven.

I want to know more

Read the Goldratt books about the Theory of Constraints.

Download and play the “I’m not a Bottleneck! I’m a free man!” simulation from http://www.agilecoach.net

Read more about the Theory of Constraints on this blog.

Apr

New Agile Coach site online

Do you want to play?

Portia, Vera and I have published a new version of the Agile Coach website. There you’ll find coaching tools we use like games, tutorials and presentations. Topics range from introductions to Agile (the XP Game, the Business Value Game, XP Loops, First Five Steps to Become Really Agile), Theory of Constraints, Real Options, Toyota Way, Interviewing techniques to Agile Fairytales.

More materials and translations will be added. All of these games are licensed “Creative Commons“, so that you can use and reuse them. If you want to help translate or improve the games, let us know.

We run retrospectives after each session so that we can improve. You can read the results of the retrospectives on the Past Events page. This transparency allows you to verify if we really take the feedback into account.

Come and play at XP Days

If you want to play the “Business Value Game” or “Mirror, Mirror on the Wall… Why Me?” come and see us at the Mini XP Day Benelux in Mechelen, Belgium (May 11th) or XP Days France in Paris, France (May 25-26th). Or invite us to come and play in your company or usergroup. Or better yet, download the games and play them yourself.

Feb

Beyond Jidoka – Poka-Yoke

Do you want to improve your productivity?

There’s a very simple way to improve productivity.

How much time do you spend on “bugs”? Finding them, analysing them, fixing them and making sure they don’t reappear. Not to forget the time spent writing the bug.

Imagine how much time you could save if you stopped writing bugs.

How do you write bug-free software? It’s simple.

Jidoka is not enough

Great, you’ve implemented Jidoka. Your systems and people find issues quickly. Your team responds quickly to resolve any issue raised. You even improve your tests whenever another issue slips through.

You’re well on your way to deliver quality quickly. But there’s something missing.

Poka-Yoke

Poka Yoke is the practice of “mistake-proofing” work. It’s another principle from the Toyota Production System. Poka-Yoke mechanisms ensure that the user or operator can’t make a mistake. For example a plug that can only be inserted correctly (like the 3 pin UK plug) or can be inserted in two ways that are both correct (like a 2 pin plug).

Poka Yoke is not Baka-Yoke or “fool-proofing”. The goal is not to prevent idiots from doing the wrong thing, but to make intelligent people do the right thing.

Poka-Yoke software

We can Poka-Yoke software if we really think about it.

In one case, a web application didn’t work because of an incorrect configuration parameter. Two tools each required a configuration setting. The two settings had to correspond. One configuration, created by the developers, contained ‘G004’. The other configuration, maintained by the sysadmin, contained ‘GOO4’. Can you spot the mistake?

Once we found it, the issue was easy to fix. How could we avoid it? Some thinking and experimenting showed that there was a way we could reduce the configuration to one setting, even with the existing tools. This type of error couldn’t happen again.

Thank you for reporting this error. Finding and resolving issues is a great trigger to add some Poka-Yoke.

It doesn’t have to stop here. Why wasn’t the mistake found sooner? Because this feature was only fully tested in the acceptance environment and the configuration error happened only in the production environment. Why wasn’t it tested in production? Because testing that part of the application could show confidential customer information. Next time, we’ll get someone who’s allowed to see the confidential information to test that part of the application in production. Poka-Yoke the software is the first step. Poka-Yoke the software process is the next step.

I had finished implementing this class. I just needed to add a comment to explain how to use the class. First, you had to call the methods A, B or C. Then, you could call methods X, Y or Z.

This class was very error-prone. Why not write a class with methods A, B and C? These methods return an object of a class that implements X, Y and Z. You can’t call the methods in the wrong order.

If I feel the urge to document, I stop and think. Isn’t there a way I could simplify? Isn’t there a way to change the system so that errors are impossible? The pay-off is clear: less time to document, more time to code.

Poka-Yoke is an ongoing process. It isn’t done until the system is so easy to use it doesn’t require a manual or training. It isn’t done until all testers have become specifiers instead of verifiers.

Doesn’t this take a lot of time?

Yes it does.

But imagine you only had half the issues you have now. How much time would you save? Now invest that time in finding root causes and making your work Poka-Yoke.

It’s simple. But not easy.

Jan

Bateaux, chapeaux et chocolats

I’m not a Bottleneck in French

Bruno Orsier describes (in French) how he has run the “I’m not a Bottleneck! I’m a free man!” game. He felt a bit uncomfortable to let his colleagues experience Lean and the Theory of Constraints with such a “silly” game: folding paper boats and hats to earn chocolates. Nevertheless, the session was a great success and he sees how the Theory of Constraints tools can be used in his retrospectives.

He follows up with another blog post about the metrics underlying the game. He applies the Throughput Accounting techniques to compute the ROI in chocolates.

Bruno reflects on the game and wonders about the role of the “Production” player: they redo the test work of the tester and count the number of pairs of hats and boats (throughput). The documentation is not completely clear on the subject. A similar question arose in a previous workshop, but this time about the “Requirements” role. The player in that role didn’t really feel part of the process, as they just hand out pieces of paper and count the pieces of paper (investment).

These two players are supposed to represent the customer. They are at the start and the end of the process, where investment and throughput are measured. They don’t really participate in the process, but they track its progress. The “Production” player tests the output like a customer would acceptance test the output of their supplier. During most of the simulation they don’t have a lot to do. How could they make themselves useful?

Don’t read on if you don’t want to spoil playing the game….

Involving the customer

How could you involve the customer more? Here are a few ways to do it in the game:

Unite the two customer representatives, one who defines the requirements and the other who performs acceptance testing.
The customer representative(s) examines the process and offers improvement ideas. The other players are much too busy to see anything but their own work.
The customer representative can be involved in the work, for example by helping with quality control. I usually add a few poorly cut sheets of paper to the stack of folding paper. The customer can help their team by performing quality control on the paper, rejecting any bad raw material.
If the quality that comes out of the team is very high, the customer has more confidence and needs to do less testing, leaving them more time to do more interesting and value-adding work.

How do you involve your customer in your work?

Thinking for a Change

Categories

Blogroll