Systems thinking with Kanban
Read most blogs discussing Kanban and they’ll discuss setting up a board, Identifying lanes (Backlog, Ready to start, In progress, Test, Done, etc.) and moving post-it notes across – Perhaps the blog will go as far to discuss WIP (Work In Progress) limits – And pull rather than push principles and that’s it Kanban in a nutshell.
Ironically if you look at the roots of the Kanban….. Which is in Japanese Supermarkets (Not Toyota, Toyota at one time referred to it as the Supermarket method) there is no Kanban board - Just a token.
Kanban thinking is a methodology for understanding systems. When I introduce Kanban I like to run a number of workshops.
The first is to understand the purpose of the system and to create a shared understanding and context…
It’s important to have the right people in this workshop… And the right people will vary from company to company! But ideally you want representatives from all parts that the system encompasses – If you’re working in the digital arena this might include UX designers, marketers, developers, testers, and importantly people from the business for drive innovation, ideas and projects through the system.
But.... Before getting into anything too serious it’s worth doing something a little light hearted – I like to use http://www.drawtoast.com/
This exercise involves everyone drawing a systems model as to how they make toast – Something simple which we all understand… And then appreciating the many different ways of achieving something so simple and well understood?..... Not to mention the artistic skills or lack of in your team!
Once the fun stuff is done you want to start discussing the purpose of the system… Why does it exist? What’s the objective of the team.. What problems do people have? What opportunities are there? Possibly get ready for some serious facilitation at this point.
The output of these sessions will vary – But hopefully you’ll have created a shared understanding and purpose – you’ll probably discover things about the system you never knew! And hopefully people will gain an understanding as to each other frustrations.
It's important to record these finding and to take them away with you - I like a lot of the work Karl Scotland's done with Kanban thinking and I like to leave with the following headings.....
What are we going to share? (Board, tokens, etc)
Study - What are monitoring?
Value - What's the value we're trying to achieve?
Potential - What could we achieve?
Sense - How are we going to monitor the system, understand it and plan?
Stabilise - WIP, Acceptance criteria, Definition of Done
How you document or record these are up to you.... Brain storming (mind showers as I think is the new PC term) whatever! Just ensure that these points are understood, recorded, public and importantly re-visited!
The 2nd workshop I run is the more familiar what is Kanban…. This talks about the infamous Kanban board and designs for Kanban boards… Everybody has seen the conventional layout but there’s no reason to stick to it! Well there are reasons to stick with it such as shared understanding and ensuring that people can easily read different Kanban boards... However I was on a training course recently and saw one team design a brilliant spiral Kanban board with tickets entering and moving through stages until reaching done... The width of the spiral dictated WIP and there was a channel to expedite tickets via!
Again it’s essential to have the right people in this meeting… I’ve seen too many Kanban boards only model the work of one team. The Kanban board(s) should help to visualise the system not one small part - Everybody in that system needs to be involved and have ownership.
Next look at the design of the Kanban ticket/token….. This might sound boring but it’s important! What information will the tickets contain will you have different shapes and colours for different types of tickets? What metrics will you record? Start date, end dates, dates worked on (Handy for calculating flow efficiency) What about recording movements on the board… Tickets tend to move left as well as right (assuming your direction of travel is left to right) In this workshop I then go to discuss WIP – I often play a game created by Mike Burrows - Featureban to explain and demonstrate some of these principles and it's a really good discussion game for the group. What are the advantages of WIP? What effect does it have on the size of the backlog? What does that mean for lead times and the ability to change direction quickly?
I then go on to discuss the concepts of agreeing WIP limits even if you don’t stick to them straight away… But do make them public and acknowledge this. Next I discuss one of the hidden treasures of doing Kanban – Metrics and for this I usually get the group to play the Penny coin game
This brilliantly shows how you go from an unstructured unpredictable system to one that’s almost clock-work – And how implementing Pull principles with WIP limits will balance a system and help to identify its natural capacity. Metrics will help you to measure and bench mark the system.
The next concept to discuss and perhaps the most important is the retrospective…..
When introducing Kanban one of its selling points is the “Start with what we do now” – This makes adoption much safer! I’m a massive fan of Scrum… But I’ve also seen plenty examples of failed Scrum.
With metrics to understand how the teams currently works you can start to make 'safe' experiments (Discuss these in the retrospectives) and then observe the effect on the metrics… If it works carrying on – If you try something that’s detrimental you’ll know and you can make the decision to roll back. Importantly it means that decisions are made on metrics not gut feel or as Google call it Hi.P.P.O's Highest Paid Persons Opinions
Kanban should be about evolutionary change not revolution - You make a hypothesis conduct an experiment to test and measure!
Finally - Before implementing these changes you need a go/no go decision! At the end of the workshop after speaking with management you need to decide if you're going to go ahead and implement change or not - Not all teams are ready and not all management is ready yet - This takes real courage but if the backing isn't there it's perhaps best to wait until it is.
If you do go ahead - Select somebody to enforce the process, we might not have a Scrum Master in Kanban but do we need a flow master/Lean Manager - Somebody who will ensure that policies are adhered too, the Kanban board is being updated, metrics are being recorded and used - Somebody to facilitate meetings.
My one biggest tip to anyone looking at introducing Kanban... Is perhaps not to call it Kanban! People come with a preconceived idea of what’s Kanban is all about – So if you’re running a workshop to introduce Kanban perhaps consider calling it something else!
If you want to look at, borrow or use my any my slides or materials.... Feel free to do so, I'll add more materials as time allows!