To the Frontlines

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

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”?


Scrum and Jira: A Love-Hate Relationship

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

Steps to Bring Your Agile Project Back on Track

The ideal way to use Scrum is to have the whole team sit in one room. Usually, the Scrum process is employed by using little stickers, and moving them around on a physical board. Jira makes that easier, but it comes at a cost.

JIRA ·  The on-premise or cloud software Jira by Atlassian is one of the leading ticketing systems available. Beyond a mere ToDo list, it provides administration functionality for projects, Scrum and Kanban boards, custom workflows, custom screens, user rights management, plugins, and third-party integration. The name itself stems from Bugzilla, the software Atlassian originally used for bug tracking. They began calling it by the Japanese name for Godzilla, “Gojira.” When they later developed their own bug tracker, they just dropped the Go—hence Jira! (see

Within a company, Scrum is usually initiated in software teams, because they are the teams who have to deal with the biggest insecurities in terms of planning. Each software project is a completely new project, even if it is “just” a new version. The software market changes rapidly, hence Agile methods are the management method of choice.

There is a glitch in the system, though: hiring people based on their computer skills often comes at a price, namely interpersonal communication. The HR department of a company should take great care to not just hire the best individual coders, but instead, people who can communicate effectively and have a high emotional intelligence (see What Google Learned from its Quest to Build the Perfect Team [Duhigg, 2016]).

We’re a culture that loves technology—sometimes to the exclusion of working with people. As a result, our communication tools tend to be complex and directed at an audience of software engineers. This also applies to Jira, which is often used to manage the Agile process. But is that really a good decision?

First, I doubt you will ditch Jira just because of this book. I, myself, rely heavily on Jira. It is likely that you are reading this book because you are already using Jira, and you will probably not dismantle Jira any time soon!

In the previous chapter, I wrote about the importance of multidisciplinary teams. Tools highly optimized for use with software developers might cause problems when other departments are expected to use them, or when creating a team with a mix of people with different specializations. A company has to be careful not to choose the method that is most effective for only part of the company, and instead must look at the company (or a given product) as a whole.

What can we do about it? Jira is a step back in terms of Agile, as it disconnects people and makes things overcomplicated. What we need to do is recognize the drawbacks of Jira and examine ways around them.

The gold standard of Scrum is face-to-face communication. To what extent is your team practicing this? I recommend taking another look at the Principles Behind the Agile Manifesto [Beck, 2001],What Google Learned from its Quest to Build the Perfect Team [Duhigg, 2016], and “Our Scrum Is Special” on the subject and then, as a first step, evaluate where you are in the process of becoming an Agile company. In what regard do you think your Jira installation helps or hinders your progress?

For example, when creating new stories, Jira gives you the option to write a summary and a description. This immediately leads people to come up with a descriptive name as the “summary,” and enter the actual user story “As a user, …” in the “description” (if at all).

I say: the description field should be used only for the acceptance criteria and the definition of done. Descriptions should not be needed or even seen by anyone outside the Scrum team. Hence, put that (long, I know) sentence into the summary! Your board will look much more structured if all the stories follow a similar naming scheme. Nobody outside the team will be in a rush to look at your board if it is filled with technical jargon. And if we take a step back, that is actually what Scrum teaches: Create a board with stickers describing user stories! Why not do exactly that? Having less (e.g., just a sticker) sometimes is better than having 50 customizable fields.

Another example is epics. These are used differently from company to company; some call it a “bigger story,” some call it a “feature,” for others it is a “project.” If you are using Jira, you first have to focus on defining an “epic,” then on how it is displayed. How would you implement epics when using nothing but paper stickers?

In Jira, epics are essentially “super-stories.” Why? Because Jira offers you a progress bar for each epic. (As this really reminds me of a pre-planned Waterfall project, I find this feature useless.) Much more interesting is the rather simple feature of color. Assigning epics to stories quickly gives you an idea what the story is about, as each epic shows up as a colored banner on the board. With epics, the Jira board comes alive: you can quickly and easily make visual sense of the entire project—where you’re at, what’s left to do, and who’s going to do it. For example, in the past, I often used “Frontend,” “Backend,” and “IT” as three main epics when working on a pure server project (in a non-Agile business environment). On the board, you immediately see what type of stories there are. Once the Scrum process is fully adopted, you will of course utilize user-facing features (as opposed to system components) as epics.

Here, I will leave you with a final point. It is a small issue, yet one that annoys the perfectionist in me whenever I start looking at a Jira board of a new client: the “priority” field. In Scrum, there is no “priority” field. First, within a sprint, it is up to the team which tasks to work on and in what order. If you, as a product owner, want to direct the exact sequence of which tasks are built, that is eXtreme Programming (XP), a topic for another time. Second, even if you take priority into account, who determines the priority? Certainly not the reporter, who might have no idea about the business value or the time needed to implement it, yet who is prompted, by Jira, to fill out the form (better to leave it empty than fill in a meaningless bit of information that will just cause more work for the one reading it). And the product owner already sorts the backlog according to priority, based on business value and estimation. The usual result is that in the Jira backlog, you end up with two types of priorities, critical and urgent, because every reporter thinks his task is kind of important. The priority even shows up as little red arrows—completely unnecessary and confusing.

BACKLOG ·  The backlog of a project is a list of stories prioritized by the product owner according to the business value of each (estimated by the stakeholders and product owner) and complexity (estimated by the team). Keeping a clean backlog is key to success: it is not an idea graveyard! You can move all those nice-to-have stories to a separate list.

Unfortunately, Jira does not allow you to deactivate priorities directly. There is a little trick, though: In the project settings, in the priority scheme, you can create a new default priority and upload an empty transparent PNG file as the corresponding icon. Problem solved and the board looks a little more like a real Scrum board!

How does your team use Jira in your Scrum process? What are your remedies to Jira’s drawbacks? Do you ever simply leave Jira aside and use a pen and paper?


Evolutionary Improvements

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

An individual game of StarCraft could be compared to a single iteration of a new product, a single evolutionary step after which you can examine the replay and discuss and improve your strategy and tactics.

This is time consuming, so to help this process, I have developed a tool, Evolution Forge, that speeds up these learning iterations. It works by running an abstract simulation of StarCraft to test how a certain strategy would actually play out. So, instead of having to play game after game yourself, you can use the tool to quickly try out different strategies and see how fast you would be in the real game.

On top of just testing the speed of a strategy, this tool was designed to come up with new random strategies to reach a certain predefined goal (e.g., building 10 Space Marines in the Barracks) as quickly as possible. I programmed it to make random changes to a basic strategy, run the simulation, test its speed, and repeat the process until the program came up with a faster strategy. Then the program used that faster strategy, made random changes to it, and on and on. In very small steps, the strategy became more and more efficient at reaching the goal.

SPACE MARINE ·  The Space Marine is the basic combat unit in StarCraft. It is the dominant unit in the early part of the game, the only protection between your own base and the enemy. Space Marines are produced in the Barracks and will be used as a basic example, in this book, for build orders. Just like a product needs a number of parts to be able to make a single sale, a lone Space Marine is the weakest unit of the game. Their real power shows when they act in a group, with other units supporting them.

BARRACKS ·  In StarCraft, the Barracks are the first production facility to produce combat units (the Space Marines). Building the Barracks also allows building other, more technologically advanced, production and research facilities, making the Barracks a cornerstone of any build order. The Barracks can be compared with the very basic structure of an enterprise with sales and marketing: No matter how good your product is, you still need to market and sell it!

Unfortunately, the program regularly got stuck because, most of the time, randomly rearranging your strategy leads to the exact same (or worse) outcome (in this case, time until the set of goal units were produced). To really improve, larger changes would have been necessary. But larger (random) changes typically lead to worse results. Does this sound familiar? It is the same situation that can be found in companies where large process changes are introduced. Suddenly, the promised improvement turns out to slow down rather than speed up project work! What to do?

In nature, transitory states become apparent in hindsight. Only then does it become clear how one thing led to the next. At no time could you point to one gene that could dramatically change a life form. No single change is a significant improvement over another because all the parts of a life form are highly optimized. Changing one thing might hinder the optimization of another. So, at first glance, it is a mysterious wonder how natural processes led up to the creation of complex organs. Looking more closely at the evolutionary process, it becomes clear that evolution really is based on very small changes. Nature cannot take a break for a few generations, working on a new prototype. Every single change has to make the life form more fit to its environment.

To suppose that the eye with all its inimitable contrivances for adjusting the focus to different distances, for admitting different amounts of light, and for the correction of spherical and chromatic aberration, could have been formed by natural selection, seems, I freely confess, absurd in the highest degree. Yet reason tells me, that if numerous gradations from a perfect and complex eye to one very imperfect and simple, each grade being useful to its possessor, can be shown to exist; if further, the eye does vary ever so slightly, and the variations be inherited, which is certainly the case; and if any variation or modification in the organ be ever useful to an animal under changing conditions of life, then the difficulty of believing that a perfect and complex eye could be formed by natural selection, though insuperable by our imagination, can hardly be considered real.

— The Origin of Species, Charles Darwin

On its own, a part of an eye cannot see; it would be the same as if you (in business) involved only a single department in product creation. A product without marketing or sales literally will not sell, just like you cannot sell or market if you have no product, just like a part of an eye cannot see.

Or can it? Part of an eye can see if that “part” refers to an earlier stage in its evolutionary development. Just as you can release a software product before it has all its features, you can build a simpler version of an eye that can see. What is the basic element of an eye? The cells that react to incoming light. Imagine you have just a plane of cells that react to light. What can they “see”? They cannot detect the direction from which the light comes, so all they can perceive is whether their environment is light or dark.

You might say, well, this is not an eye! An eye sees images! But a shade of gray is an image, just an image of very low quality. And that is the core idea: find an indicator that describes your product that can easily scale. For an eye, it would be the resolution and definition of the perceived image.

For example, if your project is about building a car, maybe make the indicator speed in combination with fuel usage per 100 miles. If you write a book, try to split it into independent chapters. You can then write one chapter, add the front and back matter and a basic cover, and you have your first version. It might be short, and it might not be finished in terms of editing, but it is a book! Then add one chapter after the other, bringing it to a finish resulting in a complete book.

Coming back to our eye, we could bend the plane of cells in our next version. This allows a very rough orientation about where the light is coming from. We could bend it further and further until we have a basic pinhole camera with a small entrance for the light and a circular layer of cells that can detect the light. Later, we could add a lens and gradually improve the vision until we have an eye comparable to ours.

Complex things can be built by finding a ramp which we can use to gradually make the things better. Once you discover that ramp for your product or organization, improvement becomes very easy. And Kanban can help you find that ramp without making large changes to the organization. Kanban itself is a passive process on top of your existing processes. It only shows you where you should go. You can then take that path in small steps without ever disrupting your organization.

For my software tool, Evolution Forge, my solution was to find such a ramp. Instead of focusing on just one thing, namely the time until the goal is reached, I looked at the overall quality of a strategy. In StarCraft, I simply included the amount of mined resources as an indicator to compare two strategies with the same goal time. When a strategy achieves the same set of goal units with more resources in the bank, it gets ranked higher and is selected for the next generation in the evolutionary process. This is similar to comparing two project plans with the same release date but different costs.

I also apply this principle of small changes in my personal life. I follow the idea of removing one thing each day. I ask myself: do I really need that? How do I benefit from a particular item? Does the happiness it brings outweigh its upkeep? It is one way of simplifying my life. It might not pay off immediately, but eventually, it might just be what gets me ahead, having a clean workspace and home and being able to focus on what is important. This helps me to get unstuck, it gives me a “ramp” to improve when I do not see the next step.

Likewise, when working as an Agile coach, when there is some idle time between tasks, I check the (real or virtual) project room to see if there is one thing that could be cleaned up or removed. When you employ this approach, step by step, your workspace becomes better and people see steady progress—the core principle for motivation.

Kanban is usually focused on the flow of work and resources through a company. What is often missed is to also improve the processes of the individual workers or the workspaces themselves. This can require some outside encouragement to change inefficient processes that have become ingrained in an individual’s work habits. It sometimes requires throwing things away, ending unproductive projects, and maybe even firing people who might actually be much happier in another job. Think about scrapping 10 percent of your current projects and processes every year. If you do not, you will eventually end up with a company that is just busy with itself. Cutting away the unnecessary stuff makes room to focus on what is actually important—that applies to businesses with complex and opaque organizational problems as it does to life in general.

Instead of trying to implement huge organizational programs, think about what small things you can change to improve the situation. While small changes lead only to small improvements, at least they can be easily implemented and their improvements are easy to see. For example, saving your team a few minutes each day by having pens and paper ready when the meetings start might not turn around a failed project or double the sales. But it is something you can be sure will improve team performance. So, instead of thinking about the grand plan and huge change processes, think about what you can improve now. These small improvements might eventually pave the way for larger changes after all.

Teach your employees the costs of not cleaning up—program code, their work spaces, or projects that just increase costs and bring no value. Instead of rushing in to try to keep your team busy with project tasks when they are finished with their current tasks, have them work on issues that they want to fix. Ask the people who are actually working on the project what could be improved: even fixing small things adds up and will give your company the energy to tackle more complex problems. Ultimately, teach your teams to tackle the smaller issues when they are stuck on a larger problem.

Likewise, teach management and product owners not to take up any “monkeys”—work that should be done by someone else, not by them. Advise them that instead of trying to be the hero, adding more and more meetings to their schedules, they could do one or two projects and be fully focused.

Learning from nature requires us to unlearn the hubris of thinking that big drastic changes are required for positive outcomes. The bigger the ideas of how to change a company, the more in peril that company probably is. People promising big dreams bet on circumstance that luck will somehow turn into their favor, grandstanding as the hero. But they will probably have left the scene when it comes to implementing those ideas or will blame others or the very circumstance they bet on if their plan fails.

There is a time to stand up as a hero, though. Standing up against big, “revolutionary” ideas that will supposedly turn everything around and focusing on what can be done incrementally now: that is the time to show courage and perseverance.


Idle Hands are the Manager’s Workshop

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

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!”).


The General

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

“It is the sovereign’s function to give broad instructions, but to decide on battle it is the function of the general.”

— The Art of War, Sun Tsu

When implementing Agile methodology, some things are often overlooked: the organizational structure, the culture of the organization, and the people involved. Management looks at the market, hears “Agile” as the new buzzword and thinks that this is the solution to the problems they (management) figure exist within the development department.

Introducing Agile is a change process and change is hard. Why is it hard? Because over time, no matter how effectively an organization is structured, people fine-tune themselves to their organizational environment to at least have locally optimal work conditions. Changing any aspect of the organization then leads to those local optimizations becoming worthless, which leads to lower productivity and stronger resistance to change.

Because of this, when adopting Agile methods, an organization leader needs to take extra care to not only change one part, but also to change the whole organization (over time). Every part of the organization is involved, because the idea of Agile is to combine different phases into one.

AGILE ·  Agile, in the context of project management, is a method to reduce waste and delays by anticipating that plans will change. It is a set of methods which are most effective when applied to projects that are complex and chaotic, especially in product development. It also has its place in production, given that customer demand as well as productivity fluctuate.

If words of command are not clear and distinct, if orders are not thoroughly understood, then the general is to blame. But, if orders are clear and the soldiers nevertheless disobey, then it is the fault of their officers.

— The Art of War, Sun Tsu

Kanban itself does not require specific roles within the team. What it does, though, is uncover problems in the organization that could be solved by assigning a single “product owner” to the team in order to give the team a vision and help with prioritizing tasks. Most often, the opposite is actually true, namely you have too many product owners and overlapping responsibilities.

Imagine you have a software team and an architecture team, each with a separate supervising product owner. The software team needs machines for production deployment, but the product owner of the architecture team prioritized another project. In theory, in true Kanban fashion, the software team could move in to help out the architecture team and speed things up. In reality, this could fail for a number of reasons, such as lack of knowledge, access rights, or simply a difference of opinion about how the IT infrastructure should look. In addition, the software team may get conflicting messages from both product owners about how to proceed. By focusing both development and IT architecture under a single product owner, these problems could be prevented and deployment could be streamlined.

Looking at StarCraft, you will encounter both scenarios in multiplayer mode. There is no separate “general” role that oversees how a team should concentrate its forces. Instead, players individually decide where and how to attack. They are very opportunistic, quickly joining an attack by other members of the team with their available forces, and with little to no need for a manager at the top. In addition, the most suitable (in terms of experience, size of force, proximity to the base, etc.) player automatically becomes a temporary leader in a specific situation.

In games like StarCraft, the general is in full control of land and air forces, from production to deployment. However, looking at military history, we see a totally different approach by some leaders. Sun Tsu, a Chinese general and military strategist in the “Spring and Autumn” period of Chinese history (722 BC to 470 BC), most famous for his work The Art of War, pointed out that it is essential for victory that generals are unconstrained by their superiors. A general must be free to wage war without interference. In World War II, the Allied command structure gave total authority to General Eisenhower, with four commanders representing the US Navy Group, United States Army Air Forces, US Army Group, and British Army Group. Each commander had clear responsibilities and was able to plan and execute operations independent of the other commanders. Land, air, and sea operations could be planned by the individual commanders, and only joint operations that required a combination of groups had to involve Eisenhower directly.

One would expect an even better organized hierarchy on the German side. However, there, you had a whole array of overlapping authorities with, for example, tank divisions being distributed among different army groups. The idea behind Hitler’s organizational setup was primarily not about efficiency on the battlefield, but to retain control over the different factions within the German army and to have the final word on all decisions (i.e., to be the dictator). Before any of his commanders could execute an operation, it had to go over Hitler’s desk because only he had all the necessary information required to make a strategic decision.

Imagine playing a game like StarCraft if team players had to share half their units with another player from the team—with the only possibility of talking to that player being via a third person who kept (informational) control this way. This allows the project to be micromanaged and controlled by a third person (basically a “dictator”); you will lose the creativity and flexibility emerging from decentralized management. In business, it is relatively easy to recognize the type of organization in which you are working. How are budgets allocated? Can individual departments work closely with other departments without involvement of the CEO? Do the departments have authority or can decisions be enforced only by mentioning the CEO (or adding him or her to the CC line in email messages)?

Sure, organizations ultimately have to remain unified. A CEO cannot have one department running wild. And there is usually a reason that an organization is the way it is, so simply changing the leadership style might actually result in even more chaos. Ultimately, it depends on the people involved. What type of people are they? Do they prefer a clean organizational chart with clear responsibilities or can they operate only based on personal bonds and informational control? Do they share and work toward a common vision, or do they prefer having a strong leader directing the way from case to case?

While every organization is different, you will find the latter type of organization more often in the field of sales-focused industries, while the former is usually to be found in production-focused industries. I think that both types of organizations have their place, but when you want to produce and run projects, you might want to think twice about wanting your organization to be controlled from the top.

What type of structure do you have in the organization where you work? Is it led by someone who is focused on production or on sales? How does that affect your experience with change in the organization?


Coaching with the GROW Model – Leadership Training

[vc_row][vc_column][vc_video link=”″ title=”Susanne Madsen leadership coach at shows what the grow model is and how it will help with managing your project work.”][/vc_column][/vc_row]


Multidisciplinary Teams in Scrum

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.


  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

 Principles Behind the Agile Manifesto [Beck, 2001]

Working in multidisciplinary teams is one of the main success criteria in Scrum. It is crucial to have different elements of the project—including the user or customer—represented on one team. In reality, in my work with clients, I often see that their move to Agile consisted only of changing the management style of a team, and in most cases this applied only to the software developer team. It is no surprise, then, that I often hear a description of the situation that goes something like this: “OK, we have this software development team here, and we want to test out Scrum. Now, we are looking for a Scrum Master. Oh, yes, and we have worked with Scrum for a number of years, but it is not working. Maybe you can help?”

My initial questions to a client revolve around what is not working and whether Scrum was set up as a project (see “Our Scrum Is Special”). I then focus on one of the points listed in the Agile Manifesto, namely multidisciplinary teams. What is a multidisciplinary team? Does creating such a team mean that you have to mix Java and Android programmers? Or that people on the team should have some PHP experience if a website is involved somewhere in the project?

Actually, multidisciplinary teams are one of the core principles of Agile, as opposed to Waterfall. To understand the benefits of multidisciplinary teams, let us first take a closer look at what the Waterfall method (which does not incorporate this approach) looks like.

The first essential step in setting up a company is assembling the right group of employees. In a company following the Waterfall method, ads for jobs are written and specialists are hired to do specific jobs, like programming, marketing, sales, or editing. Each person works in his or her specialized field with maximum efficiency.

Initially, the specialists form a common team, a handful of people working together on one project. With the growth of the company, new people are hired, and each specialist will lead individual teams; the former specialists become managers and each team gets its own room, its own planning, its own resource allocation, etc.

Depending on the environment (startup vs. large, existing company), the course of a company can vary widely, but essentially, in companies that have not adopted Agile, you will usually find specialized departments each performing a task with maximum efficiency. Sounds great, doesn’t it? You have the best people working in specialized departments highly attuned to their tasks. What could go wrong?

What could go wrong is that this kind of departmentalization will most likely lead to the use of the Waterfall management method—at any given time, a department works on one phase of the product. First, it goes through design, then development, then editing, quality assurance, marketing, and finally publishing and sales, with the managers busy with tons of meetings, cross-department communication, and resource balancing. With multiple teams, it’s nearly impossible to have one team ready to start the next phase just as another team finishes. Ultimately, this leads to long release cycles—sometimes years-long.

Then, people hear about Scrum. And what do they do? They take individual teams, set up a product owner and Scrum Master for each team, set up a ticketing system, sprints, and more meetings—with the managers still busy communicating and negotiating resources between the teams. The result? Marginal effects, somewhat more disciplined development teams (mostly because of more investment into the build systems to allow more frequent releases), and a story to tell all the developers that now, with Scrum, everything will be better and will continue to improve over time.

I hate to break it to you, but this is Scrum in name only. Specialized teams cannot deliver anything but concepts or work packages. Suddenly, the users are no longer the customers—instead, the “customers” become the next team. Eventually, only one department (sales) ever faces an actual customer who will use the product.

Now, moving from the phase-based management of Waterfall to Agile, how can companies benefit from having multidisciplinary teams?

Break with the idea of departments and focus on products (or features). Put together all the people—including marketing, design, and sales—who will deliver the final project. Does that mean that the salespeople have to learn Java and the tech guys have to do sales? Well, yes, to some extent. At least they have to learn how to deliver a product together and help each other out. Ideally, this would have begun during the hiring process, recruiting people who are good in one area, and know a little bit about all the areas. If you have only specialists, have them work in pairs (two people, one computer) on features, allowing easy knowledge transfer between departments. Also, even in early development, there is a lot to do for everyone. The salesperson might not develop a new API, but he or she can help with testing, meeting with clients, preparing presentations, advocating the team’s ideas within the company, creating beta- and sales channels, setting up newsletters and landing pages—all tasks marketing and sales could start doing early on, in addition to learning how the product works from the inside.

For an established company, this is a long road. But your competitor has already started doing it and your only advantage is that you (still) have more resources than the startup next door. When will your organization improve and become truly Agile?

When it comes to multidisciplinary teams, how is your company doing? How are the teams in your company structured? Does that structure support information exchange between departments or specialization of individuals? How are HR decisions integrated into your Agile strategy?


Kanban and StarCraft

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

“When you choose to use Kanban as a method to drive change in your organization, you are subscribing to the view that it is better to optimize what already exists, because that is easier and faster and will meet with less resistance than running a managed, engineered, named-change initiative. Introducing a radical change is harder than incrementally improving an existing one.”

—David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business [Anderson, 2010, p. 1]

In an organization, work can be distributed by two different approaches: “push” or “pull.” You either get new work put on your desk and have to manage what to prioritize, or you ask for new tasks once you are finished with your old tasks.

For example, “Gosplan,” the agency responsible for central economic planning in the Soviet Union, used a push-based logistical system. At Gosplan, mathematical models predicted consumer behavior. Based on these models, the government created plans for the entire supply-chain from the factory to the shops—with catastrophically bad results. For certain goods, there was always either too much or too little available. By contrast, “Kanban” is different:

KANBAN ·  Kanban is Japanese and literally means “signboard.” In the context of project management, the term is interpreted as “queue limitation.” Kanban is a method designed to reduce unfinished work and wasteful inventory levels; it was originally developed at Toyota in the late 1940s. Back then, marketers at Toyota studied consumer behavior and supermarket stocking strategies and applied the ideas to logistics in industrial production. At Toyota, they had previously produced as much as possible, regardless of the demand from the market. In contrast, in supermarkets, customers take only what they need, expecting that the supermarket will be stocked up the next time they visit. The customer “pulls” an item from the shelves and the supermarket makes sure to refill the shelves. This new Kanban method applied to production provided just as much as what was needed, just in time.

In addition to improving the production flow within a company, the big advantage of Kanban is that it can be applied to the production phases of any existing organizational structure without having to change business processes. With the production flow being made transparent, you can detect where work piles up at one place and then introduce a limit of the amount of work that is in progress. As opposed to a “relay race” model where work is pushed to the next department and not followed through, in Kanban, work items are pulled and work is stopped when the work limit of the next department hits its limit. This ensures that no work piles up or gets lost.

For example, cars need tires, a chassis, and a motor. Without a Kanban system, the three departments responsible for these parts will produce as much as possible: the company will always end up having either too many chassis, motors, or tires. If you instead have the departments check how many items are already in stock and stop producing when the stock is full, you save a lot of money. Sure, you might need these items later, but keeping a large inventory costs money that you could have invested elsewhere.

When presenting the situation in a business this way, it opens an objective discussion at the management level, ideally followed by incremental, evolutionary improvements. As opposed to Scrum which can be executed within a company “by name only,” i.e., by following the ceremonies but never addressing core issues like multidisciplinary teams (see my book Scrum Your Jira! ), Kanban is a organization-wide change management approach. Sure, Scrum involves creating lists of impediments but it leaves it up to you how to deal with them.

SCRUM ·  Scrum is a set of management tools that focuses a project back on the team level and uncovers internal and external impediments of the production process. By reducing communication paths through small, multidisciplinary teams, as well as frequent releases to the customer for review, the probability for project success can be improved even if the scope is not clear from the start. In addition, work is divided into units of fixed lengths (sprints) which helps to plan future sprints with your team working at a sustainable speed.

Once Kanban is in place, the goal is to focus on the bottlenecks, and manage the flow. Discussions with management can best be lead by making things explicit. Identifying the bottlenecks themselves is just the start of your work. The real game changer is to make explicit the current collaboration policies. This moves the discussion away from the abstract and maybe emotional or anecdotal arguments and toward objectivity.

After an organization-wide introduction of Kanban, usually the first bottleneck is found at the top. If the organization is strongly hierarchical, work (decisions!) piles up at the desk of the organization’s leader. In StarCraft, this is not much of a problem as playing in a team inherently includes decentralized control, but it helps to imagine how cumbersome a game would be if all decisions had to go over a third party’s desk.

Even with a decentralized organization, a common argument against Kanban is that there will be idle time because one part of the organization might not be able to keep up with the rest. As a result, work piles up until it hits the limit. This is true, but the idea that you are doing a good job when everyone is working at 100 percent is not always true. This is comparable to, in StarCraft, trying to keep all building facilities active, whether you need the units at the moment or not—or maybe even refraining from building additional facilities fearing they would not be used all the time.

Ultimately, Kanban is about trying to improve the flow through an organization. It does not matter how many items you produce if your sales department cannot bring them to the customer. Likewise, in StarCraft, you must think about how you will use the units you produce, meaning how you will deploy them on the battlefield. Sure, producing as many units as possible is a viable strategy, just like you could throw your unsold products on the market at a lower price or keep them in storage “just in case” there is a sudden demand. But it is an inefficient strategy. We can do better than mere local optimization.

This rings especially true when looking at the market. While a business does not literally fight an enemy like you do in StarCraft, your competitors try to get your market share. Scouting your enemy and adjusting your strategy are central components in StarCraft, just as they are on the market. You need to have foresight and gain intelligence about them and maybe even think about making some early risky investments before you are absolutely sure what others are doing. Why? Because waiting itself is a risk and you might miss the window of opportunity to be the first on the market with your product.

When all is in place, you can focus on communication. Using Kanban automatically leads to situations where a team is stuck insofar as it cannot pull new items to work on because the subsequent phases or departments have hit their work in progress limit. This encourages collaboration, where one team can help out the next and where teams sit together and think about how to prevent future bottlenecks. This element can be found in StarCraft, too, with very close team communication over audio during the game, as well as a review of the game and discussions about how to optimize team play afterward.

No matter the size or structure of your organization, take small steps. Kanban promotes this approach by starting with what you have in place and pointing out the bottlenecks. Where StarCraft falls short, by comparison, is the visualization of the “workflow.” While tools eventually emerged that visualized some aspects of the replays, like your “actions per minute” symbolizing your workload, I know of no tool that does it the Kanban way and actually analyzes how much time you spend on each team or location and thus points out possible paths for optimization.

The closest software that does a similar job is Evolution Forge, which I will discuss in the last chapter of this book. It helps you to optimize your basic build order in small steps. Behind both approaches (Kanban and Evolution Forge) is the grand idea inherent in nature to leave things as they are and move forward without ever making a step back. Every change you make should improve the situation and larger changes come into place as the sum of a whole number of smaller ones. In that regard, if you want to improve your StarCraft play the Kanban way, manual observation, maybe together with a critical friend, might be the best choice. On the other hand, if you want to learn the idea of Kanban with StarCraft as an easy-to-understand reference, you have come to the right place!


Our Scrum Is Special

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

Essential Steps in Implementing Agile Technologies

The Agile movement provides alternatives to traditional project management. Agile approaches help teams respond to unpredictability with incremental, iterative work cadences and empirical feedback. Agilists propose alternatives to Waterfall, or traditional sequential development.

 The Agile Movement (edited) [cf. AgileMethodology, 2008]

Scrum is an Agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement.

— What is Scrum? [cf. TechTarget, 2007]

When clients ask me to help with implementation of Agile techniques by using Scrum, my first question is: “What do you mean by ‘Scrum’?” Usually, I then hear that the company has its own special version of Scrum (or other Agile technique) because, according to the people with whom I’m meeting, their company is a special case.

First, yes, your company is a special case. Each company is unique and in a special market niche. Second, if you followed the evolutionary approach of improvements in small increments, you have adapted your process to the environment of the company. No two companies are alike. Hence your need for an external consultant to examine the special conditions in your company.

Introducing (and running) Scrum means that you want to change your company according to proven methods. You can’t have your cake (Scrum) and eat it, too (changing Scrum to suit your company)—you can’t improve your company by adapting the Scrum process to your company.

As a consequence, the reality I see all too often is that the company hires a Scrum Master who merely acts as a supporting firefighter, accompanying the former project manager (now “product owner”) and running around the company putting out fires. This kind of extra resource is justified to upper management by pointing to “Agile” and its use in other companies…

WATERFALL ·  Waterfall is a project management method where a product moves through a number of phases before a final version is finished for release. Compared to Agile, the problem with this method is that it requires additional communication channels between the individual phases and that the time until a team or company gets feedback from a customer is generally much longer.

SCRUM ·  Scrum is a set of management tools that focuses a project back on the team level and uncovers internal and external impediments of the production process. By reducing communication paths through small, multidisciplinary teams, as well as frequent releases to the customer for review, the probability for project success can be improved even if the scope is not clear from the start. In addition, work is divided into units of fixed lengths (sprints) which helps to plan future sprints with your team working at a sustainable speed.

SPRINT ·  A sprint is a timespan of one to four weeks within which a certain selection of stories should be finished by the team. Given the fact that the whole team spends 10 percent of the time (depending on the sprint length) planning and reviewing each sprint, the goal is to reach 100 percent completion of all stories while meeting the project’s quality standards and without overtime. Like a marathon runner needs to carefully plan her energy, planning a sprint requires very good estimation skills by the teams.

SCRUM MASTER ·  The Scrum Master controls the Scrum process. Besides proactively identifying and removing impediments to the process, the Scrum Master also supports the team in meetings as a moderator and individually in personal talks. The Scrum Master also stands up against outside influence on the process, ideally by propagating the Agile idea throughout the organizations and by explaining why certain restrictions are necessary for the overall project success.

PRODUCT OWNER ·  The product owner is part of the Scrum team and represents the stakeholders. The main task is stakeholder management as well as having a deep understanding of what the project is about and being able to make decisions. A product owner fills and prioritizes the backlog, keeping the complexity estimations of the team in mind. The product owner should have full authority and the final say about the prioritization of the backlog. During the sprint, the product owner answers questions from the team about the scope of the project, as well as gives feedback about finished (but not necessarily done!) tasks, but otherwise does not interfere in how the team manages its work.

Looking at the actual causes of problems

One of the techniques used in project management is to find the cause of an issue. Digging deeper, my next set of questions to the client usually focuses on the greater picture or vision of the company. Instead of telling me about their mission, they typically respond that they want to “test” Agile and then implement it in other parts of the company.

Besides noting the obvious misunderstanding of Agile as the new (local!) management technique, questions arise: What would success look like? What would failure look like? What are the concrete, measurable business objectives of the project of introducing Agile?

I am convinced that introducing Agile itself should be managed with modern project management techniques, PMBOK being my favorite. Managing Agile goes far beyond the scope of this chapter, but you certainly must have an idea about where you are going with it and what you want to achieve.

PMBOK® ·  PMBOK stands for Project Management Body of Knowledge and describes a generic system of workflows within a project. While it is mainly applied to Waterfall projects, many of its parts can also be used in an Agile project, like defining how the team communicates with the outside world, defining the vision and scope of the project, or defining why one would want to use Scrum at all. [PMI, 2013]

To illustrate this further, I recommend reading Ayn Rand’s introduction to philosophy that looks at the example of an astronaut stranded on a planet:

Suppose that you are an astronaut whose spaceship loses control and crashes on an unknown planet. When you regain consciousness and find that you are not badly hurt, the first three questions on your mind would be: Where am I? How can I find out? What should I do?
You see unfamiliar vegetation outside, and there is air to breathe; the sunlight seems paler than you remember it and colder. You turn to look at the sky, but stop. You are struck by a sudden feeling: if you don’t look, you won’t have to know that you are, perhaps, too far from Earth and no return is possible. So long as you don’t know it, you are free to believe what you wish—and you experience a foggy, pleasant, but somehow guilty, kind of hope.
You turn to your instruments: they may be damaged, you don’t know how seriously. But you stop, struck by a sudden fear: how can you trust these instruments? How can you be sure that they won’t mislead you? How can you know whether they will work in a different world? You turn away from the instruments.
Now you begin to wonder why you have no desire to do anything. It seems so much safer just to wait for something to turn up somehow; it is better, you tell yourself, not to rock the spaceship. Far in the distance, you see some sort of living creatures approaching; you don’t know whether they are human, but they walk on two feet. They, you decide, will tell you what to do.
You are never heard from again.
This is fantasy, you say? You would not act like that and no astronaut ever would? Perhaps not. But this is the way most men live their lives, here, on Earth.

—Ayn Rand, Address to the Graduating Class of the United States Military Academy at West Point New York (adapted) [cf. Rand, 1974]

In terms of a company, your immediate goal is of course to survive the next month. But then, you have to establish where you are on the map. You have to open your eyes, look at the sky, and check your instruments.

In terms of Agile, I recommend to my clients that they run it like a project. We know what works from hundreds of studies, and we can create a list of items that are implemented in Scrum. In that list, we simply mark the current state of the process. Often, even in non-Agile companies, some processes have already been implemented because the people who are managing projects notice which processes work. A simple approach is to check again the Principles Behind the Agile Manifesto [cf. Beck, 2001]:

  • Welcome changing requirements.
  • Trust and motivate individuals on your team and other teams in the company.
  • Developers and non-developers (e.g., marketers, salespeople) must work together daily.
  • Face-to-face is the most efficient and effective method of getting things done.
  • Progress is measured in terms of working software.
  • The entire team must promote sustainable development, they should be able to maintain a constant pace indefinitely.
  • The entire team must work together to continuously improve technical excellence and to enhance agility.
  • Keep in mind that simplicity is valuable; simplicity is the art of maximizing the amount of work not done.
  • The best solutions emerge from self-organizing teams.
  • Effective teams reflect regularly on how to become more effective.
  • An Agile company satisfies customers through early, frequent, and continuous delivery.

Together with the client, for each point, I detail how this is implemented in the company—this is the first step of documenting the current process. If I can’t explain how it is implemented or if we find that it is not implemented, I focus on those points and try to find explanations for each: why the company is not able or not willing to fulfill this part of the Agile process. And I do not just ask, “Why?” I ask, “Why why why why why…?” until I find out the actual reasons something has not been implemented. [cf. Ohno, 2006]

And at this point, the real work starts: addressing those issues that hinder the Agile process on a daily basis.


An Introduction… to StarCraft

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

There is a saying that if you want a successful software developer team, hire StarCraft players. Why? StarCraft not only trains you to react quickly, it also teaches you valuable knowledge about management. For the players, this is not necessarily obvious and management will often be viewed as something abstract and not related to their work. For an Agile coach, having a team with such background knowledge can help to speed up the learning process, and most importantly, increase the chances that the process will be accepted, becoming part of the team’s culture.

For those unfamiliar with the game, let us first look at what StarCraft is. Then, in the following chapters, we will compare StarCraft with Kanban.

The computer game StarCraft puts you, the player, into a management position. Your task, in the beginning, is to manage three resources: minerals, Vespene gas, and supplies. The goal is to provide the “general” (also played by you) with military and support units. The specific management goal depends on the military scenario, but it usually revolves around defeating an enemy general.

Combat is based on a complex version of a rock, paper, scissors model (e.g., air, close-combat, and ranged units), so it is important to gather intelligence about what type of units the enemy produces. There are only a few effective ways of gathering intelligence, mainly moving a unit into the enemy’s territory.

The general decides on the strategy and provides the manager the priorities based on the “market,” the strategy of your enemies: which units are most needed. The manager implements these priorities by using a certain build order, assigning worker units to produce factories, and factories to produce the military units or more worker units (“SCVs”) in the “Command Center.”

SCV ·  In StarCraft, the SCV is the all-purpose worker unit who gathers resources and constructs buildings. While it can defend itself, it is the weakest unit in the game. While it seems wise to produce new workers non-stop, you might want to temporarily sacrifice long-term growth with short-term gains: finding the right window of opportunity to build certain units, instead of investing into economic growth, might lead to you winning the game or at least getting ahead. Both in the game as in business, it does not matter how good your army or your product is, but how it is relative to your competition. Do not try to build a perfect army or perfect product. Check the market, check what consumers want: they want a better product than what the competitors are offering.

COMMAND CENTER ·  In StarCraft, the Command Center is the first building you own. It can produce additional workers to mine resources. Building a second Command Center might speed up your worker production and resource gathering speed, but it is also costly. In a company, it could be compared with the basic structure of hiring new people, training, people management, etc. Both in StarCraft and in business, you are faced with the question of how many people you will hire for a project. Will you hire just a few and save money, or do you stop any other current investments and hire more people now to have them finish the project more quickly?

As in business, you will not win the game if you take forever to produce your “perfect product”—an army, in this case. Units produced as early as possible (or simply at the right moment) can give you the upper hand in the game.

Beyond combat units, you also have carriers (“Dropships”) and buildings. The former can be seen as a means of “deploying” units by transporting them to the battlefield. The latter can be used to block enemy units, or—wrongly placed—to block your own movements, making deployment more difficult.

DROPSHIP ·  In StarCraft, the Dropship is basically a spaceship that can transport your units from one place to another. They can be seen as a means of “deploying” units. This element of the game is similar to what you have to do in a business. It is not enough to produce items, you also need to bring them to a place where your customers can see and buy them, be it a physical location or software on a web server. If coordinated properly, Dropships can be used for surprise attacks. Again, a concept you find in the business world: you need to plan your release of the product according to the external market forces, be it special dates (like Christmas) or competitor products. If you catch your competitor unprepared, the competitor might need time to adapt to your new product.

Resource management involves sending worker units to mineral fields and Vespene geysers in order to mine minerals and Vespene gas, which is used for production. These fields are depleted after a while, so you need to look out for and secure new locations that have resources. In addition, you need to build supply depots to support your standing army. If you do not have enough supplies, your production stops and you can no longer produce new units, so you have to plan for that in advance.

Besides minerals, gas, and supplies, time is another resource, as combat usually requires you to spend time micromanaging your units to move army groups and attack specific targets. As StarCraft is a real-time strategy game, any time used tending to combat cannot be used for tending to your production and resource management. While you can queue movement commands at no cost, queuing production commands in your factories binds in advance resources that might be better used elsewhere (but allows for production without any interruption).

Even more complexity is added by the fact that there are three different factions, the option to research better weapons and armor, and tech-trees that are unlocked when constructing certain buildings. Last but not least, there are islands, cliffs, ramps, narrow pathways, and hills that add additional strategical and tactical challenges.

Now, this is all interesting in theory. But what does it look like? I recommend watching a few StarCraft games together (team building!) and discussing how elements of the game apply to the situation in your company. It is a great way of opening people up. By seeing it “in action,” your team can more easily understand the management terms and concepts in Kanban. In fact, I encourage you to watch a few minutes of StarCraft replays right now or download the game (it’s free) and play. If your manager asks, say that it is for research.

Done? Now on to the next chapter, comparing StarCraft to Kanban.