As a popular agile method most would agree that Kanban is lightweight and easiest to adopt in the most basic form. It has less formal ceremonial meetings, does not require extensive training or planning and is well suited for teams that need to tolerate some level disruption. With Kanban you may not have or need deliberate sprint boundaries but may still need to be aware of them in order to sync up with other teams that do.
Typically, operations, IT, Support and other non-feature teams have important work to do but at times may need to drop everything and react to an outage or some other emergency/incident. These teams may also provide support to other teams and thus could be a dependency.
In its simplest form a Kanban board has three columns To Do, In Progress and Done. Here a team member grabs the next card or ticket of the top of the To Do list moves it to the In Progress. This essentially serves to claim it by showing to others that this is now being worked on and by who. Once that work is completed that card is moved to Done and you start over with the next most important thing typically at the top of the To Do list.
Team Composition
Ideally you want small self-sufficient teams so that you do not have many external dependencies. There is no prescribed size for a Kanban team so it could be large or small. One important consideration though in order to drive continuous flow of work through any size team a strong practice of one work item in progress at a time for each member is ideal. So, a “Work In Progress” or WIP limit of 1 is preferred in most cases.
Kanban Events
As is the case with many things there is a prescribed rhythm of business. Kanban does not follow a time boxed cycle but does recommend a few regular events to keep things moving forward:
| Kanban Event | Description |
|---|---|
| Replenishment | Similar to Backlog Refinement in Scrum where you would prioritize new work items relative to others already in the queue. At the same time this would ensure that work is fully qualified and meets the Definition of Ready. |
| Daily Stand-up | Quick opportunity for team to sync on progress, deal with blocking issues and rebalance priorities if needed. We like to suggest that demos of completed work could happen in parking lot after everyone as spoken on progress. |
| Service Delivery Review | Opportunity to review flow related metrics and perhaps identify and define improvements. |
| Operations Review | Examines the big picture of system-wide performance which could lead to discovery of more work to be captured and prioritized. |
The Metrics of Kanban
There are several metrics that serve as indicators of success with Kanban. Here are some of the more popular ones:
| Kanban Metrics | Description |
|---|---|
| Lead Time | Captures the time from when a task is requested to when it is delivered helping to show responsiveness. This could influence other improvements or even suggest a need for more or less team members to do the work. |
| Cycle Time | This is the time it takes to actual do the work from start to finish. This could a level of efficiency that may indicate a need for more improvements. |
| Work In Progress | This represents the quantity of work in progress across the team. Ideally this would be equal to the number of team members. If queue depth is increasing this could reveal a need for more team members to keep up. |
| Throughput | Represents the quantity of work completed over a time period. Of limited value in the short term because work will vary in cycle time, complexity and duration. Over a longer period, this gets interesting and ideally will show a steady increase that can be attributed to process improvement, operational efficiency and balanced resource management. |
| Queue Depth | Quantifies the amount of work stacked up in the queue. Paired with rate of incoming work and throughput can help to reveal a need to rebalance resources. |
In Summary
Kanban is considered lighter weight when compared to Scrum but that mostly has to do with the fact that there is fewer agile ceremony meetings involved. While you should have a regular retrospective in Kanban (you still want/need to improve) but you may not have sprint planning, and you might prefer to demo work completed as soon as it declared done rather than wait for a sprint demo.
If you maintain your own personal To-Do list and update it every day, then you are doing a rough form of Kanban. Over time more art and science has been bolted on, but it is essentially the same.