Boris Gloger has written a couple of posts on Kanban. While I know Boris is a great ScrumMaster, Coach and Trainer, his interpretation of kanban is wrong in my opinion – although I may have misinterpreted his interpretation! My immediate thoughts were too wide and varied for a comment on his blog, and I was at SPA2009 so didn’t have time for an immediate response, so I made a number of tweets with the #notkanban hashtag.  This post is to follow up those tweets.

Boris says, “We need to tell the development teams what they have to do and we need to make sure that all activities: specification, requirements engineering, development testing will be worked on in exactly the right order, sorry FLOW”.  A kanban system does not prescribe a process (or the activities), but rather visualises the process in order to improve it.

Boris continues, “we need to make sure that all roles in the development team needs to know exactly when the owner of a role can do a piece of work. So they can really focus on their specialization.” He also says “This is definitely not SCRUM or the idea of working creatively together. It imposed specialization”. A kanban system does not insist on imposed and siloed specialisation with handovers, but rather recognises overlapping phases. This is actually closer to the Type C development style described in the New New Product Development Game than Scrum itself, which acknowledges Type C development as a primary source.

Next, Boris says “Development teams … do not need to think anymore. They do just need to work according to plan and we do not have any break in the deliver process anymore”. With a kanban system, teams do think. They should be continuously improving the process and value stream.  As James Shore reminded us (on twitter), Jeffrey Liker said in The Toyota Way that “TPS experts get very impatient… [when people] focus on kanban… kanban is something you strive to get rid of, not to be proud of”.

Boris seems to think that kanban is a process when he says, “So we do have now a very clear focused PROCESS that works much better than all the Scrum Framework”.  However, a kanban system is merely a tool to help visualise an existing process in order to improve it and enable work. It is not something which imposes a process and inhibits work.

Yet Boris also says, “So if we agree that it is a TOOL, that means CARD than we can not explain a way of development as KANBAN”. So yes, a kanban system is a tool, but it is not just having a taskboard with cards, but should also strive to limit work-in-progress in order to improve throughput and cycle time (via pull).

Boris also says, “The terrible danger of this approach is that we put the the thinking about the features before the development”. A kanban system is actually designed to achieve the opposite and not overly invest in features before development as this creates work-in-progress.

Finally, Boris says, “Why do we always look into processess of the manufacture world. Why does nobody tries to see the value of the work-processes that works in companies like PIXAR or IDEO. These are the companies in which creativity and coolness lifes”. A kanban system does not exclude creativity. The team is responsible for the process and the workflow and is empowered to inspect and adapt the system in whatever way it wants in order to maximise the value that it generates.

If anyone (especially Boris) wants to discuss these points (and others) more, then please join the kanbandev list. That’s where I and others are trying to find better ways of using and describing kanban systems for software development.