We are pleased to welcome previous Service Management speaker and member of the ITSMF Awards Alumni Ian Jones to the blog today!
I previously led an IT Service Management team providing 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 be seen as strengths or weaknesses. Some of these differences include:
|Work scheduling||Customer driven pull||Fixed timeboxed push|
|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:
- Post Incident Review (PIR) booked;
- PIR held;
- Publish and Task Followup; and
- 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.
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.
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/.
This blog was originally published on Ian Jones’ blog.