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

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

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.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies


Published at DZone with permission of Mark Needham, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


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

{{ parent.tldr }}

{{ parent.urlSource.name }}