Positive Incline Mike Burrows (@asplake) moving on up, positively

July 12, 2011

Intangibles, value and risk (or: Portfolio thinking)

Filed under: Kanban,lean,Portfolio,Project Management — Tags: , , , , — Mike @ 2:58 pm

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:

  1. Pay to learn
  2. Build business value
  3. 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 [1] 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.

[1] “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


  1. Hey Mike,

    I enjoyed the conversation too! It seems funny that there appear to be intangibles at both ends of the spectrum. Or at least two interpretations. When I was talking about intangibles, I was really thinking about the features that are needed to build capabilities into your system. Platform stuff, refactoring, etc. The “pay to learn” stuff in Allistair’s curve. They do not have tangible business value in the near future (hence the name intangible). There might even be a conflict about the value versus cost of these feature, so you might even call them sensitive.

    I completely agree that a good balance of investment is mandated. In portfolio terms, the policy to achieve this balance should be based on your risk profile. This risk profile might be very dependent on where you are in the curve of your project. You might want to take more risk in the pay to learn versus the shine and gloss region.



    Comment by Patrick Steyaert — July 13, 2011 @ 6:55 am

  2. Hi Patrick,

    Yes, it seems that there’s intangible work all over the place! I’m not sure that I would treat those elements of “Pay to learn” that are prerequisites to planned value-driven work as intangible, but there’s no doubt that there are still some very interesting things there, including risky work that may (or may not) turn out to create new options for the future – we enhance our capability if we keep doing enough of these. And yes of course improvements, refactoring etc are definitely capability-building activities.

    But let’s not nitpick over how work is classified and lose the simple message. You can’t compare unlike pieces of work and expect come to a sensible binary priority determination. Investing over time across categories sidesteps that problem quite neatly.


    Comment by Mike — July 13, 2011 @ 7:45 am

  3. Hi Mike

    Nice post.

    I would caution against using the term “intangibles”. It is an accounting term with a very precise definition. Brands and Goodwill fall into the intangibles bucket.

    Financial Options are not intangibles. They fall into the assets/liabilities part of the balance sheet. Try thinking about these things in terms of options. It may help.

    Unfortunately the Kanban community seems to be falling into a “Knowing the cost of everything but the value of nothing mentality” mentality. Lots of costs… Cost of Delay, Cost of Quality, Cost of Learning. Unfortunately as a community they have not put much effort into understanding value. Sadly they ask Don Reinertson to keynote on Flow when his experience with value would be much more useful to the community.

    You seem to be on the right track by thinking about portfolios… but try portfolios of options. The “Pay to learn” is in line with traditional real option thinking, especially if you look at drug development. It is also in line with Microsoft’s strategy in the early 1990’s.


    Comment by Chris Matts — July 20, 2011 @ 10:46 am

  4. Hi Chris,

    Thank you very much for commenting. I very much like the idea of regarding work as options – if I can’t persuade the community to drop the term “backlog” I can at least keep on describing it as a list of things we *could* do!

    I don’t want to get into too much debate about terminology (and I can get picky!) lest it cloud the more interesting question: can we describe how portfolio thinking (with classes of service as one set of portfolio dimensions) and options thinking lead us to work differently and to what different outcomes, with respect both to each other and to traditional approaches? Much of what you write encourages me to think that we may be converging on something, in mindset if not in the detail of work practices.

    I agree with you about the cost/value mentality issue. What I am arguing here is that a narrow a view of value can exclude some subtle forms that might (if only they are given the chance) lead to significant things in the long term. I’m also fond of reminding people that burn rate is usually/mostly constant in the short term, so of all the things to optimise for, cost is perhaps the least effective! Cost of Delay however is unrelated to burn rate; really it sits on the value side of the equation.


    Comment by Mike — July 21, 2011 @ 5:22 pm

  5. Hi Mike

    I do find it ironic that a community called “Agile” can be so resistant to change. In particular some of them are good at avoiding things that disagree with their world view or that they do not understand.

    I have heard it mentioned that classes of service are a “risk management” technique. I think it is a useful prioritisation technique for describing the behaviour of how BVI travel through a value stream. I have not seen anything to explain how they can be used as a risk management technique apart from the risk that someone works on a lower priority item. Perhaps you could point me to something that explains.

    Really classes of service differentiate between commitments (bugs and external commitments) and options. There is allways the option to ignore a commitment and incur the penalty instead.

    Looking forward to see a good reference on how cost of delay can be used effectively.

    I agree that we seem to be converging on something. I think cost of delay was a means to appropriate option thinking without mentioning options.



    Comment by Chris Matts — July 21, 2011 @ 5:56 pm

  6. Hi Chris,

    “Appropriated”, or a case of convergent evolution from different starting points? A bit of both most likely.

    One problem is that we seem put each other off the more tightly we try to define things within our own set of terms. Doubly ironic if we have been mutually suspicious of an over-dependence on quantification seen in the other?

    “Risk management technique” is definitely too strong. A recognition that there is danger in doing too little of some kinds of work (a counterweight to “limit work in progress” even), that there is benefit in creating slack, that effective scheduling systems can be made explicit (as opposed to being only in the brain of the manager, or worse), that faced either with long lists or with not enough risk analysis it can be helpful to categorise. None of this is new, but I think it’s good to see it bundled into a teachable package, and so much the better if we can do it in an inclusive way.


    Comment by Mike — July 21, 2011 @ 6:44 pm

  7. Hi Mike

    I think we might be converging indeed.

    Making the decision process explicit (instead of in the brain of the manager) is an important risk management technique as it allows us to test (break) the model with examples/contexts that the manager never thought of.

    I agree with the need to bundle it for teaching.

    A good point to pause before the Belgium thing.


    Comment by Chris Matts — July 22, 2011 @ 9:10 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress