Flowing through The Bottleneck

In the much praised book Flow about product development the management of queues and bottle necks are a central theme. The book states principles on how to best deal with them. Traffic lanes and cars are great for showing the (wrong) use of queuing because most people can relate to traffic jams and bottlenecks in a traffic situation.

One major topic of any process optimization is the management of bottlenecks. One intriguing statement is made, it urges to go beyond the popular idea that ‘the capacity of the bottleneck controls system flow’. It’s not only the bottleneck, it also very important to look at the flow through the bottleneck.

The example given in the book discribes a traffic situation where three lanes are reduced to two. Combining two lanes into one causes turbulence and you don’t want this turbulence at the bottleneck, which is why the narrowing process starts miles before the actual bottleneck.

Although this is better to leave the narrowing totally unmanaged, in practice it often doesn’t work like this. On a recent car trip I found there is a better way of controlling flow which works much better than the regular solution, I’ll explain.

First the basic problem found very often on the Dutch highway, three lanes need to be narrowed to two:


The regular solution is to urge the car driver to start ‘turbulenting’ a few hundred meters before the third road ends. This usually doesn’t happen, what does happen is people cram their car into the bottleneck, usually with high speed. Their motivation is to slip through (escape) the bottleneck as quickly as possible. This decreases flow sometimes to a standstill.


An alternative solution, I recently experienced, is much more focussed on flow. This solution takes a two step approach, it splits the three lanes into two before combining them. This way the driver in the middle lane has two options when merging with another lane, to the left or right lane. This spreads the turbulence more evenly over the two other lanes. It also makes it undesirable to drive up to the road block as fast as possible because you haven’t ‘escaped through the bottleneck’ yet because the real bottleneck is still a few hundred meters ahead.

I’m not sure if the road workers made this arrangement on purpose to increase flow, but it’s a brilliant way of dealing with a bottleneck and minimizing it’s impact.


The relevance to organizations is to keep in mind that widening a bottleneck might not have the highest value, optimizing flow through the bottleneck can also reap huge benefits.

Suppose you have too few testers in your team. One thing you can do is hire more testers. But instead you can make sure the flow of work through the testers is optimal. In stead of the tester testing a feature as a whole after (or even before) it’s developed, involve the tester a few short times during development. This way he/she can detect testing issues before the full test and spread the ‘testing turbulence’ over a longer period of time, reducing the impact of tester-shortage. No extra testers, but increased flow. This is how I prefer to tackle bottleneck issues in my team, when increase in capacity is not at hand.

Flowing through The Bottleneck

8 thoughts on “Flowing through The Bottleneck

  1. A perfectly clear description of this alternative approach to tackling bottlenecks. It is an inspired solution, in fact. Thanks for that. And you offer a neat way of applying that lesson to software development bottlenecks.

    It seems there is a lot to be learnt by this industry from traffic flow; there have recently been 2 or 3 blog posts on roundabouts. Makes me want to explore further, or at least keep an open mind when caught in traffic crises. Could make commuting a happy problem to be solved rather than a drudge 🙂

  2. Nice post! I like your comparison with traffic jams which everyone understands. This makes it easier to grasp for traditional thinkers why it is so important to involve testers earlier on in the development process i/o at the very end.

  3. Havent experienced the biderecional merge on the road yet. Seems an interesting solution.

    The conventional merge can work very well _if_ everybody merges at the same point.
    A couple of years ago police patrolled onramps near Utrecht, with signs saying use up the full length of the merge lane, then merge. That had good traffic flow, because the merges were predictable, everybody can anticipate and keep on driving. Of course, having the police handhold drivers at every onramp is a bit costly…

    Road regulations state that you have to use as much of the onramp as possible, but:
    – most people forget this after they take driving lessons, therefore as your picture shows some people merge early, some people merge late. This leads to frustration and agressive behaviour on the other lane (I already let a couple of cars merge, now I want to #!#$%! drive!)
    – As you say, many drive at high speed to the end and then break. They then merge while standing still at a 45 degrees angle to traffic, which leads to blocks.

    I worked at the dutch roads agency for a couple of months, in the research/development center where they work on traffic flows. Its a complex problem – still not very well understood.

  4. Goed gedaan Machiel! Here in California in a traditional 3 to 2 merge the 3rd lane merges into the second. Some drivers merge early which depopulates lane 3 making it flow faster. This creates an incentive to stay in lane 3 until the last responsible moment. The Dutch approach is much smarter. It inherently balances flow into the two surviving lanes and creates less turbulence. Channelizing flow upstream of a bottleneck is a common technique in fluid mechanics. Youve provided good evidence that it also applies in other domains.

  5. Mary says:

    Good post and very good comments too. One from the author of the book you refer to!

    It looks like you take managing traffic jams as an example to prove that optimizing flow can avoid bottlenecks or take a lot of the pressure off in a lot of circumstances.
    Every one that comments states, one way or the other, that optimizing flow can avoid traffic jams.

    That’s knowledge creation to me. Awesome!

  6. Lars Vonk says:

    Interesting stuff Machiel. Some thoughts/remarks on the topic:

    1. What you describe with the tester sounds a lot like TDD. Creating the tests upfront (= splitting before the bottleneck) , and during the sprint (in case of scrum) both programmers and testers can work together in adding a little more tests, assisting each other etc. etc. The end of the sprint (the bottleneck) should then run smoothly.

    2. During my first year of study I actually did some research (if u can call it that) on traffic jams for a project we were doing. I havent come across the solution you suggest, so you might consider calling the Minister Camiel Eurlings :-).
    Anyway what I found interesting then was that in case of going from a 2 lanes – 3 lanes – 2 lanes all within a couple of miles, it was better to keep it 2 lanes all along. So in case of your example, instead of hiring extra testers you might also consider removing a programmer from the team.

  7. Excellent post! Havent read the book (yet), but couldnt resist providing my two cents… I agree with Lars that since a Scrum team has a shared goal, which requires all team members to do their thing, theres no point in overtaking other team members. I guess in your traffic example this would mean all members of the team are driving in separate cars to the office, and each of them carries a portion of the key required to get in. The bottleneck being the the lock on the door.

    The Dutch government also experimented with officials driving at a fixed speed (they apparently knew theres a traffic jam up ahead), blocking all lanes behind them, with the goal of improving overall flow. In your example, with too few testers, why not make the testers (or whichever role is the bottleneck) the officials? Basically blocking the developers at a fixed speed, but improving overall flow (all arriving at the same moment, nobody spends time waiting in front of the door, idling). In this setup the developers will be forced to look for ways to speed up the testers (not including flashing headlights, etc). Perhaps they can automate more of the work now performed by the testers?

    You could compare the quality of the code with the quality of the road. Applying TDD would indeed speed up the testers. Less defects, means fewer issues to fix (potholes to avoid), the entire team can drive faster. If the pressure on developers is relatively low, they could also clean up some technical debt (basically increasing the speed limit of the road), speeding up the entire team again, right? Likewise, should development be the bottleneck of the team, testers could look into taking on some of the workload, helping out with whatever is required. Dropping TDD/pairing/automated testing/etc practices will only further slow down the team IMHO.

    Of course, it makes no sense to have 1 tester (one lane), and 10 developers (or vice versa) which would be a mini traffic jam on its own… A team should always be somewhat balanced and realize their not driving in their car, but in the team bus. Just my two cents 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s