This is my interpretation of what he said (from memory) so it may not be quite right and he's probably refined it since then.

Running the whole company in an "agile" way

Essentially FlowChain scales agile practices up to the company level. There is a single (large) development team that works from a prioritised backlog of MMFs (Minimal Marketable Features). I'm not sure who manages the backlog. I've called it a "product strategist", but that's my name for it not Bob's.

The team works on multiple value streams. Each value stream has its own operations staff.

Zooming in:

Extreme flexibility

What I like about FlowChain is the flexibility it provides. If a value stream is doing well, resources can quickly be redeployed to capitalise on its success. Alternatively, new products (value streams) can be developed. In most organisations, moving developers from one project to another is a major upheaval, and that puts pressure on the project to be a success. When you can move developers quickly to something else, it relieves the pressure and allows the company to tackle more risky (but potentially more lucrative) opportunities.

Note that in a large company, the pool of resources for developing products could be very large, and there may therefore be many MMFs in progress at the same time. Bob didn't explain how to resolve resource conflicts, sequencing etc. We may have to wait for his book...

3 comments:

I would think that multiple products could use the same valuestream, provided they go through the same (or very similar) process?

You might also subdivide each valuestream into parallel flowpipes, based on size/complexity/degree of customisation, so large lumpy value items don't block the pipe and slow down the small and many items.

In case you're interested, you might like to know that I just published a new blog post looking at FlowChain from the perspective of a System of Continuous Improvement: http://flowchainsensei.wordpress.com/2013/08/10/a-system-of-continuous-improvement/