How to combine Agile and OKRs
Agile and OKRs Coach Allan Kelly offers practical guidance on how to combine Agile and OKRs.
Thou shalt use OKRs
So you've spent the last three years getting agile. It hasn't been easy, you've gone down some dead-ends, some team members have been over-enthusiastic and others downright awkward. But you got there in the end.
And then some bright spark in head office decrees "Thou shalt use OKRs". You rush out and buy Measure what Matters, you read a bunch of blogs. You buy into OKRs, you see them to your team. Again some are super enthusiastic and others cynical.
There is just one catch: while everyone tells you how great, OKRs are nobody tells you how to actually use them at the coal face. Specifically, nobody talks about using OKRs in agile teams.
Do you need agile if you have OKRs?
When you first look, OKRs look a lot like agile: planning and review, although with 13 week quarters rather than 2-week sprints, breaking down objectives to key results is like epics and stories, and so on. Yet that similarities can also lead to conflict. Do you need agile if you have OKRs? If you run both which takes precedence? And if you run both surely that increases the time that goes into planning and administration?
Then there is the question of self-organization: how can OKRs imposed from above be compatible with autonomous teams who are expected to self-organize?
Cascading OKRs down from above runs counter to agile. It is easy to see OKRs as the return of command-and-control. But it is also possible to use OKRs to enhance autonomy, support and enhance agile working and move teams to a greater alignment and even greater productivity.
Enough questions, let me give some answers.
First off: Yes, agile and OKRs can work together, and work well. In fact, OKRs fill a gap in the agile toolkit - the middle planning horizon - and at the same time enhance team autonomy.
The key is for OKRs to drive your agile machine. OKRs are not a management paradigm competing with others - like agile and traditional project management - within your organization. OKRs are THE management paradigm.
If you try to reach milestones on project plans, while simultaneously trying to burn down the backlog and meet OKR goals then someone - and some paradigm - is going to be unhappy. More likely you will make a little bit of progress against everything but achieve nothing.
I'm sure that if you put in enough effort you could reconcile all three approaches, align the goals and synchronize the outputs but, why bother? Doing so will increase your workload and your admin costs.
Making OKRs your one management paradigm
Making OKRs your one management paradigm means everything is oriented towards delivering OKRs. Agile and OKRs form a symbiotic relationship to support one another.
From an agile point of view try to see OKRs as *test first management*. At the start of the quarter, the team agrees on the outcome it intends to deliver. That outcome is bounded with key results. When you look at OKRs like this, the key results look a lot more like acceptance criteria than smaller goals building towards an objective.
Now as with any good agile process you want to limit WIP (work in progress) so limit the number of OKRs you are aiming at. As a rule of thumb, I'd say three objectives each with three key results. But as you twist that thumb you can make me agree to four and four. All the time though I'd rather you had just one objective.
Agreeing on OKRS
Notice too that I say the team agrees on the OKRs? - in an agile environment, with empowered, self-organizing teams, where authority has been pushed all the way down that is the only way it can be. Sure the product owner may take a lead in setting OKRs - they are the expert in what customers and stakeholders value - but it is the team that should set, write and agree on OKRs. It is the team who must deliver the OKRs so simple fairness demands they have a voice in setting the OKRs.
Teams shouldn't be handed OKRs from above, teams are autonomous and authorized to do the right thing. Ultimately it is customers and the market that decided the answer to that question. But in anything other than a small start-up teams are going to need to align with other teams and business strategies. Still, that is no reason to hand out OKRs.
Rather than telling teams what to do, leadership should be asking the teams to help. The role of leaders is to set out the destination and a strategy for getting there. They then turn to the teams and ask: "how can this team help?" It is then up to the teams to reply with OKRs which draw on the team's areas of specialty and help the organization move towards the goals.
The 13-week super-sprint
Now you have your OKRs it is time for the 13-week super-sprint. Within the super-sprint, you will want to run your regular sprints. For most teams that will be every 2 weeks although I have a penchant for 1-week sprints.
Each sprint is an opportunity to return to the OKRs and focus again. Review where you are at, tick those you have completed and recommit to what needs to be done. Decide where your focus will go, a little bit against every objective? Or the full team on one? Making progress against OKRs needs to be the driving force in deciding what to do in every sprint.
At the end of the sprint, it's time to take stock. Update any tracking mechanism you are using and include OKR progress in your sprint retrospective.
The question of the backlog
Now, this raises the question of the backlog. There is one school of thought which says the OKRs are used to select work from an existing backlog. This would imply the backlog is well defined, perhaps nearly complete, and the backlog has primacy over OKRs. Certainly, if you find there is work needed to meet an OKR and it is not in the backlog write it out, quickly put it in the backlog, and select it.
Now there are two implications of this approach. Firstly, if OKRs are only used to prioritize the backlog then by implication "doing the backlog" is the measure of success in which case what do OKRs add?
Secondly, if the backlog contains "all the work to be done" then OKRs need to be set by reference to the backlog. Instead of thinking hard and asking difficult questions, one can examine the backlog and craft OKRs to describe what will be chosen from the backlog this quarter.
This is a missed opportunity. Too many teams today are lost in backlogs which will never be done. "Doing stuff" has become the goal, any strategy or longer-term goal has been lost in the tyranny of the backlog.
Another school of thought holds that the OKRs have primacy over the backlog. That success is not so much about "doing backlog" and more about achieving OKRs that add value to our businesses. In this case, the backlog is little more than a collection of good ideas that may, or may not, add value and advance OKRs.
I've had the opportunity to try both approaches and I firmly agree with the second school. Make OKRs the priority, every quarter set OKRs not by reference to your backlog but by thinking hard about what will add value, further the mission of your team, and advance the company's purpose.
Throw your backlog away!
In fact, I would go as far as to say: Throw your backlog away, you have nothing to lose but your burndown charts.
That idea might be a bit too radical for many but the underlying point still stands: OKRs derive from mission and backlogs are a collection of ideas.
Treat your OKRs as story-generating machines that you use just-in-time to create the stories you need to advance towards those objectives.
Relegating the backlog like this forces you to return to your OKRs when deciding what to do next. That might make life a bit harder but it guarantees you revisit your OKRs and think about how to move forward regularly.
What real OKR success looks like
At the end of the OKR cycle teams need to step back. Review what they achieved, what benefit they added; review the OKRs they completed and didn't compete, and hold a retrospective on what could be better.
Ultimately success is not completing 100% of OKRs. Success isn't even achieving 70% of OKRs, or 65% or 80% or any other number. OKRs are hypotheses about what is expected to add value, sometimes the best way to test that hypothesis is to act on it. Real success is creating benefit, success is learning, success is moving forward and improving.
Allan Kelly wants professionals to enjoy more fulfilling and satisfying work. He advises teams and leaders on using agile and OKRs to improve the way work is organized. Happier people and better ways of working make for more effective companies and superior outcomes.
Despite being dyslexic he has written seven books - his latest is "Succeeding with OKRs in Agile". Between agile coaching and writing books, he regularly appears in podcasts and as a keynote conference speaker. His website and blog are at http://www.allankelly.net.