#notkanban

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.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

3 comments on “#notkanban

  1. Hi Karl,

    thanks for all these clarifications. And I agree, of course the intend of all what you and the others evangelists of KANBAN are doing is based on the values of agile. I only believe that the direction it heads is wrong. It brings software development more near to the industrialization of brain work than it is already. The next logical step is KANBAN driven software factories.

    Scrum and agile was always very clear about that Scrum is not a tool, not a process not a new silver bullet.

    I am sure that you and Clark know all this and that you try to improve the adaptation of the core ideas. But people only see:

    Cool — less planning, no iterations, now I do not need to wait, now I do not need to be prepared, now I do not need to commit, now I do not need to work together, as I do have my own column I can work in ….

    Maybe I am too pesimistic?

    Boris

  2. Oh, one more … yes of course my interpretation of KANBAN is wrong. I do not express, what I believe KANBAN is, I try to express that I do believe KANBAN, although it looks very promising is the wrong direction, as Scrum Typ C is the wrong direction. More about this on my blog in the next days.

    btw — I love this discussion. We need much more of this.

    Best Regards

    Boris

  3. It’s interesting how we are using the same arguments against Kanban that were used in the past against Agile. “people see no documentation, no process, no accountability…”

    I’d have one recommendation for Boris, please execute Kanban for a reasonable amount of time and then improve it (based on retrospective events and improvement actions/tasks). After a few iterations of Kanban + retrospectives analyze the results. You’ll probably be pleasantly surprised with the results you get.

    Scrum was also seen as a worst process (yes process) than others at the time when it was introduced. How quickly we forget…

Comments are closed.