Running Kanban like itāsĀ 1984 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 a name. has 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 . 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. donāt do You do nothing. No-thing. Nada, nichts, nenio. Just inĀ time 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: Work we did that we shouldnāt have done. Thatās ; wasted resources Work we should have done but didnāt. Thatās . wasted opportunity 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: Order too much groceries and they expire before we can sell them. We lose money. Wasted resources; Order too little groceries and a customer wonāt buy what they are looking for. Do it frequently enough and we lose the customer. Wasted opportunity. 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. When to turn off the Sales department 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 decides when tasks get pushed the previous work center 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 , without taking into account how much work they already have on their plate: right away 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 . What can go wrong is that thereās a part of the system down the line that simply doesnāt have the capacity: thereās no way to know if we can take the project Engineering doesnāt have the capacity to do work on the newĀ project We can fix that organization by creating . We make it so decides when should start or stop working. a feedback loop the following work center the work center before 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. Dream team switches toĀ Kanban In the 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 . previous post of the series 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 the system enough. not utilizing 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 . Once QA gets back the Kanban card, they can use it again to āorderā work from developers. together with the card 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: After initial ramp-up of 8 days the team is stable and is releasing every 4 days. After 20 days we have released 24 tickets; Often because of the WIP limits PO and Devs capacity, QA is the only one working at 100% capacity all the time; are not working at 100% Work in progress never goes above 15 tasks; Lead time never goes above 10 days per ticket. Showdown 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 can finish tasks faster. All of that is possible . and because they know when to start and stop working Why useĀ Kanban ā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, . Thereās no need in hands-on control. the system regulates itself 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ā: The organization is more reliable. We can predict how much time it will take to complete a new job; We know which commitments we can and can not make; Little to no multitasking, because inventory in the pipeline is limited; Less multitasking leads to higher performance and less frustration within the team. Once we focus on minimizing waste, the effectiveness of the organization goes up. Why not useĀ Kanban 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: Teamsā performance in the real world is unstable and unpredictable, thereās no way to calculate it reliably; Each actor in the system will have their own WIP limit. The more actors, the harder it gets; On top of that, we have to use of WIP for every actor. For example, we can not use developersā estimations for measuring QAās inventory. Similarly, Customer Success team will have different units of WIP compared to Engineering. different units Setting up Work-In-Progress limits is hard. Kanban practitioners encourage us to start with and adjust WIP limits as we go. something To put things in perspective, I had to run the simulation about 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. 10 times Summary We can make an organization more effective if we minimize waste. For that we need to , but also we need to be smart about the way we do it. do the right thing 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. ā Andrey, itās part 3 of the series and you havenāt introduced Theory of Constraints yet?! I know I know, Iām sorry. Trust me, this other stuff weāre talking about is important. Weāll get to it. Actually, is a good time to make that intro. now 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 . We should focus our attention on in the system, the constraint. every single work center a single actor 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 for the illustrations as well as her support and early feedback on the talk and articles. Cristina Amate 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
