Chasing the Constraint Beyond the Development Team

Around the same time that the term “lean” was coined in the western business lexicon, Eliyahu Goldratt published his bestselling business novel The Goal which popularized the theory of constraints (TOC). Boiled down to its essence, the theory of constraints states that, at any given time, a system of production has one and only one constraint. Improvement away from the constraint will not improve performance of the system.

More thorough plot-spoiling summaries of the goal have been published elsewhere. Briefly stated, The Goal chronicles the exploits of a fictional manager of a midwest manufacturing plant as he struggles to improve delivery of orders in time to prevent his plant from closing. In the process he is aided by an enigmatic consultant figure named Jonah who bears an uncanny resemblance to Eliyahu Goldratt. The plant manager and his team discover constraint after constraint as they transform their plant from the worst-performing plant in the company to the best-performing plant.

At this point, in the story, the management team realizes that the constraint has moved outside of their plant and that further increases in manufacturing throughput will not deliver more profit until they can sell more of the products their plant produces, so they follow the constraint into the sales organization and convince the sales manager to address the issue there.

While software development and delivery processes may be more variable and less deterministic than many manufacturing processes, the theory of constraints can also be applied to software development. By analogy with The Goal, adopting agile methods often dramatically increases the the throughput of the software development function. If the system constraint was initially in the software development function, it is likely that agile adoption will cause it to move somewhere else.

In a workshop session I organized at the recent Agile 2011 conference in Salt Lake City, a diverse group of practitioners engaged in a focused discussion of this phenomenon. Their observations provided evidence that constraints do indeed move. The general pattern was that as teams adopted agile methods they became more productive and the constraint moved either upstream or downstream in the development value chain.