Lean thinking and theory of constraints have gone hand-in-hand in the agile world for as long as we’ve been stealing/borrowing ideas from the manufacturing world. If you aren’t very familiar with how these things fit together with agile practices a good starting point is this InfoQ article (it is a little dated but still valid).
So Lean tells us we should reduce waste in our system and focus on throughput and cycle time, but doesn’t really do a good job telling us which waste to focus on first. And that is a big-ass problem – because if we focus on a part of the system upstream of the bottleneck we can adversely affect the performance of the system by increasing WIP consequently increasing cycle-time and decreasing throughput. Ouch!
Theory of Constraints comes to the rescue by telling you which waste to focus on first – the bottleneck! The slowest part of your system is where you should start because, by definition, any improvement you make to the bottleneck directly impacts your cycle time and throughput.
So for years that’s where I left it when describing it to my clients and students. The question of “How do you find the bottleneck?” never had a straight-forward answer. That’s where you bring in the consultants or spend significant time and effort understanding and measuring your system so that you can find that all-important bottleneck. An activity that has always seemed nebulous.
Okay – here comes the coolest part ever! There is an insanely simple way to find the bottleneck. Every. Single. Time. (If I stop here it would make a great cliff-hanger wouldn’t it?)
- Draw/create your value stream map. Pay special attention to identifying the queues in your system.
- Then, starting from the right-hand-side, traverse the VSM and find the first queue/inventory.
- The process to the right of that first queue from the end is your bottleneck.
Ta Da!!!! That’s it. Insanely simple way to find the bottleneck. I’m sure this must have been written up somewhere before, but I’ve managed to miss this little tidbit throughout the years (and so have many of those I’ve been checking this with over the past few months).
“It can’t be THAT simple!”, I hear you exclaiming. But think about it, if this is the very first queue from the end of the VSM, then any improvement flows directly to the user with no blockages because there are now queues downstream.
Feel free to poke holes in my theory and disprove this statement and I’ll be grateful because I will learn something along with you. But if you can’t, isn’t this really cool?
Amr Elssamadisy's Blog 
Aston_B
May 19, 2014 at 5:56 am
So lean thinking says banish waste and create wealth; but how? The answers have to be derived and the quest has to be self initiated. But I think the process of doing so it quite a hectic one and the also demands ample time. This is not possible in today’s time! Theory of Constraints is far on a better note.
I second that 🙂
Alberto Brandolini
June 3, 2014 at 1:04 pm
Hi Amr, though a pretty good rule of thumb, there might be some circumstances where this approach won’t point to the real bottleneck. In my company Kanban system “invoicing” is a place where a queue might form. However, some payment policies (i.e. end of month) or buffers (the delegated employee is apart-time worker) make this rightmost queue not so interesting in my system, where the real bottleneck is in sales.
I totally agree that this is the quickest possible starting point. In general I tend to shy away from “we need to measure first” approaches. People normally have a pretty good idea of where the bottleneck is, and that’s the area to start investigating. While measuring, of course.