Have you ever been to a casino? My parent took me a few times when I was younger. I avoided the card games as they seemed to require skills that I knew I did not have. I favoured roulette. That big wheel with numbers around the edge. The brief flash of the ball as it left the skilled croupier’s (?) hand, and the tick, tock, plunk as the ball decided the fate of the anxious gamblers and the fresh faced maths geek.

Now imagine a variant on the game. You get to run the game twenty times. Each time, you have to bet on black. You count up the number of times you win. This is your score.

Now run the game again. But this time make a change. Instead of one person placing the bet, get two, or five, or one hundred. Will it change the results?

Now try doing it standing on one leg.

Or with a glass in your hand. A glass containing whiskey. Now drink the whiskey. Drink lots of whiskey. Drink whiskey with ice, and whiskey without ice.

Do any of these changes make any difference to the score?

No!

The outcome of the game is determined by the inherent randomness of the process and the constraints placed on it (always bet on black).

This is Deming’s famous red bead experiment. It is meant to teach us that nothing we do will affect the outcome of the system. It proves that the system dominates. It ensures that by construction.

Consider an game that is more a production process in the real world. Imagine a casino where we could do whatever we like. the individuals playing the game might decide the take the ice cubes out of their whiskey glasses (there are a hundred playing so numbers count. whiskey with ice is needed) and block the red and white slots in the wheel. This would force the ball to always land on black.

That’s what inidividuals do. They change the rules of the game. They change the system.

Next time someone offers to play the red bead game, discreetly remove all the “bad” beads before one of the goes. That way, you can demonstrate to the people running the game that the system does not dominate and that individuals can have an affect bigger than 6%. Of course, expect them to be angry because they are the ones in control of the system.

I would like to thank Don Reinertson for inspiring me to think about the “Red Bead Con” with his keynote at Lean Kanban Benelux

Last week I read a nice post by David Anderson about the Information Generation Process. I realised that apart from badly naming what I was talking about, I had also failed to explain what I was talking about.

Most literature I’ve read about Process Improvement including Lean focus on the delivery of the product or service. None that I’ve read really focus on the flow of information in the process. Unless you consider the information flows, it is possible that your decisions will be severely sub-optimal.

As an example, consider the software product and information flows in software development. Traditional software development belief has an analysis phase followed by a parallel software development and test preparation, which comes together in a test execution phase. Focusingf on software only, parallelising the software development and test preparation phase makes perfect sense as it reduces the time to delivery of the software… Unless you consider the information flowing into the system. The test preparation phase involves creating detailed examples that would be used to test the software. Creation of these examples results in the discovery of details about how the system needs to behave that will be tested. The information about the examples needs to be built into the software. In other words, the information needs to be incorporated into the software development phase before the software can leave the test execution phase. The only way that the information is guaranteed to get into the software development process is as a “bug”.

In other words focusing on the software product only results in parallelising software development and test preparation which is the optimal way to deliver software INTO test execution. When you consider information flows in your system, you realise that the optimal way to deliver software OUT of test execution is to place test preparation before software development. In other words use “Specification by Example” or “Automated Acceptance Testing”.

This is one example. The general rule for optimising an information arrival process is that “All information needed to make a commitment should be available before a commitment is made.” The Feature Injection process is one way of implementing this principle. “Sense and Respond” describes a similar process for service organisations. Feature Injection starts with the value, whilst “Sense and Respond” starts with the customer.

Both Feature Injection and “Sense and Respond” are “knowledge discovery processes” that David refers to in his post.

Neither process is passive, simply waiting for information to arrive. Both actively discover the information needed in a structured manner, guided by the goal of delivering (customer) value.

I like to pride myself on the fact that I give things really really terrible names. “Information Arrival Process” is one of my worst. A ponsy name for considering how information arrives into a system as well as how the “product” flows through it. The aim is to avoid information loops where information flows backwards in the process, and ensuring the process is not halted whilst it has to wait for information to arrive. In effect, endeavor to create flow of information in the opposite direction to the “product” as well as flow of the “product” itself.

Note: “Product” is the thing delivered to the customer that generates value for them.