The Essence of Lean (and Kanban)

There is a lot of buzz about Kanban these days. There seems to be an equal confusion about what it is. Since Kanban for Software Engineering is really Lean applied to software, I am going to make the two synonymous for the purposes of this blog. I am going to refer to Lean throughout this article. I provide the alternative title because I think the essence of Kanban is the same as the essence of Lean.

In a word, the essence of Lean is flow. Flow is getting a request in and getting value out. This has been called "concept to cash" by the Poppendieck's although I prefer "concept to consumption" to emphasize that until it is "consumed" there is no value. In other words, the essence of Lean is creating value as quickly as possible. Value, is the right functionality at the right time. The ability of an organization to provide the right value at the right time is called "business agility." It provides a competitive edge to any business that has it. And it is a significant detriment to any business that doesn't. A company that is consistently less agile can only compete on price – as they will never have as good of a product as a company that is more agile. Unfortunately for them, agility achieved through Lean methods results in lower cost as well – so their competitiveness on cost will be compromised. General Motors was a grim example – they always seemed to have lower quality products at a higher price – a bad, and deadly for them, combination.

So, now that we know the essence of Lean is flow, what can we do with this knowledge? First, by knowing our goal we can see what helps us achieve it - and what stops us from achieving it. Note, this requires that we believe there is a level of causality here. In other words, even though we acknowledge that software development is complex and requires feedback to control it, we do not wring our hands and say – "it is an unknowable process". Rather, we approach it with an attitude that we can study the software development process and see the positive or negative results of our actions. We believe there are "laws", so to speak, that determine how our efforts will unfold.

This attitude enables us to avoid doing "cargo cult" development, but get at a true understanding of what is happening as a result of our efforts. Cargo cult development means to follow beliefs about your development efforts without questioning them. It is more than dogma, however. Cargo cult has the follower believe that his efforts actually are the reason for some desired results. Unfortunately, the assumptions underlying this have not been sufficiently examined – and in fact, may be beyond the capacity of the individual to do so – either because of other beliefs or because of insufficient training and knowledge.

OK, back to flow. What helps it? What impedes it? Let's start with what impedes it – because that is often easier to see.

What Impedes Flow.

Let's start with the definition of flow – "a. To move or run smoothly with unbroken continuity, as in the manner characteristic of a fluid."

Direct Delays

Therefore, anything that delays you in your efforts is an impediment. Common delays are:

Getting information when required

The time waiting for a resource to be available (analysts, developer, tester)

Indirect Delays

The aforementioned are direct delays. I suggest that there is another kind of delay – what I'll call an indirect delay. An indirect delay is a delay that causes other delays. For example, if a piece of software is written that has an error in it and this error is not discovered quickly, this delay will result in the developer taking longer to fix the problem than if it were discovered immediately. This is because the developer will no longer remember as clearly what they did and the will need to spend more time reconstructing/remembering the problem. There are probably more types of indirect delays than direct delays. Here are a few:

Time from when a requirement is given until it is validated

Time from when a piece of code is written until it is validated

Time from when an API is specified until it is used

These indirect delays are problematic when an error occurs. In these cases, the longer from the error to the detection, the greater the overall delay to the system being delivered. There is clearly the time of the delay itself, but consider the side effects of these delays. In all cases, knowledge about what is working on gets degraded. This means it takes longer to fix the problem than it would have. Furthermore, in many cases, the results of the delay means functionality that is not needed will be written and remain in the system – adding complexity. Complexity will slow us down further.

Distance between team members. Lowers the effectiveness of communications, slows things down and makes things error-prone.

Handoffs. Knowledge is always lost when handoffs occurs. Unfortunately, one doesn't usually know which knowledge is lost.

Errors. Causes rework and typically adds complexity.

More work in process than system capacity can properly handle. This causes delays because people are often not ready when they otherwise could be. This stretching out of time also causes knowledge to degrade.

Work that adds no value. If you are doing something that adds no value that means you are not doing things that will add value – slowing it all down.

Limited critical skills or resources. This causes delays waiting for people or equipment.

Strategies for Eliminating Delays

Set proper work in process levels (WIP). Kanban for Software Engineering is specifically about setting proper WIP levels. Higher WIP than desirable levels is often the cause of many (most?) delays in projects. Pull methods along with WIP limits is a common practice to manage WIP levels.

Swarm when desirable and possible. Another way to manage WIP is to get something done quickly by bringing all of the necessary resources to the work. But this often causes other problems so is not a universal tool.

Avoid building what is not needed by using iterative development. The best way to avoid building what is needed is to not build anything until one is certain it is needed. This is the basis for iterative (time-boxed or not) development. By discovering a little about what is needed and then implementing it we can discover along with the customer what is needed without building anything that isn't needed. Iterative development requires just-in-time methods.

Quarterly planning and re-planning. An organization can vastly improve their agility if they plan quarterly and re-plan quarterly. This involves using minimal-marketable-features and getting value developed and delivered quickly.

Other Strategies

Make commitments based on economics. While flow is important, it is important to remember that "value trumps flow, flow trumps waste." In other words, we don't always do flow if it causes less value to be produced.

Summary

Lean is about creating value to the company's customers quickly. Lean practitioners believe that flow can be impeded or facilitated by attending to certain causal relationships. Lean practitioners therefore attend to these.

Comments

I think you have hit this nail squarely on the head! I came to the same conclusions some time ago in an "ah ha" moment during which I scratched on my office wall "The Enemy is Delay" -- and its been there ever since!