Sunday, November 20, 2011

An Alternative to Kanban: One-Piece Continuous Flow


I'm pleased to be visiting here as a guest this week at Jeff's invitation. The topic at hand is kanban. Unfortunately, this entry is a bit long, because I want to go beyond the usual level of sound bites afforded to an important topic.


A Terminology Tour
Kanban is a Japanese word that just means sign. It is used to control work in progress, in the context of a production line where flow has already been established (Ohno, Toyota Production System, Chapter 2). The concept has found its way into software development, where it is often contrasted with Scrum or suggested as a complement to Scrum implementations. However, though most uses of the term hearken back to its origins in the Toyota Way, its popular use misconstrues much of its original intent.

The Toyota Way is a system of building things that, as a formalism, goes back to the mid-20th century, and has explicit roots in the early 20th century or even the latter 19th century. It is the way Toyota runs. Many other Japanese companies, starting with Toyota's suppliers but including many others, follow the same principles of overlapping development phases, self-organization, and learning. We find many of these companies mentioned in Harvard Business Review's The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. This is the paper that inspired Scrum, and Jeff Sutherland continues to work closely with Nonaka today, as Jeff describes in "Takeuchi and Nonaka: The Roots of Scrum."

Takeuchi spent six years studying Toyota and summarized the apparently paradoxical culture in the book Extreme Toyota. The historic relationship between the Harvard Business Review paper, and Toyota, is sometimes indirect, though the principles of the two align well. For example, the notion of starting design before analysis is complete (which we will revisit later, below) is explicit both in the Takeuchi and Nonaka paper and in Liker's description of the Toyota Way. The use of versatile, diverse teams comes out both in the Harvard Business Review paper and in Extreme Toyota.

As Jeff''s blog describes, it's important to distinguish The Toyota Way from Lean. "Lean" in its common, vulgar use — particularly in methodological settings — is too often interpreted as a shallow way to apply Toyota Way tools to production without adopting its deeper foundations. Kanban is one such tool. It can be a powerful part of a production system that already has working flow, but it's crucial to understand that the foundations of flow must come first. In this article, the term "Lean" will arise occasionally in quoted material that, unless explicitly mentioned otherwise, refers to the Toyota Way.



Scrum is a framework for building product that is based on The Toyota Way. There are few differences between their fundamentals: e.g., the Toyota Way has a Chief Engineer which Scrum splits into a Product Owner and a ScrumMaster. As we'll discuss below, Scrum is neither built on kanban nor has a need for kanban, because it is ideally suited to a mechanism for limiting work-in-progress called one-piece continuous flow.


How is Kanban used?
In Toyota, kanban is used in two major ways. The original application of kanban (as a sign — see the example at the right, from Liker's book The Toyota Way, Chapter 2) was to placate a failure mode in the Toyota Production System. Sometimes you can't have one-piece continuous flow, because of impediments like multisite development, poor organizational structure, or bad assignment of workers to work locations. If you are a supplier far away from your consumer, you need a semaphore to synchronize the handoff of goods. The kanban card is that semaphore. When the consumer is running low on parts, the consuming work cell puts a kanban card in a supply cart that requests additional supplies. The cart is wheeled to the point of supply. Its arrival is a signal to the supplier to build more and to fill the cart, after which it can be wheeled back to the consumer. The consumer can initiate the request a little while in advance, giving the supplier time to respond to the request, or the supplier can keep some inventory on hand so that most requests can quickly be satisfied.



The supplier builds inventory which is put in a cart and delivered to the point of use. The cart is left there. When the cart starts becoming empty, you put a kanban card (a sign) in it giving information on projected need, and the cart is again taken to the point of supply so it can be filled up. You don't have kanban without the muda (waste) of moving the card and the cart, of the cost of storage for the inventory. You don't have kanban without the mura that comes from low-bandwidth communication between the supplier and consumer. By definition, kanban is based on having muri: instead of continuously flowing, the work bunches up. So this failure mode creates a need to limit work in progress. A disciplined use of kanban limits work in progress.



The other application is within a work cell, to ensure that only a limited number of parts (usually one) are on the table in front of the worker at any time. The table has kanban squares drawn on it. Parts being worked on must be within one of these squares. If parts stack up, it means that there is overproduction somewhere. If I'm a producer, I should produce something only if I can see that my neighbor needs, or is about to need, the part I build. I build that part to deliver to my neighbor just in time. Kanban squares are also used at a larger scale on the factory floor, as placeholders for pallets of parts or for larger parts (see figure at right; from leanmanufacture.net).


Kanban is a Wasteful Fall-Back for Repetitive Manufacturing Work
Kanban applies to repetitive work — building the same item again and again. Liker — author of The Toyota Way and highly regarded authority on the Toyota Production System — tells us:
Not everything can be replenished based on a pull system; some things must be scheduled. Take the example of high-end products, like a Rolex, a sports car, or those killer high-tech golf clubs advertised by Tiger Woods. Whenever you are buying a special or single-use item, you have to think about what you want, consider the costs and benefits, and plan when to get it. In a sense, you create a schedule to purchase, since there is no immediate need for it. (Chapter 9)
That is what software is like: We rarely build the same thing again and again. In manufacturing someone has to build any new parts that we need. In software, we can reuse a function as many times as we want by adding as many calls to it as we like, or reuse a class by instantiating a new object of it. Much design is based in innovative, incremental aggregation and extension of existing artefacts. This is particularly true in software, but also extends to industries such as building architecture and construction. Few design jobs plough totally new territory, yet none knowingly crafts a replica of past construction. It is about building new things to a scheduled market need rather than stochastic, repetitive production of the same basic form.

Liker goes on:
TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System... The challenge is to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer. Remember: the kanban is an organized system of inventory buffers and, according to Ohno, inventory is waste, whether it is in a push system or a pull system. So kanban is something you strive to get rid of, not to be proud of. (Chapter 9)

Note: The presentation by Jim Shore and Arlo Belshee introduced by David Anderson on this topic may be of interest.

Software Has Misappropriated Kanban
The fascination with kanban in Europe and North America has its roots in misinformation about how kanban fits into the Toyota Way, but there is a cultural element to the misunderstanding as well. Kanban is properly applied as a selective, detailed fix to a specific problem. It is not a philosophy of development. Sharon Begley observes:
Westerners prefer abstract universal principles; East Asians seek rules appropriate to a situation. (Sharon Begley, "East Versus West: One Sees Big Picture, Other Is Focused,"The Wall Street Journal, March 28, 2003.)
Taichi Ōhno, who invented the kanban system, tells us in his landmark book Toyota Production System:
Close supervision of the kanban rules is a neverending problem...
Rule 6 urges us to reduce the number of kanban... (Chapter 2)
The ideal is flow rather than kanban. Again, Liker advises us, "inventory buffers are used judiciously where continuous flow is not possible today. But the ideal of flow provides a clear direction." (Liker, The Toyota Way, Chapter 8)

The word kanban is also used as the name of a recently packaged methodology based on visualizing and mathematically analyzing work in progress. We see teams adopting this form of kanban, as a tool or methodology in its own right rather than as a worldview, without first having built foundations and disciplines of one-piece flow. Kanban (the methodology) discourages teamwork and increases the risk of not completing agreed work loads within a time box like a Sprint. It does give managers a lot of flexibility. That is, it allows the Product Owner to come to the team in the middle of the Sprint and stop what they are doing while introducing a new PBI or task. This interpretation of kanban sells to managers feeling a need to regain the control they lost with Scrum. The ability to patch things up, rather than solve root problems, gives a higher sense of immediate success without having to ponder long-term consequences of short-term decisions.

These misunderstandings of the Toyota foundations are deep, and though they often have kanban as a common thread they are not limited to software. If we look at Kanban.com we find a claim from the director of IT at CVG Systems: "To get the most benefit from kanban, we needed a closed-loop solution that would support a continuous-flow process, a solution that any of our suppliers could access easily." Kanban is a stopgap in the absence of one-piece flow — not a method to achieve it.
It is about separate groups controlled by a kanban protocol that replentishes inventory on demand (pull instead of push), in a highly structured way. It is a six-step, highly structured process (Ōhno, Toyota Production System, Chapter 2)


A Truly Lean Solution: One-Piece Continuous Flow
Instead of depending on kanban, true Lean eliminates mura, muri, and muda — inconsistency, lack of continuous flow, and waste. Instead of tracking the movement and processing of materials, a good Scrum co-locates the teams or the devices that make the artefacts. The foundations of Scrum encourage one-piece continuous flow. Team members swarm around one PBI at a time. A common dysfunctional alternative is "swim-lane Scrum:" each team member individually taking ownership of a PBI through the stages of the process. If an individual gathers up multiple PBIs, or tries doing all the tasks in the PBI at once, you can get the context switching that comes from having too much work in progress. Kanban says to track the number of PBIs in progress, supported by pseudo-queuing theory math, to limit how many cards can be on the task board.

Good Scrum practice follows The Toyota Way by instead focusing on a single PBI at a time, building on the team's intelligence and self-organization — rather than a method — to manage work in progress. There are no longstanding subteams in a Scrum team: the Developers work together as a unit. It's individuals and interactions over processes and tools. If the team works as a unit, it eliminates the problem of waiting for work items to arrive from another development stage. It also eliminates both the inventory necessary to keep the development team busy at the local site, and the inventory being readied for shipment in parallel at the supplier. Kanban fundamentally depends on both of these inventories.

One-piece continuous flow can take place in a single team working as a tightly-knit unit, in a single work cell (or Scrum team), to apply several transformations to work in progress (which is limited to a single piece at a time). The team does a little analysis, a little design, a little building, and a little testing all at once in very short cycles. Individuals are multi-talented, reflecting the Toyota concept of chaku-chaku. See the illustration at right, taken from Figure 8-4 in The Toyota Way. It reflects a quite unstructured way of working, as Takeuchi and Nonaka relate in the Harvard Business Review paper:
Rather than moving in defined, highly structured stages, the process is born out of the team members' interplay... A group of engineers, for example, may start to design the product (phase 3) before all the results of the feasibility tests (phase two) are in. Or the team may be forced to reconsider a decision as a result of later information. The team does not stop then, but engages in iterative experimentation. This goes on in even the latest phases of the development process.
Liker underscores one-piece flow in Chapter 3 of The Toyota Way:
... the one-piece-flow cell is the ultimate in lean production. It has eliminated most of Toyota's eight kinds of waste.
In fact, the ultimate goal of lean manufacturing is to apply the ideal of one-piece flow to all business operations, from product design to launch, order taking, and physical production.
Pair programming is one of the best analogies we have in software. There is no coder and no tester: there are two developers working together in a work cell continuously testing and developing until the work in progress is done-done-done. Good pair programming is quite unstructured. Because the feedback loops happen locally and immediately there is no need for a literal kanban card. Because it happens as two minds working as one, there is no need for kanban squares below the keyboard. Again, Liker says, "In a one-piece-flow cell, there is very little non-value-added activity like moving materials around. You quickly see who is too busy and who is idle." (The Toyota Way, Chapter 17)

It doesn't stop at pair programming. One-piece continuous flow is a staple of the techniques we teach ScrumMaster Certification course attendees to apply across the entire team throughout the sprint. In the Velocity Game exercise we emphasize that the entire team should work on one PBI at a time — swarming instead of playing Swim-Lane Scrum. The pace is frantic but the flow becomes smooth after two or three sprints — because there is complete visibility of who is doing what, second by second. Kanban cards would just get in the way. Good development teams are like football, hockey or basketball teams. The players and artefacts of the game are the most important considerations to understand the nature of work in progress.

Pair programming as a technique depends on having the larger Scrum flow in place: good enabling specifications from the Product Backlog, self-organization and task selection among the developers, and so on. The same is true with the other forms of flow within a Scrum team. It's not a quick fix, and there is no quick path to building the foundations of quality and efficiency. In fact, kanban was one of the later additions to the Toyota Production System because it had to wait until the broader flows were in place. As Ōhno relates, "Outsiders seem to think that the Toyota Production System and kanban are the same thing... But... Unless one completely grasps this method of doing work so that things will flow, it is impossible to go right into the kanban system when the time comes." (Ōhno, Toyota Production System, Chapter 2)


Kanban: A Good Fit for Teams that View Work as Firefighting
Toyota production plants and Scrum teams exist to build product. The literature speaks of successful application of kanban in the service industry, analogous to firefighting or hospital emergency rooms. It's tricky to schedule your next fire unless you live in the world of Fahrenheit 451. Many development teams run in firefighting mode, often with "swooping" from the Product Owner during a Sprint. And getting into a discipline is hard: it's easy to want to be able to react immediately to customer change instead of integrating a request into the business plan, and it feels good to release whenever you see fit. Some Scrum teams never learn the disciplines of planning and estimation. It is easy to see how these organizations gravitate to kanban.

It is difficult for these teams ever to develop a true sense of teamwork and working together, of feeling a sense of ownership for completing work to a forecast, or to develop the disciplines of long-term planning and enabling specifications that are at the foundation of long-term value. The problem with kanban (as with Scrum-butt) is that the resulting poor execution won't kill you. In his book, Liker expresses astonishment at the ignorance of supposed Lean practitioners, and has seen as much as 80% reductions in inventory after their understanding is clarified (Liker, The Toyota Way, Chapter 14). He says:
I have visited hundreds of organizations that claim to be advanced practitioners of lean methods... [H]aving studied Toyota for twenty years it is clear to me that in comparison they are rank amateurs.
He feels that less than 1% of companies outside Toyota "get it." (Liker, The Toyota Way, Chapter 1) Many of these companies are following the pop buzzword Lean instead of the core Toyota Way. The Scrum framework, as defined, has carefully avoided this trap (see "Takeuchi and Nonaka: The Roots of Scrum").

The same is true in software. Teams that have done both have found that kanban can actually afford less visibility to the business of work in progress than Scrum does, and take away the sense of teamwork and "positive pressure" that comes from the flow of a Scrum team (see Samuli Heljo's reflections).


Taking on Kaizen Mind: Back to the Foundations
A good Scrum team automatically enjoys the provisions of kanban when practicing one-piece continuous flow. It is a built-in way to limit work in progress while encouraging teamwork. It gives team members time-boxed autonomy to carry out their plans while enabling them to better meet their planned forecast. Such maturity may be a foundation for later addition of techniques like kanban, but both the inventor of kanban and our experience suggest that it is likely to founder without a framework like Scrum that first establishes the discipline of flow.

Thanks to Gertrud Bjørnvig, Neil Harrison, Kenji Hiranabe, Bojan Jovičić, Jens Østergaard, David Starr, Jeff Sutherland, and Stefan van den Oord for comments and clarifications.

30 comments:

Jeff Sutherland said...

Comments are welcome (but moderated). Blogger was initially blocking them by mistake. We are seeing a wide variety of reactions to Jim's piece. His views are always well argued and deserve to be heard.

Perhaps not surprisingly opinions appear to fall into three categories:

1. Utter crap!
2. Stop saying anything that might upset anyone - Cockburn's Oath of Allegiance.
3. Might be worth reading.

Opinion leaders have been invited to write a rebuttal.

Yuval said...

Interesting piece Jim!

I find the discussion of kanban the tool very useful and similar to how most of the leaders in the Lean/Kanban community see "Tools-driven Lean" and the manufacturing-inspired Kanban.

I do find your piece mis-represents the Kanban Method that the community (e.g. Kanbandev) is talking about and practicing for the last couple of years.

While it is true we don't REQUIRE one-piece-flow, we DO see it as our north star, but we are trying to find effective ways to drive organizations more and more towards that direction.

Our Kanban is an inspect and adapt framework, that uses the visualization of the current state and the work in progress limits as drivers for taking steps to reducing the "number of kanban" as you quote from the Lean literature.

Kanban might be prone to abuse since it is less perscriptive. I'm sure you've seen many cases where Scrum has been abused as well.
It might be that there are more KanbanButs out there than ScrumButs. I'm not sure about it.

I think an interesting debate would focus on the effectiveness of the various inspect and adapt frameworks, and play the perfection game on both to derive even better frameworks.

In my experience at least I've seen both Scrum and Kanban successfully drive teams and groups towards better Focus, Teamwork/Collaboration, breaking down barriers between functions, pull adoption of more effective engineering practices such as ATDD, Agile Testing, TDD, Continuous Integration, Collective Ownership and the like.

I've seen Scrum teams use Kanban to improve their performance/scale. I've seen Kanban teams use Scrum as one way to focus them even more. Others look at Scrum for inspiration but find other ways to achieve the same results. So I've come to see Scrum and Kanban as two great methods to have in my toolbox...

Rodrigo Yoshima said...

I would say that your blog is great but the paragraph where you explain that kanban for software as a "recently packaged methodology based on visualizing and mathematically analyzing work in progress." sounds FUD and lack of knowledge of the model.

Kanban for Software Development as proposed by David Anderson is an approach for establishing pull, visualizing work and limiting work in progress. It's a process change management based on explicit policies, improvement and flow to flourish a Kaizen culture and augment knowledge worker's understanding of their work environment.

I would like to know if you've got any evidence that teams applying Kanban, as David defends in his book, "discourages teamwork and and increases the risk of not completing agreed work loads within a time box like a Sprint". By the way, recent Scrum Guide changes says that the team does not commit to work items planned for the Sprint. It's just a forecast, right?

Also, I would like to know how did you infer that "This interpretation of kanban sells to managers feeling a need to regain the control they lost with Scrum." Do you have any relevant cases, research or data on this?

What is your relevant and practical experience with Kanban for Software Development?

Jeff Sutherland said...

Please note that this a guest piece on the blog and is Jim's view of Kanban based on a lot of work with lean, much of it elaborated on in his recent book on Lean Architecture, perhaps the best book of its type in the field.

As for me, I've recommended doing Kanban inside of Scrum for 18 years. After all, Takeuchi and Nonaka were looking a the best "lean" teams in the world and noticed they were working intensively together in short iterations generating the "ba" that creates new product. They called it Scrum which is why I used the term.

For an interesting implementation of Kanban inside of Scrum see  J. Sutherland, "Future of Scrum: Parallel Pipelining of Sprints in Complex Projects," in AGILE 2005 Conference Denver, CO: IEEE, 2005.

jmeydam said...

"it's easy to want to be able to react immediately to customer change instead of integrating a request into the business plan, and it feels good to release whenever you see fit."

A really fast flow can be a very good thing. I think the key question is whether a development team is allowed to focus on design work without interruption by others. Frequent, small releases reduce risk and enable feedback which can inform the design. Continuous Delivery and DevOps are very important topics in particular for web based systems such as Facebook or Etsy (there are also quite serious examples such as London's Multi-Asset Exchange), and one can argue that Kanban is a good method to model flow in such a context. This is also why Eric Ries suggests the use of Kanban. My feeling is that in such a context Sprint Review and Sprint Planning are still suitable, but have a different role, more like a "pivot-or-persevere" meeting in the Lean Startup methodology.

However, I find the advantages claimed for Kanban almost inconsequential compared to the order of magnitude improvement one can get with cross functional teams set up as described by Takeuchi and Nonaka. To me, this is the core of Scrum. Kanban is completely silent on this. In fact, Kanban has tended to be associated more with "traditional" workflows with discrete steps, because, frankly, a Kanban board adds little value in the absence of a multi-step workflow.

Machiel Groeneveld said...

Thanks for explaining Scrum in terms of Flow, I like it over the classic circles. I thought Scrum was just a framework, but actually it prescribes how people show interact to be most effective, which is very helpful.

Too bad you had to pull the waterfall kanban.

babyJ0se said...

Jeff:
You are clearly confusing kanban (used to manage flow) and Kanban method (used to manage transition) up. You can't do Kanban method within Scrum although you can apply it to Scrum. I'd be interested where you first wrote about kanban (used to manage flow) within Scrum. I had never heard that discussed until recently.

It's hard to have a real dialogue about this blog since it does not describe anything like what is done in the Kanban community

Yuval said...

Jeff,
At times I've been thinking of Kanban Feature-Driven Sprints as something similar to what you called Scrum Type C. But reading deeper into your papers, I gather that Type C is more of "multiple levels of sprints" rather than flexible Feature-driven sprints.

Maybe this is Scrum Type D ? ;-)

babyJ0se said...

Liked the article you referenced bu am confused. How is your referenced article about doing kanban inside scrum anything about kanban. It wasn't mentioned, nor was managing WIP, mura, muda, muri. No mention of creating visibility from one step to the other. I agree there is some flow in there. That's good.

Jim Benson said...

Very nice perspective and thank you for this.

I do believe there is a fundamental difference in the role of variation in knowledge work than in manufacturing. The application of kanban is a red herring.

The goal for me has always been to get the most pertinent information in the hands of those who need it as quickly as possible. The visual control in the currently popular kanban does this better than anything I have seen before.

Limiting WIP has been key for teams to slow down, understand context, and deliver product with minimal technical debt.

While one piece flow may be a dream, it is a dangerous focal point. The inherent variation in software development is a healthy element of our inventive work. If we get rid of it, we will merely be assemblers of code.

Thank you again for the post, let's keep constructive dialogue open!

Jim Benson

Jay Packlick said...

The problem of teams applying frameworks and tools without a grasp of the underlying worldview and principles isn't isolated to the use of Kanban; Ceremony rich cargo cult adoptions of Scrum are hardly a rarity and a CSM course provides no guarantee that good teamwork will naturally follow nor that the decisions made by a team will be effective.

Kanban, like elements of Scrum, is essentially a tool in the Agile arsenal to augment the decisions made by a team to achieve single piece flow. If the team achieves that flow using Kanban without sacrificing other objectives (i.e. teamwork, high motivation, etc.) then the tool is effective. If the same results can be achieved with lower ceremony and overhead, all the better.

Without the application of the underlying disciplines, BOTH Scrum and Kanban are both likely to flounder.

I think the real takeaway here is that blind application of any tool, be it Kanban or Scrum, does not confer automatic benefits. Ultimately, it gets down to individuals interacting as as a disciplined team guided by principles (such as the dynamics that give rise to single piece flow) to make effective decisions.

Andreas Schliep said...

This is an excellent rendering of Kanban and its (mis-) interpretation. Sad enough, many organizations just want to reap the benefits of any approach without understanding the principles, concerns and reasoning behind it. The Kanban style concepts and visualizations we are applying to Scrum are more related to one-piece-flow, the pull-principle, overlapping phases under control of a self-organizing team than the original definitions of Kanban - and some implementations of software Kanban. Nevertheless, Scrum practitioners need to be knowledgeable about many paths to the goal.

Thanks, Cope!

Anonymous said...

"the Toyota Way has a Chief Engineer which Scrum splits into a Product Owner and a ScrumMaster."

That statement would only be correct if tech lead or Sr. Tech Person is also playing the role of Scrum Master.

Correct would be Chief Engineer = PO + Tech Lead.

Michael Dubakov said...

Swarming sounds good in theory. But will it work in practice. Let's say, we have 10 developers in our team. And we have small user stories (it is good to have small stories, isn't it?). So do you expect all 10 developers will swarm on every small user story? If not, how will you split the work between them (and in this case it is clearly not one-piece flow)?

Visionary1usa said...

I certainly struggle with this piece... but I do with many. There are too many brands and proper nouns in here. The need to brand oneself... to ride on the coat-tails of the work of others... to make claims based on personal experience as if any of us are the definitive expert on someone else's domain... I smell revenue streams - not objective analysis.

We do not need brands or wars over methodology or process. Nothing branded works out of the box... and any process that is completely stable for a long period of time misses the point. Our role should be about problem solving, growth, and learning... and what we call things may be a little important at times; but what we do matters most.

Client orientation... customer value... people over process... using real judgment and choosing from the full toolset - In my mind any diversions from this is us taking our eye off the ball. We can call it all fudge - if we are doing the right things.

The best way to kill progress is to let branding interefere. I am not here to impose my interpretations of any of these words - choosing to is little more than pushing dogma. Trying new things - is fundamental.

The game is moving industry capability forward and chasing our potential. There is no wining... its cliche - but its a journey. I am a Lean advocate... but I trace the bulk of it to Toyota - not the tools, but the principles. We choose the tools because of the principles... we are not Lean or agile by choice of tools. What is in us can not be turned into something external.

Nothing says Lean principles rule out Scrum - but the fact is, they surely do not predetermine Scrum. I was doing Lean before it was called that - almost a decade before the manifesto. SOmeone telling me what it means - you can imagine an outsider attempting to impose their meaning of Scrum upon its creators.

Religious wars - especially in a competitive domain - please; I really want this not to be a zero-sum game... this is not about wining, but growing. All of these ideas should be in our toolbag - and more.

tekzenpdm said...

This is one of the best posts I have read on the real meaning of Lean and flow for software development.

The slew of reactions for this post is very much expected given the stand Jim has taken. I commend him for taking a bold stand.

I agree 100% with his observation as a first hand witness to TPS and Lean practices in a manufacturing floor. My career started in one of the best TPS followers in the world Lucas-TVS in India,(ww.lucastvs.com) by the way a Deming award winner.

It is amazing to see so many writing about lean and the idea of the flow just by reading couple of books and touting solutions from mind games.

Now Kanban is the new in thing with guranteed imrovement of productivity using Scrum, I even posted an linked in discussion on this topic after reading Charles Suscheck's post in agile journal.

One of the important concepts of TPS is GEMBA which means 'the ral place' you need to there and experience it to understand it.
Lean flow is not achieved by just introduction of visual cues like Kanban and being incremental without the capacity to big leaps.

There are so many other aspects of Lean like Jim mentions, such as Poka Yoke, Nagare etc that is not part of any conversations.

Kanban is a one component in the Lean TPS that helps to solve a specific problem in the factory floor, if you have that kind of issue in your development team, then it is a good choice for solving it, it is no way a methodology like TPS or Scrum. Let us not compare Apples and Oranges.

Thanks

Fabrice Aimetti said...

Hello Jim (and Jeff),

Please, enjoy french translation of this post :
https://agilarium.wikispaces.com/Le+flux+continu+pi%C3%A8ce+%C3%A0+pi%C3%A8ce%2C+une+alternative+%C3%A0+Kanban

Regards,
Fabrice

Mark Levison said...

While an interesting article - the Kanabn described here for software isn't the Kanban I've seen in practice. In particular I see alot of value in Kanban at the portfolio level.

In addition I apply it at the team level for operations, support etc and where we can't start by making real change. Honestly the differences between Kanban and Scrum are smaller than made out here.

Cheers
Mark Levison - a CST who has wide ranging toolbox (Scrum, Kanban, OpenAgile and more).

catherinelouis said...

Cope,

Great article.

On the point of firefighting, I have become very opinionated that if there isn't a planning phase owned by the team (for example, "lets look at the bugs we need to solve for the top 3 customers, and create a plan to improve the product to prevent these bugs from happening"), and there isn't a retrospective phase "ok we pissed these 3 customers off in our last iteration, and we avoided that install issue which was a good thing", this firefighting will remain a never ending tail-wagging-dog thing.

I have seen some amazing teams move from firefighting (tail-wagging-dog) mode to truly influencing product direction given their direct customer feedback. The dynamic is cool too: this type of job (where you have influence on product direction) becomes a job people seek vs try and avoid our 'outsource' to let someone else handle. Again, great article and thanks.

jmeydam said...
This comment has been removed by the author.
Jeff Anderson said...

Jim,

It appears you have good knowledge of Lean history and manufacturing Kanban, but you have deeply misunderstood the Kanban method as the lssc is applying it.

This misunderstanding is a real shame from someone of your stature, when you speak people listen.

There are many points I could dispute with you but I think it would be better if you simply took the time to watch a Kanban team in action, and to see the difference this method has made for many knowledge workers.

jmeydam said...

Some of Jim Coplien's points are remarkably close to points made by Arlo Belshee and Jim Shore in 2010 at the Lean Software and Systems Conference.

http://jamesshore.com/Blog/Single-Piece-Flow-in-Kanban.html

The very first slide of their presentation "Single Piece Flow in Kanban: A How-To" contains the following quote by Jeffrey Liker:

"The challenge is to develop a learning organization that will find ways to reduce the number of kanban ... So kanban is something you strive to get rid of, not to be proud of."

The presentation proposes an alternative to Kanban based on Arlo Belshee's "Naked Planning", introduced at Agile 2007.

http://www.youtube.com/watch?v=6t4bZtnnQJA

See also the following posts:

http://agilitrix.com/2010/09/whats-better-than-kanban/
http://agilitrix.com/2010/04/enough-kanban-use-xp-for-single-piece-flow/

With regard to discrete process steps -

In March 2009, Bas Vodde made the following remarks on the Yahoo kanbandev mailing list:

http://finance.groups.yahoo.com/group/kanbandev/message/2045

"When I hear phases then I tend to assume that:

- A requirement is at one phase at one time (so not at multiple phases)
- Phases are somewhat sequential, instead of parallel or overlapping
- Certain activities fit within certain phase
- Specialization will happen according to these phases

[...] Instead I prefer to think about different activities that need to be done. [...] Then my preferred way of thinking is to try to have all these activities going on at the same time."

There is a consensus among leading practitioners that the Agile/Scrum model of colocated, cross-functional teams working in an "all-at-once" fashion is superior to a waterfall-like sequence of steps.

On November 23, David Anderson made some clarifying remarks on Twitter with regard to Kanban and Scrum:

http://twitter.com/#!/agilemanager/status/139134540097658881

#kanban was never about failings of #scrum. It was designed to help orgs resisting or rejecting #agile methods improve their agility!

http://twitter.com/#!/agilemanager/status/139135362730696704

Ironic that a #Kanban was designed to address the rest of the market but that #scrum practitioners (not targeted) have been those objecting

Recently, the Kanban community has invited several keynote speakers with messages remarkably close to Scrum. A good example is the keynote by Stephen Bungay on lessons from German 19th century military doctrine.

http://www.lean-kanban-conference.de/videos/keynote-stephen-bungay/

Dave said...

Single-piece continuous flow - a good goal, and a familiar one to any practitioner of the kanban approach to software development. The provocative title, which struck me more-or-less like "chocolate as an alternative to chocolate," led me to think there might be some interesting new insights in the piece. I started reading it with great enthusiasm. Later, I finished reading it. <sigh> Oh, well.

Ralf Westphal - One Man Think Tank said...

What seems to be missing from the discussion is the notion of small and even batch sizes. Single piece flow can be done with Kanban. It´s a matter of work organization: just pick a single feature from the backlog and put the whole team to work on it.

The problem with that: it´s hard to know how long that´s going to take. Sometimes the team works on a single feature for 2 days until it´s finished, sometimes it´s a week, sometimes maybe 10 days. That´s ok for Kanban, that´s also ok for Scrum.

Kanban admonishes the team to make features equally sized - but that´s hard to whole features. Scrum puts a limit on feature size by saying, it should not take longer than a sprint to complete it.

But why not create work items of equal size? To me it feels like that´s the very prerequisite of flow. It´s no wonder "processes" with input of different size take great pains to shred it into small and equal sized pieces, take waste processing or harvesting for example.

So I guess we need to go beyond WIP=1. It´s WIP=1 plus small work items we need.

How big should such small work items be? I think, whatever can be done in 1 day is ok. Split up user stories and features into 1 day chunks of work. Deliver working software at the end of every day.

That way development is still agile - but it can get into a flow, because what´s flowing through it is of small size, like red blood cells.

Read here for a more elaborate description of what I mean: http://geekswithblogs.net/theArchitectsNapkin/archive/2011/12/22/spinning-ndash-getting-agile-at-the-core.aspx

Eilon said...

I believe this posting over-analyzes and over-dramatizes the Japanese roots of Kanban (and Scrum for that matter).

In the end of the day, if one strips out some of the "New Age" ideas of Scrum (well, does everyone *really* have to sit in the same room? C'mon, guys), and if you strip out some of the "pull" ideas from Kanban (well, is software really an assembly line), the crux of the two approaches isn't that fundamentally different.

Kanban is much more flexible (or, less rigid, if you will) and may thus be more liked by some, but not others.

I've just posted a very related write-up on this topic, with our learnings. May be of interest, the link is below:
http://onsaasproducts.wordpress.com/2012/03/09/developing-saas-forget-scrum-check-out-kanban-and-similar-approaches/

Mike Dwyer said...

James
Well said, enough said, time to move on.
Jeff
Finally, your 2005 article is digestible. (thought leadership has a lot in common with wine)
To KanBan, Kanban, and others.
Enough of the muddle, have enough respect for your work to call it by a name that is yours. The reason Scrum works is there is no confusion with PMI. Your work has merit and value but it leaves many in a confused, bemused state.

Scott Bellware said...

Jim's Lean Architecture book is on the recommended reading list for my team. It's offered with that caveat that there are many interpretations of Lean and its application that are questionable and seam to be a view of Lean through a Scrum lens and a Scrum predisposition.

The content surrounding the Domain, Context, and Interaction pattern is the reason that the book is on our reading list, and I wish that the Lean interpretation had not been used as a justification for the architecture as it seems to suggest that the architecture isn't sufficient of its own. This made making the case for DCI more difficult for me, and it complicated long-term Lean changes already in-process.

This article smells like a defense of Scrum as an income stream rather than a reasoned looked at Lean through its own lens rather than through the lens of something else. I agree with the comment offered by someone else that observing teams in-action and over time is a good exercise. But it means that the lenses have to be recognized and then removed from in-between the observer and the observed. And that - ultimately - is a sufficient and accurate definition of Lean.

Lean's machinations aren't "The Lean". They're means to an end - and they may not be applicable to all circumstances. The goal always remains to become aware of bias, and accept that bias paints a distorted picture, and that we're always susceptible to it. This is the reason for the relentless improvement culture and predisposition of Lean persons.

I have great respect for Jim's contribution. I respect this article as a human being respects another for staying the path. But I think that the factualness of the representation of Lean is spurious.

Juan said...

I see Kanban as an approach to help organizations change in a more constructivistic and empirical way (less dogmatic), helping people see what is the problem with stocks, how it impacts lead time and improve the process they already know and work.

Also Kanban instill a culture of talking about the process, but respect the organization (and existing people) rate at which it may be changed.

Most of my customers saw Scrum as an End Goal, and were really dogmatic about it, and was this dogmatism that lead me to help them talk about the problems but the SMs didn't have the tools to do so, they only knew they had impediments.

So introducing Kanban was good so they could start to visualize how they really worked, and it introduzed some new voacabulary that they could use to talk about their problems and start generating ideias on how to improve.

Instead of creating more impediments and more heat, accusations between departments on, Kanban helped to create a common improvement goal and a concience of how everybody was impacting on the value stream performance.

For me the most important deal that Kanban brings to the table it creates higher concience of how the system works today and the dialogs on how to improve between people that hardly could be located in the same "team" retrospective.

For me Kanban focus is much more organization wide than a tool for teams.

Richard Henderson said...

An interesting piece. Just a small correction, though important. Jim defines:"mura, muri, and muda — inconsistency, lack of continuous flow, and waste".

This is not quite correct. Firstly, it should be in the order "muri, mura and muda". This is the order in which processes should be addressed. This tends to add support to Jim's points in my opinion.

Also one of the definitions:
muri is a tricky word with two meanings: irrationality & overburden. Not 'inconsistency'.

Again, this tends to support his piece better.

Nigel Baker said...

Very interesting article. I would like some of the more pro "The Kanban Method" people to discuss some of the points rather than brush them off. I think that discussion would elicit some really fascinating learning.