The short answer to this question is: A Kanban project looks like any other project. The scope and complexity are the same, the risk picture is the same, the budget and the time allocated are most likely the same. The baselines around your project are usually independent of the method you use.
One obvious difference with Kanban is its visual aspect. Kanban, loosely meaning “visual board,” is touted as a visual basis for managing a software development project. Yet many of the descriptions and discussions available on the web describe Kanban practices in words, without providing actual visualizations of the process. This article attempts to improve on that situation.
6 core practices in Kanban
Aside from its visual nature, there is also a big difference in the way you control your work in the Kanban method compared to any other method, whether agile or classic.
Let me first reiterate what the Kanban method contains and why it’s different. There are six core practices in Kanban. They all help generate “pull” signals on your Kanban board with the purpose of doing the most important thing first at maximum speed and with the level of quality that will satisfy your customer:
Visualize your work
Limit work-in-progress (WiP)
Manage flow
Make policies explicit
Implement feedback loops
Improve collaboratively, evolve experimentally
Kanban organizes work, not people!
Kanban allows you to model the method so it becomes fit-for-purpose in each individual situation, organization, project, etc. Kanban can be used to control all knowledge work, or service delivery work, including IT projects. It helps you get control over how your projects actually work, and it helps you organize that work. No roles are dictated, and no roles are ruled out.
Instead, you self-organize around your activities and decide who should do what. If you need to have formalized roles, you decide what these roles should be once you have analyzed your work and the process it should follow in order to optimize quality and flow. This way you align the roles to the context instead of enforcing certain roles that might not fit your particular situation or project.
In Kanban your board should not be empty until your project is completed. The board will never be empty if you use Kanban to control your work in a particular department or team. Work flows in a continuous stream, preferably uninterrupted. You do of course plan what should next be taken from your total backlog and into the board queue, based on value, risk, release plans, etc.—i.e., the criteria on which you prioritize your total backlog.
Let’s get practical: Kanban boards
Below you see a few examples of typical Kanban boards. These are all physical boards, but you can find software that can give you almost the same level of visualization and transparency. Unfortunately, not all software systems allow you to play with colors in the same way a physical board does with its many different colored Post-its, magnets, small Post-its on big Post-its, etc. If you decide to work with an electronic board, don’t let restrictions in the system decide how your Kanban system should work.
A Kanban board is not merely a task board. To get optimal flow in your system, you should apply all six core practices—for example, you should agree on explicit rules for your definition of done. Your agreed "team rules" will help deliver quality, and they should be visible next to the board, just as your cadences (including the intervals with which you meet with certain stakeholders), the team, or whoever can help you optimize quality and flow, should be visible.
First example: A development team’s Kanban board:
Click to enlarge. This Kanban board is simply based on a whiteboard, with sticky notes of different colors. Note that some of the terms here are in my native language, Danish, but they are explained below.
The above Kanban board holds a lot of information. It may not be perfect if you want all the Kanban practices to be in play, but it’s a good first board that can be improved over time:
The queue contains the next prioritized items that the team should work on.
After each column there is a specified "Definition of Done" that explains what needs to be in place before the item can move to the next column. The purpose is to ensure the agreed level of quality.
Work in progress limits (WiP) are set for each active column. These limits will force the team to complete activities before they start anything new. The principle is “stop starting—start finishing.” Deal with one activity at a time.
The swimlane at the top clearly shows the process steps that activities typically go through.
The first column shows the different types of work that the team has identified:
Fast lane for items that, for a good reason, need to be expedited. Items in this lane are often more important than anything else you have on the board.
Fejl = Danish for "errors" that have escaped and must be corrected.
Udvikling = Danish for "development." These work items typically need more analysis work than errors and may be defined as more important than errors. They may have deadlines.
Intern = That is, internal tasks. These are defined as tasks that the team itself decides to carry out to improve quality over time—e.g., remove technical debt, automate processes that are currently manual, create new checklists, etc.
White magnets with initials written on them clearly show who works on what. Having only one or two magnets each will minimize task switching, which prevents waste.
Other magnet colors are in use to show what items have become urgent to complete, what items are internally or externally blocked, or anything else that you want to pay attention to.
There is almost no limit to how you can put to use colored magnets and PostIt notes. They serve to visualize the state of the work, to help you proactively act on bottlenecks and blockers, and to create transparency. The Kanban board with rules, cadences, etc. will very soon become your team’s "collective extended memory." It offloads your head, reduces stress, and helps you focus on important stuff.
Second example: A board for a small project with only few team members
Click to enlarge. This board shows fewer complexities but uses the same Kanban principles for visualization.
Third example: A project manager’s Kanban board
Click to enlarge. The core practices are the same, but you focus on what you, as a project manager, need to be able to control.
Some metrics showing the status of your project
On Kanban projects, as on any other project, you need to demonstrate the status of your work and the degree to which you are in control. At regular intervals, you measure progress and trends. The following are examples of what teams usually measure:
Leadtimes: How quickly the work items pass through the workflow
Throughput: How many work items you have completed within a certain time frame
The number of blocked items and why they were blocked, so you can analyze and improve
If you are using a physical board, these three metrics are very easy and quick to produce. If you are using an online tool, you can usually make cumulative flow diagrams to provide more detailed information.
If you are a project manager or the one responsible for reporting on team progress, you usually need to produce a regular status report. Below is an example of a simple report that includes the metrics you have decided as well as a short explanation of the current status. Usually, a two-page report will give your steering committee or your management team enough information to be in control.
Example of a simple status report from a Kanban project
With Kanban you can do more with less
To summarize, Kanban provides you with techniques that allow you to create a system around the work you perform that is fit-for-purpose and reflects the context. It balances demand and capacity, provides transparency and predictability, and focuses on quality deliverables that will delight your customers. Everything is done in the simplest possible way.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
