In this episode, I discuss the Theory of Constraints as introduced in the book The Goal by Eliyahu M. Goldratt. Modern software development methodologies (Agile, Lean, DevOps) place a heavy focus on the flow of quality work through the development process - and the continual improvement of that flow. The Theory of Constraints helps us to identify areas of improvement within that flow. Note: I originally recorded this as one episode, but have subsequently split into two parts during the edit. Part 1, this episode, introduces the ideas of flow and the Theory of Constraints using a simplified manufacturing line example. Part 2, next week, applies those thoughts to our traditional software development practices and look at how we may traditional have tried, unsuccessfully, to resolve those constraints.
Or listen at:
Published: Wed, 22 Sep 2021 17:46:00 GMT
Transcript
Hello and welcome back to the Better ROI from Software Development podcast.
In this episode, I want to introduce you to the Theory of Constraints.
But before we actually get into talking about the Theory of Constraints, I want to set some context. I've talked to a number of times in my episodes about the concept of flow, the ability for work to flow through the system in an efficient and effective manner. If we look at Agile, Lean, DevOps - all of these movements work towards creating an efficient flow of quality working software through the development process. Each of those methodologies focus on improving flow over time.
And this focus on improvement of flow is in direct contrast to the more traditional waterfall methods of project management and software delivery, which focussed on the task. The more traditional waterfall method will focus on individual tasks and activities as collected in maybe a Gannt chart or a spreadsheet in a list of projects and tasks that need to be completed.
Whereas Agile, Lean, DevOps will all be looking at the flow - how work is processed through the system and improving that over time so that we can get more quality working software delivered quicker - more benefit to you and your customer.
The concept of flow is not new.
Flow has been with us for a very long time in the manufacturing space. Many of the agile techniques actually come up through looking at manufacturing techniques - manufacturing techniques to improve flow.
If you look at all of those methodologies, whether we be Agile, Lean or DevOps, there's a quite clear link back to the idea of manufacturing and the flow of work through some form of production process.
And the idea of flow is probably quite easy to understand when you look at a manufacturing line. You have a number of stations, a number of activities from goods in to a finished product. The idea of flow is efficient travel of that initial goods into goods where it can be delivered on to your customer and thus make money.
So let's move on to the Theory of Constraints - the Theory of Constraints was originally introduced in the book The Goal by Eliyahu M. Goldratt. The book is written as a novel where we follow our hero, Alex Rogo, through how he's managing a manufacturing plant, how he's using techniques described in the book, and how he learns these techniques to take his plant from being one due to closure due to underperformance, to being the shining light of the entire organisation.
As the book is written in a novel format, you really buy into the struggles Alex and his team go through. It probably is one of the most entertaining reads for what is effectively a management book. And by the end of it, you are really invested in Alex and the team and willing them to sort out not just their manufacturing plant, but their own work life balances.
So what is the Theory of Constraints?
Wikipedia describes the Theory of Constraints as:
"The theory of constraints (TOC) is a management paradigm that views any manageable system as being limited in achieving more of its goals by a very small number of constraints. There is always at least one constraint, and TOC uses a focusing process to identify the constraint and restructure the rest of the organization around it. TOC adopts the common idiom "a chain is no stronger than its weakest link". That means that organizations and processes are vulnerable because the weakest person or part can always damage or break them, or at least adversely affect the outcome.".
Wikipedia then goes on to say:.
"The underlying premise of the theory of constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput. Throughput is the rate at which the system generates money through sales."
So let's try and understand a bit about the Theory of Constraints here - that idea of addressing the weakest link in our chain is a really good metaphor. It's the weakest link in our chain, which is inherently going to control how much throughput our process will allow.
Take for example, you've got a simple manufacturing line. You have three machines that your raw materials need to go through before they can be sold onto the customer.
You have machine A, which can process 100 units per hour.
You have machine B, which can process 50 units per hour.
And you have machine C, which can process 100 units per hour.
Because your raw product has to go through A, then B, then C before they can leave your factory and make their way to your happy customer, you have that constraint of B.
While both machine A machine C can process 100 units per hour. They're constrained by B because it's bottlenecked at 50 an hour.
Now, in this simplified example, it's very easy to see where the constraint is. The constraint is that machine B, because it can only do half the amount compared to machine A and machine C - it's obviously slowing us down.
It's obviously slowing down throughput through the system. But often identifying those constraints are not simple.
The theory of constraints will have us focus on those constraints.
It defines five steps:.
One, identify the systems constraint. In this case, our constraint is machine B. It's so much slower.
Two, decide how to exploit the systems constraint. So how would we exploit the constraint if it's machine B? Are there ways to increase the throughput of machine B? For example, could we run the machine longer the machine A and C to catch up?
Three, subordinate everything else to the above decisions. If your bottleneck is B, then there is no point in A producing more than B can handle. Otherwise, all you're doing is you're spending money on an extra inventory, extra raw materials coming in, the money processing them in A and then having to pay for that partial complete unit sitting in inventory waiting to be processed by B - you're tying up large sums of money.
Four, alleviate the system constraints. If we can improve B, let's improve it. Maybe we could purchase a second machine B and have them running in parallel.
Five, warning if in the previous steps a constraint has been broken, go back to step one, but do not allow inertia to cause systems constraints.
These steps effectively produce a cyclical process. One where you start by identifying the system's constraints. You work out how to improve them. You work out how to make everything round it, work towards it. And you keep going round and improving as much as you can.
Ultimately improving the throughput available to deliver those quality products.
Now, this may all seem like common sense - and indeed the book, The Goal, talks about how often so much of what Alex and his team find they describe it almost common sense.
But that wasn't what was being done in manufacturing at the time.
And its probably not being done in most businesses now.
Take our example where we've got machine A, machine B, machine C - often what we'd be doing is we'd be looking at the efficiencies of those individual machines and the teams.
We know that machine C can do 100 per hour, but it's only going to be getting 50 per hour from machine B. This is where we find we're looking at the efficiencies of machine C and we're going "Well, it's only 50 percent efficient. What can we do with machine C?"
We may find them other jobs to do. Other activities which we believe may be useful - maybe creating surplus stock. And this seems like an appropriate use of that individual resource. But as the book goes through, you find that by doing that, what we're actually doing, is hurting the overall flow.
The individual station, that individual machines C, maybe 100 percent efficiency by doing the extra work, but the actual flow as a whole slows down.
Because we have machines C doing other work while it is waiting on B, it will rarely be ready to pick up the work from B immediately. Even if it's only 15 minutes to switchover, we have effectively delayed the overall throughput by that 15 minutes.
Plus the extra output from machine C is likely to be tying up investment for stock that may never be sold.
Another way to think about this is road traffic. In any given section of road, you've got point A, point B, and you've got cars travelling through. And you may think the most efficient way of getting as many cars through that stretch of road as possible is to have 100 percent utilisation - you have as many cars as you can fit.
Unfortunately, from a practical point of view, there'd be variation between speeds. And as such, you can only go as fast as the car in front of you. And what you get, even if the road is set at a specific speed limit, say, for example, 70 miles an hour, you will have statistical variance between the drivers on it.
Even if you ask all of them to drive at exactly 70 miles per hour, it won't happen.
There will be statistical variance. And as such, some of the cars will go a bit faster, but some of the cars will go a little bit slower. Those cars that may be able to go faster, will only be able to go as fast as the car in front of them. So if they've got a car that's going slower than 70, then that's the speed they go.
And you'll find that what you get is a bottleneck situation where you get incremental slowdown in the line of cars, because effectively any car can only go as fast as go in front of it.
By the time you get any distance back, effectively you've probably come to a standstill. And this is why I've previously described 100 percent utilisation as being the equivalent of being a traffic jam. You've used the entire space on your road by filling it with cars, but they're not going anywhere because they don't have an ability to flow.
And that same concept of statistical variance happens in manufacturing.
So going back to a machine A, machine B, machine C, it wouldn't ever be as simple as machine A produces 100, machine B produces 50, machine C produces 100. You'll find there will be statistical variance between them, both in terms of the quality and the quantity.
So machine A may average 100 usable quality parts. But in any given hour, it could produce only 75 or could produce 125. Making it so much more complicated to understand and produce that effective flow without taking into consideration any constraints in that process.