Links for 2011-07-12

Bookmarks I’ve shared on 2011-07-12:

Why SLAs smell of waste

SLA 2
Image via Wikipedia

DevOps

There’s quite a lot now on the internet about “devops” – combining development and operations work to increase flow and reduce problems

One of the key features of this approach is the idea that above a certain threshold of estimated duration, all operations work has to be included in the kanban board for visibility and flow management.

For example see these meeting notes from a DevOps conference in Ocean View, June 2011, where Lonely Planet shared their experience of this, with a threshold of 30 mins – i.e. any servicedesk issue which takes more than 30 mins gets moved to Kanban

I had a brief exchange on Twitter with Dominica DeGrandis, one of the DevOps leading lights, in which she confirmed that in her experience 1 hour was the most common point where teams found that the visibility and sharing was worth more than the overhead of putting into Kanban. This happens to be the pragmatic transition point adopted by the team I am coaching.

SLAs are a Problem!

Intuitively a follow up step will be to look at how this approach affects traditional service desk SLAs. I’m not a great fan of SLAs, as they tend to focus on failure and what happens after a failure – I’d rather that a service “just worked” and that resources went into keeping it that way.

I’m particularly disenchanted with the idea of SLAs when they are applied between two departments of the same business, not least because they stimulate the wrong sort of behaviour, in particular the chasing of local optima. The SLA-driven approach also encourages managers on the “consumer” side of the agreement to pay no attention whatsoever to systemic problems of their own making, to the ultimate detriment of the overall firm.

Having just read Bob Marshall’s Marshall Model of Organisational Evolution I can see that the frustrations I am expressing are a factor of the transition zone between the Analytic and Synergistic organisational mindsets.

I find John Seddon another source of stimulating ideas, and his piece on “Why do we believe in economies of scale?”  has some particular insights to how the SLA mentality creates organisational waste.

I humbly offer a few more thoughts to the debate:

  • “Incident management” as a process is focused on failure, and managing the impact of failure rather than removing the causes (and yes I know there is a whole other ITIL process of “Problem Management”)
  • SLAs focus resource on local optima (fix this incident for this user) rather than on the “best value for the whole firm at this time”
  • Incident management systems tend to accumulate backlogs of failure demand which represent inherent waste, and which also clog flow making the work to address underlying causes inherently less efficient
  • Efforts to create a synergistic “OneTeam” approach focused on flow are undermined by too much interrupt-driven work. Integrating the interrupt-driven work into the flow gives a much better sense of how to “add the most value possible right now”

The way I explain this to colleagues is usually along these lines:

The business has invested a fixed amount into IT development & support

Usually (especially in small / medium business) there is  a constraint within the technology team

Therefore the best value to the business from that investment is through:

  • elevation and exploitation of the constraint
  • reducing lead time
  • prioritising based on economic cost of delay

All of which are delivered by a tuned Kanban system.

To make sense of this we need to educate ourselves and our colleagues about the systemic dysfunctions caused by trying to force a system to work faster than the constraints allow. It often takes time – for far too many people from the Analytic mindset the first response is “they just have to work harder”

How about you?

I’d love to hear from other people grappling with these issues – please comment here or tweet me (@Synesthesia)

 

Links for for 2011-07-07 through 2011-07-08

Bookmarks I’ve shared for 2011-07-07 to 2011-07-08:

Kanban team weekly Review and Retrospective

A diagram to show the two PDCA cycles. The fir...
Image via Wikipedia

 

I’m coaching  a cross-functional team working across IT operations, application support and development, using Kanban to manage everything larger than the most immediate support requests.

They already appreciate the importance of reviewing their work and process, so we’ve been trying to make this into  Standard Work.

Our first attempt is the 30 Minute Review and Retrospective

Review (max 10 minutes total)

Look at every story completed this week, for each (so ~1 min per story):

  • What did we plan to do?
  • What actually happened?
  • Why?
  • What would we do next time?

Retrospective (max 20 mins total)

  • What do we want to do more of, what do we want to change or stop? (5 mins max)
  • Go round the group – what have we done for the improvement actions we committed to last week? (5 mins max)
  • Look at Cumulative Flow, Cycle Time and Lead Time – what issues do we see, what actions can we take? (5 mins max)
  • Go round the group – each individual commits to an improvement action for next week (5 mins max)

Based on the initial couple of goes at this process, 30 minutes is very very tight. This week I am going to run an hour with them, and although an hour per week is quite a large percentage of the working week, I suspect that the volume of Kaizen opportunities we are finding warrants it.

What’s your experience of introducing reflective practice within a Kanban environment?

Links for 2011-06-22

Bookmarks I’ve shared on 2011-06-22:

Links for 2011-04-05

Bookmarks I’ve shared on 2011-04-05: