Saturday, July 11, 2009

against kanban

I've been somewhat alarmed by the enthusiasm with which the agile community has embraced Lean manufacturing principles, especially kanban. While I'm sure that kanban is effective in some circumstances, I am also convinced that it exposes software teams to real risk of impaired function.

Like many of my qa/tester colleagues who were working in the field in the 90s, I used to be a real process-head. I was part of projects that enthusiastically implemented Six Sigma, CMM, ISO9000, as well as other approaches like RUP, spiral development, etc. etc. We thought then that if only we could get the process right, we could crank out great software just like factories crank out cars and engineers crank out bridges.

Six Sigma and ISO9000 were lifted straight from manufacturing. CMM was the product of a lot of analysts who looked at some properties of a selected set of software projects.

Then the Agile movement came along, and with it new processes, the most significant of which turned out to be XP and Scrum together. These were revolutionary, because they were software development processes actually created from scratch by people who were very very good at creating software. Obviously, because these processes were created by smart people creating software, these processes map very well to how we do excellent software development.

We can argue about the details: is it better to have stable velocity or increasing velocity? should we estimate using points or using ideal hours? Regardless of these details, if your team measures velocity and uses velocity to plan iterations, and if your team always does pair programming, test-driven development, and continuous integration, then you will either release excellent software every iteration; or you will quickly expose and face the reasons why not.

Kanban doesn't make it necessary to face your inadequacies. I have two examples:

At one point my dev team had a chance to interview a self-appointed "kanban expert" on the subject of kanban and Lean. At this point the team had successfully shipped something like 25 of the last 27 iterations, so releasing iterations to production was routine, we had the whole process pretty well dialed in. And we had some killer questions for the kanban expert.

Under this questioning, it turned out that the kanban expert's team had been using a Scrum/XP process, but they blew iteration after iteration after iteration. From his answers to our questions, it seemed that his team lacked the skill and discipline to be consistently successful iteration after iteration. So one iteration, when they knew they'd blown it one more time, they simply stopped doing iterations or planning to release features. This is apparently when this person attached "kanban expert" to his resume.

Before we started releasing every iteration, my team had been using a kanban-like process. We would identify a set of features, then branch our trunk code for each feature under development. When a feature was finished, we would merge the feature branch back into the trunk code. This way we always had features being developed, and we could release trunk safely at any time.

We had a lot of very bright developers on the team. Some of them were maybe a little too bright. With no timebox pressure, we had people doing a lot of gold-plating, making architecture changes that had no relation to the feature being developed, making (cool!) experiments in the underlying code, and generally making merging not very fun.

Furthermore, it was an enormous headache for the marketing people. Without timeboxes or estimates, it was difficult to know when a particular feature would be available, which made it almost impossible to do effective marketing for the product. When we switched to planning iterations based on our velocity and our backlog, we made the marketing people very, very happy.

The fundamental difference between software development and manufacturing or engineering is that in software development we do not manipulate physical objects. We manipulate concepts, and algorithms, and process. Processes designed to optimize the handling of physical objects simply do not map to the work we do when we create software. I'm sympathetic to those who see estimation and iteration planning as waste, but I think the risk inherent in not having a mechanism to expose our inadequacies is too much risk to take, even for the best of teams. We have no warehouses to fill up or assembly lines to halt, we have only the contents of our heads and of our code repository. For software development, the only truly useful metric is: can you deliver running tested features on a consistent schedule? Iteration timeboxing exposes that metric in the most obvious way possible.

What we find in both literature and anecdote about the application of processes taken from manufacturing and engineering, puzzlingly, is that for every team for which the process is successful and helpful, there are other teams who implement the same process only to meet with failure.

What I suspect is that ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail.

With an XP/Scrum sort of iterative process, we will know very soon exactly how and why we are failing. This seems to be not true of kanban or of any other software development process taken from the manufacturing arena.

45 comments:

Just because someone calls himself an expert, doesn't mean they are. it's up to you to know the difference.

Teams have rhythms; design, planning; releasing; demoing; eating; sleeping, etc. They don't have to be locked to the same timebox, and there are gret benefits from decoupling the rhythms. If marketing wants to synchronize on some given point in time, then that shouldn't be a problem. That still doesn't suggest that the work going into all synchronization events have to be batched and synced directly to each other.

Lean as a set of principles aren't manufacturing principles. Lean as a cultural system can be - and is - applied to many industrial and social contexts. I understand that Lean has a rich history in manufacturing, but Lean Software Development isn't Lean Manufacturing.

I haven't seen any discussion of rhythm in any of the Lean stuff I've read. If we're going to talk about rhythm, then let's use some other kind of language or metaphor where rhythm is a native element. I've been arguing for this for a few years now.

If Lean Software Development is unrelated to Lean Manufacturing, doesn't that make it even more of an orphan than it would otherwise be, since Lean Manufacturing is where all the success lies?

My reading of lean material hasn't precluded the recognition of an organization's inherent rhythms. It's inherent in and implied by kanban.

We may be reading different material, or we may be reading the exact same material with respective contextual mental inventories that result on different degrees of conclusions.

Lean Software Development is related to Lean Manufacturing in that it shares Lean principles, just as Lean Healthcare does.

Ultimately, Lean Software Development is more closely aligned organizationally and mechanically with Lean Product Development than Lean Manufacturing.

There's no refuting that Lean comes out of a manufacturing business, but it had to come from somewhere. The principles are contextualized to the industries where Lean principles are applied. This is possible because Lean principles aren't manufacturing principles.

Lean Manufacturing methods aren't directly applicable to lean Software Development, but we can still learn something about applications of Lean principals by observing them in practice in other contexts.

I have had extremely successful agile projects over the years that consistently turned in predictable results. I have also run kanban projects that did the same.

There is no process truth. Agile isn't evil. Kanban isn't god. Any process that claims to be "the true process" is a liar and the experts are riding it for the income.

In the end, you are a manager, you have a group, that group operates in a certain way. If it works well with Scrum, great.

What I've seen, though, is that many scrum / agile teams treat the process as sacrosanct. When I hear someone say "it's a textbook agile project", I cringe.

"Textbook agile" is like "Enforced Happiness". Agility was always meant to be customizable.

Some groups will be scrum, some XP, some scrumban, some kanban, and some even waterfall. Some groups will be random coders in an open source repository building at their chaotic whim. And they will all be successful.

So, I totally agree with your post. But I don't think it should be "against kanban". It should be "There's more to life than your cardwall."

Personally, I'd be interested more in the analysis of why these different things failed. I doubt that the failures were caused by choosing a faulty methodology du jour. I also doubt that anyone planned to fail. So that leaves me wondering what unanticipated factors were at play.

I would suspect that continued lackluster performance has to do with broken feedback loops in the process but I can't prove my hunch.

As a tester, I'm aware of a vast amount of information about software defects but I honestly don't know where to find out more about software *process* defects. I'd be thankful if someone out there could point me at material like that.

no, I really am against kanban. I believe that it does not accurately describe our work, and that, like all models from manufacturing, leaves holes in which the incompetent can hide their deficiencies.

Bellware is right, I'm not interested in dialog. I'm particularly not interested in self-referential, circular-reasoning nonsense.

I am interested in new approaches to software development process, and I think the vein to mine lies in aesthetics, not in engineering.

I would agree with most of the points you made (Most :). Kanban doesn't mean no time boxing. If we do anything without a clear finishing line it is always dangerous. Micro Releases (Clear end line) + Kanban may be a good combo.

I use kanban as a tool to fush out constraints which the team is facing. It has helped me. Not sure about others. I think Kanban is not about manufacturing process. it is more about how you organise work items or stories so that you get a flow rather than chunks of work.

And Developers trying to do too much not related to adding functional value is a smell. It is only magnified by using iterationless process.

Kanban or not idea as you always know is release early, release often and add business value (and enjoy doing it :)

Lean Software Development started as a theory piece. Kanban started as applied theory ( practice followed theory ). So far I am aware of one book on the subject "Scrumban by Corey Ladas".

IF you joined the Kanban group you would discover that the pro-Kanban people are just as critical ( in a positive sense ) as the anti-Kanban people. They are mostly practitioners who have used Scrum and migrated to Kanban. They prefer Kanban as it works for them.

There is a law of diminishing returns when we improve things. From Waterfall to Agile was an 80/20 move, but there is only 20% more efficiency to find. Kanban took us from 80% to 90% ( ignore the numbers, its the reduced increase in efficiency ). Toyota are continuing to seek out the final 0.000001% as they see the value in it.

If your team have reached a level of efficiency with Scrum that is "Good Enough", or do not need to respond to frequent changes in business direction, then Scrum is where you should be. If you want to improve, then you might find additional improvements in Kanban.

As for Koolaid. The one I drank that no one seems to be interested in anymore is.... "We are uncovering better ways of developing software by doing it and helping others do it.".

Come join the Kanban party on the yahoo group. There are just as many dissenters as there are advocates.

It seems your main gripe with kanban is that you perceive it not to exert any time pressures on the team - "it was difficult to know when a particular feature would be available" and "With no timebox pressure, we had people doing a lot of gold-plating".

In the Lean and Kanban literature I've been reading rhythm has been a primary feature in the form of Cycle times and Lead times. I believe that these provide a sufficient time pressure as the teams focus on reducing them by analysing the system for constraints, and are a good predictor of delivery.

I'm practicing Kanban now, and I must say I agree with a lot of what you say. I also agree with much of what Scott is saying too.

I think you guys are talking past each other, because you are looking at the problem at a different level of abstraction.

"Lean" as I think Scott is using the term, describes a management philosophy, that builds on scientific management, by adding human psychology and respect for people to the mix.

Chris is talking about Kanban the process, which is supposedly inspired by "Lean" practices in the manufacturing industry.

I am using Kanban right now, and I must admit I have a lot of difficulty in viewing it as a process. I see it as a tool (the familiar story board we've used for years with the addition of WIP limits).

Can a tool be good or bad? I think I agree with Chris. If the tool is being promoted as an all encompassing process or philosophy then yes (I've referred to a couple of levels of abstraction here in case you missed it:)).

So I see kanban as a tool as useful. As a process, it leaves several gaps. I've asked a number of questions in an attempt to fill the gaps, such as "how do you do production leveling" in software? and how does iterative development and feedback work? I haven't got any consistent answers other then to fall back on a Generic Agile approach (What I believe Chris refers to as XP/Scrum).

Until Kanban the process has decided what it is exactly, then IMHO we should treat it as just another tool (i.e. not a full blown process or a management philosophy).

Kanban's main strength (for the moment) is that it makes work and the flow of work explicit. This is important because it takes work out of a fuzzy conceptual level (invisible things you have to do) and puts them in a space with physical form and substance. Cognitively, this makes the work easier to grasp and responsibly complete.

Vasco's post is awesome for debunking the misunderstandings about kanban as a tool, and thanks Vasco for the post I'll be promoting it in a few minutes.

But!

All processes are mix and match strategies with one common goal: produce something. Koolaid drinkers and haters need not apply to the responsible leadership camp.

I've used kanban since before I knew what it was. When I learned what it was, I used it better. But it was always in some agile hybrid arrangement. Why? Because in the real world your clients won't always let you have the process you want.

Processes are not holy. They are marriage counseling. If I told you I had the perfect process to make all marriages work - you'd laugh me out of the room.

"no, I really am against kanban. I believe that it does not accurately describe our work, and that, like all models from manufacturing, leaves holes in which the incompetent can hide their deficiencies.

Bellware is right, I'm not interested in dialog. I'm particularly not interested in self-referential, circular-reasoning nonsense."

Good to see someone take an unambigous stance against kool aid fuelled semi-mystical mumbo jumbo.

I am so reminded of when XP came out all the blogs about how it couldn't work. When Scrum becames popular all the blogs about that how it couldn't work. What you need to remember is that the people doing Kanban have done XP and Scrum. We are not using Lean from manufacturing but general principles that manufacturing _also_ used. Kanban Software is, unfortunately, poorly named, and therefore misunderstood.

Think about if there were value to understanding your process (which was still yours) or following the laws that affect software development (many don't believe in these, but they are there and you ignore at your peril).

Chris, I know you mean well, but you are misunderstanding a lot. Kanban provides feedback just as fast as Scrum. There are also huge attitudinal differences between Kanban and most Agile teams which assist it going beyond a team.

Too much to say in a comment. You might look at my blog "Differences in Beliefs Results in Differences in Approach" (http://tinyurl.com/pysl4f) and a chapter (Going beyond Scrum) from our book Lean-Agile Software Development: Achieving Enterprise Agility (http://tinyurl.com/lwetxq) (which is more lean than kanban) http://www.netobjectives.com/resources/books/lean-agile-software-development

First, Kanban is not based on Lean Manufacturing, but on the principles of Fast-Flexible-Flow, Deming's theory of profound knowledge (which applies to all systems, manufacturing or software development) and the practices of pull, limiting work in process, ...

Second, referring to a Kanban expert as a person who does agile but doesn't do iteration is like taking someone who doesn't do over-documentation and calling him an XP expert (even though they don't do TDD). Lack of iterations is not the big think in Kanban although it is a side aspect of it.

I love working with someone who regularly generates such great discussions! Go Chris!

Doesn't mean I always agree with him 100% though. Personally I don't like any "schools of thought" or labels. I've been on four teams since 2000 where Scrum and XP principles/values/practices + fantastic, disciplined people = success. But I've also been on teams where waterfall + fantastic, disciplined people + good automated regression test coverage at all levels = success.

After about 3 years, my team at ePlan Services was fortunate enough to get Mary and Tom Poppendieck to come by for a quick visit. They had a huge impact on us. I've read three Lean books including theirs, but never tried to actually implement any of it. Several months after their visit, we were working differently. We no longer tried to plan an entire sprint at a time, but simply made sure we were all busy and kept bringing in stories as we had time. We released every sprint, but also sometimes during the sprint if we finished a feature the business needed now. Our PO started only asking us to estimate the stories planned for the next one or two iterations. This all made a huge improvement in our productivity (and no, sorry, I don't have any metrics to prove it, but we did ask our customers for feedback and they were enchanted by what we were doing).

So, kanban is the new buzzword. My new team at Ultimate consists of all top-notch people. I think we could do well with kanban (from my admittedly limited understanding of kanban). Then again I think we can succeed at any process we try. We are all highly disciplined, test-obsessed, committed to delivering the highest-quality product possible.

My personal understanding of Lean as applied to software is that, like various agile "schools", it's focused on letting people do their best work. So I think kanban can work as well as anything, if you have good people.

Anyone who's read even a fraction of my public writing of the last few years would know that I am cultivating a pretty radical position regarding the theory and process of software development. I expect disagreement, but I also expect a certain amount of respect both for the logical soundness of my arguments and for the depth of my experience in the field.

So thank you very much for your comment. The more public descriptions we have of actual practice, the better off we all are. "An example would (always) be handy right about now."

> My personal understanding of Lean> as applied to software is that,> like various agile "schools", it's> focused on letting people do their> best work. So I think kanban can> work as well as anything, if you> have good people.

I think that part of the story.

Culture and organization are not necessarily the same. The teacher/student dynamics are sometimes informally hinted at in Agile but isn't necessarily part of Agile's foundation. The fundamental drive to create learning organizations is also sometimes hinted at in Agile but it's not necessarily foundational as it is with Lean. Some non-trivial differences issue from these distinctions.

Organizational structure and behavior differences between Lean and Agile can be quite different, and some fundamental presumptions inherent in Agile aren't necessarily the same as with Lean, just as Agile questioned fundamental presumptions of what we started calling 'traditional' software organizations and process.

I think it's healthy to question presumptions about Agile the way that we did when questioning preceding tradition with Agile.

Again, and I don't think this is mysticism or circular logic. I've found that there's a lot to Lean - a lot more than I had suspected when first looking at it from my own Agile perspective. And like you, my time in Agile started in 2000.

I think Lean deserves fair consideration and I think that means study and practice, just as it did with Agile. I think there's great benefit to be had from drawing analogies and comparisons, but I think that Lean ultimately should be seen through Lean lenses rather than Agile lenses.

I agree that examples are handy, and we might yet be a ways away from having them.

And yet the absence of examples didn't stop people with an intuitive sense for XP to start putting the practices into play at the beginning of this decade.

I think that it's great to push for examples, and I expect that more and more will be surfaced and published based on the early experiences of those whose intuitions and study afforded sufficient confidence and understanding in Lean software principals and practice.

Scott makes a good point that Lean, like Agile, requires study and experimentation to know the best way to put it into practice and how well it works. I'm willing to study and experiment with it, given that people I respect say it works for them.

As I read your post, my take-away is that you seem to emphasise the "incompatiblity" of Kanban as an exampler manufacturing practice to software development.

In most of the comments posted here, message coming out is "here is Kanban, it worked there, there and there. Let us find out why it is or it is not working here in software development"?

Why people are missing the "incompatibility" issue here? By saying "we need good people" or "we need to customize practices to fit in a organization context" - can we put aside fundamental misfit or incompatability issues between Kanban and software development/testing ?

What if you replace the word software development to "software testing" here in this article?

As you mentioned, many in testing world today think that if we get process right, we can be as successful as car makers and Civil engineers/architects.

A lot of study has been performed in the 1990's to try and incorporate Lean ideas into Software. This was mostly at the SEI by Watts Humphreys and led to processes such as PSP and TSP. It is also the underpinning of the CMMI.

So Lean in Software has been around a long time, a lot longer then Agile. I'm a certified CMM assessor so I have some experience here.

The results for anyone who has some experience with these processes doesn't feel very Agile, and is focused on "defining" how you work to the extent that the work becomes "quantifiable", deterministic and predictable, leading to an "optimal" system of work where quality is assured by applying "quantitative statistical process control". The 'Optimised" level of maturity as described by the CMMI.

Unfortunately the SEI never stopped to think where you would find "optimal" machine like people to fit an "optimal" process :).

We need to be precise and question as Chris is doing. The bottom line is software is not like anything else, and we need to do the hard work to discover what exactly software development is trying to be. At some point manufacturing analogies break down and we need to think for ourselves and do the hard work to find out what works in our context.

These are the qualities that made Agile such a radical departure from what came before.

7th pixel, my team at ePlan not only executes Agile with some Lean practices well, but also the company is doing great. When the s/w development was completely dysfunctional, the company was almost out of business. So I agree, the best metric is (for a for-profit), are we making money over the long term, while also allowing our employees to enjoy their work?

Paul, I don't know if there's much new under the sun. Like a lot of software folks, my team was doing a lot of what is called "agile" back in the early 80s. I think what is new is that some people have formulated different practices and values into something that has a name, so it's easier for teams who have lots their way to try "agile" or "lean".

> I think what is new is that some> people have formulated different> practices and values into something> that has a name, so it's easier for> teams who have lots their way to> try "agile" or "lean".

As much as I want to refute this comment, I'm inevitably struck by what truth there is in it.

My second look into Lean came after a dramatic failure on an Agile project. We had experienced, and in some cases, renowned staff. It was a failure that really shouldn't have happened, and a failure that had sounded warning bells long before it all came apart for good.

In the end, it was a cultural failure that was somewhat reinforced by some Agile orthodoxies that could not be unseated even in the face of imminent failure.

In our case, there was indeed a loosing of the way. However what was found by looking for answers in a broader scope had already been known, but over-shadowed by orthodoxy.

Many of the principles that could have been effectively applied in our situation were specifically called out in Lean. And when I say "Lean" I want to be clear that I'm talking first about principles and not about specific mechanics and process. Although, in retrospect, the organization and cultural mechanics that specifically support kanban would have gone a long way to clarifying some of our challenges.

So, in a sense, I thoroughly agree with you about this 'lost way' idea. But I also disagree with it because I'm not sure that when you say 'Lean' and when I say 'Lean' that we are referring to the same big ball of wax.

What I found in Lean wasn't a process, but principles that I can use to craft a process to fit whatever context I'm in without being bound by specific process orthodoxy, which is what I think most teams who know their way already know to do.

And I found a set of principles to methodically guide and explore improvement that are terrific allies to some of the practices that I had learned in Agile.

The improvement principles have taught me that a 'lost way' is a constant, and that teams are constantly finding their way. Whether they're able to do so without loosing even more of their way is the differentiator.

Alan, you're right. This post has served its purpose and more. There are side issues involved and I don't intend to make the comments thread on a single blog post ground central for those issues. I'm done.

I want to be clear that I was not saying that they should not communicate this way on a blog comment list. Any form of communication is good. So please don't say I was right and that is why you are cutting this off. All communication is good. I was just making a suggestion to increase communication. If you don't want this on your site - you should say that - but please don't put it on me.

Done: hey everybody, I am really tired and stressed over this whole thread, and Mr. Shalloway happened to recommend taking the discussion to mail lists just as I was contemplating implementing moderation for the entire blog. Pure coincidence. So please take it to the lists. I'm out. Peace.

WOW. I am flabbergasted. All I can say is that your quoted kanban expert was clearly NOT. While reading your post, I kept thinking that you must have been misled or that you mistakenly used “kanban” as the term for some other tool.

The most striking statement to me was when you said that kanban doesn't make it necessary to face your inadequacies. This is completely contrary to the definition of kanban. Kanban is a sophisticated tool within lean and should be implemented after a solid lean foundation and culture are in place. In fact, even when really smart companies believe they have their processes under control and they launch kanban, they unearth a whole host of additional wastes and inconsistencies that were carefully hidden in their support processes leading into the main process. It is one of the fascinating bonuses of kanban, and when companies are not willing to do the work to fix the newly exposed issues, that is when kanban "fails".

I am concerned about how kanban was defined for your situation, or how the definition may have been modified to apply to your processes, and I'd suggest that you consult with at least one true lean sensei about your application. The greatest leaders that I can recommend are the contributing members of the Lean Enterprise Institute. Any one of them will know the right questions to ask to help you get the bottom of issues in your application.

As a general comment to anyone considering hiring a consultant, please take note:If any person you speak with claims to be an Expert, this is your first and best warning sign that you are NOT dealing with a true lean subject matter "expert". Anyone with more than a decade of experience and hundreds of hours of training and a passion for lean will NEVER call her/himself an expert. They will use terminology like, "student teacher" or "life-long learner" or "sensei", because the central imperative of lean is that there is no such thing as perfection; continual improvement is paramount.

I'm sorry, I was in the meeting with Chris, the whole "well, if they said that, they aren't an expert" is something called the "No True Scotsman" fallacy.

Person didn't claim to be an expert; he was a well-regarded and senior member of the KanBan Community.

Forget Lean, KanBan, and, to a lesser extent, XP. Fundementally, what you've got to be able to do is to model the system of forces around development at your shop and select the practices that will get you the outcome that you want, then run them like a simulator in the your head. If it works, you try it. If if fails, you adjust it - or even it is succeeds but you have a better idea.

Deming called that "plan do check act."

If you turn your brain off and follow a process, but it lean, XP, Scrum, Crystal, whatever, you are probably screwed.

Now, for commercial software development in corporate America, I suspect that, if you do a good job modeling those forces, what you will often come up with could be called 'lean', 'scrum', 'agile' or 'the Toyota production system'

Within that, I view KanBan (limiting work in progress, generating a 'pull' effect, making WIP transparent) as a tool you may or may not want.

Super post Chris, you have stated your case very clearly. Very provocative with a lot of good conversation.

You should be aware of a couple of points.

Kanban, as defined by David Anderson, actually has its roots in the Drum-Buffer-Rope concept from Goldratt’s Theory of Constraints. The kanban (signal card) itself came into play because of its ability to provide a simple Visual Management tool for throttling WIP to the pace of the constraint in the system. Lean/Agile techniques are often applied to exploit or elevate the constraint.

Kanban allows the team to explicitly identify the inadequacies in their software development system. One of the really cool things about it is that it identifies the bottleneck so you can act in a way that leads to immediate exploitation and a strategic elevation at the constraint – thereby increasing throughput.

Kanban has very predictable Release Planning. With some history and experience a Kanban team can predict when they will be able to produce a specific set of features. The fact that there are no iterations is not significant because the timing of the Release is decoupled from the development cadence.

Kanban has very clear cadence. You can read Karl Scotland’s work on Cadence in Kanban on his blog.

Finally, Kanban has been shown in some cases to be a less disruptive step towards incremental development, improved testing, continuous integration, more effective teaming, better resource allocation, etc. The teams work with a clear understanding of the constraints in the system and apply practices to elevate the constraint. In organizations that have problems getting Scrum to work, Kanban can bring the motivation to the team to discover the need to implement many Scrum/XP practices.

As we work to develop better ways of building software these conversations provide an excellent opportunity to explore variation in the way people build and understand software development. It is this variation that creates opportunities for the learning from which better methods will emerge.