In Japan, a kanban is a little card that is used as a signal device. The idea, in manufacturing, is that teams downstream "pull" new work, instead of having work "pushed" to them, which creates bottlenecks.

A gentleman named David Anderson took the idea and applied it to software to create Kanban Development, a surprisingly popular movement, to the point that it has it's own user groups and conferences.

That's right folks; without any specific skills training, any people interaction, or changing of the office environment, Microsoft saw something like a 150% increase in the number of tickets the team could handle in a month. How did they do that?

- Eliminate the time the team spends planning and estimating. Not reduce; eliminate.- Technical staff took stories that makes sense that they were actually capable of doing (rewards well-written, well-conceived change requests)- They moved from a push system to a pull system- They made the process transparent- They stopped batching up User Acceptance Test and Deployed a ticket at a time- He got the team out of meetings

Now, the idea of Kanban for software - where we make the work visible by having a board, limit the work in progress, achieve pull, have no fixed iterations but (possibly) continuously deploy, arguably came out of this case study.

Personally, I have a different interpertation: That if you take a team doing CMMI 5 and PSP/TSP and /stop doing/ a lot of required practices, moving your team from 20 hours of meetings a week to three of four, throughput will go up. Further, by working on a story at a time, you'll have technical staff actually talking to each other instead of throwing work over the wall via electronic tools. This will work wonders for eliminating the "hot potato" game.

Finally, and most importantly, if you live in an environment where the customers can make as many ill-conceived change requests as they want, and you have to constantly estimate, evaluate, and shuffle the deck, then take all that away, yes, productivity will go up.

So, I agree, what Mr. Anderson did at Microsoft can work for certain kinds of projects - namely, a maintenance team working on legacy applications that are small, separate, and distinct. That way, you can test one entire 'system' at a time and deploy continuously. (This is pretty much exactly what we did with the small projects team at Priority Health, about the same time, with good results.)

Now, labeling it, calling it Capital-K "Kanban" and giving it out to everyone as a silver bullet to improve the process ... I am not really excited about that.

First of all, it's universalism. "This process worked for me one time so it should work for everyone all the time." Just like labeling "that thing that worked well for us that time" a "best practice", it is a rookie mistake.

But now we have the Kanban discussion list, which I have tried to be involved with. I see a lot of smart people with good ideas, but there are things about it ... something I can't put my finger on just yet. Here's what I'm struggling with:

1) There's something odd about the way this community talks. I mean, I have a master's in CIS, I study software (and manufacturing) process, one of my writing/speaking partners is a Six Sigma black-belt and process engineer, and there's something ... odd there. Why call it a "Value Stream Mapping"? Why not just call it "How we get from concept to cash?" Why is it that skills, training, experience, and expertise just never come up in discussions with these groups? Why is it that instead of talking about development or testing, we call it "workflow" or "process mapping?" I have an inkling on why, and I'll come back to that in number 4, but also ...

2) It seems to me this community uses a lot of 20th century worship words. Productivity. Throughput. Optimize. Lead Time. Cycle Time. Flow. Leveling. There's nothing wrong with these words (although, if you can measure productivity at all is a different discussion.) I see these terms thrown around in a naive, cavalier way. Like "New and Improved", "Hyper-Productive" and "Best in Class", they almost guarantee attention and receptivity for an audience - management and executives.

But does that make them right? Certification is another worship word. And, the day I first heard of ISQTB, at the STAREast conference in 2004, an ISTQB trainer told me literally "You can charge twice as much for training if you give away a certificate at the end of it."

Is that right?

In fact, the Cavalier way those terms are thrown around (compared with, say, the way you'll see metrics talked about on this blog), tells me that there are a number of possibilities, ranging from over-optimism to universalism to genuine deception. I'm not excited about any of them.

3) Kanban works best if you start out slow and stupid. As Dave Nicolette pointed out recently, if hyper-productive means a 10x or so improvement, then the companies likely to see that kind of improvement are traveling at a snail's pace to start with. In other words, if you team is already dragged down, spending 20-40% of it's time planning, estimating, and writing stories for work, that are 6+ months out, then yes, you can see improvements with Kanban. Or, if, say, you batching up work to be release only once or twice a year then do heavy-weight trade offs through an electronic system, instead of having people talk to each other. But in those cases, systems thinking can lead to improvement directly, without using a label or brand.

4) What about people and skills? I don't see any of this in the Kanban literature. It's as if people are cogs that can be interchanged in some sort of machine that is stable, predictable, and repeatable. Hey - wait a minute - I've heard that before! Yesterday I read a Kanban history post that claimed that Toyota had adapted the ideas of Frederick W. Taylor, and Kanban came out of that.

That is factually inaccurate. The Toyota Production system did not come from Taylor, it came from a number of consultants, most notably W. Edwards Deming, as an explicit rejection of the work of Taylor.

I don't have time to get into Taylor and his philosophies, but suffice to say, Taylor was an elitist who believed in separating the worker from the work - having a class of scientific managers tell the workers how to do it - and Deming believed in engaging the worker in the work.

If Kanban comes out from the philosophy of Taylor, then having your process designed by "experts" who don't want to deal with the fiddly-bits of requirements, development, and testing, but instead design a meta-process that turns software development into an assembly-line makes perfect sense. In that world, you might not call it "development" at all, but instead, something like "Workflow" or "Work Products." (Notice issue number one, above.)

If, however, software development is actually knowledge work, which requires the whole person to be engaged, and can be done better or worse -- well, then, hopefully, we'll use the work Taylor as either a door-stop or a cautionary tale.

5) The Kanban movement just isn't interested in discussing testing. I've brought the issue up several times on this list, and get a number of non-answers. That could be because the list members haven't really done much development. Or it could be that they are working on internal applications, where if you type in an invalid entry, the VP of Finance can say "use Internet Explorer Seven ONLY" or "if you want your reimbursement check, ignore the bizarre error, click the back button, and enter it correctly!" Or they could be working on very small, non-connected systems where the testing burden just isn't very high.

But on a real project - a large software project - not something a pair of developers can bang out in three or six months. A project where you want end-users to pay out of pocket, fall in love, and recommend it to friend? Well, a big part of what I do is risk management, and I see continuous deployment with a simple CI suite as naive, perhaps even reckless.

So I see Kanban/deploy per feature moving from limited environments where it can work to general acceptance, and in that, I see serious risk.

Note: In North America, we like our westerns - with Good Guys in white hats and bad guys with bandannas. It would be all too easy to paint the entire Kanban for SW community as "bad." In reality, the ideas are a mixed bag that can be helpful in some environments. Some members of this community are strong system thinkers that have good ideas, and can separate when an idea might work from when it might not, taking in actual feedback and adjusting. Sadly, in general, due to over-hype, I have a final concern ...

6) Some people will actually listen to these jokers. We'll see a lot of hype about Kanban, there will be Kanban certifications, a Kanban alliance, and "Kanban conversions." There will be Kanban instructors, tutorials and lots and lots of books.

And, two years from now, or perhaps five or ten, I expect that a lot of companies will have experienced some critical failures and have a code mess all over the floor. Meanwhile, the consultants will have moved on, embracing and selling a new process - perhaps 5s, or Kaizen. It may not be Japanese at all; it may come from Northern Europe.

11 comments:

Am trying to be open minded about kanban. While I'm hearing things about it that concern me, we can often pull good ideas from a variety of places and so I suspect there are things we could pull (hah) from kanban to make our own projects better.

But, it's really difficult because - as this post makes abundantly clear - there is a huge amount of obfuscation around it.

I mean, Fredrick Taylor?? um, yeah. Is this just the pendulum swinging back to the other extreme? Or is there really something in here we can use to help us on our projects?

Thanks abby. I think Kanban can and does provide some good tools. Of course, most of those tools did exist under the names "Agile", "General Systems Thinking", "The Theory of Constraints", etc. for a long time.

A rose by the name Lean, as they say, might smell more sweet to management than a rose named Agile.

I think the idea of limiting work in progress, and viewing WIP as a liability, instead of an asset, is a genuine insight.

So yes, I'd agree there may be some tools for your toolbox in there, and it might be helpful for me to do a post or two on that.

In my mind the jury is out. To me Kanban is an interesting, but as yet untested set of ideas. I'm not ready to risk at a client yet. What I do appreciate is the tools that Kanban has already given us i.e. limited WIP etc.

To Anonymous - if you're going to say something like: Wow. Just wow. Personal attacks AND nationalism? (Anti-European). - have the integrity to use your name.

I use something similar to what I understand from Kanban in my projects. Though my clients often have an overall vision for the project, and a list of desired features, on a day-to-day basis I can only work on one thing at a time. We therefore collaborate to choose the one thing to focus on now until it is done. Once that feature is done we can look at what to do next. Sometimes that will be an evolution of the feature, it may be something else off the original story list, or it may be something new either in response to additional info e.g. from their marketing department, or in response to the feature itself.

This works well for me and my clients. As you said, it might not work so well for others.

So that newcomers to the movement, like me, can go look up the term and find out how to do it.

> What about people and skills? I don't see any of this in the Kanban literature.

Possibly because the literature focuses on the differentiators (the processes and tools). I've had several conversations with Kanban community members about how to multi-skill people to be able to act across roles, and I'm pretty sure I remember coming across these discussions on kanbandev too.

> I've brought the issue up several times on this list, and get a number of non-answers... Some people will actually listen to these jokers.

If you value people and skills, you might like to try constructively feeding back on the usefulness of answers. Approaching the discussion respectfully may also help.

I look at Kanban similar to how I see Agile, it is the (not so) new kid on the block that managers are discovering. A lot of people searching for new process are doing this because there is some larger and possibly unknown problem in the organization preventing them from achieving whatever the current goal is. This has been my experience with process evangelists at least..

Unfortunately, no process can magically make people work together happily and can not magically make people skillful in their given craft. I think the solution is in the combination of having people on a team that really click together and are also technically savvy. These people will succeed regardless of what you call the process they are using.