This article introduces Kanban(看板), a very effective process for organizing your team’s work and driving improvements, especially if you are on an interrupt-driven team such as Site Reliability Engineering, Operations, IT, or Customer Support.
The essential part of the process is the kanban board, which consists of cards representing each work item. Cards are moved between columns representing the state that the work item is in usually from left to right, such as:
- Backlog
- In Progress
- Done
Some teams use physical boards and post-it notes, while other teams use a SaaS like Jira, Trello, or Notion, and others run self-hosted systems like Wekan or Taiga- what matters is that the entire team is using the same tool to track their work.
The immediate benefits of implementing Kanban are:
- All work is visible: you can now see what your team does
- All work is measurable: you can now see how your team is performing
- Work is easy to reprioritize, which is very useful for interrupt-driven teams
These benefits allow you to build credibility and trust with your stakeholders and customers by completing work as quickly and consistently as possible while remaining flexible to changing business demands.
In contrast to full-on agile frameworks such as Scrum, there are no prescribed processes or rituals. I personally recommend however at minimum a brief daily standup that is focused on discussing the state of the board and any blockers.
Let’s go over the basic rules on how to effectively manage a kanban (from my personal experience).
Kanban Rules
All Work Gets Tracked On The Board
No matter how small, every piece of work should be tracked as a task and put on the board.
Benefits:
- You can clearly articulate the business value your team is providing.
- When someone wants the status of a task, they can consult the board on a self-service basis rather than interrupting the team with a question.
Create Columns For Every Work State
Earlier we mentioned example states such as to-do, in progress, and done, however, there can be several more depending on the nature of the team’s work:
- Triage: a request needs to be reviewed before being accepted as work
- In Review/Feedback: a code change needs to be reviewed prior to merge
- Deploy: a code change needs to be released to production
- Reopened: a request needs rework as a result of a defect
Be careful that each column (and underlying process) is necessary as they can introduce bottlenecks.
Keep Task Scope As Clear and Small As Possible
Each work item should have well-defined acceptance criteria and be small enough in size that it doesn’t need to be broken down.
This results in work items being similarly sized, creating more consistent metrics.
Keep Tasks Up To Date
Ensure that each task you own is in the right column on the Kanban board. I also recommend providing daily updates in the form of comments on tasks that are currently in progress to indicate that they aren’t stale.
That enables the team to easily identify stale tasks on the board as part of the daily standup, ensuring that no task slips through the cracks.
Limit Work-In-Progress
Decide as a team the number of tasks each member can have in progress. My recommendation is 2 as it minimizes the amount of time lost to context switching.
As part of the daily standup, ensure that work-in-progress limits are being adhered to.
Flag Blocked Tickets Loudly
If a task cannot be completed for any reason, mark the task as blocked and discuss it with the team during the daily standup if still unresolved.
If you learn that a task is blocked, see how you can help its owner.
The blocked state can be its own column in the kanban or a simple tag or attribute for the task itself.
Ideally, your ticketing system should be able to notify your team automatically via chat that a task is blocked allowing for an immediate response.
Re-Prioritize The Backlog on a Consistent Basis
Create a periodic meeting where work in the Backlog column is discussed and prioritized based on the current business needs.
(I’ve been on a team where prioritization was discussed on a daily basis!)
Protip: As part of the meeting, take the N most important tasks from the Backlog column and fill up an “On Deck” column on the Kanban board, where N is approximately the number of tasks that have been completed between meetings in the past. “On Deck” will then be the column that the team pulls work from.
If ‘On-Deck’ becomes empty, simply replenish it from the topmost items in the Backlog column.
The benefit of this is that once a task is placed into “On Deck”, stakeholders know with certainty that the task will be completed by the next prioritization meeting.
Do Work In Priority Order
This should go without saying, but be sure to pull work in the order it is prioritized so that stakeholders can trust the state of their task(s) on the board, especially when queued.
Use Swimlanes for Specializations
Sometimes, specific tasks can only be performed by specialists on the team (eg: DBAs, Network Engineers, etc). In those cases, the Kanban board can also be split up into rows for each specialized work type (called ‘swimlanes’).
As a specialist, consume work from your swimlane(s) first in order to prevent bottlenecking, and consider how you can enable the rest of the team to perform this work.
Use Deadlines Sparingly
There may be situations where a task must be completed in a specific timeframe in order to fulfill a contractural or compliance-related obligation. In those situations, attaching a deadline to tasks makes perfect sense.
Release those tasks into the “On Deck” column when they can still be completed on time by the next planning session.
Use deadlines with discretion as they can disrupt the team’s natural work cadence and predictability.
Useful Metrics
If possible, generate these metrics and display them on a dashboard to assess the performance of the team. Given the low volume of tasks performed, mean and max aggregations are probably okay to identify general trends and occasional outliers.
Lead Time
The lifetime of a task from open to close. This includes how long a task is waiting in the queue. This metric is to Kanban as points-per-sprint is to Scrum.
Cycle Time
The lifetime of a task minus the time waiting in the queue; is in the time spent when it was assigned to someone and being performed.
Throughput
The number of tasks completed per time period. This will be useful when prioritizing the backlog to extrapolate when a specific task will be completed.
Reopen Rate
What percentage of tasks were reopened due to defects/not meeting the acceptance criteria?
Driving Improvements
Now that your work is visible and generating metrics, you can create a continuous improvement process (kaizen) on how work is done. Here are some ideas to get started:
- Investigate what types of task(s) have the highest cycle times and determine how to lower them. Is the work too manual and requires some automation? Is there too much back-and-forth between the task owner and the requester?
- Investigate which task(s) were reopened and determine why. Are there additional quality control measures that are needed to reduce their rate of occurrence?
- What are the most common sources of task(s) being blocked? How can that be resolved?
- If the team is experiencing low throughput, investigate sources of interruptions or unplanned work that aren’t being tracked in the Kanban (alerts and outages) and determine how to address them.
Conclusion
Kanban is a really powerful tool to provide visibility and consistency to your team’s work as well as create an ongoing conversation on how to improve how work is done- so long as you stick to the process!
I’ve implemented Kanban successfully for both operations and software development teams, which has helped them both become more efficient and visible to the organization. Are you struggling with how to best organize work on your team? Reach out and let’s together bring order to chaos!
(Reference: Kanban: Successful Evolutionary Change for Your Technology Business)
(Image produced by OpenAI DALL·E 2 with prompt “pencil sketch of a kanban board”)