Manual for Setting up Kanban

E-T-A has been using lean in production for years – and is expanding its capabilities with agility. As part of our joint work in agile transformation, E-T-A and wibas colleagues meet to work together on establishing agile techniques and agile thinking. Yesterday Stefanie and Katja from E-T-A sat together with three wibas colleagues Rafael, Daniel and Malte. Our question was: „How do we set up work with the Kanban Framework in a team?“ For this purpose we developed a guide which we share with you here. This is our System Thinking Approach to Introducing Kanban (STATIK).

The result: more than a board

When we tried to pin down the objectives of the workshop (how you do it as a good moderator) we quickly realized that it is not just about a board with cards, but about implementing the Kanban Framework.

Why is Kanban more than just a ­board with colorful stickers on it? Because Kanban defines principles, roles and meetings that make Kanban the useful method. So the following is a guide how to start using the Kanban framework in a team – and not just the board.

In the spirit of the principles “Evolutionary Change” and “Start with what you do now”, our workshop is not about implementing Kanban in its full beauty, but about starting. So it may be that we leave out some things from the Kanban framework at the beginning (a “Proto-Kanban”).

Who’s coming?

We invite the team that does the work to the workshop. We come as Flow Master, i.e. as an Agility Coach who understands Kanban and facilitation. As Flow Master we support moderately and bring in techniques such as board design. Or in short: As Flow Master we moderate, the team designs its Kanban.

Kanban lives from the people who use it.

The steps in the workshop

Our basic idea of the workshop is: First the team understands the value stream with its rules and limits. Then the team visualizes the value stream with a board. Finally it establishes the roles and events. Susanne, Agile Coach at E-T-A, knows why we let the Team do the work: „If the Agile Coach develops or even maintains the board, the team does not work with it.“ We coaches nod. „Sure, it’ll be your board, not the team’s.“

Here are the steps of our moderation plan:

  1. We ask the workshop participants about their experience with Kanban. The query helps us as moderators to understand how many explanations we have to include on the way. Our motto is: we explain stuff when it is needed. This saves us a big Kanban explanation at the beginning.
  2. We let the team describe the value that it delivers to the customer through their work. This understanding is important so that we can align the process with this value.
  3. We let the team write some typical customer requests. This helps us to better understand what the customers want. We also have a few examples for service requests so that we can try out Kanban in a later step (see #9).
  4. The team does a brief review of its work with two questions: What is going well? Where does the team see room for improvement? This gives everyone a feeling for „where we start“.
  5. We let the team identify the flow of work. To do this, we go with the team through the process step by step and let the team model its workflow. We use sticky notes for this purpose, where each note represents a step in the process. In this way, the workflow is created dynamically and can be easily extended and modified.

As coaches we support the team with questions such as:

  • What are the steps you do as a job?
  • What is the result of the step?
  • Where does the work come from?
  • What kind of work is that?
  • What makes a good process?
  • How does the implementation of work happen with you?
  • How do you choose work?
  1. Based on the above workflow, the team creates its first board. For this we first clarify whether the workflow is always the same or whether the tasks are completely different. If the tasks are always the same, each work step is represented as a column in the Kanban (each column has the sub-columns “in process” and “finished”). For very different activities we design a board with an individual decomposition of the work into tasks.
Examples for Kanban Board Desings.
  1. We let the team determine the limits of parallel work – these are the so-called “work-in-progress limits” or “WIP limits”. By limiting the amount of parallel work, we eliminate waiting times and shorten lead time. We become more efficient. For good WIP limits, it is important that the team starts with initial limits, observes lead times as the work progresses, and then adjusts the WIP limits so that the work does not jam at any point.
  2. We let the team formulate its policies in the course of work. We ask for this:
    1. What does it mean when a step is done? Are there criteria for this? This becomes something like a „definition of done“ for the respective „done“ columns (or possibly only for the last done column).
    2. We ask the team how they select their work from the queue (the first column in the Kanban). Are there policies for this? How is the queue ordered? The results at this point are typically policies for ordering or prioritizing the customer requests.
    3. Are there other policies that are important at work?

The team writes these policies on large Post-Its (we often take A5) and hangs them above the board. Policies for defining „done“ make sense e.g. above the respective „done“ column.

  1. We test the Kanban Board with typical requests from step three. That means: we run a customer request „through the board“ and simulate the work for it. If necessary, we adapt the board.
  2. If we have time, we can include a simulation of Kanban at this point, so that the participants learn how Kanban works. For example, we could use the Okaloha Flow Game or the TWIG Game. Such a simulation helps to give the team an understanding of Kanban that would otherwise need some cycles in real life.
  3. We clarify with the team the roles of the Kanban framework (Flow Master and Service Request Manager/Product Owner) and we determine who will take over these tasks. At least for the near future.
  4. We clarify with the team what the cadences of the feedback loops are. By “cadence” we mean: how often do we do which meeting. We find the Kanban Meeting (“Standup”) and the Service Delivery Review particularly important. Actually, the Replenishment Meeting and the Delivery Planning Meeting are also important, but we can also introduce these in a later step. For all meetings we determine when and how often it takes place (and of course: who comes and how long it takes).
  5. The team loads the board with the current status of work.
  6. We ask what else the team needs to get started.

That agenda itself we *of course* have on a Kanban board. On the one hand, because we want to set an example of Kanban, but also because the agenda changes during the day and we can react.

For such a workshop we need at least four hours – a whole day would be better.

We lied. That wasn’t a manual.

We have briefly outlined how to set up Kanban with a team. Of course, this is only a small part of the truth. We cover the details of setting up Kanban in our official training KMP I. There you will learn the exact process of Kanban, the principles in detail, facilitation techniques and board design variations.

Team of authors

The team of authors: Stefanie Stampfer and Katja Kiel from E-T-A with the three wibas colleagues Rafael Kasprzak, Daniel Schauperl and Malte Foegen. If you still have questions, ask them here in the blog – we will be happy to answer them. Or call us: 06151 – 50 33 49 0.

Descaling instead of scaling: Why scaled agility should simplify the organization.


Quo vadis agile scaling?

More cheese, more holes

More holes, less cheese
More cheese, less cheese

Is this paradox cheese? Possibly. And is it transferable to the organization of organizations? It is possible.
One thing is certain: to achieve more with less in terms of organisation is not such a far-fetched idea at the latest on second thought. Especially when it comes to scaled agile frameworks, this idea is just too contrary. Continue reading Descaling instead of scaling: Why scaled agility should simplify the organization.

How do you “scale” agility? An interview with Malte Foegen.

How do you decide which agile approaches to take out of the agile toolbox when it comes to creating an agile organization?

I look at every team and every level for itself. This is the only way to find out which agile approach makes sense for which team and at which level.

And you can’t just take a Scaled Agile framework like that? Continue reading How do you “scale” agility? An interview with Malte Foegen.

Certified Scrum Master (CSM) or Professional Scrum Master (PSM)? An honest comparison.

CSM and PSM are the two recognized Scrum Master certifications. What’s the difference? There are many one-sided “comparisons” out there. We offer you an honest one – written jointly by a Scrum Alliance and a trainer.


Continue reading Certified Scrum Master (CSM) or Professional Scrum Master (PSM)? An honest comparison.

Agile Myths: User Stories – a mandatory format for Scrum Teams?!?

The User Story format is often used by Scrum teams to document requirements. It’s a short syntax that sounds totally simple, but when we sit down and try to fill this syntax with life, we quickly realize that it’s not that easy. Some of you may have stumbled across user stories that somehow sound “artificial”. So what is it about this little sentence? Why do so many people use it? And do Scrum Teams have to document requirements in the user story format? Don’t they otherwise make a “real” Scrum? Continue reading Agile Myths: User Stories – a mandatory format for Scrum Teams?!?

Agile myth: Writing user stories is Product Owner work

Again and again I am confronted with the statement that only the product owner writes and prioritizes user stories. The Product Owner is the person who prioritizes the Product Backlog. But for reasons I don’t understand, many people seem to be convinced that it is a core task of the product owner to sit down at his desk and write a user story until it is ready for a sprint. Is that really what the Scrum Guide says? Continue reading Agile myth: Writing user stories is Product Owner work

X no longer marks the spot – Y we believe in something else

Theory X and Y describe two contrasting models of workforce motivation and behavior. They were created by Douglas McGregor in the 1960s. According to these theories, there are two types of employee behaviors that can be encountered. Theory X behavior is driven by extrinsic motivation, while theory Y behavior is driven by intrinsic motivation. Continue reading X no longer marks the spot – Y we believe in something else