This is the third post in the series āTheory of Constraints in software startups.ā If you havenāt read the other two. I recommend starting with those: part 1, part 2.
Everything was better in the 80s, so letās go back in time for a minute. Imagine you are a worker on a plant. The plant is supplying parts to Toyota factories, where they assemble the gorgeous Corolla AE86.
āFactory worker on roller skatesā by CristinaĀ Amate
Your shift starts at 7 am. You come to the plant 10 minutes before, change and go to the Kanban storage area. There on your shelf you find one card with the name and the number of the part you will make.
Kanban card
Once the part is done, you put it on the designated shelf and go back to the Kanban storage area. This time there are no cards on your shelf. What happens then is the result of a hundred years of evolution in management. The genius invention of Taiichi Ohno calledā¦ actually, I donāt think it has a name.
If there are no cards on your shelf. There are no parts that the plant needs from you at the time. So hereās what you donāt do. You donāt just start running parts that you think you āmightā need in the future, you donāt go to managers and ask for work to do, you donāt go help your colleagues do their job.
You do nothing. No-thing. Nada, nichts, nenio.
This technique, using Kanban cards to control work on a factory floor, is a part of a larger framework. The framework is called Lean or Just-In-Time.
The goal of Lean is simpleāāāminimize waste. There are different ways to classify waste, but I like to think there are just two big groups:
Letās say we are managing supermarketsā supply chain. We are making sure each shop has just enough supplies. It is a tough problem and the solution directly impacts the bottom line of the company:
Waste is a universal concept. Orders in a supply chain, inventory on a plant floor, product features and bugs, customer projectsāāāall can be a source of waste. Today Lean is used anywhere from a production line to a startup business.
Too much work leads to waste, too little work leads to waste, how much work leads to shiny mountains of gold? Enter Kanban.
In a non-kanban process the previous work center decides when tasks get pushed to the next work center. It creates issues down the line where one of the work centers might be overloaded with other projects.
Here is how a B2B startup might handle customersā projects:
Customersā projects flow in a B2BĀ startup
Letās say a Customer agrees to do a Proof-of-Concept (POC) with us. The worst thing Sales could do is to ask Customer Success team to handle the project right away, without taking into account how much work they already have on their plate:
New projects will have toĀ wait
Letās say Sales did consult with Customer Success, and those have the capacity to handle the new project. Should we agree to take it?
Customer Success has capacity to handle the newĀ project
In a non-kanban process thereās no way to know if we can take the project. What can go wrong is that thereās a part of the system down the line that simply doesnāt have the capacity:
Engineering doesnāt have the capacity to do work on the newĀ project
We can fix that organization by creating a feedback loop. We make it so the following work center decides when the work center before should start or stop working.
Engineering signaling that it canāt take up moreĀ work
Feedback propagates from the next work center to theĀ previous
With that feedback loop we now know when to start new projects so that they donāt spend time waiting for resources.
Letās take Kanban for a test-drive in our simulation.
In the previous post of the series we saw how our dream-team drove the company into the abyss of ever-increasing inventory and lead times. The problem was that the team was doing too much work.
We can, of course, be wasteful by going radically in the other direction too. Letās say we start with only one spec every other month when the system can do twenty every week (which there is enough market demand for). In this case we are wasting opportunities by not utilizing the system enough.
Hereās how we can fix the process with Kanban. We have three work centers: Product Owner, Devs, and QA. We will give 13 Kanban cards to QA. Theyāll use those cards to āorderā features to test from developers. Devs can not start working on a new spec until they have a card from QA. Once they finish a task, they move it to the tester together with the card. Once QA gets back the Kanban card, they can use it again to āorderā work from developers.
Weāll do the same with Devs ordering specifications from the Product Owner. Developers will have 7 cards.
Iāll talk later about where those concrete numbers for WIP come from later. First, letās run the simulation.
Some observations:
Letās compare the Hard-working team and the Kanban team over 20 days.
Comparing Hard-working team vs Kanban Team. On the left: lead time by task, on the right: inventory overĀ time.
The Kanban team is crushing it! WIP limits helped them take inventory and lead times under control. They can predict and plan with certainty and can finish tasks faster. All of that is possible because they know when to start and stop working.
āSignaling systemā by CristinaĀ Amate
Kanban is a signaling mechanism set up between actors of the system. It notifies them about when to work and when to stop.
Kanban is also an instrument of balance. Once we set the work-in-progress (WIP) limits, the system regulates itself. Thereās no need in hands-on control.
We can use Kanban to manage the flow of work in one team or in an organization as a whole.
Here are some of the benefits of this approach compared to just āworking hardā:
Once we focus on minimizing waste, the effectiveness of the organization goes up.
It all sounds good, but we havenāt yet talked about how to actually set up those work-in-progress limits. This is, in my opinion, Kanbanās weak spot, because:
Setting up Work-In-Progress limits is hard.
Kanban practitioners encourage us to start with something and adjust WIP limits as we go.
To put things in perspective, I had to run the simulation about 10 times on paper in order to figure out actorsā WIP limits and Iām still not happy with results. For example, I know we can lower lead times by changing the WIP limit for Devs. Try it out yourself, if you like.
We can make an organization more effective if we minimize waste. For that we need to do the right thing, but also we need to be smart about the way we do it.
Kanban is a smart mechanism that makes different parts of the system communicate and balances the work.
Kanban is not easy to implement and maintain because we need to adjust WIP-limits regularly for every work center.
I know I know, Iām sorry. Trust me, this other stuff weāre talking about is important. Weāll get to it. Actually, now is a good time to make that intro.
Eli Goldratt built his Theory of Constraints on top of existing frameworks like Lean and 6-sigma during the 80s. His breakthrough idea is that if we want to improve the system as a whole, we donāt need to worry about every single work center. We should focus our attention on a single actor in the system, the constraint.
He understood that no matter how complex the system is, no matter how many parts it has and how intricate the workflows are, each system has only one constraint. Weāll talk about how to use his discovery the next part of the series.
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Ä.
Special thanks to Cristina Amate for the illustrations as well as her support and early feedback on the talk and articles.
Iām looking for opportunities to talk about Theory of Constraints in startups. If youād like to recommend a conference or invite me to speak, please reach out: https://flpvsk.com