A bit technical this one, bringing together some loose strands after the excellent Kanban Leadership Retreat in Reykjavik, Iceland (#klris):
Strand 1: This begins with Patrick Steyaert and I in conversation in the #klris hotel bar (the bar conversations alone were worth the plane fare!). I was talking about the way business valuations (as performed by financial analysts and as observed in the markets) depend on capability. Patrick uttered the one word “Intangible”, in reference both to the Kanban class of service (a heading for improvement work, experiments etc) and to the part of a company’s valuation that derives from brand and capability. Aha! Now I’m completely reconciled to the David Anderson terminology (whether or not he consciously intended this interpretation), thank you Patrick!
Strand 2: Maarten Volders repeatedly encourages me to bring Kano analysis and other models of product development risk into the way I teach classes of service. This idea resurfaced in a small session in Reykjavik on Kanban and Complex Systems (or “Mega projects and all the crap that goes with them”) led by Rich Turner. Perhaps you wouldn’t apply Kano analysis to (say) a defence project, but it is certainly true that the risks of these large projects are multi-dimensional. Maarten, you are right of course, thank you for forcing me to make the connection!
Strand 3: The timely publication of Alistair Cockburn’s post Agile in Tables. and in particular the first figure (under “Risk-Value-Tail table”). I will continue to draw a more S-shaped curve than Alistair’s but I like (and will use) his names for the curve’s three regions:
- Pay to learn
- Build business value
- Shine & gloss (aka the tail)
I like too Alistair’s risk categories:
- Business risk: Are we building the right thing?
- Social risk: Can these people build it?
- Technical risk: Will all the parts of our idea work together?
- Cost/schedule risk: Do we understand the size and difficulty?
To bring these strands together:
Alistair’s “Shine & gloss” might seem hard to justify in pure dollar terms, but try saying that to Apple! And history seems to be more on the side of the Toyota way than the Motorola way  when it comes to improvement. More broadly, the mindset of striving to minimise all work outside the “Build business value” category seems at best simplistic, at worst blinkered both to risk and to the bigger economic picture. Rather than minimise or ignore these other aspects, it seems much more useful to make choices and policies explicit and invest carefully across classes. A portfolio-based approach if you like.
 “No Six Sigma project is approved unless the bottom-line impact has been clearly identified and defined” – Pros and cons of Six Sigma: an academic perspective /via Wikipedia