Tempo 2.0 - Chapter 3: Your company is a system and section 3.1: The Monty Hall Problem

To manage a system effectively, you might focus on the interactions of the parts rather than their behavior taken separately.

— Dr. Russel Ackoff

Companies and other organizations are systems. All systems have some properties in common. As you will soon see, these properties can be counter-intuitive. If we rely only on intuition, we will make the wrong decision, even when we have all the information we need to make better ones.

The Monty Hall problem

We are used to solve problems through analysis. To analyze means to split a problem into parts, and trying to understand the whole by understanding each part separately. The idea is that understanding the parts enables us to understand the whole. This way of viewing the world is called reductionism, and it has been the dominating way of viewing the world in Western culture for hundreds of years.

Analysis is indeed a powerful tool, but it has limits. When we try to understand a system by examining its parts, we loose the full picture. This can lead us to making bad decisions. Here is a classic example, the Monty Hall problem:1

You are a contestant in a game show. The game show host, Monty, puts three cards on a table. All cards are face down. Monty tells you that one of the cards is a winning card, the other two are blanks.

Monty asks you to pick a card, but keep it face down on the table. Then, Monty flips one of the two remaining cards over. It’s a blank.

Now you get to choose: You can either stick with the card you have, or you throw it away and pick the remaining card on the table.

Think it over before you turn the page and read the answer. What would you do, and why? Does it matter what you choose?


Figure: A Future Reality Tree with the solution to the Monty Hall problem.

The diagram above has the solution. Read the diagram in the direction of the arrows, from the bottom, and up, to the top.

The diagram is called a Future Reality Tree (FRT) and it is one of the tools you will learn from this book. It is fairly easy to read the diagram even if you have never seen a Future Reality Tree before.

Boxes with rounded corners contain text describing reality as it is right now. Boxes with straight corners describe things we do to change reality. The ellipses mean and. No ellipsis means the content of any one box can cause the effect on its own. Note that in a complete tree, all the boxes must describe things that actually do exist. Speculation and guesswork should not be present in the diagram itself.

The four boxes at the bottom of the diagram are read like this:

If there are three cards on the table face down and only one of the cards is a winning card, and I pick a card, but I do not look at the face side, then there is a 1/3 chance I have picked a winning card.

Analysis can easily lead you astray when you are dealing with anything even slightly complicated. If you break the problem down in separate parts, you end up in a situation where you have two cards to pick from, the one in your hand and the only remaining card on the table. It is easy to conclude that there is a 50-50 chance of winning, regardless of whether you switch cards or not. Because of this, most people choose to keep the card they picked at the start.

If you follow the diagram all the way to the top, you will see that after Monty has flipped a blank card, there is a 2/3 chance that the remaining card on the table is the winning card!

Really! Please do not take my word for it, after all, I could be wrong, or even trying to trick you. Walk through the diagram yourself. Even better, go get a deck of cards, and try it out a couple of times.

The Future Reality Tree helps us combine two different ways of thinking, analysis, and synthesis:

●  Analysis is breaking down the problem into parts. That is what I did when I split the problem up in little boxes.

●  Synthesis means putting different ideas together to form a whole. I did that when I organized the boxes, and drew arrows and ellipses.

You can think of it as laying a puzzle. Analysis is when you look at the shape and color of each piece. Synthesis is when you put the pieces together, so we can see the entire picture.

In this book, I use one of the best methods I know to understand complicated problems, The Logical Thinking Process (TLTP). I explain how you can use The Logical Thinking Process to solve problems and develop both strategies and tactics in Part C: Navigation.

It is fairly easy to read TLTP diagrams even if you do not yet know how to create them, so I’ll use them whenever I want to be extra careful to show cause and effect, and to build logical arguments.

Like all other tools, TLTP diagrams are based on certain assumptions of how things work, and that means they have certain limitations. We will have a look at those limitations later on, when we get to complexity theory and Cynefin. The reason I mention the limitations now, is I do not want you to believe that just because I show you a really great hammer, all problems are nails. We will deal with both nail-shaped, and not-nail-shaped problems and solutions in this book.

Takeaways

●  Analysis is when you break a problem into smaller pieces to try to understand each piece.

●  Synthesis is when you organize and connect pieces of a problem, so you get an understanding of the whole.

●  We need analysis and synthesis together to understand and solve complicated problems.

●  Visual methods, like The Logical Thinking Process can be a great help when analyzing and synthesizing problems and solutions.

●  Just because you have a hammer, not every problem will be a nail. The tools in this book has limitations, and to use them well, you must understand not just how and when they work, but also when they do not work.


1 The Monty Hall problem got its name from Maurice “Monty Hall” Halperin, who led the game show Let’s Make a Deal in the sixties and seventies.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more