Kit Friend is an Agile Coach, proud geek, and Atlassian Partnership lead for EMEA at Accenture (despite his enthusiasm, these views are currently officially only his own until his brainwashing program reaches its targets). In this Voices of OKR feature Kit explores the way a business can not only derive real value, but also measure it effectively.
Value! That most inarguable of topics for all modern enterprises – everyone agrees they need to be value-centric, everyone signs up for ‘embedding value in their decision making’, everyone keenly maps out a fancy value tree (maybe virtually these days), and then everyone quietly files that tree away and forgets to go and update it… sound familiar?
Whether compiling a gigantic waterfall business case (please don’t) or transforming an organization to agile (please do, but carefully and with proper support), every team agrees to make a laser focus on value core to the way they operate, but can often really struggle at how to make this part of how they actually run. We fall at the first hurdle, in that defining what we’re going to measure often comes too early and in isolation, and then stumble at the end of the race by neglecting to have any method or follow through to actually do the measurement.
Let’s view this through the lens of perhaps my favorite graphic to use when explaining cycle time, the wonderfully frank views of Dr. Klaus Leopold at Agile Greece Summit 2017 . Here we have the horrible reality of ‘agile’ development in many large organizations (with some slight censoring as you’re a new audience for me… for those less sensitive, enjoys its full glory!):
Now let’s consider the painful reality of where defining and measuring value typically fit in this cycle:
Surely there must be a better way!
As ever, the best solutions are routed in simplicity. So, how can we:
1. Minimize the cycle time between us ‘guessing’ the value of making things and finding out if we’re right?
2. Make defining and measuring value less painful?
3. Help teams use data to make decisions based on what they’re learning?
The answer to 1) is of course, our beloved world of agility, DevOps, and proper use of ‘MVPs’, ‘MLPs’,’ MMFs’ and alike – that is to say, an obsession with smallness and a willingness to put out imperfect products to get ‘real’ customer feedback. Even our best Product Owners, with the best fancy market research, are only human – we need to get their ideas for product and service enhancements out to real users as swiftly as possible to test and learn.
The answers to 2 and 3? This for me is where OKRs , and tools that support using them come into their own. By effectively giving our teams a method to visually and transparently build a network of metrics that politely force them to align their ideas to real numerical impacts, we can help them to make data-led decisions, and get into a habit of actually seeing how these decisions play out. A key-proving ground for this is ensuring that ‘shiny’ product features don’t automatically override the ‘less exciting’ economies your team might get via something like optimizing the cloud infrastructure they’re using. If your usage of data is correct, play out a scenario like this using your current prioritization process and see if an inarguably more valuable saving can make it through the gauntlet against an exciting new UI improvement without much quantifiable benefit.
It is of course worth coming clean that doing this well isn’t an exercise for spreadsheets – and indeed, in virtually every course I now (virtually) teach, I joyously share with students the advice of my treasured colleague Jon Pokroy of agilefixer.com which is something along the lines of:
Like never before, we have a vast range of tailored tools to help make this happen – and I promise you that the cost of them is vastly cheaper than the time and errors you will be incurring with the traditional range of enthusiastic manual munging of data in meetings and documents.
So – how to fix the mysterious quest for value? OKRs facilitated by decent tools could certainly be part of the solution – but more importantly, give it a go as quickly and roughly as possible – the feedback from a representative experiment is always better than a hypothesis.
If you liked this piece, find more from Kit:
- You can’t make a skateboard into a car
- Remote agility in a pandemic
- Starting agile with a recipe, not just ingredients
Looking to get started with OKRs? Try Gtmhub FREE for 7 days!