Last week I attended Lean & Kanban Europe 2010. It was the first conference I attended with such a specific focus on lean software development. My expectations were largely fulfilled thanks to some great sessions and thought provoking ideas.
Being a big fan of presentation styles, I was really amazed by the closing keynote of John Seddon. He didn’t use any slides, just stood in front of the stage and started talking. The story was about systems thinking in general, not an easy topic, but a great presenter knows how to bring a message across. And so did John Seddon. He engaged the audience by story telling, intense eye contact, humour and of course expertise on the matter.
Another session that really struck me was one by David Anderson. He explained how using classes of service with Kanban systems help to improve customer satisfaction.
By not just treating every feature the same, but categorizing it into a class of service, customer satisfaction can be improved. Let me try to explain.
Many kanban teams have 2 categories of work without realizing it:
- Standard work
(These are new features, bugs, changes, …)
- Top priorities
(Stuff that has to be live asap. Drop everything you’re doing!)
I’ve seen it mostly in the form of a kanban board with a top horizontal swim lane reserved for top priorities and a bottom one for standard items.
This works quite well, very visual and easy to understand. If hot stuff comes up, it can be treated in the emergency lane and gets priority over the rest. Great way to deal with the mix of new development and unforeseen issues.
David takes this a step further by recommending to categorize each request to one of these four categories:
- Standard work
(new features, production bugs)
(silver bullet, top priority stuff)
(not production bugs)
The next step is to map these to one of these 4 classes of service:
(Drop everything and try to get this into production first, resulting maybe in broke WIP limits. We don’t expect to have a lot of these at the same time)
- Fixed delivery date
(must be done before a certain date)
- Standard class
(can follow the normal flow)
- Intangible class
(lowest priority, can be dropped to handle silver bullets and fixed delivery date items)
Now how do you decide on the class of service to use? David used the example of an upgrade from SQL Server 2000 to 2005. If we got this request in 2001, it probably would have been marked as intangible class. But if we let it linger until 2010, it would become Expedite class (because of the support stop by Microsoft).
Key is to get a healthy mix. I think we all see it happening every day, stakeholders only want new features and no refactoring, maintenance or upgrades. For each request, we must try to understand the cost of delay and choosing an appropriate service class which determines how it will pass the flow.
By agreeing on an SLA based on the service classes, we can make sure that low priority stuff gets treated once in a while, so that they don’t become a serious issue after a while. For instance this might be an SLA:
- Expedite class : maximum 5 %, on-time 100% within 5 days
- Fixed delivery date : maximum 25 %, on-time 95% within 15 days
- Standard class : maximum 55 %, on-time 95 % within 40 days
- Intangible class : maximum 15, on-time 50 % within 40 days
By using color codes we can visualize the different service classes on the kanban board.
Now let’s set Lean or Kanban aside for a moment. Can we apply this to iterative development? Why not? Our SLA can be applied to a sprint backlog, where user stories get mapped to the appropriate service classes, which help us to create a healthy mix of work.
I plan to get into detail on this idea and see if it helps to create a flow that provides high business value and sustainability at the same time.