The Case for Multiple Avatars

September 2016

Don’t let the “rules” kill your Service Ops Kanban adoption

For the many years I’ve employed kanban, scrumban and flavours of proto-kanban in teams I’ve worked with I have sometimes felt like a bit of an imposter. (see Gitte Klitgaard here)


Having been introduced to the ways by a number of supremely experienced and clever Agile Delivery friends, I at first became worried when transferring these techniques to my own Service Operations world. Pretty much every person I have ever met, in the Lean Agile world, is caring, emotionally intelligent and, as described by Mike Burrows in his book ‘Kanban from the Inside’, interested in shaping a more “humane” way of working together in IT organisations however I still retain the anxiety that a world centred around strict ceremonies and rooted in scientific method is not overly keen on some interloper coming along and diluting the tenets or appearing to play around with some of the fundamentals.

You may find however, Service Ops is quite different from Software Delivery;

  · often staffed by people with vastly different personalities than software delivery

  · many more entry points/channels of demand,

  · dizzying volumes of tickets, contacts, interactions

As an example, I once initiated a “kanban” adoption within a large IT Support department struggling with upwards of 7500 backlogged tickets, aging on average 190 days, in an old, unloved ITSM tool. The usual stories applied; more additional work being handled through e-mail, messaging & snatched conversations, little definition of sources of demand (e.g. Service or Project, Opex or Capex, Incident or Request) ….and so the department ends up losing track of the amount of work it is accepting, the cost/value inherent in the work, and whether the team is sized correctly to deliver it at all. Recognisable issues for all IT teams, I know, but Service without exception deals in much larger scales and (due to the largely ubiquitous, uniform and often unrealistic SLA/SLTs in IT) on much tighter time frames.

There are a number of approaches (Deming’s PDCA, Boyd’s OODA, Seddon’s CPD) that can be taken in such situations and they all share a great deal, especially in a desire to bring about improved outcomes from some sort of intervention. In all of these there is a period of checking or observing to enable the interventionist to understand the status quo and then how each change affects it.

My key observations when introducing visualisation of work into Service Ops departments has been the struggle to understand how to “stop starting work and start finishing work”, and thereby how to limit an individual’s focus on to a smaller set of tasks. When coming from such a vast starting point reducing this down to all work on a single board and each individual to a single avatar has without exception proven too much. Team’s often point out that if we are to create a board and a value stream that reflects how things get done right now, then to only have one avatar fails to highlight the fact they are seldom seen as a single person and by extension the amount of work channelled their way is much more than one individual could ever deliver.

For this reason, every adoption I have begun has allowed for multiple avatars; the proviso, which we make an explicit policy, being that we limit the number of avatars to a number far lower than the number of work items being demanded and we are clear that each avatar represents a proportion of that individual’s time - the avatar represents a commitment. With the volumes of work usually represented on a Service Ops board, the initial breakthrough is the understanding of how much work is not being done and this is an invitation for the right people to begin the right conversations.

From this point the real work begins, which will ordinarily ensure this initial “proto” version starts behaving more and more like Kanban day by day.


(addendum) That example; using the techniques described it took 4 months to half the average lifespan of a ticket and 6 months to bring it below 20 days and in line with SLA.