Part 4 of the series “Theory of Constraints in software startups” This is the fourth post in the series “Theory of Constraints in software startups.” If you haven’t read the others, I recommend starting here: . part 1 There are thousands of possible reasons for a piece of software to not perform well. How many ways do we have of finding and fixing those issues? There’s one way we can do it. Thousands. One. Choose what is that you want to improve: speed of execution, memory consumption, something else; Identify the place in the code using tools like CPU or memory profilers; where the issue is the most present Improve the piece of code that you found on step two. Because that piece was performing the poorest, the system as a whole will improve; Go back to step 2. Chrome Memory and CPU profiler Improving performance of a business or a team is no different. Once we understand the goal of the system, we can find that we need to control to improve the system as a whole. That was the brilliant idea behind Eliyahu Goldratt’s Theory of Constraints. exactly one constraint A quick heads up. This part of the series is a titbit more theoretical than others. It might require some extra energy and curiosity on your part. Thank you for taking a swing at it, I hope it will be worth it! Looking for the Constraint There are metrics that can serve as CPU and memory profilers data for a business. We talked about them in . The two most important ones: the first part of the series or how much useful work does the system complete over a fixed period of time; Throughput or how much work is in the system but will be released at some point. Inventory stuck Constraint of a system is a department or process that limits the output of the system as a whole. Throughput of each element of a three-part system In other words, constraint is the element in the system that has the lowest throughput. One of the indicators of a constraint is growing amount of inventory in front of it. Every system has (in rare cases two, but never more) If you’ve found more than one constraint, most likely you haven’t defined the system and it’s goal clearly enough. only one constraint . Throughput of each element of a nine-part system If we can measure throughput and inventory level of every step of the process, we can find the constraint. But we can’t measure abstract concepts. What exactly are our throughput and our inventory depend on the system and its goal. Example Let’s say we’ve founded a startup and we are doing . As an early stage company, our goal is to find a problem worth solving and a viable solution. We work towards that goal using an iterative process of formulating and validating hypotheses. customer discovery Average throughput of each step of the process We know we found problem-solution fit when during interviews 8 out of 10 potential customers are willing to give us something of value. We are looking for some kind of commitment from them — could be time, money etc. of that system is the amount of hypothesis we have validated during one month that improved the score (increased the amount of committed potential customers); Throughput of that system is the number of hypotheses we’re working on at a given moment. Inventory The constraint of such a system is a department or process with the lowest throughput. In our case it’s the “Prototype” stage: Inventory in the system One indicator of a constraint is a growing pile of inventory in front of it, aka a large backlog. What can go wrong? the constraint is limiting production capacity of a system. That also means that if we manage the constraint well, we can . By definition, only increase the throughput of the whole system the constraint was the hard part. By comparison, it is fairly straightforward. We need to avoid these two things: Finding controlling 1. Underutilising or “starving” the constraint. Every other department or process has extra capacity to waste, except for the constraint. If is not producing useful work, the output of the system suffers; the constraint Underutilising constraint leads to waste 2. Overproducing or “overloading” the constraint. If departments are always overproducing, the inventory in the system grows continuously. we saw what it leads to. Things take ages to complete. before the constraint In the previous article Overloading the constraint leads to waste Example Here’s what we could do wrong in the startup example above: Startup example process In this process we must make sure that the Prototype phase is never starved. For example, the Prototype Team might be blocked waiting for specifications to build. They could also be doing bogus work validating ideas that could be rejected without a prototype. The time of the constraint is the most precious resource in any organisation, we shouldn’t waste it. the constraint in this example would mean to keep producing hypothesis and stacking them in the Prototype’s Team backlog. What will this company do with a list of hundreds of ideas? Best case it will add overhead to whoever manages the backlog, worst case it will encourage the Prototype Team to multitask. Overloading Improving the flow of work Goldratt laid out an algorithm that helps us continuously improve any system. He is arguing that before we throw more resources at the problem, it’s important to make sure that we improve the flow of work through the constraint. He proposed these mechanisms to achieve it: 1. Exploit the constraint. We should make sure that the constraint is 100% utilised. That there’s no downtime due to any reason. That the constraint is doing only work. useful 2. Subordinate other elements of the system to the constraint. Other parts of the system need to maintain a continuous flow of useful work through the constraint. Often times it means that those parts themselves would be working “inefficiently” in order to make the constraint and hence the system as a whole more efficient. Example Even though the “Exploit” step seems straightforward I often see teams fall into the trap of making the constraint wait for resources. The most common example I saw and experienced comes from Engineering. Let’s say our engineering process looks like that, with QA being the constraint: Engineering process Let’s say we use Scrum. We select a bunch of features and bugfixes before the sprint starts and then try to finish them during the iteration. The problem is that for the first half of the sprint (until developers implement the first feature) QA will have no useful work to do. The constraint is under-utilised. Scrum process will hurt this team’s performance. Now let’s say QA returns 70% of tickets back to developers for rework. That means that QA would have to go through most of the issues two or more times. We can other elements in the system to help lift some of this burden on our constraint. For example, we can ask developers to test each other’s implementations before they go to QA. subordinate In the last example developers will have to do work they are not qualified to do. Their efficiency will go down, but they are not the constraint, QA is. In that example by making developers less efficient, we make the system as a whole perform better. Five focusing steps In , Eliyahu Goldratt laid out a process of continuous improvement of organisation. Step zero is to . Then we follow the steps: his first book any formulate a clear goal Find the constraint; Exploit the constraint; Subordinate other parts of the system to the constraint; Elevate the constraint (give it more resources); If the constraint has been broken, repeat. It’s an iterative process. We find the constraint, try to get the most out of it, add more resources only if necessary and repeat if the constraint has been broken. The purpose to gradually remove all constraints, but to know where the constraint is right now and how we can get the most out of it. is not The scariest place you can be in as a business is not knowing your goal and your constraint. Our experience with ToC has been very rewarding. Initially, we’ve applied it to different isolated parts of the company. First engineering, later product and sales. Gradually we’ve noticed that it works best when applied to an organisation as a whole. At Productive Mobile we used it to set up health metrics for each team, to structure the product roadmap, and even to remake our sales strategy. Personally I’m using Theory of Constraints as a mental model to reason through system. It helps me reduce complexity and focus. It’s been a liberating experience for me. any Enough Theory! Now that we’ve got the theory part out of the way, I hope to give more examples from real world situations in the next articles. If you have tried ToC yourself, please share your experience in comments. Till next time 👋 I’d like to thank people that shared their experience and useful insights with me. Their inputs are the foundation of this series. In no particular order, these people are: , , , , , . Stefan Willuda Ricardo J. Méndez Ed Hill Adiya Mohr Conny Petrovic Goran Ојkić
