theory of constraints « Thinking for a Change

Jan

Outliers and raising the capitalisation rate

The Story of Success

Father Christmas brought me a large stack of books. First off is an easy read, the new Malcolm Gladwell book “Outliers: The Story of Success“. In the book, Gladwell tries to dig deep to explain the causes of unusually successful people, the outliers that are so far beyond the statistical norm that they seem magical.

Why do some people become hugely successful corporate lawyers, wealthy captains of industry, billionnaire IT entrepreneurs or hockey stars?

First of all, there’s talent. But talent isn’t enough. It takes effort, practice and hard training to develop that talent. Gladwell states that you need at least 10,000 hours of practice and illustrates the number with examples of The Beatles, Mozart, Bill Gates and Bill Joy.

But talent and practice by themselves are not enough to explain the cases Gladwell examines.

It’s not only who you are, but where you come from

For example, if you look at the month of birth of successful Canadian hockey players, the statistics show that most of them are born in the first months of the year. A few years ago I heard about the study that showed the same weird result for Belgian football players. Coincidence? Fluke? Is there something in the air in those months that gives babies an edge in sports? Gladwell doesn’t think so.

You see, there’s a cutoff date to select promising young players. That date happens to be the end of the year. The children who are born in january are just a few days too young to be eligible, so they have to wait until next year. By then, they are 11 months older than the eligible children born in December. They are stronger, smarter and have had more practice. They are more likely to stand out, get selected and profit from intensive training given to talented children.

A similar case can be made for successful IT entrepreneurs: they were all at the right age and in the right environment to profit from the availability of computer time to develop and apply their skills.

Held back by systemic constraints

In the case of the hockey players, it is likely that children born in December are (on average) as talented and hard working as those born in January. If they don’t get selected, a lot of talent and effort is wasted.

Gladwell calls the rate at which talents make it the “capitalisation rate”. The capitalisation rate for hockey players is lower than it could be. Why? Because of an arbitrary systemic constraint: the decision to select and sign young talents based on one cut off day. This effect is known and repeatable across the world. When the cut off date changes, the distribution of children is changed accordingly. We’ve all been subject to this systemic constraint because schools work with a fixed calendar.

Should we just accept those constraints?

Raising capitalisation rates

If we wish to raise the capitalisation rates, we need to tackle similar systemic constraints. One hopeful chapter describes how a school system improves the results of its pupils. First they notice the systemic constraint:

children from richer backgrounds do better after the summer holiday as they have lots of stimulating activities;
children from poorer backgrounds do worse after the summer holiday as their environment is much less stimulating.

The solution: less vacation and more school. Which also leads to more hours of practice, the second factor of success. Which leads to more opportunities to succeed and provide a stimulating environment to their children.

The chapter about plane crashes is chilling. The chapter contains several transcripts from cockpit conversations right before a crash. One common element comes back: the pilot makes a set of small mistakes and no one dares to speak up.

Some airlines have many more accidents than others. These statistics correlate with the culture of the country of the airline. Geert Hofstede has compiled a set of cultural dimensions for countries. One of the dimensions is “Uncertainty Avoidance”. A high score indicates a culture that doesn’t like ambiguity, relies on procedures and plans and is likely to stick to procedure regardless of circumstance. Another dimension is the “Power Distance Index”: a high score indicates that authority is very respected and a more powerful or knowledgeable person will not be questioned easily.

Do high Uncertainty Avoidance and Power Distance scores correlate with high numbers of airline incidents? Yes. If something goes wrong you want people to speak up and consider alternatives to the routine. Knowing this, training can take into account the differences. For example, techniques to lower the power distance can be taught and applied in the cockpit. Again, dealing with the systemic constraints brings dramatic improvements.

What have we learned today?

I got two lessons out of this book.

First, the capitalisation rate on our teams. It is sometimes said that “Agile only works with really good people and teams”. That’s true. But Agile also makes the people a lot better by providing them with a better environment, support and many learning opportunities. We create communities, conferences and help each other get better. We raise the capitalisation rates within IT. But we can do a lot more if we have the courage to tackle the systemic constraints. For example:

Why are there fewer women than men in IT?
Why is IT seen as a “young man’s game”? Why don’t we value experience more (and keep reinventing yesterday’s mistakes)? Don’t we need to put in our 10,000 hours to become proficient? Well, at least many of us put in many hours in death marches. I don’t know if that’s useful practice, though…
Why the division into “Business” vs “IT”? Aren’t we in this together?
Why the division into development, testing, maintenance, operations? Isn’t it all one value stream?
<your favourite constraint here>.

What small thing can you do to raise the capitalisation rate?

Secondly, Belgium was used as an example of a country with a high “Uncertainty Avoidance” culture. Yeah, we’re great at creating little rules to organise everything. We’re also great at breaking the rules, because they keep us from doing any useful work. But nobody must know we broke the rule, because we’re also a culture with a very high “Power Distance Index”. In this, we’re quite similar to France. Now, that’s not a culture that’s naturally predisposed to accept Agile methods. Except maybe, when they’re introduced top-down and are very structured?

On the other hand, The Netherlands and Scandinavian countries have a much lower Uncertainty Avoidance and Power Distance Index score. One would expect that they would accept Agile methods more easily.

Have a look at the scores for your country. Do they correlate in any way with the success and ease of introducing Agile?

Watch Gladwell present some of the ideas in the book:

Oct

Exploit the workers

Criticize shortcomings at a workplace without fear or hesitation!

Bottlenecks in Paris

This week I was in Paris to host an “I’m not a Bottleneck! I’m a Free Man!” or “A l’aide! Mon Processus m’étrangle!” workshop to help a company to apply the Theory of Constraints.

The workshop is fun and playful. We simulated a team making paper hats and boats. The team got paid in Belgian chocolates. Participants enjoyed learning about The Theory of Constraints. In the retrospective, most participants noted that they liked the relaxed atmosphere, the fun way of learning and the friendly cooperation.

And yet, there were a few moments where the participants felt uncomfortable and voiced their disagreement with the material.

Say NO to the exploitation of bottlenecks!

Step 2 of the “Five Focusing Steps” tells us to exploit the bottleneck. As the throughput of the system is determined by the throughput of the bottleneck, we need to do everything we can to increase the throughput of the bottleneck. We need to get as much value out of the bottleneck as possible.

When I asked the participants how we could exploit the bottleneck in the game, many people bristled at the suggestion. They felt I was trying to ‘squeeze’ the unfortunate worker who was (by design) the bottleneck of the game. To them, this smacked of “Taylorism” or “Fordism“.

It took some convincing and explaining to get the participants to look for ways to exploit their overworked, stressed and sweating colleague. Adding more people seemed like a simpler and more powerful improvement technique.

Go on, exploit the bottleneck! It’s just a game.

Now, what did the team come up with to get more output from the bottleneck? How did we make the bottlenecks in the game and in the real processes more productive?

Ensure that there’s a small buffer of work in front of the bottleneck, so that the bottleneck is never idle due to lack of input. Install a ‘pull’ system so that whatever the bottleneck needs arrives just-in-time when the bottleneck needs it.
Reduce interruptions, so that the bottleneck can stay concentrated on their task and get into the “Flow state“.
Reduce task switching. Finish each task before starting on another. Focus on the task at hand and don’t worry about upcoming tasks.
Prioritise the work to be done by the bottleneck, so that they always work on the task that brings the most value.
Reduce waste in the bottleneck’s work, so that the bottleneck doesn’t spend time on non-value adding work.
Ensure that the inputs and tools of the bottleneck are of the highest quality so that they don’t waste their time finding and correcting errors or dealing with machine breakdowns.
Even out the workload (Heijunka) to combat the waste of unevenness (Mura) and overburdening (Muri)

At the end of the day, each team had several exploitation ideas that they could work out the next day. Exploiting the bottleneck is usually quite easy as it doesn’t require investment and doesn’t involve many people.

And yet, these simple changes can add a lot of value. For example, we recently almost doubled the productivity of a development team by installing some simple measures to reduce interruptions and by prioritising work better so that there was less task switching.

If that’s what “being exploited” means, you can exploit me too!

The result of all that exploiting? A bottleneck that’s less stressed and less overworked and yet has higher productivity. A bottleneck that can concentrate on their job without all those energy-sapping distractions and wastes. In their final retrospective, the team that doubled their productivity noted that this project was a lot less stressful than their usual projects.

Participants in the workshop learned that there are better, easier and cheaper ways to improve processes than to add more people. They learned that “exploiting” in the Theory of Constraints is very beneficial to the bottleneck, despite the negative connotations of the word.

Would a “softer” word have helped? Would another word evoke less resistance? I used to think so. Now, I think that we need to go through that resistance that the word exploit evokes. If we let the participants of the workshop optimise the game’s process on their own, they will probably get no further than throwing more bodies at the problem. The Theory of Constraints is simple, but its consequences are counter-intuitive. By dealing with the resistance to the idea early, participants learn to break through their existing patterns. Having seen Eli Goldratt in action, I appreciate he’s no proponent of the “softly, softly” approach.

And it gets better

After participants have accepted the exploit step, we move on to “Subordinate every other decision to the bottleneck”, which leads to another set of counter-intuitive ideas. For example, the participants learned that they could get more output from their processes by slowing down certain people.

Resistance in Amsterdam

Lean has another set of counter-intuitive yet effective ideas. On Friday, the suggestion that “Standardized Work” could be useful in IT was met with strong resistance by participants of the Agile Holland conference. More about that later.

I’m starting to enjoy resistance. In my experience, resistance from myself and others means that we’re on the right way, that we’re trying to do something different. Because if we want to get a different result, we will have to do something different.

What have you resisted this week? Now imagine that the thing you resist is not your enemy but your friend. What would the world look like if that were true?

You can download the Bottleneck Game from the Agile Coach site.

The “I’m not a Bottleneck! I’m a Free Man!” game by Pascal Van Cauwenberghe and Portia Tung is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.

Image courtesy of ‘Freedom Toast‘, licensed Creative Commons, Attribution Non-Commercial.

Jul

Agile 2008

Agile 2008 is coming near

I’m glad I’m going to Agile 2008 in Toronto this year.

I’m glad Portia and I will present two sessions.

Mirror Mirror

“Mirror, Mirror on the Wall… Why Me? Snow White and the Seven Dwarves Kanban” is a mini-adventure of self-discovery to improve personal effectiveness. Think “Kaizen meets Agile Fairytales.”

Huh? What do a bunch of dwarves and an Evil Queen have to do with Agile? In this session you learn more about yourself, how you see others and how you can improve working with others. You learn to recognize the strengths of each (potential) team member. With the help of fairytale characters, you can create and maintain teams that play to the strengths of their members.

Why is this important? Software development is a team sport. I’ve been on some great teams. I’ve seen aligned teams in sports, theater and IT outperform non-aligned teams by a large margin. These two ingredients, efficient communication and playing to the strengths of members, were vital in each case.

Nine Boxes

“La technique d’interview des Neuf Cases pour mieux comprendre votre client” is a game where participants learn to perform structured interviews. The interview technique comes from the Solution Selling sales process. The Nine Boxes allows you to discover

The real root causes of the problems your customer experiences
Who is affected by the problem and how they are affected
Co-create a vision of the future where the problem is solved

Huh? What does selling have to do with Agile? If we want to lead meaningful lives, we must attack the root causes of our customers’ problems. We must really understand the system. We must make all stakeholders enthusiastic about solving the problem, so that they will help bring about fundamental changes. We must give them back hope.

And then we can start writing user stories… IF AND ONLY IF software will help us to deal with the customer’s bottleneck.

See you there

I’m afraid to get lost in such a big conference, with so many sessions and so many people.

I’m glad I’ll be seeing friends inside and outside the agile world in Toronto.

Jul

Why bother with bottlenecks?

Why?

Bottleneck Game at XP Days London 2005

Portia writes about a participant of our Bottleneck session asking her about the relevance of a session on (industrial or manufacturing) process improvement techniques at an IT conference. Portia already told me she had the same reaction when she attended this session at XP Days London in 2005. If you look carefully, you can see Portia at the right, a bit bored as she’s waiting for the bottleneck.

Moreover, with terms like ‘exploit’ and ‘subordinate’, the 5 focusing steps don’t sound very friendly. Is this just another management fad ‘to squeeze the workers’? Can we apply manufacturing ideas to IT? Isn’t the manufacturing metaphor (or the house building metaphor) responsible for some of the worst ideas in IT?

That participant took the first step in understanding: they asked “Why?”

What is it about?

The session (and the Theory of Constraints) is about creating meaning and value by really understanding systems.

To do this, you need to:

Design systems that fulfill a meaningful goal.
Take a step-by-step approach to diagnose problems.
Find real cures by going beyond your area of responsibility, beyond your comfort zone and considering the system as a whole.
Involve everybody, to continuously challenge assumptions and long-standing traditions to create lasting improvements.

These are things I use every day in my life and my work. Are these things you could use in your work, in your life, every day?

Thank you to Portia for excellent writing advice and helping to edit this entry.

Jul

Les goulots d’étranglement pt. 3

Université du SI day 2: Heroes

We start the day with a refreshing run up the Champs Elysées, down to the Eiffel tower and along the Seine. I’ve been looking forward to this day: I will meet two of my heroes!

Eli Goldratt challenges us throughout the whole keynote. Do we want an easy life or a meaningful life? We have in our hands the most powerful tool that has ever been invented and what have we done with it? Have we brought enormous value to companies and people? We haven’t: we’ve automated the same old processes; we’ve looked no further than local optima; we’ve enabled people to perform useless work faster than ever before. Is that all we want to achieve?

What is the greatest challenge businesses face? The ability to take the right decisions at the right time. IT is the ideal tool to support that decision-making, at all levels of the company: we can store, transfer and manipulate prodigious amounts of data almost instantly. We can provide the Information people need to make decisions. We can create an enormous amount of value, but by all accounts (sic) we haven’t.

Why haven’t we fulfilled the promise of IT? The tools are out there: Theory of Constraints, Lean, the Thinking Processes, Agile… Most of them readily available and only a few clicks away. Why haven’t we used those tools? One of the reasons is that we would have to step out of our comfort zone. We need to stop dabbling with technology and look further, to accounting, sales, marketing and production. We need to see the whole system and realize its goal. Do we want an easy life or a meaningful life? Do we want to ‘fulfill requirements’ or do we want to add value? Who dares to enter into a contract with a customer where payment depends on value added?

Where are the real constraints?

The real constraints are in (implicit) rules. Who has the intelligence to recognize those rules and the guts to challenge them? Common Action (“that’s how we’ve always done it”) is not the same as common sense. Accounting rules and the way we measure are some of the most pernicious constraints. We have the tools and the obligation to change the system, to enable our companies and people to realize their full potential.

People do not resist change, according to Goldratt. People resist changes that are unclear, that threaten them, that might harm them or that bring no clear value to them. Resistance is your cue to realize that your proposal is not fully worked out and that your explanation is not clear.

Goldratt’s call to arms can be summarized as: “Get of your asses and start using your brains!” I thought this was an excellent, inspiring and thought-provoking keynote. I left the auditorium with a renewed resolve to create meaning and value.

Lean

We participated in an excellent exercise led by Olivier Pizzato and Christian Daniel about using Lean techniques to solve IT project challenges. We worked in small groups on different scenarios. For each scenario we defined three approaches to solve the problem; listed the three biggest obstacles/objections to the most promising approach; searched for a way to overcome the biggest obstacle. After a group presented their analysis, Christian linked the solution back to Lean principles and techniques.

What I like about the session are the exercises and the short (15 min) timeboxes. To make this session perfect I would provide participants with more structure and guidance about Lean, so that they can apply the techniques to the exercises.

We attend part of the session about how Google will revolutionize the development of IT systems. Bernard Notarianni and Didier Girard pair-presented the session in a very relaxed style. Portia thought it looked like a French game show. The session gave examples of web design principles that can be applied to internal IT systems. The resulting systems, often using a RESTful style, are simple and easy to integrate. We had to leave before the end to prepare for our next run of the Bottleneck Game.

Goulots d’étranglement, take three

After Goldratt’s keynote interest for our session is very high, the room is packed full. Seven volunteers come forward to play the role of the “workers”; the other participants are the “consultants” who observe and give improvement tips to the workers. They all get paid in Belgian chocolates and British sweets.

After one round of play we go through the “5 focusing steps”:

0. Define the goal of the system
1. Find the bottleneck
2. Exploit the bottleneck, get the most value out of the constrained resource
3. Subordinate all decisions to the bottleneck
4. Elevate the bottleneck when it has been exploited fully and all decisions have been subordinated
5. GOTO 0. Don’t let inertia become the constraint

The team makes some improvements to their process and plays a second round. The decision to subordinate to the bottleneck wasn’t fully implemented. The team had planned to put a buffer of work in progress before the bottleneck. They failed to keep it filled, which led to an idle bottleneck and reduced output of the system. The players used their idle time to ‘learn’ so that they could help the bottleneck in the next round.

Changing the system, breaking through constraints

Warning: don’t read this section if you want to play the game with an open mind!

The game is filled with arbitrary constraints:

players are very specialized and can’t help each other
the two customer representatives sit far apart
the layout of the table makes it difficult to get an overview and to communicate with the other team members
testing is done at the end. Nobody but the tester knows the acceptance tests

In the third round we make the players think about the assumptions and rules built into the game. They get to change their system. The most powerful thing they can do is to re-arrange the tables. As you can see in the picture, the team has a better oversight and can communicate more easily when they sit around the tables.

In the end, this team didn’t produce as much as the previous team on the first day of the Université du SI. I think this is because this team tried to be too sophisticated. Instead of simply implementing an optimisation as agreed, they kept discussing and tweaking their way of working. The DO part of Plan-Do-Check-Act shouldn’t be skipped.

Running this session in 90 minutes is exhausting. Time for a break before the closing keynote.

Man from the moon

OCTO brought Neil Armstrong to Paris for the closing keynote. As a little kid I read a lot of science fiction, fascinated by the tales of wonder and limitless possibilities. I devoured everything about the “Space Race”. These people were making science fiction a reality. By the time I was old enough to understand what was happening, the space race was already over; interest for space exploration was gone. We had stopped looking outward.

Armstrong’s keynote was humorous, enthralling and humble. These teams achieved wonders with the technology of that day (e.g. on-board computers with a few K of memory) and took enormous risks. The American and Russian space programs are a testament to what we can achieve if we really set our mind to it.

I was thoroughly inspired by these two keynotes by my heroes. Armstrong showed us what we can achieve; Goldratt exhorted us to achieve our potential, starting NOW.

The end. Or the beginning?

The conference is over. Our visit to Paris is over. Thank you to Octo for organizing this conference and for inviting Portia and me. We left Paris buzzing with ideas and energy.

Thinking for a Change

Categories

Blogroll