{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner

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

Related posts:

  1. Kanban for Video Game Production Clinton Keith gave an insightful session around designing and configuration...


Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks