Enough Kanban! Use XP for Single-piece flow

Arlo Belshee and Jim Shore had an interesting pair presentation on titled “Single Piece Flow in Kanban” at LSSC10. A more accurate (although inflammatory) name for the talk is “Enough Kanban! Use XP for Single-piece flow”. It is worth mentioning that the context of the discussion is new product development.  Not sure about team size – seemed manageable. So this may be suitable for this context.

The basic arguement is that we should consider the flow of customer value. This is real flow. Moving Kanban cards representing tasks may be motion and not actual flow of value. The solution is not something new but something we already know: eXtremeProgramming (XP).

One challenge that Taiichi Ohno encountered decades ago when introducing Single Piece Flow at Toyota is that there is often resistance from specialists. They are more comfortable just knowing one piece of equipment.

The same challenge exists today when we ask developers, testers and domain experts to work together to deliver value. If your environment can work this way (and some can’t very easily) there can be a big cycle time and business value win.

What’s wrong with some Kanban implementations? Some have too many hand-offs and WIP due to queues. So, if you are using Kanban, this is something to watch out for.

Arlo and Jim describe the software work-cell as a collocated, cross-functional team that swarm work to minimize WIP and handoffs.

Gone is the release plan and the product backlog (see diagram). Instead a vision (which was a mindmap) drives the just-in-time generation of MMF (minimum marketable features) that are queued in the “on-deck” area. MMF is generalized to mean anything of business value. It could be a product feature. It could be a demo for a tradeshow.

For in-progress work, the notion of a Detective’s Blackboard was introduced as a dynamic unstructured area where tasks and task generators could be added and removed organically depending on the nature of the MMF. The idea is that tasks will grow as work gets started and then start to collapse as progress is made and new tasks stop appearing. (Maybe around when the MMF is ~2/3 complete.) In the example provided, the team was large enough to support 2 MMFs. The video and slides are available on InfoQ.

What looks like an earlier version of this is on Jim’s blog. See also Arlo’s video on Naked PlanningA video with session slides + Audio are on Jim’s blog.

Very cool stuff.

Print Friendly
Tagged with:
, , , , , , ,

Find Content

Adoption Agile Agile2009 Agile Failure Agile in the Large Agile Tour Toronto Change Artist Christine Day Coaching Communication Container Craftsmanship Creativity Empathy Facilitation Fear Games and Simulations Hierarchy Kanban Kotter Leadership Lean Management Observing Organizational Change Organizational Culture People Personal Growth Production Product Strategy Project Management Red Pill Safety Scrum Strategic Play Teamwork Technical Practices Training Training from the Back of the Room Transformation Transition Trust VAST Vulnerability XP


  1. Arloe
    I saw your presentation at lssc10, and liked the detective blackboard approach, I have doing the same thing for my personal kanban that I use to track a range of tasks, from direct sales, to opportunity development , practice dev, billable work, etc….

    It’s really good for connecting the dots between a while range of stuff, and for a team fortunate to have onsight co located teams, complete control of the technology, and control of the political climate that may be all you need. Same goes with XP.

    Problem is, I live in a place called reality. Working with legacy systems and people can’t be avoided, packaged software (think sap or peoplesoft) is a major component on most big business rodmaps. Offshore is huge.

    Are these all ideal, no, but they are a huge part of the IT landscape.

    You have taken kanban, something that can actually universally provide value to all of these contexts, and made it as narrowly applicable as XP. Kanban appeals to me becasue it can help even stodgy big business get on the path to agility.

    This is not to say I don’t like your approach I think it’s a great practice for XP teams, I guess I think most XP teams are already quite good, if not excellent, I’m looking for help on getting others to become more XP like.

  2. Jeff, thanks for the comment. I think you are 100% on-target. The kind of world Arlo and Jim were describing is a very different place than many people inhabit.

  3. I always like that comment that I must be living in a different world. Everyone picks a different reason, but the statement is “because of constraint X, you live in a different world. That can’t possibly work for us – it is limited to a vary narrow scope of applicability”.

    Well, my world is full of legacy code – pretty much everone has a few million lines of really crap code, a very poor DB schema, no build process, no way to deploy a DB change, and political structures that make it impossible to ever remove anything from the schema.

    Also, most of them are playing with offshoring, usually because their teams aren’t that effective anyway, so the powers that be might as well pay less to get that result.

    My teams are filled with average programmers. They only become programming gods after a year or two of a good environment – it’s not that we have the chance at a good environment because we hire programming (or planning, or …) gods.

    In other words, my world is your world.

    The difference is that I look for what I can do to make that world effective. I don’t tolerate a lack of ability to change the database. I learn from others (eg, Ruby migrations, SqlAlchemy & Linq ORMs) how to make them malleable, and then do so. I don’t accept the politics; I ask why the assumption is present, then show how the tech advancements in the last 5-10 years make that deccision now invalid.

    And distributed teams is just one more assumption that turns out to be changable, because the decision to distribute teams is based on assumptions that are not based in fact. At the time the decision was made, there was a legitimate reason. Usually, it’s because there was a problem (low productivity, typically), so they decide to lower costs. However, there’s another solution: improve the effectiveness of the team.

    That’s the approach I take. It seems to work. In a lot of different contexts.

  4. Arlo,

    Thanks for you insightful comments and for clarifying my misunderstanding of your presentation.

    I think you highlight an important problem – are we engaged to adopt some Agile practices and get help a client get some improvements or to help them transform their group/organization. The statements “I don’t accept” and “I don’t tolerate” are consistent with a transformational approach. Sometimes clients understand and want this and at other times they don’t.

    – Michael

    P.S. I just had a question from someone reviewing my upcoming eBook on adoption and transformation ask me why I didn’t respond. I didn’t respond because, I consider Arlo’s comments on his own work to be correct and any discrepancies with my summary to be a mis-understanding on my part. I am responding now as there is apparently confusion around my lack of response.



  1. LSSC10 Keynotes on Process Models, Assumptions and Risk - [...] Elimination of Variability is Toxic. Great Product Development requires creativity, taking risks and encouraging failure. No errors means no…
  2. What’s better than Kanban? - [...] process. This is what Arlo Belshee and Jim Shore attempted to explained in their LSSC10 session Enough Kanban! Use XP…

Submit a Comment

Your email address will not be published. Required fields are marked *