So you are considering getting started with Kanban, but where do you start? In this article we describe the approach we used in Danske Bank to get teams off to a good start with Kanban. You are free to use the material and content to get started yourself and the purpose of the article is to explain the what and how of the workshop to enable you to use it.
The workshop has been developed as part of a large scale agile enablement initiative, which has ran in Danske Bank for at least 3 years. Initially, this initiative was based on a Scrum approach and as the initiative grew it became clear that in some cases Kanban might be a better choice. We observed this specifically for teams and areas with very diverse tasks. For example, a mixture of operational tasks, small development tasks and case handling. The workshop and material was developed by Sune Lomholt in collaboration with Rasmus Kaae and Gitte Klitgaard Hansen.
Based on our experience with training in methods and tools we decide to make this more like a workshop rather than standard training. Basically, we used the mantra from Benjamin Franklin “tell me and I forget, teach me and remember, involve me and I learn”. Thus we decided to focus on involvement to ensure learning and commitment to the introduction of the Kanban approach. The feedback from the workshops has proven this to be a very good choice. Participants are very satisfied and express that they have learned and gained a lot. Additionally, the workshop in most cases has enabled the teams to start with their Kanban system immediately after the workshop thus ensuring fast time to usage from the experience and knowledge gained during the two days.
The workshop runs for two days, where the first day is all about understanding agile and discussing Kanban practices. While the second day focuses on building the first Kanban system for the team. The content of the workshop is built with inspiration from David J Anderson 1, Jesper Bøgh 2, Henrik Kniberg 3 and Rick Simmons 4. The approach and workshop material described in this article you are free to use for executing your own workshops.
Day one
The first day focuses on understanding and discussing agile and Kanban. This is done using the following parts.
Introduction
This is setting the scene for the workshop and more importantly letting the project manager or line manager state his objectives for starting with Kanban. These objectives are kept visible throughout the workshop. This enables you to relate the discussions, the outcome and output of the workshop activities to the manager’s objectives and the comments to these from the team.
Agile in a nutshell
This is a very short introduction to agile in order to set the scene and have some initial discussions on the agile mindset, which we believe is also an inherent part of the Kanban approach. Basically we discuss the agile manifesto, working in small batches and the importance of feedback cycles.
Kanban practices
First we shortly describe what Kanban means in IT. We keep this short and the main intention is to demystify the Kanban word by providing some context to it. Then we have the participants discuss the five Kanban practices in small groups. When we created this there were five practices, however since then it has changed and the Kanban practices now consist of six practices. Basically we have 5 posters - one for each of the practices. Then in small groups of 2-4 people the participants walk around to the posters and note down whatever they think about the practice (spend 3-5 minutes at each poster). Note it is important that we have not presented the practices very deeply at this stage; we have only introduced them by their name. This part is for the participants to tune in on the practices and put their own words on it. Since they only have the name of the practice we may need to help them a little and provide some clues or ideas, but we are very careful not to lead them. Afterwards we usually walk through each practice and discuss it based on their words on the posters and what we believe it is. We found that having the participants putting their own words on the practices and then afterwards relating our explanation to these words highly increases the understanding and commitment (involve not tell).
Kanban Software Game
In this part we spend 2-3 hours playing a Danske Bank version of the Kanban game 5 from Christina Skaskiw. The intention of the game is to try the practices in real life (involve over tell). So far it has proved to be very effective and gets people involved. We have several improvements to the game to make it even more real life like and ensure that we actually get through the practices. For example, we have added measurements and a retrospective. This is likely the hardest part to facilitate in the whole workshop and we have exercised the game ourselves several times before attempting to facilitate it. The game is concluded with a set of follow-up questions that you can use for discussion about the game and getting participants a deeper insight into the characteristics and benefits of Kanban. For example, we discuss how agile practices such as daily meetings where part of the game.
If time permits this is a good place to link some of the learning back to original objectives from the beginning of the day. In this way we relate their discussions to the reason they are on the workshop, thus anchoring their workshop experience with the purpose for beginning with Kanban.
Figure 1: Two teams playing the Kanban Software game. The board can be seen on the table and the measurement poster which the team must update is shown on the wall. Team have been anonymised to protect the innocent.
Ending day one
We end the first day with stating three things.
Firstly, Kanban does not tell you to have daily meetings, but you should. This is a must to ensure usage of the board. Furthermore, this is a key enabler to increase collaboration and team work (which we believe are foundational in agile).
Secondly, Kanban does not tell you to have retrospectives, but you should. In our experience to get the Kanban practice of “Continuous Improvement” to work you need to have regular sessions focusing on this. We call them retrospectives to align with our Scrum based approaches. We also typically use the same techniques.
Thirdly, Kanban is based on two principles “start where you are” and “agree to improve incrementally”. The first principle we use to get commitment from the participants. We do not intend to change anything from the start, hence you will work the same way tomorrow and the only change will be the daily use of the Kanban system. Obviously, to some this may be a significant change. However, the workshop focus on the team(s) collaborating to create their own Kanban system mitigates the risk of this being seen as a big change.
The second principle we state that if they do not agree to improve, we actually think that we should not do the second day. We believe this is the strength of the approach; it promises change, but does not introduce it (similar to “everybody wants change, but no one wants to change”).
If time permits we typically end the day with various examples of boards from other departments at Danske Bank. This enables us to say there is no right or wrong board layout it depends fully on your work and context.
Day two
This second day is focused on building the first Kanban system for the participants. The goal is to have a board, cards and policies at the end of the day. However, to get the participants back into the workshop mode we begin with a small activity. We ask the participants to establish small groups of 3-4 people and draw what they learnt the day before. No written words may be used. After 5-10 minutes of drawing you ask the groups to interpret the drawings from the other groups. For example, in the picture the team discussed that day one was about
- Kanban board to visualise work
- Mesaurements
- Improvement through experiment -> observe -> check
- explicit policies – get them out of the box
- stop pushing work items to team
The rest of the day is a set of activities to drive out a Kanban system through analysis and discussion on how the participants actually work today. During this it is important to keep track of time and drive the participants forward such that they reach the goal of having an initial Kanban system. So we frame the day that output is more important than quality and agreement – we need to have a first cut on the Kanban system at the end of the day. Thus we need to make decisions based on consensus. Here we also continuously stress that improvement is the prime objective and thus the first system should not be perfect.
Work item type analysis
The first activity is to have the participants identify and describe the type of work they do. This is the type of tasks or deliverables that they typically have. It is important that they also note down the characteristics of the work. For example, does it typically have a deadline, does it typically involve other people outside the team, does it typically require special skills or competences, what is the input channel, etc. Once the participants have these in place they are asked to see if they can group them to aggregate into fewer work item types (trying to make things simpler).
Work flow analysis
In this activity the participants are asked to specify the value flow or work flow for the work items types. Basically, noting down the steps necessary to take an instance of a work item type from initiated to complete. In this part be careful not to allow the participants to be too high level. Some participants tend to abstract everything to plan, doing, done. It may be the best approach for them, but the focus of this part is to understand the workflow, before we abstract to a Kanban system. You need to go into more details in order to identify differences between work item types. These differences may be very important and should be part of the Kanban system since this exposes how we actually work.
Figure 2 Team doing workflow analysis with post-its on the wall
Best approach here is to use sticky notes with each of the steps and then having each work flow stacked on a wall above each other. In this way you can easier notice similarities and differences between the workflow.
Deciding on the Kanban board and card
In this part we use the work flow analysis result and try to identify an initial board that can visualize the work. This is the point in the workshop where we observe discrepancies in the expectation the participants have to the outcome. Often participants have begun to have their own ideas about the layout of the board (they begin to have this already at the beginning of day one). Thus the collision of their individual ideas and thoughts will appear here. To mitigate this it is important that we do not let the participants be abstract in the workflow analysis. Abstraction in the work flow analysis will enforce the ideas, because participants will interpret the abstract parts differently and make it match their own. This will lead to an abstract workflow that actually does not visualise the work, but rather just put tasks on board. Part of these discussions is the creation of both columns and swim lanes or how do you want to visualize the work you are doing. What are the most important characteristics? Finally, we also discuss WIP (Work in Process) limits and how to express these on the board. It is not something we focus a lot on, i.e. sometimes it is just 5 per person or 5 per column or swim lane. We have found that it is difficult to really identify WIP limits just from work flow analysis and thus we more want to get some to start with. Therefore this is also a focus for the follow-up coaching we do after the workshop.
We as facilitators play an important role to drive the participants towards a decision. Furthermore, this may not be a decision that satisfies all, but we focus on getting consensus. Therefore it is important to remind the participants about the Kanban principles “start where you are” and “pursue incremental improvements”. We use these statements to keep focusing on getting a starting point and then improve from there. Hence we strive to avoid discussions that speculate on how the board could be especially when these speculations may change the current way of working.
This part ends with designing the Kanban cards, basically deciding what kind of information is needed on the card and maybe if you need different colors. This may also include a discussion of other visual markers such as who is working on it, is it blocked, deadline near, priority, etc. However again we must ensure not to introduce something that is not part of their current work flow.
Finding policies and validating the board
At this point the participants have their initial board and cards. Then we work through the board and discuss policies for moving the cards and not least getting cards on the board. The beauty of this approach is that while discussing the policies you are actually validating the board. It is very similar to taking example work items and moving them through the board (which is a good way to test the board). Again in this activity completeness is not as important as to getting to some policies (we can always add more policies).
After the workshop – action plan
At this point the participants are tired and if we succeeded there is a very visible result from all the hard work. Therefore we typically end the workshop around here. However, to ensure the participants are able to implement when the return to work, we provide an action plan containing some prefilled actions and often a few more that we fill in during the workshop. So we end by determining a responsible person and deadlines for the actions to ensure progress in getting the Kanban system to work.
The experienced readers may have noticed that a couple of concepts are more or less left out of the workshop namely measurements and classes of service. Regarding the measurement we generally tell them to measure lead time, cycle time and create cumulative flow diagrams. In a later coaching session we then use their own data to further introduce measurements as a foundation for improvements. The classes of service are also introduced later if necessary. Some teams have already identified them as different work item types and thus adding a concept of classes of services just adds a layer of complexity that the teams do not need at this point in time. However, in some cases we introduce the concept later if it can help the team improve their process and Kanban system.
Results
As stated in the beginning of the article we have had significant success with this workshop and our survey on participant satisfaction indicates this as well. The survey result is from 10 workshops over a 6 months period. Furthermore, we interact with the participants afterwards in coaching sessions and in many cases they are all up and running and have understood the basics of Kanban. Hence we conclude that the content and structure of the workshop is very well suited to introducing Kanban and getting teams off to a good start. To conclude with a quote from a participating manager “Initially I thought we could do this in a couple of hours, but now I am glad that you convinced us to go for the whole two days. It was time extremely well spent, that is 2 days is necessary and sufficient. Thanks!”
Click on the image to enlarge it
/filters:no_upscale()/articles/fast-track-kanban/en/resources/Image6-large.png)
Conclusion
We have now used this format with good success. So if you want to get started by yourself – please feel free to use the workshop material 6 and the Software Kanban game 5. If you use it I will certainly appreciate your feedback on how you are using it and if you have made improvements to it.
If you have any comments, experiences or improvements please share these.
Disclaimer
This article was initially written and submitted when Sune Lomholt was working in Danske Bank. He is now employed elsewhere.
Bibliography
- Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. s.l. : Blue Hole Press, 2007.
- Boeg, Jesper. Priming Kanban. s.l. : InfoQ Minibook, 2011.
- Kniberg, Henrik. Crisp's Blog.
- Simmons, Rick. Kick-starting-Kanban.
- Lomholt, Sune. Software Kanban Game.
- Sune Lomholt, Rasmus Kaae & Gitte Klitgaard Hansen. Fast track to Kanban.
About the Author
Sune Lomholt, PhD and engineer with 12+ years of experience in solution development and architecture including modelling of processes, services and user interfaces. Several years of experience with agile practices both as practitioner but also as coach and team lead for agile coaches.