Craig Watson (@craigowatto) 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.
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.