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.


Lisa said...

You have a good point about iterations, I think there is value in them though I think a high functioning team can be a lot more flexible.

I don't understand why you say there is no room for creativity on the factory floor. What I've read about Toyota, such as in Vodde/Larman _Scaling Lean & Agile Dev_, say that Toyota encouraged factory workers to think for themselves and find creative new ways of doing things. The motto was "Good Thinking - Good Products". Right?

The main thing I do like about Lean is this emphasis on people thinking for themselves and relentlessly finding ways to improve.

marekj said...

From Japan I love the story of Kurokawa Hot Spring Village and Tetsuya Goto as told by Ikujiro Nonaka, the guy behind Knowldege Creation investigations.

Here is pdf from Ikujiro Nonaka.
(slide 54)

I first saw this on Alistair Cockburn's site which did not surprise me at all since he is the dude behind "Cooperative Games of Invention and Communication".

I would follow that some ideas from "Disclosing New Worlds" by Fernando Flores about 'history-making' and my favorite: "Programming as Theory Building" from Peter Naur.

Notice that in these themes I present there is nothing about 'manufacturing'. The entire 'activity' is to communicate, invent, distinguish spaces, disclose worlds, make new meanings, alter ways of seeing etc.. all in the context of community.

And yes, in the end there is code to be written that 'runs' and produces 'value' by a certain 'time'.

I am not sure Kanban makes me fall in love with software.

Well, my reply is not on topic, just some reflections.
Thanks @rubytester

Tobias Mayer said...

@Chris "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"

Powerful statement, and one with which I concur. The ceremony at the end of a timebox is a (known and agreed) common waypoint we can all travel towards, and meet; it is a place to be still, to breathe. This meditative moment fulfills a deep tribal need. I don't think people understand what they are losing when they throw this away.

Waste. Yes, the over-emphasis on this is worrying. In an efficient process it gets confused with slack, and the emphasis is on removing it. Again, we can end up throwing away our best innovation.

Value-stream mapping is the antithesis of the creative process. I wrote more about that here:

Scrum & Kanban - different animals: http://bit.ly/16XXjm

(excuse the self-promomotion)

Another thoughtful and awareness-raising post. Thanks Chris.

Machiel said...

I think you make a valid argument, but I'm not comfortable with the way you speak of the current Agile community. For instance, I get the impression all xp/scrum teams are quite homogenous, all practicing scrum fairly successful. Which is of course not how it is in reality.

What I mean is this: when a group speaks out against some conflicting ideas (perhaps for good reason) it usually diffuses their own heterogeneity and issues. This simplification doesn't lead to an open and fruitful debate, especially if the competing ideas are trying to address those issues and heterogeneity.

I'm not out on the whole Agile/Scrum/XP/Lean/Kanban debate, I hope we can keep the debate open and engaged so as to keep testing our ideas and experiences.

Jeffrey460 said...

I find it hard to believe you have read any serious book on the subject, nor worked in a lean environment.

I think it would be very hard to reconcile your fears of Lean and Kanban with the writings of the Poppendieks who have focused on Lean in the software world for years now and have written three books on the subject. There latest published book is http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/ref=sr_1_1?ie=UTF8&s=books&qid=1253702767&sr=1-1

Or a more general work on Lean, like "Elegant Solution" http://www.amazon.com/Elegant-Solution-Toyotas-Mastering-Innovation/dp/0743290178/ref=sr_1_1?ie=UTF8&s=books&qid=1253702626&sr=1-1

which is a title that I imagine would resonate with any software developer, or any software development team. The book focuses on discussing "Toyota's philosophy of team-based innovation and creative business practices" and how they "have a reported one million ideas from its employees being implemented each year"

Whether Lean is a good idea or not is one thing, but the reasons you give against its use in the software world are naive, and for the most part, wrong. The bigger challenge than proving Agile is better than Lean is highlighting the differences at all. They have the exact same philosophical basis. Things like XP have some specific practices that are uniquely evolved to the software world, but you would have to search very hard to find a good Agile practice that cannot be defended by Lean principles.

Jeff Santini

kjscotland said...

Hi Chris,

I was also at the same Ideas Factory session. My conclusions were clearly different from yours.

1. The benefits of the time-box you mention are actually the benefits of a regular release cadence, or simply regular releases. A good kanban team can achieve these benefits without a time-box. See

2. For me, Lean provides an equally viable pidgin language. The point is not who created the language, but that it can be used effectively to communicate. The Kanban community chooses to use a Lean derived pidgin language. See http://availagility.wordpress.com/2009/07/10/kanban-is-my-first-language/

3. Since when did Lean involve no creativity, process improvement or social interaction? Respecting people and continuous improvement are two pillars of Lean! See http://availagility.wordpress.com/2009/07/09/does-kanban-respect-people-self-organisation-and-continuous-improvement/


Andy said...

Chris, you've developed some very different ideas about Lean and Kanban than the ones I have ... I don't know where they've come from.

1. If you've really been subjected to 'intimidation' by means of 'corrupted Japanese words' then I guess you've had a poor teacher. If you forget the words and stick to the concepts, you'll find useful perspectives such as 'continuous improvement'. Can I suggest you read the Poppendieck books for a better understanding ?

2. You seem to think that retrospectives will be somehow sacrificed in a Lean environment. On the contrary, retrospectives are just one way of achieving 'continuous improvement'.

3. Waste is indeed one of the crucial concepts in Lean, but I can't imagine that anyone who's read the Poppendieck books, which go into the 'respect for people' principle, would think that water-cooler time, and other social activities, are 'waste'. Waste is the flip side of value and understanding what those mean in the widest possible context (e.g. the whole business rather than the dev team) is crucial to seeing opportunities for improvement.

If you do some more reading you should find that your ideas about what Lean is (in the software dev sense) is more closely aligned to the ideas held by Lean enthusiasts, and then the dialogue will get really interesting :)

Andy Roberts onesandthrees.com

Damon said...


I'd like to point you to the Poppendieck's response to quite a few of your views.

Here's their thoughts on water cooler moments being seen as waste:

Matt: How do you respond to someone who wants to eliminate waste by cutting out team discussions or coffee breaks?

Mary: That’s taking the word “lean” and using in exactly the opposite way from its meaning in the Lean Manufacturing and Lean Product Development world. One of the big principles of Lean is to “optimize the whole.” Making shortsighted cuts and calling it “lean” is not Lean at all.

Tom: Product development is fundamentally about learning, about deeply understanding a problem and collaboratively creating an effective solution, not about producing drawings, documents, or cutting code. Discussion is one of the stronger techniques to pursue and share learning. The view that team discussion or coffee breaks are waste sees development as a manufacturing process with code as the primary output rather than as a learning process in which the code is simply the repository of part of what the team has learned.

agilemanager said...

Can you show me where in the Agile Manifesto or the Principles Behind the Manifesto that it states there must be a timebox?

TestWithUs said...
This comment has been removed by a blog administrator.