Mind the bottleneck: Why students should recognise one

Bottlenecks are more common than people realise, and aren’t always attached to bottles.

I realised later that the previous post about theory of constraints, forgot to go over bottlenecks, and how to resolve them. I’m sorry about that, so you have this post to tell you more.

Bottlenecks slow the rate of flow of liquid from a bottle so that you don’t have your beer, catchup, or whatever spilling out too fast. In production, and office systems they appear as the place where work piles up in the process. The people who process the work after this step are working less, as they are waiting for the others to finish.

Bottlenecks are everywhere

Oliver Burkeman, wrote about how he wonders if the way we move through airports also suggests a bottleneck. He suggested reading The Bottleneck Rules (full book online plus links to print versions) would help lots of people see bottlenecks more easily, which would help them in work.

Go look at Paul Hammant’s blog to visualise what bottlenecks look like in work, and how they can be addressed.This little graphics help us see the effect of a bottleneck, and to realise that once ‘fixed’ the bottleneck will move. This might not be as bad as it sounds.

Once you have identified your bottleneck, then you need to optimise it so that it can keep pace with the other steps in the process.

If optimisation is insufficient, then you can coordinate, collaborate, and curate your process to remove work from the bottleneck. As part of this step you can also upgrade equipment, and train people to improve your bottleneck.

Now, your bottleneck might have moved, and you can start again.

Alternatively, you leave out an improvement so the bottleneck stays were it is. This way you know where it is, and can manage it accordingly.

The biggest takeaway from understanding bottlenecks is this: there is NO benefit to speeding up everyone in the process, as some step will always be slower than the others. Because one step is slower, the output of everyone is limited by that step. The output for everyone can only improve if the speed of the slowest step is improved.

Bottlenecks have a large impact on software development

Clarke Ching relates these steps to software development in his buffalo story. Go watch the six/seven minute story (or the whole thing if you prefer). Learn why helping the slowest team members helps the whole team. Even though this talk is almost ten years old, it still holds valuable lessons. These lessons are not taught to students, so watching old videos, and reading old books still hold important information.

Expanding on what Clarke talks about you can see that there are many things you can cover with your students to improve the speed and quality of their work.

Teach your students to handle bottlenecks

Teach them to automate steps in building and testing their work. Any time it takes for them to learn automation is quickly recovered by the time they save later. Tests will tell them where errors are, and automating means steps aren’t forgotten.

Show students how to build their products in thin vertical slices. Doing this ensures they avoid doing work which will be later thrown away. This can help them make errors, bugs, and changing requirement more obvious.

Students should also learn to limit the amount of multi-tasking they do too, as context switching is costly.

Pairing and mobbing on the work spread knowledge within the team. This helps both the capable and the less capable students. The team only goes as fast as the slowest team member, so by helping them, the team helps itself.

Lastly, we are our own bottlnecks. We hold so much information that others could use. The key is to learn how to share it in a useful manner. That’s one reason I’m putting these posts out there.

---