Theory of Constraints

Every professional wants to be productive. If you are not productive, you are wasting time and money. But what does productivity mean. Is it measured by number of meetings, or hours spent coding??

Every manager wants their employees to have 100% utilisation. Some want even more than that.?

Now, is this a good idea to require your employees to work at 100% utilisation? On the surface it might sound good, but what if I told you it can lead to your company going bankrupt??

Yes, in fact if every employee works at 100% utilisation it is guaranteed your organisation will fail, and spectacularly.?

How is this possible? Let me introduce theory of constraints.

It’s connected to lean manufacturing and was introduced by Eliahu Goldratt in his book “The goal”. A very important book, which software engineers should definitely read. In the book the main character Alex Rogo needs to save his factory from being closed.?

Turns out in the factory, where everyone was working at 100% utilisation, the profitability was low and falling. Besides this, the factory was packed full of intermediate work in progress, half finished inventory, nobody knew who is doing what and why, yet everyone was busy.

An awesome coach, Henrik Kniberg created a wonderful video about this very point a couple years ago, and I always remember it when coaching my teams.?

Great video. Remember to go to their channel and give them a like.

If you focus on making people busy, you get a bunch of busy people. If you instead focus on the flow of value, optimise it, then the teams will not need to work at 100% for you to get the most value out of your value stream. In lean this practice is called on-piece-flow. Focusing on vertical completion of a single item, before moving on to the next. It makes measuring throughput very easy. This is also the reason why kanban recommends a WIP limit of ~ 5 items ~

Coming back to the book, It took the realisation what is actually important to save the factory, what is the goal.

The goal was not just to produce, but to SELL the items the factory created. Not just make them, not just store them, sell them to customers. And customers will only buy what they want to buy, only that what gives them value.?

The value stream was not the production, but also the selling and getting paid. Therefore LOCAL optimisations of the production, or even individual steps, if they were disconnected from the ability to sell and optimise the vertical throughput, could lead to devastating results for the organisation.

While optimising the small, you need to think about the impact on the whole.

The factory previously was producing things that were not demanded by the market, thus increasing the inventory. And the growing inventory, besides taking up space and processing throughput of the factory, also required dedicated storage, which needed to be rented with money. This again decreased profitability. Nobody noticed, because every single manager at every single station was interested in increasing utilisation of that one station. Everyone was very busy, and nothing was getting done.?

Besides this what was important was the unit throughput of the factory, and the demand for the products themselves. Increasing the throughput, and assuming the demand was not saturated, would in direct increase in profit.

Now how to increase throughput of the things the customers actually want to buy? You need to map you value stream. You need to understand what are the individual steps needed to manufacture your products, and how much time is required in each step. Also how much time is spent waiting. You might be waiting for example for other products to go through the same process. Maybe those are products which then end up on the shelves, gathering dust, and your profitable gadget is just blocked.

In the case of software the individual steps can be requirements gathering, development, compilation, unit testing, integration, functional testing, packaging, deployment…

You probably also need to loop in some of the steps e.g. development and unit testing will be a loop where you need to spend some time, iterating until your code works correctly.

Now imagine one of these steps… lets say functional testing, requires significantly longer than any other step, and has some kind of maximum number of changes allowed in the repo before no more commits can be made…

Let's imagine the development takes 30 min of active work and looping with unit testing, and at the end you have code you integrate for another 30 minutes, and then you kick off the automated functional testing which takes 12h…

In a situation like this the biggest influence on the speed of your development are not the coding practices, your efficiency while typing, or anything you do directly… it’s the functional testing which is slowing down the throughput of your continuous integration pipeline.

An exercise of creating a value stream map allows you to see what is the active time vs wasted, waiting time spent in each station in your production flow.

Using the example I mentioned, we would see there is 30 minutes for dev, 10 minutes for unit testing, another 30 minutes of integration, and between these there is no waiting until the station is ready… it’s your workstation. But then the next step is the automated functional testing on the testing server, which takes 12h… for which time the server is running the Jenkins job, and no changes can be made in the source.?

And not only that, you can only run it after working time is over, because the tests are so long, and require so much processing, they cannot be run during the day. So after a round of morning work, you have about 5h spent waiting for the tests to even start. What do you do? Do you continue working on another story? More untested commits? More work in progress?

Assuming the steps after the functional tests take about 30 minutes each, we get about 14 hours of cycle time, which means a piece of software can be considered done and delivered (if in fact your value stream contains continuous delivery) once every 14h at most… in reality even less frequently than that. Let’s say It takes at least 24h for the code to be “done”.?

Now this doesn’t even take into consideration any bugs you would find through functional testing… the waste of time is multiplied with every loopback. 1 bug means 48h, 2 bugs means 72h etc.?

A lean approach, based on theory of constraints teaches all quality assurance measures should be moved much earlier in the value stream, and focus on prevention, because repeating the same work multiple times is the single biggest waste of effort.

In this example it doesn’t matter how big the code change is. To fit in the 30 minutes development time window of the thought experiment it would need to be quite small… let’s imagine a single line change.

A single line of code taking at least 24h to complete, with the assumption of no bug after the pipeline is finished…

Can you see the throughput constraint?

This is the kind of constraint talked about in theory of constraints and the book “the goal”.

Now the main idea - in every system there is always at least one constraint reducing throughput.

How do we know there must be at least one constraint? Because otherwise the throughput would be infinite.

There are typically many more constraints, but they are not all active at one time. At one time there again is typically only one constraint.

Why? Because otherwise we would need to have 2 constraints with the same level of impact on the value stream, and that is simply improbable.

Now, why would we not want to have people working at 100% utilisation before the constraint? Because they would only be producing a constantly growing pile of work in progress, since we are unable to push it through the constraint. This would artificially increase the complexity in your organisation, add noise and lower visibility.

We want the constraint itself to dictate the speed at which work in progress is provided at the input.?

Secondly, we want to optimise the throughput of the constraint whenever we can. And in the case of software it is frequently possible, and frequently quite straightforward.

Wouldn’t it be good to have the entire software value stream take hours instead of weeks? From requirement entering the backlog to a done software iteration and valuable increment in days, hours, minutes, instead of weeks, months and years?

• Do you have requirements sitting in your backlogs for years, until people forget where they even came from?
• Are people in your organisation afraid of deleting these kinds of work items?
• Are your backlogs measured in hundreds of items?
• Does your organisation understand its own value stream?

The ideas of lean manufacturing, understanding of flow, optimisation of throughput of your value stream, value stream mapping and removing waste are universally applicable in any industry, including software. They helped revolutionise ways of working and provided 10 and 100 fold increases in profitability.

They are the fundamental basis for ideas like continuous integration and delivery, along with scientific method, quick learning cycles, minimalism and empiricism.

Read “The Goal”, “The Phoenix Project” or “The Unicorn Project” today, and change the overly complex, noisy, command and control culture of your organisation. Adopt value stream mapping and the idea of pull to understand what your goal is, and how to optimise it as a whole.

Thank you all for joining me today. Please like, subscribe and share, provide super thanks or Patreon support if you can, and have a beautiful day. Until next time, your software minimalist.