Kanban for Software Engineering?

There is a lot of buzz in the community over kanban lately.

Although I think there are some good ideas in the Lean/kanban system, I think that most of it’s power is lost when it is applied to software engineering.

I’m very familiar with the whole notion of Lean/kanban/Value Streams etc, having developed software to essentially automate such a system for the Semiconductor Industry.

The product was so concerned with value streams and product flows it was called — wait for it — wait for it — FlowStream.  This Software was probably used to run most of the factories making chips for the machine you are using right now.

But we didn’t use a kanban system for developing the software — why not?

1 word — Cycle Time

The whole key that makes a JIT/Kanban system work is known cycle time for the various process steps.

Given the known time, to say, etch, or lithograph, a wafer, and what machines are in use, one can map out how they should flow through the factory to maximize value.

However — in software development — these cycle times — are usually unknown.

Therefore, it is hard or impossible to know, just when in time you should use a Kanban signal that someone should start working on something.

Keep in mind kanban is designed for the serial production of manufactured product. It is not designed to DESIGN new product.

In software, this would be using kanban to say, manufacture and ship out floppies or cd-roms, not create the product itself.

I certainly value Lean principles, and reducing waste, and to me that requires experienced architects not coaches.

To me most of kanban enthusiasm is about getting to more of a flow and get out of sprints, which is fine, but there are a lot of ways to do that.

To me, adopting kanban is like using Japanese words without understanding what they really mean.

In the future I’ll blog about Management by Walking around (“Gemban”) and why most manufacturers do not even use the kanban system as popularly described anymore.  But for the impatient the reason is because they don’t need to — technology has advanced.

Please note: I am referring to well known “kanban” systems in this post, not proprietary implementations such as Anderson’s “Kanban”.

PostAgilist

Advertisements

About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

3 Responses to Kanban for Software Engineering?

  1. There seems to be a small misunderstanding here. In David Anderson’s Kanban, as used a lot by organizations delivering software products, you don’t need to know cycle times for every step and it is not the whole key that makes it work. Of course there is a lot more variability in a typical knowledge work value stream than in manufacturing, but that is ok. You can take measurements and know the average cycle times across steps, and that might be worth doing to help manage flow but it is not the whole key.

    And the idea of Kanban signals telling people when to work on something doesn’t seem to be a part of Kanban (David Anderson Kanban) either. People decide when to pull a new item and use explicit policies to decide which one, but specific or average cycle times across steps are not usually an input to that process.

    The Kanban that the lean software development crowd are talking about does differ a lot from Kanban as used in manufacturing, as far as I understand, so someone with manufacturing experience cannot simply hear the word Kanban and understand how it applies to knowledge work. So to a certain extent yes, people have taken the word because its Japanese, and cool and marketable etc, and started using it in an unfamiliar way, but it seems to make sense. If you read Anderson’s book you will see how it works with knowledge work, and how it works with variability, but differing from manufacturing Kanban.

    Also that bit about people using it to get more out of flow and escape from sprints is true. That does seem to be why many use it, and it works well for that. The actual intention is to manage change i.e. Kaizen and ideally help move towards a high-trust culture.

    • PostAgilist says:

      Hi Kurt

      Thanks for the comments. I think there is some confusion but not necessarily a misunderstanding.

      I am describing traditional kanban systems here, not David’s or anyone else’s proprietary implementation.

      The confusion stems from David taking a generic word, changing the system drastically, and stilll calling it Kanban.

      I’ve asked David to describe his approach and how it relates to software development, succintly, and he has to date refused.

      If you’d like to do a writeup about it that is fine — I’m not sure what he has changed or how worthwhile his proprietary method would be to software engineering, nor do I get the impression that that would be even adequately explained in the book — I’m sure you have to go to seminars before you really find out what is going there — it may be something — it may not be something.

      What I’m talking about here is “kanban” not “Kanban–The–Anderson–variant”.

      I think there a lot of ways to get into more of a flow state and out of sprints and people should have honest choices out there, not just jump on some proprietary bandwagon for one feature.

      I also think there needs to be, a public, free, description of what makes Andersons version useful. He can provide more details in a book or seminar, but to provide so little details publicly strikes me as, at the very least, odd, and makes me quite skeptical that there is something of true value there beyond buzzwords and post-its.

      It seems deceptive to remove the heart of what makes kanban work — cycle time and signalling mechanism — replace it with who-knows-what, and still call it kanban. Perhaps “David’s Approach” would be a better name for his methodology?

      Whatever anyone calls it, there should be a public version that explains the benefits, enough to convince the community that there is something of real value there, and not just yet-another-agile-bandwagon book/seminar endeavor.

      PostAgilist

  2. Pingback: New PM Articles for the Week of July 9 – 15 | The Practicing IT Project Manager

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s