This session was presented by Pascal Van Cauwenberge and Rob Westgeest and introduced the Theory of Constraints .

The theory

Acknowledging cause and effect, the premise of the theory is that "the throughput of any system is determined by one constraint or bottleneck", and that the throughput can be optimised by following 5 focusing steps:

1. Find the constraint

2. Exploit the constraint

The system's output equals the output of the constraint, therefore try to maximise the output of the constraint by removing non-productive work from the constraint, or buffering the input to the constraint and have the constraint pull work in. The constraint exists and is therefore already paid for, so always try exploiting first because it doesn't have additional costs.

3. Subordinate to the constraint

Resources which are not bottlenecks will have spare capacity so try subordinating them to the constraint to help boost its output by taking over some of the constraint's work, or improving the constraint's input, or carefully treating the contraint's output to limit any waste. The other resources with capacity are already paid for, so when no further exploits are available focus on subordination because it doesn't have additional costs.

4. Elevate the constraint

Time to spend some money on improving the constraint's output by investing in training, coaching, better tools or perhaps more people. Only do this when exploitations and subordinations are exhausted.

5. Repeat

Removing one constraint simply promotes the next constraint, so around we go again.


The session

The first half of the session saw the group simulate a development process constructing paper hats and boats. Unbeknown to the group the distribution of tasks placed the constraint at the developers. Following a 5-minute production run 24 sheets of paper entered the process but only 3 boat-hat pairs were delivered to the customer. 5 boat-hat pairs were rejected by QA or the customer, and the rest lay incomplete somewhere on the production line. The observers identified the constraint noting that the developers were overloaded and decided that the construction of hats (which were easier to make) should be subordinated up-stream to the designers.

A second 5-minute production run delivered 4 boat-hat pairs to the customer with only 1 boat rejected by the customer. I can't remember how many incomplete boat-hat pairs were in the system but it was better than the first run. Following the simulation, 2 additional focusing steps were revealed:

0. Find the goal

Understand the goal of the system and make it explicit at the start.

6. Change the system

Eventually, options for improving the throughput of a system will run out. At this point, if the system is not achieving an acceptable throughput it's time to ask whether the whole system is wrong and should to be replaced with a different system.

The second half of the session saw us split into smaller groups. One person became a customer and described a real-life problem they had experienced to the others, now Theory of Constraints consultants charged with finding and resolving the constraint. Our customer, Willem Van Den Ende , described a troubled CMS project where the customer was dissatisfied with the usability of the functionality delivered so far. The team comprised permanent developers working flat out on new business value, a part-time graphics designer writing brittle and smelly template code, and a part-time usability consultant who seemed to pop-in occasionally to make cursory comments about the usability of the UI. The graphics designer and usability consultant were seldom in the office at the same time, and neither attended the iteration planning meetings.

We identified the goal 'to deliver usable functionality to the customer' and decided that both the graphics designer and the usability consultant were constraints. Following some discussion another focusing step was revealed:

1.5. Choose the constraint

The theory claims that a system is unlikely to have more than 3 constraints. However, when faced with more than 1 identified constraint, you need to select the one to deal with first.

So we decided to deal with the usability consultant constraint. Since the usability consultant's time was already paid for, we set up a strategy to tackle usability proactively rather than reactively.

An exploitation involved the usabilty consultant attending the planning meetings, pairing with the graphics designer up front to create UI mockups, and then pairing with developers to make them aware of usability factors as they code.

A subordination cleared the developers of implementing new functionality and instead refocused them on resolving current usability issues.

An elevation involved paying for the usability consultant to conduct formal usability tests with real users in an observation laboratory. The developers could attend these sessions as observers to witness, first-hand, the problems and frustrations experienced by the customers. The usability consultant could then follow-up with a usability training course for the team.