Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Theory of Constraints: Blaming the bottleneck

12.27.2010
| 3088 views |
  • submit to reddit

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.

References
Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Matthias Bohlen replied on Sat, 2011/01/01 - 5:17am

Hello Mark,

blaming the bottleneck isn't useful, indeed, and does not help the teams. In fact, being a bottleneck is not a shame at all: When a company has no bottlenecks any more, it will soon go out of business. Why? The capacity demanded on the system would be less than the capacity of all the resources in the workflow of the company. This would mean that the company has too few demand from the market. So, do not feel blamed if somebody says that you are the current bottleneck of your company.

OK, let's return to your test bottleneck:

"Work on un-necessary parts" can also mean "do non-value-add work", for example:

  • filling time sheets
  • writing test plans
  • repairing test equipment (servers, clients)
  • and so on...

Management could make an intervention to remedy such a situation. For example:

When your team introduces a Kanban system and sets a WIP (work in progress) limit to the most important columns on the board, you would see that test hits their WIP limit frequently. A little later, development would hit their WIP limit, too. Analysts (if you have them) would hit their WIP limit a little later and sit idle, too. Analysts could then go and help the testers do their work or write test plans, etc., because they know what the requirements are. After a while, the system would resume flow.

These is what Goldratt calls "subordinate everything to the bottleneck". Kanban does this for you, automatically.

In a last step, you could elevate the bottleneck by hiring more testers ore by cross-training others (e.g. analysts, developers, ...) to be able to switch to the tester role temporarily as well.

So, you have lots of options beside blame. :-)

Cheers,
Matthias

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.