Monday, September 14, 2009

against kanban part 2

After conversations with various well-meaning folk at the Agile 2009conference about some details of Lean and kanban, I remain moreopposed 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 clientswaiting 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 acard 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 singletransaction 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 outsidethe 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 streammapping". 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.

40 comments:

Again, nice post. It is provocative. But the example does a poor job of making your point. There is no intent in Kanban to manage work as if it were a physical object. It is about managing the flow of information in a community. You are missing two key points.

1. The hand-off a new client to a consultant is not a simple hand-off. There is detailed discussion in the hand-off regarding expectations, terms, relationships, and pitfalls. The card indicates the need to have a conversation - just as the card does on a software development Kanban. Certainly the hand-off of a new client has as much context to communicate as the hand-off of a new task.

2. The Kanban board itself has a lot of information to communicate to the community - and as you point out this information is communicated at a very low transaction and coordination cost. Using your example, if I am in the final days of delivery to a client and the sales person has nothing in the pipeline, she knows she better get busy. If there is a glut of work in the pipeline, management knows they need to increase the pipeline. If there are a bunch of projects waiting for customer acceptance, the team knows it needs to get together and solve this problem.

Improved internal coordination, improved flow, highlighting impediments, keeping the system from getting flooded, and highlighting the ability to make and keep promises to new clients. All at a very low coordination and transaction cost. Looks like a great approach to a challenging problem.

Dennis, I am not sure how the post rises to the level of "nice". You have explained some problems with the post, but done nothing to support your "nice" statement.

It looks like a simple analysis of a simple isolated concept(kanban) that is used successfully as part of a set of concepts(lean). The author comes to an absolute conclusion that when used in isolation kanban is useless, therefore it can only ever be useless, except, of course, in the toddler or basket scenarios.

It is essential for this community to have people like Chris challenge the madness (bordering on religious fervour) of using manufacturing techniques for a creative process.

Software development has almost nothing to do with process and almost everything to do with people. I wish all the proponents of lean, kanban, six sigma, cmmi, blah blah blah... would wake up to that fact and stop trying to create some easy-to-use "process" to solve insanely complex problems.

Using something as simple as Scrum, or core Agile, is all that is needed in terms of process. And it is hardly process at all, more like a framework. It is raw. It exposes. Everything else is just another way of hiding dysfunction.

This is not a nice post at all. It is a harsh and much needed criticism of a bunch of process-jocks who spend way too much time pushing their preferred process rather than facing up to the reality of the complexity inherent in our work.

On P. 41, they say, "Management tools are *not* a pillar of lean". "... some ostensibly 'lean' promoters that reduced lean thinking to a mechanistic superficial level of management tools such as kanban (a visual management technique) and queue management. These derivative descriptions ignore the central message of the Toyota experts who stress that the essence of successful lean thinking is 'building people, then building products' and a culture of 'challenge the status quo' continuous improvement."

They go on to say:"Reducing lean thinking to kanban, queue management and other tools is like reducing a working democracy to voting. Voting is good, but democracy is far more subtle and difficult." Later they say, "To simplify lean thinking to tools is to fall into a trap repeated many times by companies superficially and unsuccessfully attempting to adopt what they thought was lean."

Chris, is this part of what you are saying - that people latch on to a tool such as kanban, and think it is the magical path to developing good software?

After reading this, I am much more excited about lean thinking, and the Toyota motto depicted in the book, "Good Thinking, Good Products".

jeffry460. By nice I mean it Chris has done a good job of articulating his position. It allows for productive dialog as we try to uncover better ways of developing software by doing it and helping others do it.

tobias. Have you seen a Kanban team in action. I don't just mean a team using a kanban board, I mean a team using a highly visible limited work in process pull system focused on continuous flow and improvement. The level of trust developed, focus of the team on improvement, and maturity achieved is very high.

Kanban (capital k)as described by David Anderson is not a just a lean tool. It is a method for change management (in software engineering and knowledge work), an enabler of a Kaizen (continuous improvement) culture and process. This isn't about big process - no creativity. It is about empowered teams working together to improve their ability to deliver value to their customer.

Agile teams don't have no process. Successful teams have highly developed communication processes and also typically have highly developed engineering processes. This allows the team to focus creativity where it is valuable and results in a sustainable and scalable approach to development.

Arbitrarily saying the purpose of Kanban is to move physical objects doesn't make it that. Saying the best way to develop software is to just let people work on whatever they want to and to make up the method every time is irresponsible.

I'm concerned that people are speaking from very different perspectives and missing valuable points on both sides as a result.

I find it unfortunate that the word 'kanban' came to represent the entire set of lean thinking that we are applying to software development. I also find it unfortunate, but understandable, that people assume we are primarily focued on lean manufacturing approaches. Rather, I believe most of the people doing and teaching 'kanban' are applying lean design approaches, as we identified that most of the lean manufacturing approachces do not translate well to software due to the variability and uncertainty involved in the work, among other things.

Tobias stated "Software development has almost nothing to do with process and almost everything to do with people." Nothing about kanban attempts to refute this in the slightest. He then states "Everything else is just another way of hiding dysfunction." I agree with this intent, but not with this characterization of the kanban approach. Everything within kanban is focused on exposing dysfunction as quickly and obviously as possible. As a whole, I perceive Tobias' comment as indicating a very deep understanding of software development and the appropriate ways of helping people interact to accomplish the stated goals. Unfortunately, I also perceive that the perspectives on kanban from both Chris and Tobias are shaped based on either second-hand or summary information. I'd encourage both of you to spend time speaking with somebody who is passionate and respected within the kanban community that does not have any specific business interest in the success of kanban. Karl Scotland jumps to mind as somebody who teaches and coaches both Scrum and kanban, although there are certainly others.

@Eric Actually, I have had quite a few discussions with Karl, and you are right, he holds a fairly balanced perspective. Still, nothing he has told me about what he does convinces me it is a better way of working than using simple Agile/Scrum practices, and letting solutions emerge as needed. It doesn't add anything. Kanban is all about process. That is its big drawback.

@Dennis Nothing about any of the actual practices of Kanban (e.g. as described in Jeff Patton's writing) are new to the Agile world. Big Visible Things of all descriptions have been used for years. Scrum is rooted in the value of Focus, of course it is all about limiting WIP and working on the most important thing. And it is also about freedom to explore and create a process suited to the context.

Everything I have heard being described as Kanban I have seen and used with Scrum teams and Agile-oriented organizations. Everything except 'loss of timeboxing' which I continue to believe is just (as it has always been) a way of hiding dysfunction. Timeboxing has an uncanny habit of surfacing the truth. I would never choose to give that up. I like the truth.

@Lisa: I guess Eric cannot be responsible what people think when they talk about kanban. Same goes with scrum, agile.. we all must have seen scrumbuts, scrumwalls etc.

Regarding your kanban I would recommend you to place the Value Stream Map visible next to your kanban board, in case you did not yet have it there. :o)

@Tobias I wonder why you think that iterations are required to be transparent (maybe I misinterpreted).

For instance, we are measuring cycle time for a feature. If that cycle time goes way beyond the estimate, something must be wrong - and yes, it is very visible for the whole company as we are "late". How is that less visible?

With the capability to release any day we have felt that waiting to the end of the sprint is just waste - we wanted to release the feature when it is done to have better time-to-market.

Still I think scrum and kanban are just tools to be mixed&matched. :o)

@Tobias I find your response incredibly amusing, not becuase of what's in it, but because if you swap the words 'scrum' and 'kanban' then you have almost exactly my perspective on the two.

I suspect this means that we're both taking the framework at hand and helping teams do the right thing to get work done.

It does confuse me that you characterize kanban as "just process", as I personally view (and use) it as the lightest-weight non-anarchy approach I've ever used except possibly some interpretations of Crystal Clear. At its simplist, kanban introduces two rules: limit the size of each queue and make the work visible to everybody. Neither of these ideas is new in and of itself. Everything else comes out of this and can be learned by the team through experience, although introducing some of the useful practices and short-cutting certain parts of the learning is useful. The thing experience has shown me and leads me to value kanban is that the limited queues will raise impediments in a matter of days or occasionally hours, compared to the 1-2 weeks that I'd encounter under Scrum or FDD with iterations.

As an aside, I saw this same benefit when we dropped iterations from FDD and focused on cycle time of individual items instead.

@Eric "At its simplist, kanban introduces two rules: limit the size of each queue and make the work visible to everybody."

Kanban didn't introduce these rules because they already existed in Scrum.

"The thing experience has shown me and leads me to value kanban is that the limited queues will raise impediments in a matter of days or occasionally hours..."

Yes, focusing on one thing at a time does that. You just don't need to call it by a new name. Scrum uses Timeboxing in multiple ways. Every day is a timebox, every meeting is a timebox. Respecting these timeboxes surfaces problems.

@Marko "With the capability to release any day we have felt that waiting to the end of the sprint is just waste - we wanted to release the feature when it is done to have better time-to-market."

This is just another misunderstanding of Scrum. There is no rule to say you can't release whenever you want. Just as there is no rule that says you must release at the end of a sprint. You release /when it makes sense/.

Really, I have to ask the Kanban world in general: What Are You Adding? ...apart from having a cooler name, because really, as a name, 'Scrum' really sucks :-(

@Tobias (Queue comment)When I say "queue" I mean "A set of work items at a similar stage of the value stream".

Yes, this does imply handoffs, although one goal that seems to emerge from every team I've used kanban with is to reduce the number of handoffs as far as possible.

@Tobias (Other comment)a) I meant "introduce" in the sense of "from no process, apply these rules", but even that's not strictly accurate because it assumes some knowledge of your value stream.b) I don't know of any specific things that kanban has added to the general body of knowledge that hasn't been done somewhere before. It does do what agile and scrum (and fdd, crystal, cmmi, RUP, etc) did and bring them together as a cohesive perspective, although not as cohesive as most I have to say.c) In my mind, the core difference comes back to what is used for triggering the inspect & adapt cycle (aka kaizen events). Scrum uses a number of nested timeboxes, which do a good job of addressing the problem if used properly. Kanban uses hard limits on work in progress to trigger on abnormalities, which do a good job of addressing the problem if used properly. My personal experience is that a team will mature towards identifying and resolving their 'problems' faster with the continuious nature of kanban. On the other hand, I suspect teams can fail worse with poorly implemented kanban than with poorly implemented Scrum. To me it feels like the next evolution of the need for discipline that was introduced with XP, but this is very much my personal opinion.d) Where are you located? I'd love to have this conversation at higher bandwidth than blog comments, especially since we seem to have hijacked Chris' comment thread :)e) Tobias, I appreciate you for this open and direct conversation free of the "passionate expressions of zealotry" I see in too many other places.

@Tobias (kanban queue pics)Yep, sure does look like that, and I find it how many teams start out thinking that's the right way to do things. What's interesting is what happens when they realize that it's not the only way to work, and start erasing the lines.Then, they find ways to bring operations and marketing into their team perspective, and add lines... then remove them again.

Eventually, it becomes all about the nature of the work, and all of the people align to move it as quickly as possible from concept to cash. That "as quickly as possible" will often fall much lower than the 21-day average lead time offered by Scrum with 2-week sprints.

@Eric "we seem to have hijacked Chris' comment thread" Are you kidding? He creates this environment deliberately :-)

"Where are you located?" On a wing and a prayer mostly, in between times in Palo Alto, CA. Maybe we'll meet in Munich?

"I appreciate you for this open and direct conversation..." Likewise.

last comment (tonight!)"one goal that seems to emerge from every team I've used kanban with is to reduce the number of handoffs as far as possible." When teaching Scrum, I say right at the beginning: There is no such thing as a handoff in Scrum.

@Tobias "This is just another misunderstanding of Scrum. There is no rule to say you can't release whenever you want. Just as there is no rule that says you must release at the end of a sprint. You release /when it makes sense/."

Sure, but does it make sense to have the timebox after than change...

I think it is leveraging the concept of "every iteration produces product increment" quite a bit as actually product increments have nothing to do with iteration anymore. Hence I like to use "some other term" for communication about it - especially when we dropped the timebox. Maybe we should call it teddybear :o)

Lets think more about the timebox. We have had co-operation with other parties (like integrations) that cannot fit into the timebox so they span across the timeboxes (causes hassle). We've seen that it makes easier to manage such cases without timeboxing (= Less inventory as there is no artificial story splits - integration is done when it is done, there is no partial integration to be shipped). When we dropped timebox, but still maintained the visibility with cycle time we did not felt loosing anything.

I wonder how this fits to definition of scrum (is it just 'sensible scrum') and still how that is giving less transparency (hiding dysfunction as you put it)?

Scrum, Kanban, Lean, Agile. In the bigger picture of things, it's 95% the same. And the remaining 5% depends on context.

(Assuming good faith, some amount of common sense and a level of understanding about agile and software development of course. If you have to operate in an environment operated by do-gooder shu-level kids playing with power tools you have already lost the game.)

The bigger picture I am talking about is the the majority of the IT industry that has not realized that most software is best developed incrementally, with tight feedback loops, and some amount of leadership and caring. Oh yes, probably it's good that the people involved actually talk every now and then.

Why are we endlessly arguing about my flavor of agile versus yours? Focusing on trifle details instead of principles? Spending time arguing amongst ourselves instead of trying to bring light to the rest of the industry?

Is it the consultants - pitching their latest home-grown method - who drive us into this? Big egos? Lack of hygiene in the community: anyone is free to pitch whatever - no standards need apply? Golden hammer syndrome? Or what?

@Ari I'm "fighting" because I've found Kanban to be a really valuable tool, and I'd rather not be put in a situation where I can't use it.

Also, since I'm now associated with the Lean and Kanban community (and explicitly named in the article), saying that Kanban's not a useful tool is also suggesting that I can't choose my tools appropriately. There are definitely poor ways to use Kanban, and Chris has called out some of the big ones in this article. There are also some excellent ways to use it, in conjunction with the usual Lean / Agile practices of high communication, feedback, etc.

I guess we missed these out of the conversation with Chris for the same reason that Kent Beck missed "Respect" out of the first XP values - because it seemed so obvious we didn't think it needed stating!

I'm all for defending your position (whatever that may be), and really like Kanban so don't get me wrong, Liz!

I like Kanban's focus on value streams and the bigger picture invaluable. I like Scrum, too, especially in really chaotic team-level situations where you're in deep trouble already. XP with it's engineering practices is invaluable, and Theory of Constraints, and...

But in the end they are all tools in the toolbox, some done for the same job, some for a different. So much depends on context and there is always a better way to everything.

It would be great to have more conversations about context than about the Grand Ultimate Solution. In which kind of environment did that work, where did this work?

For example the starting point for improvement is completely different if you have an old, broken organization riddled with politics than if you start from a functional organization.

I wish that the agile and lean folk would realize that we are in this together. Much can be gained by trying to understand our different ways and presenting a unified front the ahem... Real World out there.

(Not to say that good, heated arguments aren't useful. All good things come from conflict. Lot's of garbage, too.)

@Tobias Good grief! You seem to be focusing on "Scrum can do that" rather than the question of "what can Kanban bring to the table." The largest value that I see that you are bringing to this discussion is that you are forcing people to understand their thinking better and to become more eloquent in their description of their thinking.

I'm not sure I see the point of trying to convince people that there is no need to go outside of Scrum. Why discourage people from thinking, experimenting and learning?

While it is probably true that whatever you can do with Kanban you can do with Scrum, that's really not a useful position IMHO. Think of Kanban as a pattern within Scrum. If people derive value from that pattern in general and want to share it, it is easier to share that experience via a label, such as "Kanban" than to copy and paste in 10 pages of text that don't contain the word Kanban every time they want to say Kanban.

Are you worried that the folks on this page that are talking about Kanban are irresponsible and misguided and will somehow harm the very people they are trying to help?

It seems to me that everybody in this thread has a deep passion for the principles of Agile. How about we focus on the substance rather than the form? For instance, if you don't like the fact that "pure" Kanban doesn't have the implied per-story length limit of Scrum, why not complain about that rather than complain about Kanban in general?

In summary, it seems to me that every Agile advocate should be encouraging thinking, learning, experimenting, and growing rather than trying to somehow set boundaries on it.

I just remembered... the Manifesto contains everything you need to do Agile. I don't see why we need this fancy Scrum thing. :-)

Aw, snap! Now you've got me advocating the Manifesto, which advocates embracing change (I'm paraphrasing) but never has changed.

This discussion is not about "my tool is better than yours", or "my process is better than yours". To feel or express that as being the root of this discussion is to entirely miss the point.

I am not fighting for Scrum, I am fighting against charlatanism, against process-thinking.

Scrum is not a tool. And it is not a process. It is a fundamental change in the mindset of how we do our work. So-called tools like Kanban, with its hand-offs and queues keep us in old-thinking. They are not forces for essential change, but appeasements to people who just can't or won't adopt radical new (new to software, not new) ideas about how creative work is done.

As I have said many times, there is nothing special about the idea of minimized WIP and big visible tools, and small items of work. Those /are/ tools. Use them, be happy, call them by whatever fancy Japanese name you like. They will help you do your work, of that there is little dispute. But don't think you'll change the hearts and minds of software folk by seeking a "repeatable process" (http://bit.ly/sTWER).

@all How dare I sleep on a comment thread... well done all, very nice perspectives!

@Marko I feel you're on the right track focusing on the role of timeboxes, but think more deeply on what _replaces_ timeboxes, they do serve a function, and I feel kanban has mechanisms that serve that function better.

@Tobias "This is exactly the dysfunction I am talking about, and removing timeboxes hides it." Agreed, unless you substitute something that raises the issue even more obviously.

@Liz Thank you for sharing, and I like your perspective on the personal integrity aspect of defending the tools you find useful. You're also right that we need to pay more attention to the obvious, perhaps you could say Rediscover the Obvious ;)

@Tobias "This discussion is not about 'my tool is better than yours', or 'my process is better than yours'. To feel or express that as being the root of this discussion is to entirely miss the point" -- Entirely agreed. I very much enjoyed where our discussion was going last night, but things feel very clouded this morning.

@Tobias "Scrum is not a tool. And it is not a process. It is a fundamental change in the mindset of how we do our work. So-called tools like Kanban, with its hand-offs and queues keep us in old-thinking."

I feel very confused by this statement, although it may be a result of failing to state what I perceive as obvious. I have no disagreement considering Scrum a mindset, those are the words I use to describe Kanban. I do have a problem expression either Scrum or Kanban as a process (less problem calling them tools), for neither prescribes behaviors to the level we'd associate with RUP, most CMMI processes, etc.

You have pointed out a number of times that kanban did not introduce anything specifically new at a practice level to our thinking. Nor did Scrum, and possibly not XP, FDD, Crystal, etc. At the same time, each of these has brought together a cohesive set of perspectives under a named brand, and each one has provided many pratitioners with a new perspective on common sense, and a new language to use when discussing what needs done next. Luckily, each of them has adopted much of the language and many of the practices from earlier and concurrent efforts. None of the principles or values have changed, only our ability to express them.

Every company has a value stream, kanban just chooses to use that specific language from lean to describe the model. Every company has handoffs, even the 1 guy in his garage... at least I hope he releases to his customers. Kanban chooses to explicitly model the handoffs in order to draw attention to them.Every company has queues of work. Some approaches choose to do a batch transfer every 14 or 30 days, some choose to manage the contents dynamically over time, some choose to ignore them. Some approaches work better than others in various circumstances. Kanban chooses to use WIP limits.Every company needs ways to identify pain, ideally before it hurts. Kanban chooses to monitor Cycle time and currnet WIP to identify these issues. As an aside, so did FDD back around 1998 or 1999, iirc.

Every company needs to improve its approaches to survive. Kanban chooses to call these Kiazen events and applies thinking tools based on Lean Design approaches. Kanban has generally rejected the approaches from Lean Manufacturing for these purposes. I encourage you to read "Managing the design factory" and "The principles of product development flow" by Don Reinertsen.

The point I wish to make here is that all of the approaches have the same goals, they merely choose different mechanisms. This is one of my biggest frustrations with "Scrum vs. Kanban". They solve the same problems in different ways using the same tools our community have adopted over the last 10+ years. Each has its context.

Regarding your link to Corey's post: I encourage you to read more recent materials. That post is now two years old and represents some of the earlier exploratory conversations around kanban. The consensus perspectives have changed quite a bit since then.

"I feel you're on the right track focusing on the role of timeboxes, but think more deeply on what _replaces_ timeboxes, they do serve a function, and I feel kanban has mechanisms that serve that function better."

Yeah, one thing we are having is kind o f "SLA" for delivery based on the size of a feature (we use S, M & L) and the historical data how fast we've delivered similar size item. When the time goes beyond expexted/close to expected (kind of timebox..) then we mark the feature with special marker to emphasize it.

I am happy to hear if you have done something different - time to share and learn :o)

Anyway, I will write a blog post describing the current state of our "teddybear" way of doing things and poke you in twitter about it.

I like that people are going out and trying new ways to deliver software. I understand that in your opinion all this fits in Scrum since it is all inspect and adapt and that nothing else matters. I am concerned about one way of doing software crushing others. I want to quote a very wise thought leader in the software development space.

"Giant monolithic institutions representing “the interests” of their members may not be the way of the 21st century. I for one, think Maybe small is better. I sincerely hope that the Scrum Alliance won’t scale to PMI proportions. I’d like to see it splinter instead, into small passionate, self-managing groups each with a slightly different agenda, and different interests."

Here is the source link: http://agilethinking.net/blog/2009/03/11/oppression-revolution-and-the-future-of-scrum-1/

@Dennis Thank you for reminding me of this -- and in such a gently humorous way :-) Indeed I still hold true to that ideal. I read somewhere that the largest manageable organization size is 160 people. This likely applies to non-profits too. Trying to represent "all your members" is doomed to failure.