This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games.
StarCraft is a game of real-time strategy. Beginners who are new to this concept tend to make a critical mistake: building just one of each type of factory and filling its building queue. The big advantage of this approach is that the factory works at 100 percent efficiency with no idle time, and you do not need to spend extra time issuing new commands to the factory. This is comparable to having specialists working on their pile of tasks with a 100 percent workload. From a classical project management view, this sounds perfect. No idle times, and maximum productivity.
The problem is that having your factories run without idle times is not an objective of the game. You can pat yourself on the back for having such effective factories, but you will not win the game because of it. In project management, these “factories” are your workers. A common management stance is, unfortunately, the idea that you have paid for the worker’s time (40 hours a week) so you need to do something with him or her for 40 hours. But this is local optimization, more like an intellectual evasion, as in “I managed to occupy my workforce full-time, so I must be doing things right.”
This approach of issuing commands requires management time. In StarCraft, you need to tend to combat and unit production at the same time. You need to interrupt managing your army and switch back and forth to and from production. The alternative is to plan in advance, spending or reserving additional resources, and risking being unable to react to changes. If you do not want to do that, you have to rely on time-boxing. Just as you focus on one task at any given moment in Kanban, you focus for a while on combat in StarCraft and only afterward switch back to managing production facilities.
TIME-BOXING · The idea of time-boxing is that you can be more efficient by working on similar tasks during one time period. For example, instead of answering emails throughout the day, reserve half an hour each day to work through any unanswered emails. This eliminates the overhead of having to refocus between different tasks.
Time-boxing with just a few workers or production facilities available can be expensive, though. One way to mitigate that in StarCraft is to invest in multiple production facilities. Your resources will otherwise pile up while you are not giving new production orders. You need only to switch back once, give all the orders, fill the production lines in your factories, and then return to combat with a fresh army waiting for you when you switch back the next time. While more facilities might ultimately mean that some of them will stay idle at times, you will be able to effectively turn over your resources into new units and replenish your forces more quickly compared to putting all your orders into a backlog pipeline which would bind resources you could use somewhere else: it takes time to plan and re-plan all those orders in the backlog when there are changes.
In Agile, you try to protect the team from having to go back and forth to their “production facilities” (e.g., new tasks from management, emails, interruptions in the room, bureaucracy) and instead work on a task until it is fully finished. In Kanban, with the limitation of simultaneous “in progress”-work, tasks do not get dragged along. There will be a stronger tendency to prevent tasks getting “90 percent” finished (with a business value of zero) and then left unfinished for a more pressing task.
In this context it might be interesting to mention the so-called “Pomodoro technique.” It also uses time-boxing, although for the opposite reason: you should not work on a task for too long. Keep the tasks small by breaking them up into units and taking a break in between units. Looking at this with “Kanban eyes,” this approach also helps to improve the flow of work. Individual tasks don’t block the workflow for too long, and the next department can work on a task (or unit) sooner and in smaller increments.
POMODORO TECHNIQUE · The Pomodoro Technique is a simple time management technique that allows focus on one task, followed by a break, then moving on to the next task [Cirillo, 2017].
Real emergencies require a slightly different approach. In Kanban, this is usually implemented by adding a horizontal “fast lane” with the highest priority and with a very low “work in progress” limit. For example, if the company website is down (or in StarCraft, if you face a sudden previously undetected attack), the task is pulled through the fast lane. The cost of not reacting significantly outweighs anything gained through time-boxing.
The big question is what an emergency is, as opposed to a normal task with highest priority. For example, do all customer requests require being put into the fast lane? What about requests from the CEO? The answers to these questions have to be documented and will constitute a “Service Level Agreement” (SLA). The involved parties have to understand that a requirement for immediate action comes at a cost. Sure, you could prioritize any CEO request as an emergency but that also means that even the CEO’s favorite project will suffer a delay. Even a buffer of a few hours where other tasks can be finished will help to smooth the otherwise disrupted workflow.
SERVICE LEVEL AGREEMENT · Thinking about Kanban leads to thinking about how different departments or teams work together. Written or not, there is always some sort of contract between the parties involved. A Service Level Agreement is such a contract and usually denotes the time between the initial request (e.g., for a software fix) until the first response by the team. This contract is established implicitly when people meet the first time or have the first telephone call. “Do you have a minute?” “Sure!” is a common contract. It means “Drop everything you are doing right now and focus on my problem.” For the person requesting the service, this means that the supporting person is available on very short notice and ongoing work can be interrupted. In Kanban, with time-boxing, the answer is “Sure, but let me first finish what I am doing right now, and check if there is other, even more important work.” If the current tasks are generally small, the request will still be worked on within a short time, but any overhead related to stopping and restarting current tasks is prevented.
In StarCraft, an “SLA” would be anything that gives you more time to react by predicting your opponent’s moves. Map scouting and detection help you to finish what you have started. Your SLAs will always be changing, though. If you have scouted your enemy preparing dropships to attack your base, you might want to set the reaction time very low. For some remote empty base, you might want to set the reaction time much higher or even ignore an attack completely. Ultimately, the lesson is that it is OK to make small “mistakes” and to delay certain actions in favor of other, more important ones.
What about the other kind of problems, “defects”? Imagine you are attacking the enemy, moving your force near the enemy’s base, only to discover that you are missing a crucial unit or ability. Maybe you forgot to build a scanner to detect invisible units, maybe you are missing a medic, or perhaps you discover the upgrade your attack depended on is not finished. This is comparable to a situation in business when a story is supposedly finished but is found to be defective in the next phase (testing). What options do you have?
Imagining it again through the game of StarCraft, first, you could move your units all the way back to where they started, wait for the missing unit to be finished, then move back to a new attack. This certainly works, but seems ineffective. A better way is to first check whether the attack can proceed anyway (i.e., if the product can be shipped anyway), proceed or retreat to a safe position, and then (if still necessary) file a defect at the base to produce the additional unit or ask your teammate to help out. In business, the defective story will block the testing team and they might hit their work-in-progress limit. If this occurs, they will either directly ask the development team to help out in typical Kanban fashion, or they will move the story to a parking position (not affecting the “work in progress” limit), adding a defect to the development team (affecting their “work in progress” limit).
WORK IN PROGRESS · The general idea in Agile project management is to limit the number of things you work on at the same time. In Scrum, you limit it by setting a fixed time frame (sprint) for a work package. In Kanban, you directly limit the number of tasks or projects worked on. This reduces overhead and automatically will lead to more complete tasks. If you can focus on but a few tasks and bring them to a finish, they are no longer dragged along half-finished without any value.
The solution you ultimately choose really depends on your business and the workflow. It might be unclear who actually caused the defect and who can fix it. Imagine the sales department is unable to close a deal; is it then a problem of the marketing department? Or is it the product itself that does not fit the customer’s need? Implementing Kanban also means that you have to start asking those questions and thinking about a solution instead of relying on uncoordinated emails and case-by-case decisions.
A good approach is to create a ticket, but to assign it to a special support group who knows the product very well and have them analyze and decide which department most likely caused and/or can possibly fix it. And maybe the supposed defect is not a defect at all, so this would also shield other departments from false positives (“It’s not a bug, it’s a feature!”).
