by Marcus Hammarberg and Joakim Sunden, author of Kanban in Action
Kanban is an approach to software development based on the principles of lean. It has quickly been picked up by many businesses around the world. You can pick it up too! This article, based on chapter 2 of Kanban in Action, defines kanban, introduces kanban principles, and gets you started using kanban.
In this article, we’d like to show you the principles kanban is based on. But fear not, this not a lengthy theoretical write-up on everything kanban. We will keep the theory to a minimum and serve it too you in bite-sized chunks just as you need it.
We’ll also give you quick recipe for how you can get up and running with kanban quickly. So let’s dive right in and see how kanban is different than other methods and why that is good news for all of us.
We have presented and introduced kanban to many teams at conferences, through presentations and as consultants for different companies. Had we chosen to introduce other processes such as Scrum, Extreme Programming (XP), or even Rational Unified Process, we would have focused on how and what to do and not to do, how long iterations or sprints are, which tasks are for the Product Owner role, and so on.
Kanban is not like that. It doesn’t prescribe that many things at all, but is more like a meta-process that can be applied to whatever process you are working with today. This is great news because that means that we can start where we are today, without changing anything, and improve from there. No new process, no new roles and no troublesome reorganizations needed.
|Kanban, kanban, or kanban?|
|If you read the text closely you might spot that we’re spelling kanban with a lower case "k” in this book. The kanban community is continuously improving and evolving, so things change a lot. We have interpreted the current knowledge as follows:|
So, what is kanban?
Kanban is an approach to software development based on simple, but powerful ideas. It aims to make the work flow fast through the whole value-chain, from idea or concept to software in production, delighting our customers. The tools that make this happen are a couple of simple, yet powerful principles: visualizing your work and policies, limiting the amount of work in progress, and helping the work to flow better through the process.
These tools can guide you to continuously improve your process to gain an even faster, even smoother flow of work through your process. This is a never-ending quest that will help you and your team to improve, little by little, every day.
|The Japanese connection|
|You should probably know something about the word kanban itself, if for no other reason so that you can impress your friends with your knowledge in Japanese. Because kanban is actually two Japanese words put together: "kan” meaning visual and "ban” meaning card. Put together is becomes something like "visual card” or "signaling card."|
|Kanban as a concept comes from Toyota Production System (TPS) and signals that new work can be started or pulled from the station before yours. Lean was adapted from TPS when this thinking was introduced to the Western world. This is why you will find a lot of references to both TPS and lean throughout Kanban in Action and any other text that talks about kanban for software development.|
Although kanban doesn’t prescribe many concrete things, we still can improve greatly by using it. How can that be? At the heart of kanban are a few principles that guide us on how to use kanban to improve. Let’s take a closer look at those principles.
The principles of kanban
Kanban is based on three simple principles:
At first, making your work visible can be as simple as creating post-it tickets that represent each work item, and then a board to track each item’s current status. This is a great way to get to know your work, how your "work works” and to start seeing problems and improvement opportunities in your workflow.
For many teams that we coach this is actually the thing that creates a big impact right away: just making visible the information that previously was not can help you solve a lot of problems.
There are other, underlying aspects to visualization as well, since we’re also starting to make implicit policies around the work explicit. That is, everybody might know how we work with a feature request but, by just showing the workflow on the board as columns, this becomes very apparent to everyone in the team. By doing this we make any differences we might have on policies around the work more evident. This can lead to a discussion that clarifies the policies we work from and we can easily capture them on the visual board, so that all team members approach the work in the same way.
The principle of limiting work in process quite simply means that you deliberately establish a limit for how many items you work on at the same time. The first apparent gain from this is that with fewer items being worked on at the same time, each item will be done more quickly.
But limiting work in process is important for other, more subtle reasons as well. By establishing a work in process limit, you create a little tension in your workflow, and this is a Good Thing™ since that will start exposing problems in our system or, as we put it, "an unrealized improvement opportunity.”
Limiting work in process will begin uncovering problems. Progress through the workflow will stall (stickies moving slowly over the board), begin to back up (a lot of stickies in certain columns), or stop completely (items waiting forever). These are all indicators that you can improve your system. What you do to fix these problems will determine if you improve or not.
But, if you want to improve, you should know what the goal is, and this is where the last principle of kanban comes into play: help the work to flow quickly and without interruptions through the workflow.
Here is where your journey to continuously improve the workflow begins. The bad news is that you will never be done with this task. Your workflow can always be improved; there’s always a bottleneck that slows you down. The good news is that the problems will reveal themselves to you, visually, on the board. Not only that—often the biggest problem will be revealed first. Solve that and you have made a big improvement to your system.
There are several things you can do about this:
- Check to see if the way deployment was done is hindering the flow.
- Discuss and handle bugs. You could say that bugs are of another class of work than the other items and maybe should be given precedence over other items in prioritization.
- Put work in process (WIP) limits in place to help your work to flow smoothly, for example, queue items for acceptance so that you don’t have to run to the team several times everyday.
There are a lot of things you can to do help the work to flow. It is within this principle that you can start using many of the techniques from lean in order help your work to flow smoother by removing waste in your process. Or maybe take a look at theory of constraints and identify, exploit or alleviate the bottlenecks of your system. Other practices from the agile movement might help you to improve collaboration and code quality and thereby improve the flow of your system. It’s really up to you which route you take to improve your system. The important thing is that you react to the signals that your work is sending you and improve on it.
In reality, you will see the principles combined with each other a lot: for example, in order to get a quicker flow, you limit work in process, which is also shown visually on the board.
With a visualized workflow, limiting the work in process and focusing on moving work through your workflow, you have set yourself up to easily spot problems and remove them. How you go about doing that is pretty much up to you. Tap into Kanban in Action for practical explanations and examples.
The search for improvements will soon take you outside the boundaries of your own team. In order for you to get a faster flow, you might have to interact with other teams or functions around you in a different manner. A first step toward this is to include teams or functions before and after yours, on your board. Or maybe even have a board for all the teams in your department, aggregating the status of the teams there.
This is where the kanban principles can be used on a broader scale to become the Kanban method . It’s the beginning of a transformation, ultimately, of the entire company, in an evolutionary way. Soon you will find yourself teaching kanban to others and be involved in change management.
|Three principles? I thought it was five? Or maybe six?|
|Kanban is fairly young as a methodology used in the software business. There’s a vibrant community, and new things are discovered and put into practice continuously. This is of course something good and sits very well with the principles of lean and the continuous improvement thinking.|
|The three basic principles we describe in this article are the foundation that kanban is based upon. Recently David J. Andersson has extended the three basic principles to six, what’s called core practices . We’ve already mentioned some of them and they are:|
|That’s three more practices added to the principles that we’ve talked about so far. Note that this holds true for the Kanban method of "incremental, evolutionary change for technology development/operations organizations,” and in that context the last three practices are important.|
|As you probably have noticed already, we take a practical and pragmatic approach, and for us the last three practices fit nicely within the basic principles:|
|From this sidebar, you now understand why we are talking about three principles when others are talking about five practices. Or was it six?|
Get started right away
You can easily get started right away, due to the lightweight nature of kanban. In fact, why not start now?
It doesn’t take much and you can start easily right where you are today. Just start focusing on getting stuff done, really done, before picking up new work. Make that the motto for you and your team: stop starting—start finishing!
This is a simple way to limit the work in process, but it can be very effective.
If you want to be a little more concrete and practical, you can also do an exercise. Here’s a short description on how that can be played out:
- Start by visualizing your work. We asked the team to just create a post-it for each work item they actually worked on and post it anywhere on a whiteboard.
- Map your workflow to the board. A simple way to do this is just to create a column for each stage in your workflow. Move the tickets that are in the different stage into the right column. Resist the urge to optimize your workflow before you can see what’s going on. After this exercise, you might end up with a board like this:
- Make a couple of dry runs with some work that has passed through your workflow to see that it actually is the way that you work. Change as needed. We think it’s good practice, and it quickly shows you if you got the workflow right or not. Remember, at this stage you’re aiming to track down how you actually work.
- Decide on a work in process limit—how many work items you, as a team, should be working on at the same time. But, please don’t overthink it. It’s better to just get something up there and improve as needed. For now, just go with two per person in the team and spread them evenly across all columns, for example.
A WORD FROM THE COACH Make sure that you draw the board together as a team. Don’t let one person do this by themselves—not even you. The buy-in from the team will suffer greatly. Trust us—we’ve made that mistake far too many times already.
A very simple way to make this exercise a team effort is to just pass the pen around as you draw the board.
For extra measure, create some avatars, small pictures of yourselves, and attach them to the things you are working on now. This will help you more easily see what’s going on and who to turn to if you have questions regarding one of the work items.
There, you now have a very simplified kanban board to improve on. But even this simple tool will help you to spot problems and continuously and relentlessly improve, in small steps.
You are up and running. As your work progresses, move the items accordingly on the board. Decide to meet each morning and talk about any problems that occurred—these are your improvement opportunities! Don’t waste them!
Kanban in Action is packed with practical advice on visualizations, how to limit work in process and different ways of helping your work to flow smoothly and quickly through your workflow. We have put a strong focus on practical matters to make sure that you can use the practices, patterns and tools we describe right away with your team.
Here are some other Manning titles you might be interested in:
Agile ALMMichael Huettermann
The Art of Unit Testing, Second EditionRoy Osherove
Unit Testing in JavaLasse Koskela