One-Piece Continuous Flow - an alternative to Kanban?
- Share
-
- |
Read later
My Reading List
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?
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Kanban and Commitment
by
MAR RAM
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 big misunderstanding
by
Håkan Forss
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
An Argument with No Flow
by
Dan Mason
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.
Educational Content
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013
Hello stranger!
You need to Register an InfoQ account 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