Insights are often unveiled in casual conversations we have with clients, colleagues or friends – a point in time where both parties realise this is important stuff, and most people are struggling with it. These insights don’t wait for formal engagements – they happen over coffees and on couches. Our ‘couch coffees’ is a continuing series of posts where we’ll publish some of these insights – simple, short and sharp. They might be second nature to some; for others, they might be closer to epiphanies. For most, we hope they’re simply nudges in the right direction.
We’ve been working with a client over the last few months to assist in marrying their agile methodology and their OKRs. They are a great client to work with, with engaged employees at all levels and setting out to solve touch challenges. Due to their level of engagement, we’ve discussed these challenges during many interesting conversations (and sat and listened to many more).
This Agile-OKR marriage is a complex and intricate challenge. What’s more, there is no simple, singular solution. We are convinced that the solution will be unique to every organisation. This should be no surprise, as implementing OKRs is unique to every organisation – and now you add a healthy dose of agile to that which leads to exponentially more possible iterations!
Agile has learnt the lessons
One striking revelation we’ve had is that in so many ways, OKRs is to strategy execution what the agile methodology was to IT implementation 20 years ago. And so in many ways, we’ll see similar solutions as well as similar hurdles. For example, both encourage adding value as a priority. Both welcome changing requirements as we learn. They promote an empowered workforce. And both recognise the value of continuous learning through regular reflection.
Another element that both drive in different ways is reduced batch sizes. In agile, this principle is to “Deliver working software frequently”. Whereas with OKRs, we see this in the charge for a quarterly cadence (or some similar timeframe, but less than the typical one-year planning cycle we’ve become accustomed to).
In our experience, this is one of the hardest elements to crack. Teams that are used to longer-term, strategic projects find it challenging to think in small batches. To think about the measurable business value they can add in the next quarter or the next sprint. In OKRs, we often see Key Results like “write a business plan” or “present to the executive committee”. Although they are a good start, they leave the reader wanting to understand the business value that will be added.
Some reasons why Agile recommends small batch sizes
Why are small batch sizes better? Without trying to be comprehensive, here are a few reasons:
- It reduces work in progress, which means “assets” spend less time on the sidelines
- This also means customers experience the value quicker
- And consequently, the hypothesis can be tested faster
- Little’s Law proves some of this, and all of it frees up mental capacity, leading to increased focus and reduced stress
Simple tips and tricks
There’s no simple answer to implementation – if there was, we would all be doing it. Here are a few
- Start Small
- Agile would recommend starting with the smallest deliverables and work from there. For OKRs, we’d say prioritisation is key – pick the most important objectives, and work on those.
- Release Often
- This will require a focus on one or two goals for a cycle. And it might require collaboration. In that time, work to get a shippable product out – something that adds measurable business value.
- Test Hypotheses
- Write a statement of what you want to test – in OKRs, we’d say these are the Key Results. What is the required outcome of a piece of work, or a piece of functionality? Then do the work, score your outcome (or test your software), and reset for the next cycle.
These methodologies get better and smoother only through practice, but there are numerous things that OKRs can learn from the agile methodology. And there are numerous ways that they can work together. For example, Marty Cagan, founder of Silicon Valley Product Group, would recommend OKRs as an alternative to product roadmaps. Maybe we’ll explore this a bit more in some of our future couch coffees!
If you have questions, we’re always keen for coffee.
Get in touch so that we can brainstorm a few solutions together!
