Kanban

/Kanban

Delivering Problem Management with Kanban

ian jones

 

 

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:

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_wall

 

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 or 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.

This blog was originally published on Ian Jones’ blog.

 

By |2018-03-19T16:23:20+00:00June 2nd, 2016|Kanban, Service Management 2016|

Q&A with Sandy Mamoli!

Sandy Mamoli Photo

 

 

 

 

 

From working with Sony Ericsson’s global enterprise website in Amsterdam and Copenhagen to being one of NZ’s leading Agile coaches and Chair of Agile Welly , Sandy Mamoli brings her practical European flair and passionate advocacy of all things Agile to NZ businesses. She’s a former Olympian, a geek, a gadget junkie and emerging triathlete. Sandy is one of the owners and co-founders of Nomad8.

You know your way around a Kanban board. How would you explain the concept to a beginner?

Kanban is a way of managing your list of things to do. In a clear and visual way you can see what’s important and urgent, as well as what you’ve achieved and what’s coming up. It’s tactile – moving sticky notes from one column to the next is immensely satisfying. And it’s universal – from school kids managing their homework schedule to developers planning their tasks and stories, it works.

Has your use of Kanban changed the way you approach things outside of the workplace? If so how?

I admit that I use my Kanbanfor1 board for almost everything now. It gives me a really clear sense of what’s on my plate both in and out of work. I feel a lot more in control of my ‘things to do’ which actually gives me more freedom to enjoy my non-busy time. My partner and I even share a board when we’re planning together – like a holiday, or moving house.

If you could express the essence of Kanban in one word, what would it be and why?

One word – that’s hard! I want to say ‘simplicity’ but there’s also ‘productivity’ and a certain amount of ‘zen’.

The best word though may well be ‘flow’.
Tasks and work and projects flow through your life. Kanban helps to manage that flow. The board lets you visualise the flow.

You’re a former Olympian and no stranger to achievement! Tell us a bit about the qualities one needs to think like an Olympian in their work.

Focus, ambition, collaboration. An Olympic athlete is no stranger to these things. Hours and weeks and months and years of hard, consistent training. Laser sharp focus on the task at hand. A shared team goal and purpose. Big dreams and the courage to follow through. There is no time for slackers, but there is much learning from failure. I think I’m a lot less intense now than in those days, but I still work hard and love a good massage!

 

Sandy will be leading a workshop on Kanbanfor1 at Service Management 2015.

By |2018-03-19T16:23:23+00:00May 5th, 2015|blog, ITSM, Kanban, QandA, Service Management 2015, Workshop|