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?