The main reasons to use Kanban are that it shows everyone the true state of the work, exposes the stage where work gets stuck and stops a team starting more than it can finish. It suits work that arrives continuously, such as support requests and small changes to a system already in use, better than it suits a single large build. This article explains what Kanban is, gives seven reasons to use it, and says where it is the wrong choice.
What Kanban is
Kanban began in Toyota’s factories as a way of signalling that a process needed more parts; Toyota translates the word as “signboard”. In software and office work it has come to mean a board with a column for each stage a piece of work passes through, for example:
To do, In progress, Testing, Awaiting approval, Done
Each piece of work is a card. Cards move from left to right as the work advances.
That much is only a tidy to-do list. Two rules turn it into Kanban. The first is a limit on how many cards may sit in a column at once, called a work in progress (WIP) limit. The second is that work is pulled, not pushed: a new card is started only when a column has room for it. The Kanban Guide, a short free document maintained by practitioners at kanbanguides.org, sums up the whole method as three practices: defining and visualising a workflow, actively managing the items in it, and improving it.
Seven reasons to use Kanban
1. Everyone can see the state of the work
A board answers “where are we with that?” without a meeting or a status report. A manager, a developer and the person who asked for the change all look at the same picture. If the board is shared with you as a client, you can check progress whenever you like.
2. Bottlenecks show themselves
When cards pile up in one column, the board is telling you something. If ten items are waiting for testing and one is being tested, writing more code will not help; the constraint is testing. In our experience the full column is often “Awaiting approval”, which means the delay is on the client’s side and is easy to cure once it is visible.
3. Less work is left half finished
Without a limit, people start new tasks whenever they are blocked on old ones, and a team ends up with twenty things begun and none complete. Half-finished software has cost money and delivers nothing. A WIP limit forces the uncomfortable but useful question: what do we need to do to finish this before starting that?
4. Priorities can change without upheaval
Kanban has no fixed cycle to protect. The order of the “To do” column can be changed at any time, and the next card pulled is whatever is now at the top. Work already in progress is left alone, so an urgent request does not derail everything else.
5. It fits work that arrives unpredictably
Support and maintenance cannot be planned a fortnight ahead, because nobody knows what will be reported next week. A flow of small items with a clear order suits that kind of work far better than a plan made of milestones. This is why Kanban is common in software maintenance.
6. It gives you forecasts based on evidence
Record the date each card starts and finishes and you soon know how long a typical item takes, which Kanban calls cycle time, and how many items are finished in a week, called throughput. “Most requests of this kind are done within eight working days” is a statement drawn from the team’s own record, and more useful than an estimate made in a meeting.
7. You can start from where you are
Kanban does not ask you to appoint new roles or adopt a new calendar of meetings. You draw the process you already have, put the current work on it and improve from there. That makes it cheap to try and easy to abandon if it does not help.
When Kanban is the wrong choice
Kanban manages a flow of work. It does not, by itself, tell you when a large project will be complete or what it will cost. A defined build with a budget and a deadline needs an agreed scope, milestones and acceptance checks as well; a board is then a good way to track the work inside that plan. We compare plan-first and iterative approaches in agile vs waterfall.
It also fails quietly when nobody enforces the limits. A board where every column is allowed to grow is just a display of the backlog.
Be careful with one benefit that is often claimed, which is that a visible board makes individuals accountable. The board is for seeing how the work flows. Used to compare one person’s card count with another’s, it encourages people to split work into small cards and to avoid the difficult ones.
Scrum is the usual alternative. It works in fixed cycles called Sprints, with a Product Owner, a Scrum Master and Developers, and suits a team building a product towards a goal. Plenty of teams combine the two, running Sprints with a Kanban board and WIP limits inside them. The top software development methodologies covers the wider choice.
Kanban tools
A whiteboard and sticky notes are enough for a team in one room. For teams that are not, these four are widely used on software projects and were all current products when this article was updated:
- Trello, from Atlassian: boards, lists and cards with little else to learn, and popular outside software teams.
- Jira, also from Atlassian: Kanban boards with WIP limits, tied to detailed issue tracking.
- Azure Boards, part of Microsoft’s Azure DevOps: Kanban boards with WIP limits and a cumulative flow chart, alongside the code and the release pipeline.
- GitHub Projects: a board view over the issues in a GitHub code repository.
This is not a ranking. If your supplier already keeps the code in Azure DevOps or GitHub, the board that sits beside the code is usually the sensible choice, because cards can link directly to the changes that completed them. Our guide to Kanban software looks at the options in more detail.
How to try Kanban for a month
- Write down the stages your work goes through now, including the waiting stages such as “Awaiting approval”.
- Put every item currently in hand on a card in the right column. The number of cards is often a surprise.
- Set a limit for each working column. Start lower than feels comfortable: the aim is to make the team finish things, and a limit can always be raised later.
- Meet briefly at the board each day and read it from right to left, asking what would get the nearest card finished.
- Note the start and finish date on every card.
- After a month, look at how long items took and which column they waited in longest. Change one thing and run another month.
If a supplier does the work for you, ask to see their board and ask what their WIP limits are. A supplier who manages work this way will have a ready answer, and the board will show you where your requests are waiting. Our list of questions to ask a software supplier has more to check before you sign.