You may have heard the term Kanban used in your organisation or you may have heard people mention it as though it’s a keyword in a secret society.. If you haven’t ever heard of Kanban, then its worth investing 10 to 15 minutes of your time to find out what it actually is, and how you may be able to use Kanban. If you’re already a Kanban expert then please feel free to give us your input and feedback so that we can share your insights with others.
Firstly, What Is Kanban?
‘Kanban’ is a Japanese word for a visual signal or word. It was used by Toyota to mean a signal card. The concept was introduced by Taiichi Ohno considered to be the father of the Toyota Production Systems (TPS). The signal card was a physical card used by line-workers in the Toyota plant that encouraged teams to communicate better and work smarter on what work need to be done and when. For example it could be used to signal when to move inventory from a supply step or storage location. Hence Kanban became the ‘just-in-time’ inventory control system for the Lean manufacturing model. It effectively helped to eliminate waste and improve value. The current term Kanban was adapted from the Lean manufacturing approach (Liker, 2004).
Looking back on what I now know of Kanban I recognise that this as what we were using in a cardboard carton printing company I worked at back in the 1970’s. We had a large wall board which showed us our work in progress (Work Tickets) and backlog of work scheduled for the various printing, cutting & creasing and gluing machines that were used within the manufacturing process. It allowed us to efficiently schedule work and ensure that we didn’t end up with bottlenecks at any stage in the manufacturing process, or equally expensive machines and operators standing around idle. It helped ensure that materials in our supply chain were delivered on time and customer delivery dates were also met. It ensured that we operated in an efficient, effective and flexible way and that everything was visible to everyone (especially management) at a glance.
What Is The Kanban Method?
The Kanban method (Anderson, 2010) is an approach to continuously improve Service Delivery. The method emphasises the smooth, fast flow of work.
Kanban does not prescribe specific roles or process steps as it is built on the concept of evolutionary change. The start is to understand how your current software delivery system works. When the current flow of work is visualised and measured, it allows you to improve it one step at a time, and continue doing this again and again.
Here are the 6 core Kanban practices:
- Visualise The Work – Meaning that you should be able to, at any time, look at your overall workload, be able to determine quickly what you should work on next, and have visual cues for priority and time to complete. The system should also be easy to add, remove, and re-organise.
- Limit Work In Progress (WIP) – Means that you should limit the number of things you work on at the same time. There are two key advantages to this. First, it makes it easier to visualize your work, because you keep an eye on (literally), how much you have on-going at any moment in time. Secondly, it also helps you avoid taking on more work than you can handle.
- Measure and Manage Flow – This means that the members of the team/project should measure their progress and use the gathered information to improve their way of working. This is also the flow of work through the various stages in the workflow. Smooth, fast movement, indicates productivity.
- Make Policies Explicit – The design of your Kanban board will make process policies explicit. This could be by designing the board to specify how the work flows, or to use WIP limits to explicitly state in your policy about how much WIP you are able to take on.
- Implement Feedback Loops – Processes that need to evolve over time require feedback loops. The purpose of feedback loops is to be able to compare expected outcomes with actual outcomes and make adjustments. Operational feedback loops may include: the standup meeting; the service delivery review; the operations review; and the risk review.
- Improve Collaboratively and Evolve Experimentally – A shared understanding of workload, workflow, process, and risks, will ensure that you can build a shared comprehension of a particular problem and can suggest improvements which can be agreed by consensus.
What’s The Purpose Of A Kanban?
Many teams, especially operational teams are often under excessive pressure take on more work than they have the time or capacity to perform. This can cause long delays for customers in terms of access to services and products, impact to revenue streams and reputation, not to mention personal pressure and stress for those within the teams.
Kanban in its simplest terms is quite simply allowing you to see the work in progress i.e. work that has been started but not yet finished.
I should also point out that whilst we talk about a Kanban board, Kanban is more than just the board.
What Are Your Objectives Of Using A Kanban Board?
Typically the key objective stated by those using Kanban is to make work visible, but other objectives could equally be:
- To manage workflow;
- To help counterbalance demand and capacity;
- To improve customer satisfaction;
- Help reduce stress on those participating in actual service delivery.
If these are amongst your objectives of using Kanban, then great, but how will you know that you have achieved them? We’ll talk later about measurement, KPI’s and metrics.
What Are The Benefits Of Using A Kanban Board?
The key benefit is that work is managed so that teams do not take on more work than they can actually manage. It makes the backlog of work visible (to everyone), and allows management to understand conflicting priorities and where bottlenecks exist within a workflow. It allows them to see where they need to increase capacity within the workflow to allow demand to be met, or occasionally when to reduce demand. Optimisation is the key, just enough pressure on staff to encourage performance but not so much that they go off sick with stress adding more pressure on the remaining team members.
Kanban can also assist in getting us to recognise (not an easy task), that as well as planned work there is this something called unplanned work that we have to make space for. If we fail to plan for unplanned work then we will end up with more work than we can actually manage. Its a bit like committing a team member to work 100% of their time on a new development project, and also expecting them to fix the incidents which occur because of bugs in the existing product. A Kanban board now makes this unplanned ‘invisible’ work visible. A Kanban board ensures that work is only pulled into our team, or individual work queue, when we have capacity to manage it, otherwise it stays on the back burner (on our to-do list). The key is about limiting work in progress which sounds counter-intuitive but believe me it isn’t. In this case, less is more.
Kanban Board Concepts
1. Use a board which is visible to all stakeholders – this could be a whiteboard a magnetic board, a plain painted wall or even a flip chart.
2. Team members update work on the board – this is imperative so that it does not become out of date.
3. All stakeholders have a shared view of the work – visibility is the key.
Because we now have a large board attached to the wall, anyone passing by can see that board. Any team member can update the board. You all have a shared view of the reality of your work. Your team can also gather around the board and easily review the current situation.
The board could simply be a physical white board or it could be a large video screen. The important point is to make the information about your work really visible, not just potentially visible.
KANBAN VS SCRUM
Scrum and Kanban are both good planning tools, so it’s a bit like comparing a knife and fork to chopsticks. Both Kanban and Scrum are highly adaptive, but relatively speaking Scrum is more prescriptive than Kanban i.e. work managed in 2 – 4 week sprints. Scrum also gives you more constraints like not to amend the sprint forecast during a sprint, and thereby leaves less options open. Scrum also prescribes the use of time-boxed iterations which have to be reset, Kanban is persistent, it doesn’t need resetting.
Scrum prescribes three roles:
- Product Owner (sets product vision & priorities),
- Team (implements the product)
- Scrum Master (removes impediments and provides process leadership).
Kanban doesn’t prescribe any roles at all.
Kanban in comparison is continuous, allowing releases at the team’s discretion and change can happen at any time of the work cycle.
So can we then suggest that Kanban is really a better option than Scrum for operations? But we could equally say that Kanban could be used to manage a series of Scrums, or where Scrum just isn’t suitable, or where we choose to use Kanban to replace Scrum.
It really depends on whether you want a formal or informal agile approach. The choice is yours.
How To Actually Create A Kanban Board
Firstly differentiate the different types of work. It’s your choice but maybe use the following as a guide to different types of work
- Project Task
- Service Request
- Internal Improvement
- Unplanned Work
Colour code the types of work on different colour post-it notes
A Simple Kanban Board
Now create your board using different columns (stages). At a very simple level how about?
- To Do
Or maybe make it a little bit more complex… How about these as column headings
- Available Backlog
- Top 3 Priorities
- In Progress
- Require Validation
- Doing Validation
As well as vertical columns which indicate what state the work is in, you can subdivide your board into horizontal swim-lanes- rows which may indicate types of work that could be allocated to sub-teams or individuals. You may well create a special swim lane for tasks which are blocked for some reason.
The choice is yours, adopt Kanban ‘Best Practice’ and make it work for your particular requirement. Don’t be afraid to add or remove a column as you learn what works and what doesn’t.
If you have multiple teams then it’s likely that your board will differ from other teams. Avoid imposing a standardised board on all teams. In fact the people that are doing the work should be the ones that get to design each board. And remember they aren’t ‘set in stone’… adopt and adapt to meet changing business needs.
Multiple Kanban Boards
You don’t have to limit yourself to one Kanban board. How about boards at 3 or 4 levels
- Personal Kanban - A simple system for measuring your to-dos. It’s an easy way to visualise and prioritise your workload. The real benefit is that it helps prevent you taking on too much work and makes your work not just visible to you but to your colleagues. The ‘done’ section should also help to motivate you by showing your successes.
- Team Kanban – Ideal for maintenance teams that manage small pieces of work that don’t require much estimation or planning. Equally could be used for large on-going pieces of work which don’t fit naturally into a SCRUM based Sprint timeframe.
- Project Kanban – Ideal for project teams that don’t need or want the constraints imposed by the use of a SCRUM approach.
- Program level Kanban Board – Ideal for very long term activities compared to a project board which will just exist for the life of the project.
Again chose the columns and swim-lanes that work for you. Remember it’s all about being able to visualise the work. It makes sense to standardise the coloured post-it notes for different types of work across all boards, otherwise you’ll cause some confusion.
Physical boards are great, but what about if your teams are spread across different offices, even different countries. Well its technology to the rescue. Kanban has been around as a concept long enough for our software vendors to spot an opportunity.
If you are using tools you will need to ensure that people have the same level of access that they would have to a physical board.
Some Challenges And How To Overcome Them
Complexity – Don’t try to ‘boil the ocean’. A Kanban can do a lot, but the more complex you make a board the more confusing it will be. Simple is best. For example rather than try to cram in project risks onto a project board, why not create a separate risk board.
Buy-in – Get the stakeholders to design the boards that they’ll be using. It has to work for them otherwise they won’t use it.
How do you measure progress using your Kanban board? Firstly identify what it is that you should be measuring… from a customer and a personal perspective.
What does your customer care about? How long will some piece of work take to complete? When its going live? Where’s it up to?
And what do you want to know? Where are the bottlenecks? Where are things getting stuck? Can you catch up or even go faster?
A Kanban can answer some of these questions but being quite honest it’s a simple tool.
You’ll have to start collecting data like work arrival rates and completion dates which will allow you create cumulative flow diagrams. These will make work visible and show where a backlog of work is starting to build up. It will show how much work is actually in progress and lead-times for completion of work.
In my research it was suggested that you could take a daily photograph of the board or whenever a change is made. It is then possible to create a stop/start movie of the progress that has been made.
Interesting in formal Agile training?…
Why not consider taking some formal accredited training (Accredited by the DevOps Institute and APMG).
- DOI DevOps Foundation
- BCS DevOps Foundation
- Certified Agile Service Manager (CASM)
- Agile Project Management Foundation
- Agile Project Management Practitioner
Other areas of formal Agile training will be announced during 2018 and beyond.