One day to get started with Kanban

I’d like to share with you an example of an activity you can use, based on experience, to introduce and initiate a Kanban transition within a team... With just one day of workshops!

Icebreaker

First of all, with this type of day, I like using an icebreaker / energizer to get the ball rolling.

One I particularly like for teams discovering Kanban is the first name game. In addition to getting people active and moving, it begins to introduce the challenges of multitasking and the benefits of limiting work-in-progress (WIP).

Presentation of Lean, the origin of Kanban and its objectives

I then give a brief presentation of Kanban’s history and origins, including Lean principles, before addressing the main objectives of Kanban, which are laid out in the visual below.

 

At this point, we take a moment with the team for it to define the objectives it is looking to achieve by deploying Kanban. We make sure that these objectives are SMART (specific, measurable, achievable, realistic (or relevant), and time-bound). These objectives make the setting up of Kanban meaningful and, a few months down the road, will enable us to assess benefits and define improvements to be made.

Discovering Kanban’s principles and practices through a simulation

Rather than giving a theoretical presentation of Kanban principles, I prefer to explore them with a simulation game. One I often use for these presentation and setting up days is the Kanban Pizza Game.

In the space of just two hours, it makes it possible to discover and experiment with several Kanban practices, such as workflow visualization, WIP limits, continuous improvement, use of feedback loops and more.

You can read an explanation of the game in French or English.

A review of Kanban principles

In this step, I go over Kanban principles with the team I’m assisting. It’s a chance for me to explain that we will not be revolutionizing their way of working today: current roles, responsibilities and processes will be maintained. However, it will be their responsibility to make Kanban their own, in order to improve the way they work.

Review of the various Kanban practices and a setting-up proposal for the team

Once they have discovered the practices through this game, we look at them one by one, in order to see how they can be transposed into their specific field. Following a presentation of each one, I help the team think about how it could be applied in their environment.

 

 

A. Visualize the flow

I begin by asking the team who they work for (who are their customers or users) and what service they are providing. It is important to understand the customers behind requests. The team can then identify how requests enter the system. Ideally, these people should be involved in the process of setting up Kanban.

I then ask them to explain the flows linked to the various types of requests they handle. In Kanban, we do our best to produce a global vision of the value flow. Step by step, we build the flow on the board, right up to value delivery. Once this is done, we look at the columns that could be meaningful in their Kanban board.

Here, the aim is not to define a flow that will match 100% of the team’s requests, but the majority of requests.

B. Explicitly state the management rules

Once the columns in the Kanban board have been defined, I ask the team to explain who is working in each column, and what the conditions for moving on to the next column are. I continue to take notes on the board.

C. Limit work-in-progress

I then ask the team to define several limits in its board, without forcing it to set ones that are too demanding. The idea here is to get started with Kanban. The team can refine its limits later as its experiment with the method. I take this opportunity to talk again about the ideas of ‘pull flow’ and ‘push flow'. I then suggest that the team adds two sub-columns, ‘In Progress’ and ‘Complete’, in each of its columns. Lastly, we cover the topic of emergencies, and the team defines how to address them initially.

If the team has trouble understanding the benefit of using limits, even after the Kanban Pizza Game, other games can help build a better understanding, such as the Aeroplane Game.

D. Manage the flow

For flow management, we talk about the possibility of setting up a daily meeting. I present good practices for a daily Kanban meeting and ask the team if it would like to use one in its environment. If so, team members together define the time of this synchronization meeting.

E. Implement feedback loops

At this point, we together look at what the team would like to apply feedback loops to.

• To its product: would it like to organize demonstrations of functionalities deployed? If yes, who for? And how often?
• To its work planning: how often and how would it like to manage the supply and prioritization of requests? It is possible to define frequencies that are fixed (e.g. we resupply once every two weeks) or linked to events (e.g. we resupply when there are less than X requests left in our backlog). Supply and prioritization techniques will be covered in greater detail at a later stage, with the person(s) in charge.
• To its performance: here, I present the various metrics frequently used in Kanban and their utility. Generally, at first, if the team uses a physical and not a digital board, I suggest that it notes the Kanban system entry and exit dates, and that it counts the number of tickets in each column on a daily basis. I explain to the team that time and a certain volume of data will be required for these data to be usable. I therefore ask it to simply note down this information and suggest planning a quick meeting a few weeks down the line, in order to look at how it can use the data.

F. Improve collaboratively and move forward experimentally

Here, I talk about retrospectives. While in the other sections of setting up a Kanban, I try to assist them without pushing them to make decisions, in this section, I do insist that they plan an initial retrospective. I also advise them to define a frequency for the first few retrospectives. This is because, for teams starting out with Kanban or Agile, they do not naturally feel the need or get into the habit of conducting retrospectives. So I take the liberty of pushing them a bit!

We can also cover other practices that are often used in Kanban:

• Classes of service: here, we go over the various types of requests the team handles in order to see if it wants to turn them into classes of service;
• Corridors: I then present the ways in which corridors can be used and the team decides together if it finds this meaningful.

At the end of the day, the team has an idea of what Kanban is and the benefits it can bring, and it has already started work on its first Kanban. Generally, by the end of the day, the whole team gets to work on creating the Kanban board based on what it has decided during the day! It is important to underline that this is just a beginning, that this is the team’s Kanban, and that it is up to the team to own it and develop it, in order to draw maximum benefit from it.

Assistance from the coach does not end here of course: we ask the teams what they expect from the coach. Furthermore, we suggest holding regular progress meetings together, and offer to provide support for the first daily meetings and retrospectives, the prioritization and planning of work and deliveries, use of metrics, and so on.

Two important points need to be kept in mind for this day:

• The coach must enable the team to design its own Kanban. If the team doesn’t own it, there is a strong chance that it won’t produce continuous improvement. The coach will therefore be there to facilitate, assist, and possibly advise and raise any points they identify that require caution.
• If the team isn’t familiar with agility or continuous improvement, it seems important to me that the coach works with the team for a period to build this state of mind. The same applies when it comes to questioning practices and possible improvements. Without assistance, it is likely that the team’s Kanban will not evolve, and that it will find itself a few months later facing exactly the same problems it faced before!

I’d like to share with you an example of an activity you can use, based on experience, to introduce and initiate a Kanban transition within a team... With just one day of workshops!

The images in this article are taken from Kanban sheets that we created and distribute at the end of our Kanban training courses and introductions. You can download them: