Kanban Practitioner Case Studies, UK Lean and Kanban Conference Day 1
The first day of the UK Lean and Kanban Conference was an interesting experience nicely situated in The Great Room in the RSA House with a magnificent sequence of paintings on the theme of progress of the human knowledge and culture.
The focus for the first day was Kanban in general and practitioner reports of Kanban experience in particular. The day started with a panel of practitioners consisting of Alan Kelly, Matt Wynne, Reni Friis, Benjamin Mitchell, Mattias Skarin and Chris Matts. They had ten minutes each to tell us about their experiences; benefits, mistakes, puzzlements, and so on.
Kelly pointed out the fact that Scrum is supposed to be about self-organized teams but you are not allowed to change the Scrum process itself until you are doing Scrum perfectly. This is actually an impediment to continuous process improvement. He also mentioned that David Jones, one of the authors of Lean Thinking, when visiting an XP conference in London recently, pointed out that “you guys are calling this agile, it looks like lean to me – I don’t mind what you call it, you can call it whatever you like”. Agile is a form of lean.
Matt Wynne first came in contact with Kanban at an XP day 2007 navel-gazing session called: “Have we lost our mojo?” There he met Karl Scotland and Fred George who really had this zeal and were excited about the stuff they were doing. They talked about solutions to frustrations Wynne was feeling with his current practices with Scrum., such as having to clear the pipeline every two weeks, sit down and plan the work for the next two weeks of which some were never done because of changed prioritization etc.
Wynne made an analogy with Behaviour Driven Development that sometimes is called Test Driven Development done right: “This lean/kanban stuff is agile development done right.” He saw a real culture change happening when everyone was buying into this. The magic word for him was pull, when the developers are deemed responsible enough by management to set the pace in which work gets done. It’s about having respect between managers and developers.
Among the things Wynne learned was that iterations can be good because you get the chance to stop and celebrate, show and tell about what you’ve done, do retrospective etc. It is important to remember to do these things when you do iterationless Kanban.
Danish IT management consultant Reni Friis talked about her experience in a kind of “midwifish” role to help programmers understand processes. She told us about her success in lowering the cycle time of MSI installers development for the Department of Defense from 640 man hours down to 260 hours and reducing the number of steps in the value stream from 29 to 16.
Friis and her colleagues got all the people in the department together in a room to do a value stream map, educated them in lean thinking and got them really worked up and enthusiastic about continuous improvement. They challenged current practices such as why testers don’t supply the developers with the test they develop. It seems obvious but it rarely happens. She called it “logic for chickens” a freely translated Danish proverb.
One of the challenges was to get an important person that was a bottleneck to disentangle herself from the several steps of the process where she was a constraining dependency. It is all about explaining that the process is inefficient, not the individual.
One mistake they made was to not include all of the department in the training. The people that were trained experienced an epiphany that was difficult to transfer to the rest of the organization and it became a source of irritation for the others.
Another mistake was not involving management enough. The manager needs to know the process and the culture she is responsible of.
Benjamin Mitchell works at an investment bank and first came into contact with Kanban when he met Karl Scotland at a Scrum Gathering and they did an Open Space session on Kanban together.
Mitchell and his team were doing Scrum when they encountered a big and difficult bug that later proved out to be a bug in Internet Explorer. They were forced to relax the Scrum rules in order to accommodate the amount of work it took to fix the bug. This made them aware of the possibility to actually improve Scrum beyond the traditional rules.
The level of chaos Mithchells team experienced did not work well with Scrum. The company had a command and control environment where people felt compelled to say yes to everything. With Kanban they turned this “yesman culture” into a positive: “Yes we can do that, just tell us what we should remove from the work we’re already doing.”
Mitchell also made an eh… interesting analogy between the need for release cadence and the human fondness of orgasms; there’s something in humans that want things to build up and then release.
Next out was my fellow countryman Mattias Skarin. Mattias honored the time limit and even compensated for the others running long by keeping his report short and to the point. He pointed out that Kanban helps people discover problems regardless of what environment it is applied in rather than selling a generic solution to people.
Mattias warned us about the mistake to not appoint a facilitator, e.g., a Scrum Master, to be in charge of telling the team when a commitment they’ve made has been violated etc. Another mistake is to appoint a Scrum Master or facilitator that is to coupled to the status quo and hinders the team from improvement instead of facilitating it.
Last in line was Chris Matts who was mostly into the practitioner experience part of Kanban; practitioners discussing real issues, solving actual problems. The Kanban community is a community of practitioners harvesting great ideas and presenting genuine problems they want to solve. As a practitioner Matts want all of the tools in the toolbox and is not interested in labeling them – all of you guys out there, how are you solving real problems, with or without Kanban?
After these presentations there was time for Q&A, but since I deliver my notes incrementally and by pull I will post the rest when pulled (through comment on this post!) and there is capacity…
3 Comments
Comments are closed.
Thanks for the briefing Joakim! If I can make a wish, I’d love it if you wrote a post about new things you personally learned at the conference – that would be interesting. /Tobias
Thanks for sharing your thoughts. Pretty good summary of the items.
Scrum and XP started as a way of continuous improvement and flexibility became so rigid and inflexible over the years. It is hard to imagine when this transition happened. Hopefully the same won’t happen to Kanban. I really like this method of development. We implemented it in an overall team of 200 people starting in 2006, and had very encouraging results.
Hi, almost like being there!
Thank you.
Since I now am a Yes-man (using Kanban that is, check with David) I really like the sum up of the case studies.
Keep it up – our man in the UK. :)