Tuesday, September 22, 2009

against kanban part 3

At the agile2009 conference, David Carlton and Brian Marick presented something they called "Idea Factory", an overview of three sociological systems by which the scientific community comes to regard a certain thing as fact.

Carlton's presentation was particularly intriguing. He cited work pointing out that disparate communities come together in what are called "trading spaces" in order to pool aspects of their expertise to create new work.

One of the signs of a "trading space" is a creole or pidgin language created by the participants in the trading space and used by participants in the trading space to negotiate among themselves. Such language may seem weird or impenetrable by outsiders, but participants wield it in order to accomplish things among themselves.

In contrast, Six Sigma, ISO9000, and now Lean/kanban, are imposed upon the agile development trading space. They are concepts and processes and ideas forged from managing factories, fitted (roughly and badly) into a culture that, when healthy, has no need of them. Just a quick glance at the hundred or so two-column translation tables in the book "Lean-Agile Pocket Guide for Scrum Teams" gives a clear indication that it takes serious effort to map Lean processes onto an indigenous Agile framework.

To my mind, the agile/XP/Scrum community conceived three brilliant "trading space" type of ideas around which our work revolves:

First, the idea that at a certain time, we will release a predictable and well-known set of running, tested features to production, over and over again, reliably, puts the emphasis on actually shipping things for people
to use. This emphasis on succeeding within a time box consistently (and the subsequent celebration by both the agile team and by the customers!) is utterly critical to the success of agile teams, and Lean/kanban throws it out the window.

I had a number of Lean advocates tell me that "you can still have iterations with kanban", but the radical de-emphasis of the time box and of the ceremony of releasing features to the customer at the end of every scheduled development cycle is a huge step backward. In other writing I have suggested that software development without a regular, public, scheduled, celebrated release of features to production cannot be agile, regardless of what other processes are involved in such software development.

Second, the fact that the language to describe this work (iterations; big visible charts; information radiators; test-driven development; continuous integration; pair programming; automated testing; etc. etc. etc.) comes
directly from those who practice the work and is indigenous to that work. These terms have no meaning outside the realm of agile software development. This insistence on our own creole or pidgin language gives the agile software development community a high degree of self-reliance, and a degree of resistance to corruption.

The language used by Lean/kanban software folk is strewn with corrupted Japanese words and phrases ripped from a generation of Japanese manufacturing. In my experience such words (kaizen; pokyoke) are used more to intimidate and confuse the uninitiated rather than to actually further the work at hand. There are perfectly good words in the agile "trading space" to describe such concepts without resorting to arbitrarily adding terms from an entirely different culture, the culture of Japanese automobile manufacturing.

Third is that every Scrum process for every individual team contains the seeds of its own destruction. Every agile retrospective contains an opportunity to break the rules for a good cause. Want to scale your team up to three times the recommended size? Go for it. Want to replace pair programming with institutional code review, replace CI and TDD with a hair-trigger build system plus dedicated testers expert in the debugger? Go for it.
There is no room for creativity on the factory floor. Any significant change to a manufacturing process involves significant retooling expense. In software we have no such expense. We can change our development processes right now, and then change them again an hour from now, and again an hour after that. The agile frameworks and tools we use give us fast feedback that tells us what works and what does not.

The Lean/kanban term that probably concerns me the most is "waste". On a factory floor, this term has a reasonably clear meaning. In a software development team this word has dangerous implications.

I am a dedicated telecommuter, and the best telecommuter situations I have worked in have provided proxies for the "water cooler": wikis where we can post photos of our gardens and of our vacations, messaging systems where we can talk about our music or even our religion. On the face of it, this is waste; in practice, it binds a team tightly together and increases productivity.

This healthy social interaction in the course of the work is a symptom of a healthy "trading space". Besides the pidgin/creole language created universally by devs + BAs + testers, there is a creole created within individual teams to describe their work and how it affects their lives.

The foreign concepts Lean/kanban offer present a clear risk of corruption of the natural discourse of agile software development, and its other concepts like "waste" and "value stream mapping" pose a threat to the social interactions that make working in healthy agile teams such a productive, easy, and even joyous experience.

Monday, September 14, 2009

against kanban part 2

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.