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:

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.