Theory of Constraints

I attended a small workshop on the ‘Theory of Constraints‘.  It is a management perspective on work introduced by E. Goldratt.  There are five steps towards minimizing waste, work in progress (WIP) , and increasing efficiency.  There are some assumptions about the system, such as only having 3 levers of control – expense of operations, throughput of the system, and inventory or WIP.

  1. Find the constraint, where things start to get backed up. Some function, process, change, etc.
  2. Exploit or Focus on the constraint. Figure out how to get the most out of it.  This draws down the WIP, and smooths out the production flow.
  3. When the constraint is elevated – the rest of the process is subordinate.  The constraint is visible, and we subjugate the rest of the flow to it’s capacity.
  4. Elevate and start improving upon the constraint’s capacity
  5. Repeat these steps to continue increasing the flow through the system.  It may even be a new place where the constraint occurs.

Just having typed… I might only keep three.

  1. Identify the bottleneck.  We need situational awareness about what is happening.  Part of this is knowing if it is temporary or a usual suspect.
  2. (You are here) – Improve this. As it is now the most important thing in the process.
  3. After some stabilization, revisit and repeat by stepping back and looking at the process as a whole.

which kind of sounds like plan, do, check.

Great teams have a way of looking at these constraints as opportunities to improve.  The workshop had a small exercise for teams of 5 people that helped each team explore and improve upon what the ‘system’ constraint was.  Manufacturing a ‘product’ that was comprised of index cards, stickers, and marker lines.   Through 4 rounds our team changed and steadily improved how and even what we did.  All in order to assemble the specialized product faster, easier, with less mistakes and without accumulating excess WIP.

There were a few thoughts that occurred along the way.  The theory can equally apply to either a push or a pull system.  Lean has taught us that pull systems are usually the better model to emulate.  Using a rope held by people as an analogy – a rope generates slack (WIP) when it is pushed forward to another person’s hand.  The rope stays  smoothly even when everyone is gently pulled along.  Scrum and Kanban are PULL type systems.  Allowing for the capacity of the team, stage, etc.

A vertical slice explores the system for constraints as well.  When taking a very thin slice from the topmost  user interface to the depths of architecture, with something very small, -we are probing for the part that was most difficult to change.  It is a form of learning, and risk reduction.  Learning about the system, and precisely where it is appropriate to improve.  Since right now this part took us the longest to implement some change with.

Finally, I wonder what constraints we may have imposed upon ourselves,  – simply by not having noticed.


Please leave a reply

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

You are commenting using your 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 )

Connecting to %s