The implementation of Kanban can be as simple or complicated as needed. A very basic example is a table drawn on a whiteboard with 4 columns: backlog items, in development, under review, and done. A unit of work would be pulled across the board as it is being worked on until it is completed. Each piece of work on the board would be of equal priority. Unfortunately, ‘simple and tidy’ and ‘IT project’ are terms that are rarely used together. In many cases, higher priority units of work and interruptions, such as production problems, appear on a regular basis. Different types of work can represent different classes of service, each class with its own relative priority to the other groups.
In order to explore why some teams need to parse their work into different groups with different priorities we’ll look at an example. Recently I visited a team that generally worked on support tickets and small enhancements. The team has a service level agreement that obligates them to spend approximately 50% of their time doing enhancements and the rest on support. The support category is mostly comprised of low severity production tickets. Their Kanban board originally was undifferentiated and looked approximately like the example below:
The only way to really understand whether the team was honoring their commitment to spend 50% on support was to look carefully at each item on the board. However, the stakeholders didn’t trust that the IT was honoring the SLA. In order ensure transparency the team modified their Kanban process to acknowledge the two classes of work (support and project) creating a new board similar to the one below.
- Kanban Board with Class of Service Shown.
The new Kanban board not only separated the support and project tickets, but highlighted the split work in progress limits. I have seen groups use different color cards to as an approach to the same information need. Another example of a support team that used a Kanban board to visually manage the flow of work had three classes of work; one for priority one problems, and others for priority two and three problems. Find the level of granularity that works for your team and stakeholders. Do not be afraid to experiment with different categories.
Another common issue that most groups wrestle with is the infamous high priority interruption. While interruptions should be minimized, some interruptions can’t be avoided. When an interruption is unavoidable the work enters the board and, if we are running at our WIP limit, supplants a unit of work of equal size. The Kanban board below explicitly calls out an expedited and on-hold track so that when interruptions occur that the impact of accepting new work into the flow can be assessed and visualized.
In a real life example, a hardware manufacturer adopted a simple board for their test lab that included an expedited track and waiting track. When an “emergency” change entered the lab, a test on a current project had to be stop and put on-hold. The simple board was put in the window of the test lab so that everyone in the plant knew when an emergency change was put into test, and which project had been sidelined as a result. The transparency reduced the number emergencies. Analysis of the data after implementation suggested that most emergencies reflected poor planning or workflow, and were therefore avoidable.
Application of a Kanban approach provides teams with a mechanism to manage workflow regardless of complexity. Both different categories of work and interruptions can be visually portrayed using a Kanban board. When the flow of work can be visualized, it is easier to manage. This provides teams, their managers and stakeholders with a powerful tool to improve the control of their work environment.
December 29, 2014 at 11:55 pm
[…] a typical implementation of Kanban, classes of service allow teams to break backlog items into different groups either based on risk or the cost of delay. […]