One-Piece Continuous Flow - an alternative to Kanban?

| by Anand Vishwanath on Dec 13, 2011. Estimated reading time: 2 minutes |

Jim Coplien, from the Scrum community, proposes One-Piece Continuous Flow as an alternative to Kanban.

“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.”

A one-piece-flow cell can be compared to pair programming 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.

Jim advocates swarming as a team to work on one Product Backlog item at a time, instead of playing ‘Swim-Lane Scrum’. He further argues against Kanban by asserting that

“Kanban as a methodology discourages teamwork and increases the risk of not completing agreed workloads within a time box like a Sprint.”

Samuli Heljo made a similar observation around lack of commitment when transitioning from Scrum to Kanban.

“One of the biggest problems was caused by the lack of a time box. We had no predefined release cadence (maybe we should have), nor had we cadence for demos.  But the problem was not only about cadence; it was also about the lack of commitment and ‘positive pressure’. In Scrum, time boxed sprint will foster positive buzz as the team will not want to look stupid in demo. I felt that Kanban was lacking this energy.”

 Jim’s post has been viewed with a lot of criticism in the Kanban community. David Anderson, leader of the Kanban community and author of the famous Kanban book, felt that Kanban was never about displacing Scrum or any other Agile method.

Kanban is a way of helping people struggling with adoption of methods like Scrum do better.”

Liz Keogh, on her blog, talks about some of these challenges in adopting Scrum, a major one being the creation of cross-functional teams.

The context in which Scrum starts is not often possible. We’re not always co-located – many start-ups and companies now allow developers to work from home, and the industry still seems to suffer from a delusion that offshore work is cheap to obtain. We may not have multi-skilled people – it takes some time to learn skills. “

 On a more recent thread in the Kanban mailing group, Alan Shalloway further discusses 2 main difficulties in implementing one-piece-flow in software.

“1. Work varies (in size and who needs to work on it)

2. The skill sets and backgrounds necessary to do the work rarely exactly match the work coming in.”

Have you faced similar challenges while implementing Scrum or Kanban? Can One-Piece Continuous Flow help you as an alternative?


Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Kanban and Commitment by MAR RAM

For projects we add additional higher-level "commitment" plan (milestones, demos, deliveries, etc.) with sets of associated features (like Sprints). On lower level there's "continuous" Kanban covering what the team is really working on, regardless of current project or "Sprint" boundaries. It's good enough, flexible, yet it can be more chaotic at times (= price for flexibility!).
In comparison I find pure Scrum too idealistic for our environment: sometimes regular demos don't make sense, sometimes your team cannot be co-located, sometimes organisational hurdles prevent truly cross-functional teams, other times you face urgent maintenance tasks for older products, your stories do not fit in sprints, people may hate stand-ups for many reasons, etc.

An academic piece by Chris Matts

The article reads like an academic piece. It would be interesting to hear from teams who successfully implement it. That way it would fall under the Agile approach where the " doing it.." piece is key.

The big misunderstanding by Håkan Forss

The Kanban Method and the visual scheduling tool kanban from Toyota Production System are two different things sharing the kanban name.

The Kanban Method is not a development process that describes how work should be done. The Kanban Method is something you apply to your current process to induce process improvements.

The tool kanban from Toyota Production System is a visual scheduling tool that tells the process when a piece of work should be done.

Flow of work through a process is a core concept of the Kanban Method. Depending on what your goals are for your process One-Piece Continuous Flow can be a target condition you want your process to achieve. Achieving One-Piece Continuous Flow over the entire process, from ideation to in production, is often very hard if not unobtainable or not economical feasible. The Kanban Method can be used to move towards the target condition of One-Piece Continuous Flow through its three core principles:

  • Start with what you do now

  • Agree to pursue incremental, evolutionary change

  • Respect the current process, roles, responsibilities & titles

And its five properties:

  • Visualize the workflow

  • Limit Work-In-Process

  • Manage Flow

  • Make Process Policies Explicit

  • Improve Collaboratively (using models & the scientific method)

One very popular tool for Limiting Work-In-Process is the visual scheduling tool kanban.

When using the Kanban Method you start with the process you got and if you target condition is One-Piece Continuous Flow you reducing you Work-In-Process over time and this will unearth problems in your process that you need to address as a team. When the problems are resolved and your process stabilizes you can reduce Work-In-Process again until you reach One-Piece Continuous Flow. When you are at One-Piece Continuous Flow the visual scheduling tool kanban is probably not needed but you can still use the Kanban Method to improve your process in other ways.

If the regular cadence of a time box is beneficial for your process use it. If the demo is creating value for your organization, use it. The Kanban Method has no opinion on the matter except that is should help you continuously and incrementally improve your process.

Iterate on Features not on Time by Tim Elton

I loved Scrum when I first learned about it, practiced it, and defended it; but as I've studied and practiced further, I've come to realize that Scrum is a sub-optimization of the engineering/development team. Further, its time-boxed iterations are artificial in nature and disconnected from the business environment. I'll take continuous flow, iteration on features, and release on-demand anytime over the jerkiness of Scrum's start stop start stop start stop start stop... "Sprint" should be renamed "Spasm". I know a lot of the Kanban community likes to co-exist with the Scrum community, and not have infighting within the broader agile community. I don't care about that. The funny thing is, that even though Kanban was not marketed as a replacement for Scrum, those that truly understand and value lean principles will gradually ditch Scrum on their own, just as I have done. So I've moved on. Thanks Scrum for being a great stepping stone to something better.

An Argument with No Flow by Dan Mason

First, I'd like to thank Jim for inspiring me to go back and read "The Toyota Way" in great detail, trying to understand the logic of his article. I conclude that there isn't a lot of logic there.

The title itself makes little sense to me - kind of like saying "An Alternative to Testing: Defect Free Code?". Sure, the ideal of the TPS is continuous one-piece flow, but kanban is a primary method for managing toward that goal, just as testing is one of the ways we manage toward defect-free code.

The current experiments with lean-agile methods using kanban seem to be reasonable embodiment of two adages from "The Toyota Way": 1) challenge everything, and 2) Build Your Own Learning Enterprise, Borrowing from the Toyota Way.

And, there is no real data in the article to support the notion that Scrum is the true embodiment of Lean, The Toyota Way, and TPS, nor that it achieves One-Piece-Flow. Not sure where this claim comes from, and not sure that it matters anyway. The goal is to have methods that work, not to be leaner-than-thou.

I'm an advocate of Scrum, by the way. I do think that kanban is a useful addition to Scrum, specifically to throttle the workload and make work highly visible.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss