When I first discovered how Kanban in general, and Work In Progress limits specifically, worked as a catalyst for deep systemic improvements it was like an epiphany. Kanban, which at the beginning seemed like a neat and light-weight process management tool, proved to be far more than that. Not only was it helping to clean up the mess short term but also steered sustainable changes in the long run.

When Tools Fail

These were my early days with Kanban. Since then I’ve seen a lot of teams applying Kanban in all sort of ways. A thing that surprised me was that, even among the teams that achieved a certain level of maturity of the adoption, the results were mixed at best.

Some of these teams are doing great and the early results I’ve seen no longer stand as exceptional. Most of them though weren’t even close. Clearly the magic of WIP limits that induce slack time, which in turn results in a steady stream of sustainable improvements, is neither obvious nor granted. There has to be something else.

No curious person, and I tend to consider myself one, would pass on this observation without a second thought. No reasonable person, and I tend to consider myself one, would keep sharing the success stories ignoring all the counterexamples.

Of course, one obvious reaction would be that the teams that failed to achieve exceptional results got it wrong. In fact, if you want to look for such attitudes among our thought-leaders it is pretty common. The method works, only those unskilled folks mishandled it, they’d say. No wonder these teams still crawl in the misery, they’d add. Actually, they sort of deserved it by not doing the thing the way we preached, the thought-leaders would sum up.

Fortunately I’m not a consultant or an owner of a business that depends on popularity of a specific approach. I consciously chose to stay in practitioners’ camp. This leaves me with no neat and simple (and wrong) answer to the puzzle.

A nice thing is that, given enough experience, we will stumble upon such puzzles on and on. Gemba walk which seems to be mentioned in every other important management book from The Goal to Lean Startup was another such realization for me. Failed stories of applying Kaizen boards and holding Kaizen evens was one more. Organizations struggling with Improvement Katas is probably the most recent one but the list goes on.

Cargo Cult

A cargo cult is, in short, defined as mechanically following practices or rituals without understanding why they worked in the first place and expecting the same results as achieved originally. In case you wondered it doesn’t really do miracles. In fact, the only known successes are creating prophets of cargo cults.

A common observation, and a sad one, is that our efforts with applying different methods are surprisingly close to that definition. Even worse, such attitude is often encouraged. By the book applications of any tool means spreading the disease. It is like saying that we need to trust an enlightened prophet who guarantees two-, three- or fourfold productivity increase as long as we do exactly as they say.

Don’t get me wrong the other end of spectrum, which is NIH syndrome, is equally bad. If NIH syndrome was a good guidance it would mean that entire management knowledge is useless because no one in the world was exactly in the context such as ours.

In either case the missing bit is understanding the underlying principles behind the tools. One exercise I typically start my Kanban training with is asking a group about practices and principles. While they always know a few practices, sometimes most or even all of them, almost no one remembers any of the principles.

By the way, the same thing is true when it comes to Agile Manifesto. Everyone knows “this over that” part but most of the time that’s pretty much it. It seems like we haven’t understood what we read. Alternatively, we never read that thing at all but heard about it somewhere where they used only the marketing part of the manifesto on a slide.

It is kind of like knowing how but having no clue whatsoever why we’re doing something. And then we wonder why we fail so frequently.

Understanding

I know that belief in universal solutions has certain appeal. It doesn’t require us do to the hard work of trying to understand what is happening around. I don’t think there’s a shortcut here though. I mean one can get lucky, as I did during my early adventures with Kanban, but this experience can’t be easily translated to different contexts.

Now, certain techniques give us a promise of help in facilitating the understanding how we work. Visualization and Gemba walks come as obvious examples. However, before we rush to apply them we may want to ask ourselves a question do we understand how and why these techniques work. Seriously. Even something seemingly so straightforward as visualization may be a waste unless a team understands that one of its biggest powers is reflecting current condition and current process and not projecting an expected state, or that too much burden on keeping it up to date will render it irrelevant, or that that too many objects on a board makes it incomprehensible and, as such, pretty much useless.

I think the most common practice across all agile teams I know, no matter which method, if any, they follow, is a daily standup meeting. I believe I can safely assume that vast majority of agile teams have their daily standups. Now, how many of them asked themselves why they are doing that? Why are standups a part of a canon of Agile and Lean? Why were they introduced in the first place? And why, the hell, are they so prevalent?

It doesn’t seem to bug many people. That’s interesting because they may be just following a cargo cult and maybe they could have been doing something much more useful in their context.

Take pretty much any popular practice, technique or method. The same story again. We don’t understand why the tools we use work and simply blindly apply them. Doesn’t that fulfill a definition of a cargo cult?

By the way, I think that one of significant contributors to the situation we have here is pretty common perception that Shu-Ha-Ri model universally applies in our context. A basic assumption that when being on Shu (apprentice) level we should do as a master say because we are incapable of understanding what we are learning doesn’t seem to be an extremely optimistic view of our teams.

Call me lucky but most the time I worked with teams that are perfectly capable of better understanding how the work gets done and how specific tools contribute in that. The missing bit was either knowledge itself or curiosity to get that knowledge.

A side note: the higher up we go through hierarchy the less of that curiosity I see, but that’s a bit different story. Most of time talking about tools we are in the context of teams, not VPs and execs.

A Fool With a Tool is Still a Fool

Any time a discussion goes toward tools, any tools really, it’s a good idea to challenge the understanding of a tool itself and principles behind its successes. Without that shared success stories bear little value in other contexts, thus end result of applying the same tools will frequently result in yet another case of a cargo cult. While it may be good for training and consulting businesses (aka prophets) it won’t help to improve our organizations.

A fool with a tool will remain a fool, only more dangerous since now they’re armed.

Not to mention that I don’t think orthodoxy is anyhow helpful in this discussion.

By the way: as much as I didn’t want to engage the recent TDD versus anti-TDD discussion you may treat it as my take on it.