Bookmarks I’ve shared on 2012-02-03:
- The Science of Kanban – Process
- The Science of Kanban – People
- The Science of Kanban – Introduction
Bookmarks I’ve shared on 2011-07-12:
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.
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 humbly offer a few more thoughts to the debate:
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:
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”
I’d love to hear from other people grappling with these issues – please comment here or tweet me (@Synesthesia)
Bookmarks I’ve shared for 2011-07-07 to 2011-07-08:
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):
Retrospective (max 20 mins total)
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?
Bookmarks I’ve shared on 2011-06-22:
Bookmarks I’ve shared on 2011-04-05: