Monday, June 22, 2009
Kanban and Lean Roundup June 22nd
In today’s roundup, I’m covering some more general Lean stuff that is flying under the more specific flag of Kanban. It’s amazing how people want to be associated with success.
First off, who is this making Kanban t-shirts all of a sudden? Personally, I’ll be waiting for my official Limited WIP Society shirt! Designing these is on my backlog, but I haven’t pulled that job into my personal WIP limit yet 
Next up, super post from Rob Bowley detailing his team’s current practices. A lot of Lean going on here with cumulative flow diagrams, cycle time metrics and so forth. Excellent stuff. One or two tweets on this referred to it as Kanban but Rob is really quite clear in his post. He’s doing Lean stuff and doesn’t even call his card wall a Kanban board.
Matt Wynne’s Kanban State of Mind is worth revisiting.
Kanban in Portugal anyone?
And another example of someone trying to adopt Kanban for their personal life. Not sure if this one has a WIP limit and is a pull system or not.
I’m not entirely sure what Si Alhir is on about with this comparison of Leanness, Agility, and Competitiveness. If someone can understand this chart and explain it to me, please leave a comment. Thanks.
I’ve mentioned it before on Kanban Roundup but Kallokian blog’s Defining Kanban has provoked an interesting discussion thread about kanban versus Critical Chain and early versus late start. I’ve noticed that when talking to folks with a manufacturing and industrial engineering background about our use of Kanban (or Drum-Buffer-Rope earlier on) that they simply can’t get their heads around it. They have a mindset that project management is for knowledge work problems and they have their pet solutions to variability and project dependency graphs such as Critical Chain or GERT (Gantt meets PERT and they had a baby.)
The whole issue of early versus late start is mute with Kanban (using a capital “K” now) because of the prioritization scheme and the use of classes of service. There are no estimates - unless the class of service demands it and a specifically “late start” prioritization scheme is adopted, as I have documented with the Fixed Delivery Date class of service at Corbis (and elsewhere) - so you can’t early or late start against an estimate. There is no concept of a dependency graph of the order of work because selection of work is delayed until it is prioritized into the input queue. This looks awfully similar to “late start” to me, but what it really is, is a very similar process to TOC Buffer Management and self-prioritization in advanced DBR solutions.
The problem with the folks debating the project management solutions is that they can’t break their minds out of the project management dependency graph paradigm and think of software development as a flow problem. They want to wrap everything up in a project with a defined release date and by doing so, wrap all the activities within the bundle into a homogenuous blob from a risk perspective. There is no concept of “cost of delay” or “loss function” at the individual work item level, only at the project level. Kanban frees us from these man made imaginary constraints and enables us to treat the work independently from a risk perspective and consider the cost of delay (or potential loss) for each item indvidually. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management