The Theory Of Constraints

Overview

In conjunction with Queuing Theory, the Theory of Constraints (ToC) presents some additional ideas for making improvements in the efficiency of the Software Development process.

The Theory of Constraints was introduced into management by "The Goal", a book written by Eli Goldratt in 1984.

The basic idea is that you can always find a slowest point (the area with the slowest throughput of work) or the "limiting constraint" in a process by finding out where there is a buildup of unfinished work. This slowest point defines the limit of the amount of work that can be put through the system.

This slowest point is where you need to concentrate your efforts for improvement - because improvements made anywhere else will not improve the rate at which work can be moved through the workflow.

For example, suppose two people are cleaning dishes in a restaurant, one washing dishes and the other drying. If the number of wet washed dishes keeps building up, then the constraint for the process is the person drying. Increasing the rate at which dishes get washed won't increase the number of dishes you are able to put on tables, because those dishes aren't going to be dry. If you want to increase the rate at which you can put dishes on tables you need to increase the rate at which dishes get dried, not the rate at which they get washed.

Applying The Theory to Agile

In more complex processes such as software development, it is sometimes more difficult to see where the constraint is. So look for people who are waiting for work that is coming from someone else. Usually, the "someone else" is a constraint, so a method should be found to improve the efficiency there.

In Agile, the focus on resolving the constraint would be to provide that person with extra training or get other members of the team to assist in the work by "Swarming".

The ToC is important because it tells us where to focus our efforts. For example, if we need to improve throughput in a project, it would be a waste to increase the developer's capacity to code stories from 90 points up to 100 points per sprint if the BAs could only supply 80 points of elaborated stories and the testers could only test 70 points of stories!

The "Limiting Constraint" is defined as the point at which the lowest throughput occurs - in this case the testers, who can only throughput 70 points of stories. Work that focusses to improve any other area will be wasted as our delivery of tested code would still be limited to 70 points per sprint. The first area of concern should be the limiting constraint.

NOTE: Removing the limiting constraint (in this case the testing process, at 70 points) simply moves the constraint to a new bottleneck (in this case it would move to the BAs at 80 points). The process of identifying and removing constraints is thus ongoing.

The Theory of Constraints can be applied to measures other than rate of work throughput. There may, for example be a limiting constraint on work quality.

The ToC may have implications in prioritizing which areas to improve during a Retrospective. If an area identified for improvement does not represent a constraint to the work by any measure (volume, quality, etc) then this area may not be a priority.