Kanban’s Geological Record

Kanban's Geological Record

Craig Watson (@craigwatsonuk) from SkyBet.com has been hoarding away the cards that flow across his teams card wall for many months. He’s kept them in the exact order they were completed. Craig explains “it’s like a geological record of the Kanban system”. As a very general guide, blue cards are platform related, yellow cards are new features, and pink are defects / tech debt. We see a lot of pink throughout the record which for me is a healthy sign that trade-off decisions (aka tech debt) and live defects/incidents are getting the attention they need. We can see bands of yellow and blue throughout the record signifying a specific change in selection policy for work entering the team. What’s the basis of these decisions and how visible are these policies across the organisation? Are they purely reactive decisions based on whim? Is service interruption driving the prioritisation? What if we get to the end of the fiscal year and all investment has been spent on blue cards – which might deliver a highly resilient, defect free platform but no value to the customer? Eek!

What Craig has done here is demonstrate the important role metrics can play in the upstream decision making process. Andy Burton (SkyBet CTO) introduced an investment model described in a recent McKinsey & Co article  that talks about spreading your investment portfolio, not just on the shiny new stuff but to aim for a well balanced investment portfolio across three themes.
investment buckets

The three themes are Customer (new features and incremental enhancements), Back Office (the tools that underpin processes to drive operational capabilities), and Platform (aka keeping the lights on and servicing the aftermath of trade-off decisions). If you short change any one of these pots over the others then you have consequences to deal with. These consequences will usually hit you directly in the pocket in the form of system downtime or customer dis-satisfaction.

These themes can be traced directly to Craig’s geological record. What if we visualised our WIP using coloured cards aligned to these investment themes? What if we used Kanban’s classes of service to govern the allocation of capacity to each investment theme? What if we used the following graph to show the effectiveness of our selection policy and classes of service and call the decision making policy to account?


I really like the concept of the three investment themes. I like it because all to often I see teams and organisations focusing too much on the next big customer facing feature whilst development teams are left demoralised picking up the pieces of short changing platform related demand. I also see operational teams managing their work through spreadsheets because the back office tools are short changed.

As for future investment needs, just look at the backlog of work – assuming you visualise your demand. If demand is outstripping supply (which is the case for most orgs) and your backlog of “platform” demand is growing then this is a signal in the system to trigger conversations at every level in the organisation.

Now thinking about your own organisation, what does your investment spread look like? 33/33/33? 10/80/10? 0/0/100? Do you even know?

As a bit of background, this team is very mature in the use of Kanban. That is, they make all work visible, limit their WIP, make process policies explicit, and use data driven retrospectives to continuously adapt. Small batch size, frequent releases, optimised for flow, and underpinned by metrics to support the retros and decision making. They visualise their backlog in a way that enables informed upstream decisions enabling the shaping of demand for end-to-end flow optimisation. Using these techniques enables them to improve quality, gain greater efficiency, and get an overall better return on investment.

Footnote: Investment themes are not a new concept in this space. A key concept from the (to quote Martin Fowler) “Shitty Agile Framework for Enterprises – SAFe” is investment themes. But what I’ve not yet seen across the many teams struggling with SAFe is how to put the investment themes into practice, at all levels in the org, that’s easy to understand. I hope this article shows a practical implementation of how investment themes can be used for product development no matter what methodology or framework you’re using.

4 Comments on "Kanban’s Geological Record"

  1. I really like this article as it’s particularly prevalent in the environment within which I operate – we’re an agency who build, support and maintain products for our clients and I personally have to deal on a day-to-day basis with the constant drive from my clients to push for more and more features as a high priority to the detriment of back office processes and maintainability. This is because it’s where my clients think the value lies – for instance more features to increase sales – but they leave no space to deal with technical debt or back office processes which can lead to frustrations for both parties (eg: more bugs / poor performance and a back office that requires a developer to help perform tasks or an understanding of system ‘quirks’ that tend to be passed on verbally).

    I think that part of the problem is that people who aren’t experienced in software development don’t actually accept that a thing such as technical debt exists in the first place. They expect to pay a fee and for the perfect code to materialise which never has to be refactored or touched again (of course a fallacy but all the same it’s what people think). For the backoffice stuff, I just think people are willing to sacrifice these aspects for more features and to start with it’s OK, in fact to start with it makes sense (MVP) but it’s easy to fall into the bad habit of always sacrificing back office for more features and it’s possible to sleepwalk into big problems.

    Your post is a great way of explaining and visualising this problem and being able to do something about it by weighing up the balance between all three elements and it’s certainly going to help me. THANKS!

    • Kirsten, trade-offs come in all sorts of shapes and sizes such as tech debt, dropping features, MVP, etc. Blind trade-offs are very very bad. A blind trade-off is when you make a trade-off but don’t capture it and make it visible. Trade-offs are a critical tool in product management but only if it’s managed and tracked. I urge all teams to capture trade-off decisions and visualise them in the backlog. Some teams I’ve helped go through a “Bring out your debt” exercise. Simply visualising this stuff and reporting on it has a tremendous impact on selection policies and prioritisation.

      Thank you for the comment and feedback. Glad you found it useful.

      • Thanks, I couldn’t agree more re: trade-offs. The issue arrises in my world at least when a client is trying to determine the terms of the tradeoff and it’s for me to interject to manage that tradeoff which I have to admit I haven’t always done brilliantly in the past (wanting to please short term goals). But I am now, though experience, and having seen the negative impact, much more conscious. I really like your / Craig’s way of visualising and quantifying the balance and will give it a go.

  2. Reblogged this on Sky Bet Engineering and commented:
    Ian Carroll has been working with SkyBet to improve our Agile processes. Read his thoughts on balanced investment in a growing business using Kanban.

Leave a comment

Your email address will not be published.