This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games.
The central idea of Kanban is flow optimization. While Agile methods like Scrum are focused on creating and maintaining a central multidisciplinary team, Kanban accepts a non-optimal situation: teams are not 100 percent dedicated to a project, and project work is done in phases outside the core team. This is similar to the situation in StarCraft.
In StarCraft, you do not have a core team that executes building, movement, and combat. What you do have are multiple groups of units (or bases) and limited time to give orders. What do I mean by multiple groups? During the game, a StarCraft player has to switch between units and bases, giving commands to solve current issues, like building new buildings or units, or attacking enemy units and building up a bridge-head. Each location basically is a “group” in that regard.
Translating that into Kanban requires some thought. Imagine that every StarCraft group gets new “tasks” whenever something should be done, strategically or tactically. When you produce a new unit, then that unit needs to be deployed to a location; when you see an enemy dropship flying by, then your units need to intercept it; when you complete the construction of a new base, you need to start gathering resources, etc. Likewise, the amount of time you invest at each group location to work through those tasks relates to the manpower you would have in a Kanban project. You can imagine that it is not wise to spend minutes working on your economy while your base is overrun. Likewise, if you do nothing but defend your base and micromanage your units, work (like expanding the economy) piles up at other locations. A good StarCraft player will be able to analyze the situation and surmise that maybe she spent too time in one location while ignoring the tasks piling up at another. So, she will correct the workflow to spend more time on other tasks as well, helping out those groups.
With time being an important resource in StarCraft, novice players are inclined to spend as little time as possible on certain tasks. They may place buildings wherever there is space at that moment and then move on to the next army group to do the same. Units then might have to maneuver around these misplaced buildings. Or, perhaps factories are placed far from the front line: costly seconds as forces will take longer to replenish or mount an attack. Searching for individual misplaced buildings in order to give new production commands can slow forces down.
TECH-DEBT · In software terms, “tech debt” usually refers to code that later needs to be rewritten or systems that later have to be scrapped and rebuilt and reconfigured. The term can apply to anything that saves you time now but has to be paid back later in the form of additional work.
More advanced StarCraft players seldom to never take up such “tech debt.” They do not place buildings in the walking path of the units. They concentrate production facilities so that when they quickly switch back to them during combat, they save those precious seconds that could give them the edge in micromanaging combat. Their game flow is highly optimized; they don’t spend too much time at one place. What can we learn from their approach?
Of course, I do not want to imply that you should never take up debt. Remember that you do not want to build a perfect product but instead to strike at the right time with the right product. Cutting corners in that regard can be OK when connecting it to a clear purpose and when keeping in mind the added later costs. Where Kanban can help is identifying when fast-tracking a task can be useful, and setting up reminders to work on it by adding it to the Kanban board. Once the objective is achieved, this task should be worked on soon because it will continue to add costs to the deployment of your existing units (or your product) or the time needed to produce new units (or products). Keep in mind, though, to limit the number of tech debt tasks and to eventuallywork on them. If the tech debt reaches the final product, you might have been better off changing your idea of when a task is “done” instead of aiming for higher quality but never living up to it.
In terms of reporting development speed, you might want to not (or only partly) include any fast-tracked tasks, as they ultimately do not add to the finished product. Toward the “general” (business), it is important to visibly demonstrate that a decision to speed up a project at the cost of such tech debt has consequences. There needs to be a justification for how this early time-saving ultimately saves, not costs, money.
How does Kanban solve the problem of long waiting times?
Another point is how to actually deploy your units to the far-away front lines. StarCraft provides an automatic feature where you can just set a waypoint for each building and the units will then, one by one, move toward that point. The big problem here is that this can cause additional costs. First, those units in transit are hard to control as they are individual groups spread over half of the map. Second, your supply line of new units can easily be disrupted by an enemy’s strike-force. Both of these problems also appear in normal production within a business. Some of the tasks might require long regulatory processes or are interrupted by long delays for ordering new hardware prototypes, or even disrupted by supplier problems or competitors. Inside the company itself, handing over a lot of small tasks one-by-one to the next team might likewise interrupt their work as they might need briefing for each item.
Hand over reasonably sized tasks to the next department. This is the equivalent of sending out groups of units over the battlefield instead of trying to micromanage individual units. Kanban mitigates problems with external suppliers by at least optimizing the throughput and workflow so that the cost, up until ordering a new prototype or starting the regulatory process, is lower. In addition, consider starting the same long process multiple times and earlier. Imagine you are building a new mainboard for your machine and the supplier will take 10 weeks to finish it. Instead of working for four weeks, finalizing the board and sending out the order, send out the first order after two weeks with a half-finished board, then send out another order after four. Sure, you will still get the final board only after 14 weeks, but maybe you will discover a problem with the first prototype after 12 weeks. You will have reduced the delay for a possible defect by two weeks at additional costs for ordering. In some cases, if your development time, not your ordering expenses, is the bottleneck, this might be worthwhile. Translated into StarCraft, it simply means that you can send out the second army group while the first is still on its way. Maybe the first army group will defeat the enemy. If it has to retreat, your second army group is ready to support them—lower risk at a higher cost.
Another Kanban approach is to include the external supplier as a part of your supply chain: the visualization on your Kanban board will show them to be the bottleneck, with work piling up on their side. Ask yourself how you can help them! Maybe they can produce a first prototype with more lax specifications; maybe provide them only with test cases and acceptance criteria instead of asking them to build it exactly to your specifications. Perhaps have your team visit their factory to speed up the setup, or invite them to your meetings to get them started right away once you are ready. In software development, make use of mock systems or models that simulate the systems you ultimately want to connect to or users who will use your system. Find people within your company to test unfinished prototypes that have not yet passed the long internal regulatory processes. Early feedback is the key. In StarCraft, you could think about building production facilities right near the front line (they are relatively cheap!), or you could spend some time re-examining your current building setup. Do not be shy about destroying buildings in your way or building extra facilities closer to the front line to speed up the deployment.
In the end, though, you need to have an idea about how to release your product. Start with delineating your release process. Writing everything down helps to make clear which parts of the release process are unfinished. All too often, a company produces something without really knowing how to distribute, market, or sell the item—this is mostly true for companies who have faced little to no competition, be it because they are the only one on the market or because they are a startup.
Likewise, in StarCraft, ask yourself what you will do with a unit. Is a dropship ready to be deployed? Do you have set waypoints? What army group will you assign it to? What is its purpose? The time a unit just stands there unused costs as much as the value another unit would produce during that time.
Ultimately, all the points mentioned above are pretty obvious once you see them. The key is to visualize what is actually going on. Far too often, I have seen that features are produced but then never used. This is partly because of the 100 percent fallacy mentioned previously, which leads to a lot of items getting “pushed” to the next department as opposed to being “pulled” by, ultimately, the customer.
One good exercise in StarCraft is to make a cooperative play where one player solely commands combat units while the other player solely commands production units and facilities. Observe how they develop a strategy of communication. Will they favor “push” or “pull”?
