Over a million developers have joined DZone.

Theory of Constraints: Blaming the bottleneck

DZone's Guide to

Theory of Constraints: Blaming the bottleneck

· Agile Zone ·
Free Resource

You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang

I've been reading The Goal over the last week or so where Eliyahu Goldratt describes the theory of constraints as a philosophy for allowing organisations to continually achieve their goal.

Goldratt goes on to describe bottlenecks – resources which have a capacity less than the capacity being demanded of the system.

The capacity of the system cannot be higher than that of the bottleneck which means that we need to find a way to optimise the bottlenecks in any system.

In a software context I think an agile/lean approach to delivery is quite effective for allowing us to quickly see where the bottlenecks are – this will typically be where the cards are piling up on the wall.

The problem with this is that we can frequently end up blaming the people working in the role where the bottleneck seems to be.

On the projects I've worked on stories tend to get stuck in QA since there are significantly less testers than developers on any team.

Since blaming isn't particularly useful Goldratt suggests two ways to optimise bottlenecks:

  1. Don't waste time of the bottleneck
    • Processing defective parts
    • Sitting idle
    • Work on unnecessary parts
  2. Take load off the bottleneck

The bottleneck ends up sitting idle when we wait until we've completely finished a story before showcasing what we've done to the testers.

It's frequently the case that we can QA test a piece of functionality before the whole thing is complete.

We can avoid processing defective parts in this case by talking through a story with a tester before we start and thinking of the bugs we might create in development. Unit testing can also be useful for reducing defects.

I'm not sure how working on unnecessary parts would work most of the time – perhaps testing features which aren't required for the next release would be an example of this.

We can achieve the second to an extent by ensuring that we have more scenarios automated so that a tester doesn't need to manually cover them each time.

We could also get developers to temporarily take on the role of a tester to increase capacity but from my experience that doesn't seem to work out as well in practice as it seems like it should.

Download the free agile tools checklist from 321 Gang. This guide will help you choose the right agile tools to position your team for success. 


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}