Edward Deming and his Red Bead Experiment, in practice.

We had an interesting brown bag lunch meeting the other day about Edward Demings red bead experiment. I've heard and read about it before but never got to participate, it was interesting, thought provoking and fun. Some good discussions afterwards as well.

Edward Deming was a management consultant and statistician. He had a massive impact on the management styles and philosophy of Japanese business in the 50's and 60's. He used the red bead experiment to illustrate the impact that a system, and traditional management approaches, can have on individuals who work within a system, and how traditional management approaches (slogans, the usefulness of targets, annual appraisals and financial rewards) are not always (if ever) that effective at improving quality.

Details on the red bead experiment and how it is performed can be found here http://www.redbead.com/. For our results in the actual experiment read on.

Results
The session was run by a thoughtworks colleague, in a really good way, we had the workers, the management, the QA staff, and lots of fun.

The workers were set targets of 5 defects max per person ( a total of 15 per iteration for the team)
The 3 workers, were split into 2 average and 1 good (what ever that means)

Iteration	1	2	3	4	Developer Totals
Dev1	6	8	5	7	26
Dev2	10	7	5	7	29
Dev3	7	8	10	11	36
Iteration Totals	23	23	20	25	91

After iteration 1 workers were told that their efforts were not good enough, and basically told off by management. This made no difference, and so, after iteration 2 the workers were given incentives and appraisals, if they upped their game they would be given hard cash. This worked and management were encouraged to do more of that, offering bigger rewards for better performance.
But iteration 4 was the worst yet and so managers assumed that the incentives had failed because no one actually achieved them last time.

So what does this actually tell us?
That in a fixed system where the workers have no ability to manage or better themselves or their work, the management effectively can not effect workers performance though traditional carrot and stick management.

How does this relate to Software?
I have found that as software developers we don't get to change the system as a whole very often. Often software is seen as the solution to business problems, when actually changing the system would be a better approach. Just by making the process electronic doesn't always work and often makes things worse or masks the underlying problem. This is just another reason why software projects fail.

The experiment also relates to the software development process. If software engineers work in a rigid system where QA and strict process is seen as putting the quality in. Where the engineers don't have the ability to change their environment (technology, process, physical environment, methodology) then no amount of incentives, slogans, rewards can make the software produced better (less defects, meeting business requirements more effectively, etc.). I have seen this at several clients, and can say that clients who have empowered workers have a big advantage, these companies have better motivated, more professional developers and in the end better software.

Summary
Systems Thinking is a really interesting field at the moment and if you want to read more do a google for Edward Deming, systems thinking and John Sedden.

So even if you are CMM level 5 (i.e your processes are robust and repeatable) you can still have quality issues, The red bead experiment highlights that it is not process that produces quality, nor rewards, targets or incentives, its the system within which workers work that matters and their ability and motivation to help change and adapt the system.