After conversations with various well-meaning folk at the Agile 2009
conference about some details of Lean and kanban, I remain more
opposed to a general implementation of them than ever.
But I'm willing to grant that a single kanban call might have value.
Liz Keogh had a good example: a group of agile coaching consultants, each with multiple clients, each client moving at different rates, with more clients
waiting for attention. The consultants track their work with cards on a board. (Note: tracking work with cards on a board is NOT kanban...)
When one consultant finishes with a client, that consultant adds a
card to the board saying GIVE ME WORK.
As I understand it, this is the essence of kanban: as Eric Willike told me, the essential image of kanban is a colored card in an empty basket, sent up the line to have the basket filled again.
But what a frighteningly low-bandwidth transaction! This means of communication is for infants: GIMME followed by either YES or NO. Put a bunch of infants in a room and you will certainly observe social behavior and even happy cooperation; but those social transactions cannot be very complex. A social system based only on GIMME: OK/NO is a poor substitute for real adult communication.
But it is a perfectly adequate system for interacting with inanimate objects, such as on a factory floor.
I was asked to supply my favorite metaphor so we could apply lean/kanban to it, and of course I chose a musical performance: a group of experts negotiate a set of things to perform at a certain time at a certain place for a paying audience who will be delighted by the performance. At the arranged time and place, the group of performers demonstrate their expertise for the delighted audience. Then they do it again two weeks later.
My interlocutor then asked me to imagine how to deal with the transportation and the instruments and the catering and the sound and lights and the hotel, etc. etc. etc., implying that lean/kanban is an appropriate system with which to negotiate the larger ecosystem in which a software development team works.
Thinking it over later, though, I still think that not only is kanban a poor fit, it's a dangerous approach when applied to any transaction more complex than filling a basket with parts.
The essential problem is that arranging a performing arts tour or releasing successful iterations to production requires complex negotiations among people at every stage. Kanban defines only a single, infantile transaction: GIMME: OK/NO. If this single
transaction is the only model you have for dealing with people, your project, whatever its nature, is doomed to fail.
On the other hand, if your communication model is complex, for example as they say in the Scrum world, if your story is a placeholder for a conversation rather than an empty basket to be filled, you are doing something-- but whatever it is, it is not kanban. If your cards on a board represent more than just Work In Progress but instead represent complex agreements among groups of people, you have stepped outside
the lines of Lean and kanban and you are doing something altogether different.
The risk I perceive here is that organizations will not only attempt to reduce all of their software development practices to infantile GIMME:OK/NO transactions, but that they will pursue such oversimplifications to great expense in the name of "value stream
mapping". This is an approach that blends the brain-dead process descriptions of ISO9000 with the outrageous process design expense of Six Sigma.
As I've noted many times, processes designed to manipulate physical objects map very poorly to software development.
conference about some details of Lean and kanban, I remain more
opposed to a general implementation of them than ever.
But I'm willing to grant that a single kanban call might have value.
Liz Keogh had a good example: a group of agile coaching consultants, each with multiple clients, each client moving at different rates, with more clients
waiting for attention. The consultants track their work with cards on a board. (Note: tracking work with cards on a board is NOT kanban...)
When one consultant finishes with a client, that consultant adds a
card to the board saying GIVE ME WORK.
As I understand it, this is the essence of kanban: as Eric Willike told me, the essential image of kanban is a colored card in an empty basket, sent up the line to have the basket filled again.
But what a frighteningly low-bandwidth transaction! This means of communication is for infants: GIMME followed by either YES or NO. Put a bunch of infants in a room and you will certainly observe social behavior and even happy cooperation; but those social transactions cannot be very complex. A social system based only on GIMME: OK/NO is a poor substitute for real adult communication.
But it is a perfectly adequate system for interacting with inanimate objects, such as on a factory floor.
I was asked to supply my favorite metaphor so we could apply lean/kanban to it, and of course I chose a musical performance: a group of experts negotiate a set of things to perform at a certain time at a certain place for a paying audience who will be delighted by the performance. At the arranged time and place, the group of performers demonstrate their expertise for the delighted audience. Then they do it again two weeks later.
My interlocutor then asked me to imagine how to deal with the transportation and the instruments and the catering and the sound and lights and the hotel, etc. etc. etc., implying that lean/kanban is an appropriate system with which to negotiate the larger ecosystem in which a software development team works.
Thinking it over later, though, I still think that not only is kanban a poor fit, it's a dangerous approach when applied to any transaction more complex than filling a basket with parts.
The essential problem is that arranging a performing arts tour or releasing successful iterations to production requires complex negotiations among people at every stage. Kanban defines only a single, infantile transaction: GIMME: OK/NO. If this single
transaction is the only model you have for dealing with people, your project, whatever its nature, is doomed to fail.
On the other hand, if your communication model is complex, for example as they say in the Scrum world, if your story is a placeholder for a conversation rather than an empty basket to be filled, you are doing something-- but whatever it is, it is not kanban. If your cards on a board represent more than just Work In Progress but instead represent complex agreements among groups of people, you have stepped outside
the lines of Lean and kanban and you are doing something altogether different.
The risk I perceive here is that organizations will not only attempt to reduce all of their software development practices to infantile GIMME:OK/NO transactions, but that they will pursue such oversimplifications to great expense in the name of "value stream
mapping". This is an approach that blends the brain-dead process descriptions of ISO9000 with the outrageous process design expense of Six Sigma.
As I've noted many times, processes designed to manipulate physical objects map very poorly to software development.