A lot of what I teach nowadays revolves around the idea that management has the power to change policies in an organization and that policies control a lot of the sources waste (muda) and bottlenecks (constraints). [Note to the knowledgable TOC readers: Eli Goldratt has abandoned the idea of policy constraints and I agree with him. Instead policies are thought of as the result of subordination decisions to support the exploitation of a capacity constrained resource.]

Hence, the puprose of tracking customer-valued work (using a product like Team System) and reporting on it transparently for everyone to see, is to provide an opportunity for open objective discussion about problems and the policies that may be causing them. Surprising large amounts of waste are caused by policies. The case study from XIT Sustained Engineering showed that almost 60% of capacity was being wasted through policies that were within the power of management to change.

There are two particularly common problems which can be non-obvious to everyone in an organization that are easily exposed with transparent data.

(1) Boiling Frogs

Peter Senge used this analogy in The Fifth Discipline to describe a common systems problem. If you put a frog in cold water and gradually heat it up, the frog will not know that it is being cooked because it cannot detect the gradual temperature change. By the time the frog knows it is boiling it is too late.

XIT Sustained Engineering had this problem. They were trying to schedule change requests and always the schedule would turn out to be inaccurate (wrong) and things would change. The result was that the business asked for more accurate estimates in order to make the schedule for accurate. [It was assumed that the schedule was wrong because of poor estimation. This was a wrong assumption.] So the team spent longer on estimating, but the problem with schedule accuracy didn't go away, and so they were asked to do more accurate estimates and they spent more time on estimation. By the time the frog was boiling they were using 40% of their available work time on estimation rather than doing customer-valued work.

(2) Superstition

Superstitions are things people do even though they cannot explain why they do them. Often the reason why has been forgotten. There was a joke went around the Internet via email a few years ago. The story is believably based on scientific experiment. It went something like this.

A troup of caged monkeys were able to press a series of colored buttons and receive a reward - a favorite food. One day one of the buttons was changed to give them an electric shock. Quickly troup members would rally to prevent others from pressing the button and receiving the shock. When no more monkeys were pressing the button the experiment was changed so that the button once again provided the reward. Gradually the monkeys in the troup were rotated out and new monkeys introduced. When each new monkey arrived, it would try to press the feared button and the troup members would scream and rally around to persuade the monkey not to do it. Eventually ever member of the original troup was gone and all the monkeys in the troup had never ever experienced the shock from the feared button. But each had learned the superstition that the button must never be pressed. That was the way things were done around here.

So imagine you have a problem in your team and management makes a policy change to fix the circumstances that caused the problem. Everyone starts to work the new way. Over time the reason for the management policy is forgotten. Equally over time the source of the problem may be eliminated. For example policies introduced because build integration is so painful may no longer apply if you have deployed a modern build tool such as Team Foundation Server. However, the policies associated with the problem may never be changed, because that is the way things are done around here! 

So if you are analyzing reports from work item tracking, looking for bottlenecks and waste, challenge old assumptions. Ask, is there a boiling frog in the room? or, are we following a superstitious belief? What was the root cause that prompted us to create this policy? Technorati tag: Agile, David+Anderson, VSTS, Management, Peter+Senge