Book: Succeeding with OKRs in Agile (2nd Edition)
Author: Allan Kelly
Part: I — Why OKRs
Chapter: 2 — Why use OKRs?
Reading time: 9 minutes
Tags: okr-benefits mid-term-planning test-driven-okrs team-communication psychological-safety okr-fundamentals agile-planning-gaps bottom-up-engagement okr-failure-tolerance quarterly-planning sprint-okr-integration focus-and-prioritization
Summary: Kelly argues that OKRs fill a critical gap in agile planning between short-term sprints and long-term vision. He presents three reasons OKRs fit agile: they provide mid-term planning, they embody a test-first approach to goals, and they enhance team communication. The chapter warns that OKRs require psychological safety — teams must be free to aim high and miss without punishment.
Previously, this realization would have resulted in replanning to move out the target schedule, perhaps repeatedly. Instead, given the group’s commitment to the larger result, we found a much more aggressive behaviour. For example, the OpenVMS AXP group publicly committed to their target schedule and stated, “We don’t know how to achieve this, but we commit to finding a way.” The next day they went to a project management consultant for training on how to build an aggressive, attainable schedule.
Peter F Conklin, director of Alpha AXP Systems Development¹
Objectives and key results – OKRs from here on – did not start life as part of the agile toolkit. Indeed they predate ‘agile’ by 20 or 30 years. Yet in recent years they have received more and more attention in agile circles. More companies and teams are experimenting with them, and it’s no longer uncommon to find them used by agile teams. They may not quite be a standard item in the agile toolkit, but I wouldn’t be surprised if they become one.
Why? Or perhaps, what makes OKRs a good fit with agile working?
To my mind there are three reasons why OKRs work well with an agile approach: they fill a need at the mid-term planning level, OKRs are essentially a test-first approach, and OKRs enhance communication.
If OKRs sound too good to be true – and reading some authors, they can sound like that – then rest assured: OKRs can go wrong in many ways. The laser-like focus OKRs create needs to be tempered with countermeasures.
2.1 Mid-term planning
OKRs fill a hole in the agile planning processes that many teams struggle with. By planning, I mean planning in all its forms – software, UX and test design, coordination and scheduling.
¹Enrollment Management, Managing the Alpha AXP Program, *Digital Technical Journal Vol. 4 No. 4 Special Issue 1992
Agile, and in particular Scrum, has plenty of short-term planning tools: the morning stand-up is a form of daily planning, Scrum and XP teams will have regular sprint/iteration planning meetings, and retrospectives are also a form of planning.
Teams usually have some long-term plan too – although these are usually independent of the chosen agile framework.
A team may have a long-term plan or a roadmap², a mission or vision statement, a business plan or statement of the market opportunity, maybe a job to be done, or a customer problem the team is addressing. Such plans usually start beyond the current quarter and may look years into the future.
However, in the middle ground lies a problem. There is no standard way of thinking about the mid-term, the period beyond the sprint but a little longer than the quarter.
Once upon a time teams created ‘release plans’ that showed what they planned to ‘release’ (or rather, build and release) during the next few weeks. For some teams that might mean sketching what would be in each of the next six release over the coming quarter (that is, three months, 13 weeks). Or it might simply be a list of what was to be included in a release that only happened once a quarter.
However with widespread adoption of continuous delivery, release plans make less sense. What is the point of a 13-week release plan when a team releases many times a day?
Other authors have suggested other solutions. I myself have advocated ‘quarter plans’ – that is, the plan for the coming quarter of the year³⁴. I and others have tried to sketch what a process would look like around that, but since there has not been consensus on ‘what is the right thing to do’, few of those solutions have become mainstream.
OKRS offer the opportunity to fill that gap and provide the glue between the short-term daily and sprint planning and long-term plans.
OKRs potentially provide a way of balancing the demands of here and now with the need to steer some kind of course. By focusing on the quarter OKRs can provide mid-term goals, consistent enough over several sprints to achieve meaningful results, but flexible enough not to mislead the team.
²Roadmaps suffer from several problems themselves. All too often they are little more than a list of features with speculative dates against them.
³The Art of Agile Product Ownership, Allan Kelly, Apress, 2019
⁴An Agile Reader, Allan Kelly, LeanPub, 2017
Quarterly, three months, 12 weeks
In just about every case I have heard of, OKRs are reviewed and updated quarterly – four times a year. I can imaging using them on a shorter cycle – every six weeks maybe – or on a longer cycle, perhaps annual – but the consensus seems to be quarterly.
Quarterly seems about right; three months is a good balance between thinking more strategically and getting on and doing it. It implies sticking with something for long enough to see whether it works, but not so long that one is flogging a dead horse long after it has stopped breathing.
However, companies already make heavy use of quarterly cycles for things like budgets, sales targets and performance reviews. There is a good case for not adding another process on the same cadence. A ten-week or four month cadence might work better for OKR cycles. This would also avoid coupling OKRs to things like performance reviews.
2.2 Test-driven OKRs
Finally, one reason why OKRs work well with agile is that OKRs are a high-level implementation of test-driven development. I sometimes think of them as ‘test-driven management’. Consequently they sit well with the agile mindset.
Each objective (the ‘O’) has a set of key results: the ‘KRs’. Each of these key results is a test: has the result been achieved?
Each key result should be measurable. One should be able to look at the key result at the end of the period and say: did we achieve it? Or better still: how much did we achieve? How close did we get?
In other words: right at the start of the period, when setting the KRs, people are thinking “How will we know that this is done” and “How will we test that this has been achieved?”
Anyone who has practiced test-driven development at the unit test level, written acceptance criteria for a user story, or sketched a BDD-style scenario before any code is written will recognize this approach. This is what agile calls test first.
Test-first works well for at least two reasons. First, a test-first approach creates focus – yes, focus again! By knowing the tests that the work must pass to be successful, one is able to discount some work and measure progress towards the desired result. Anyone who
has written automated test cases that show as green and red result bars will know the motivational power of such a feedback loop.
Green means success, and you want more success!
Red means something failed and it’s damned annoying – you want to make it work!
Either way you get a dopamine hit and are motivated to carry on – fix the red thing or add more and get more green.
The second reason test-first works is because it tells you when to stop: stop when the tests pass.
Given any piece of work there is always a temptation to keep doing more and more – particularly when there is a positive feedback loop in place. Yet doing more and more means you will do more than is required – the famous ‘gold plating’ that managers believe software engineers regularly engage in.
My friends Jon Jagger and Kevlin Henney like to ask: “Why do cars have brakes?” Most people answer the question “So you can stop!” or “So you can drive safely.” Jon and Kevlin like to say: “So you can drive fast.”
I vividly remember the day the brakes failed on my first car. Or rather I remember driving my car to get the broken brakes fixed. The car – the engine – worked, but I had to navigate traffic lights and a hill between my apartment and the garage. As the car had manual gears (that’s a stick shift for American readers), I could slow down by changing down (although I pretty much stayed in first the whole way) and use the handbrake to stop. Needless to say, I drove very, very slowly.
When you work test-first you don’t stop until the tests pass⁵.
That is true at the unit test level, the story level, and – with OKRs – the business objective level.
By the way, if you want a third reason why test-first works, let me add: it forces you to think about what you want in advance. While that is true, I think the first two reasons are far more powerful.
⁵Although when coding after the tests are passed, you probably engage in a little refactoring. Refactoring is essential, but knowing when to stop refactoring can be hard, simply because there is no test to tell you when you are done.
2.3 Communication
By summarizing the work a team has done and will do into a standardized format, OKRs make it easier to communicate what a team is doing. I like to think of OKRs as creating an interface, or API, for the team. That might be for communication within the team, with other teams, or to managers higher in the hierarchy.
Similarly, the standardized format simplifies status reporting. Today, everyone knows that ‘percentage of requirements done’ is a meaningless metric: teams need a way of showing what they have achieved in the current period, what they are doing now and what they (hope) to work on next. OKRs offer a way of summarizing this information.
Because OKRs offer a means of communicating status and progress, they also offer a mechanism for judging success and failure. Success motivates continuation – “More of the same please!” – while failure motivates change: “Don’t let that happen again!”
A team API
The team, especially the product analysts, listen to what the senior leaders say about purpose, strategy and company objectives. They also listen to what customers and the market want. And they listen to the needs of peer teams, the product itself and many other sources of work requests.
Each cycle the team responds with OKRs which form an API - application programming interface. This API tells others the outcomes to expect from the team in the coming cycle. The API sets out what the team will aim to achieve, what they will forego and the priorities. There may be some negotiation during the setting process but once the OKRs are set the team is trusted to do their best.
OKRs create an API for the team
2.4 The team
In addition to communicating outside a team, OKRs enhance communication inside it. OKRs build a shared understanding and goals, and thus create a vocabulary for discussing work.
This first happens in OKR-setting, where team members have a voice about what is being proposed and how the goals are formulated. In creating focus and common goals OKRs bind the team together – more about focus in the next chapter.
Of course, such benefits depend on teams playing a role in OKR-setting. Unfortunately, where companies impose OKRs from outside the team, such benefits are lost. (Chapter 25 has more on cascading OKRs.)
2.5 Warning
Few things in life come with no downside, and OKRs carry certain risks. I’ll dig into some of these risks later, but right now I want to make it clear that OKRs are not risk-free. Like any powerful tool, OKRs entail certain risks: the more you understand the risks, the better you will be at avoiding them.
Sometimes the right thing to do is throw the OKR away and work on what is in front of you. If your live server goes down and customers are without services there is no point in saying “Sorry guv’nor, I’m working on my OKR.” OKRs create focus, but they shouldn’t create blindness.
That philosophy extends to the results too. I’m going to argue that OKRs should be measurable, but not everything that counts can be counted. Not everything that is important can be mapped out in advance.
Consider your life partner, or, if you are single, think of your parents. When choosing to spend the rest of our lives with one person, who draws up a requirements list?
Actually, Charles Darwin did. Reportedly Darwin drew up a list of pros and cons for marriage. Cons included:
- ‘Being forced to visit relatives, and to bend in every trifle’
- ‘Loss of freedom to go where one liked, the conversation of clever men at clubs’
- ‘Terrible loss of time’
Still Darwin concluded:
It is intolerable to think of spending one’s whole life, like a neuter bee, working, working – only picture to yourself a nice soft wife on a sofa.
He ends his notes ‘marry – marry – marry Q.E.D.’ ⁶
Darwin married Emma Wedgwood in January 1839, a little over two years after completing his journey on HMS Beagle.
Even though I, and possibly you too, like to think of ourselves as rational people when it comes to big life decisions, rational tools are often abandoned. Life partners, whether to have children or not (and how many!), divorce (Heaven forbid) and even buying a house are more likely to come down to emotion rather than rationality.
As humans we sometimes do things not because they are rational, but because we want to. Call it intuition or motivation. If we only did things that we could justify rationally (before the event) life would be boring and in time machines could probably replace us. Sometimes the important thing is what do we want to do?
2.6 Summary
- OKRs create focus.
- Set and reviewed on a quarterly basis, OKRs fill a gap in agile between sprints and roadmaps.
- Being test-first in nature, OKRs fit well with the agile mindset.
- Some things are more important than OKRs, and sometimes those things can’t be measured.
⁶Darwin C, The Autobiography of Charles Darwin, ed. N Barlow, London, Collins, 1958 and quoted by John Kay, Obliquity, 2011