Kanban Set Up Guide

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.

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?

6. 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.

6. 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.
7. 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.

9. 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.
10. 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.
11. 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.
12. 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).
13. The team loads the board with the current status of work.
14. 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.