Delivering Problem Management with Kanban

I previously led an IT Service Management team provided Incident, Problem, Change and Configuration Management services in line with ITIL. Our work was highly variable and ranged in complexity since we primarily supported other IT professionals in their IT operations. The whole team used Agile Scrum to manage our work and the problem analysts used Lean Kanban for (ITIL) Problem Management. This blog post will outline how Kanban was applied to effectively deliver our Problem Management service.

Our organisation used Agile as the main delivery method for projects, and Lean (based on the Toyota Production System) for operations. Bell and Ozen (2011, p8) suggest Lean aims to empower teams to simplify, then when appropriate, automate routine tasks. Process improvement frees up capacity, providing individuals with more time and better information to exercise problem solving, creativity and innovation in situations that are not routine.

What is Kanban?

Kanban means sign, signboard, billboard, card or signal of some kind (Liker, 2004, p. 106). It is a scheduling system for Lean, just-in-time production and a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary process improvement for organisations (De Haaff, 2013). For readers who are familiar with Scrum, you would be aware of this concept of the signboard or visual management in the form of a story wall. There are differences between Kanban and Scrum and these differences shouldn't been seen as strengths or weaknesses. Some of these differences include: 

	Kanban	Scrum
Work scheduling	Customer driven pull	Fixed timeboxed push
Task estimation	N/A	Yes
Tracking work	Focus on flow	Focus on velocity
Work in progress limits	Yes	N/A
Process ownership	Team	Scrum Master
Continual Service Improvement	On demand, as defects are seen	At the end of the sprint in the retrospective

Application to Problem Management

Initially my team employed Scrum for managing their problem investigations however we found the concept of timeboxing the work into sprints added no value. Investigations could vary greatly in complexity and therefore finding the root cause and completing corrective actions could be difficult. Task estimation was also challenging and the actual results varied widely due to the above reasons. The team then applied Kanban as an alternative and their wall contained the following columns:

• Backlog;
• Post Incident Review (PIR) booked;
• PIR held;
• Publish and Task Followup; and
• Complete.

Kanban suggests that staff 'pull' work from left (first column) to right (last column). If staff have capacity  (actual work in column X < work in progress limit in column X) then they pull work from the previous work step (column on the immediate left). This video provides a visual explanation. 

The problem analysts employed a series of important variations to their Kanban wall. These variations included:

• They pulled work from the 'Publish and Task followup' and not 'Complete' as this step is entirely dependent on other IT staff (tasks like corrective actions are mostly performed by other IT staff) and the duration of task followup is variable; 
• Unlike typical value streams, the problem analysts do not hand over their investigations to other staff and tended to progress the investigation from start to finish (except for extended absences from work). This was because the effort and cost of task switching between problem investigations exceeded any proposed benefits from handovers between investigation steps;
• Work in Progress limits were informally used and not strictly enforced. If an analyst had too many investigations in a particular column, we used it as a flag for assistance and potentially management escalation rather than a reason to block the incoming work. Upon these events, we preferred to negotiate with stakeholders (service owners, management) on work priorities rather than block the work.  

So as you can see, the team took the concept of Kanban and tailored it in a way that supported them which should not be surprising since problem investigations by their nature, are not generally standard nor repeatable forms of work. 

One significant benefit we saw in adopting Kanban was that it supports Principle 5 of the Toyota way "Building a culture of stopping to fix problems, to get quality right the first time" (Liker, 2004, p.38). The visual management of our work and conducting daily stand-ups allowed the analysts to easily identify defects or weaknesses in their investigations, pause work and jointly derive immediate improvements to their service. This has led to significant quality improvements in their work which was acknowledged by our customers and management.

References
Bell, S., and Orzen, M. (2011). Lean IT, New York: CRC Press.

De Haaff, B. (2013) Kanban the secret engineer killer. Retrieved July 30, 2013 from

http://blog.aha.io/index.php/kanban-the-secret-engineer-killer/

Liker, J. (2004). The Toyota Way, New York: McGraw-Hill.