Approximately once per week someone asks us how do OKRs fit with agile product teams and do they even fit at all.
There is a great article written by Felipe Castro that explores this particular problem and I cannot recommend it enough.
Whereas Felipe looks at the matter in a holistic way, in this post I am going to explore more practical aspects from the perspective of an engineering team.
Presumably, if you made it so far through the post, you are familiar with OKRs. If you need refreshing, you can read Anatomy of an OKR: How to set your OKRs post which provides a hands on guide. It also has some fancy infographics.
The basic idea is that OKRs link your efforts to the overall goals of the company – and that’s a good thing – read on.
OKRs, when implemented correctly, can transform a business for the better and that, in itself, is a benefit for the engineering team. But it does not stop there. OKRs really do enhance the agile itself – they are not an alternative, they are an add-on.
We all know how much “fun” it is to plan a sprint. Open Trello, Github, JIRA, Aha.io or whatever is your choice of poison, look at the 3000 stories, bugs, ideas, issues and then figure out what to do next sprint with your limited resources. OKRs don’t tell you what you should do, but they do provide a transparency in terms of what should be achieved – they provide objectives – and that is a great triage tool. If your objective is to improve the performance of the application, that narrows it down quite a lot. If your objective is to increase engagement, that again narrows it down.
Communicating your intentions
I am not sure if you ever tried to explain to an MBA why you need to reduce the cyclomatic complexity of a particular module, but trust me – it’s right there next to asking a tree to move out of your way.
What OKRs allow for is to keep the implementation details where they should be (with domain experts) and instead translate “what are you going to do?” into “why are you going to do it?” (or in MBA lingo “value”). For example, you could say that your objective is to reduce the onboarding of junior developers from 12 weeks to 8 weeks, and to do that you will reduce the cyclomatic complexity by 10%.
Bonus point here is that you’ll have to first explain to yourself why you want to do something – it’s not that we, as developers, don’t sometimes do things for the sake of it (or as we often put it “to come up with a more elegant solution”).
One of my favorite quotes is that of Jim Barksdale, CEO of Netscape. If you haven’t heard of Netscape, it’s like what AltaVista… never mind, forget it – he is a smart guy.
If we have data, let’s look at data. If all we have are opinions, let’s go with mine.
Jim Barksdale, CEO of Netscape
At the heart of OKRs are quantifiable key results. There are many ways to skin a cat, some work better some worse. OKRs allow you to learn which ones work and which don’t and then use that data to make objective decisions.
For example, let’s say that our objective is to improve the stability of the application. There could be many opinions on how to go about that.
- Hire more QAs – they’ll find more bugs
- Hire more Devs – they’ll fix more bugs
- Write more unit tests – there will be less bugs
- Write less features – no new features, no new bugs
- Buy it, don’t build it – outsource your problem to someone else
- Use open source, don’t build it – crowdsource your problem to someone else
All of these options could make sense in given circumstances, but you don’t really know unless you use the data to evaluate them.
OKRs are not a magic bullet. They do come with their peculiar set of problems acquired over not so long time.
Adopting OKRs requires a mindset change. Many times they are implemented pro forma, but the mindset is still old. Think of the rise of agile, when many companies would adopt agile and then sit down to plan 52 sprints ahead or have a standing requirement design meeting.
OKRs demand a lot of autonomy. One cannot be given objective, than told how to achieve it and at the end be held accountable for it. There are ways to ease this change into an organization or circumvent it, and I wrote about it in the Who should own OKRs: person, team or both? post.
Perhaps, General Patton put it best.
The deceptive simplicity of OKRs
One of the problems we see time and time again, is people underestimating the introduction of a new process into an existing organization. OKRs are simple in principle, just as is winemaking – you let some grapes ferment. In practice, and especially at scale, not so much.
It’ll take time – usually one or two quarters until everyone or at least most of the team goes through their little personal epiphanies.
Having an internal OKRs expert or hiring a consultant goes to great lengths in alleviating this problem.
Tasks as objectives
What we see often, especially with engineering OKRs is treating tasks as Objectives or Key Results. When just starting, it’s a normal and expected reaction, but it defies the whole purpose of OKRs in an instant. For example, objective such as “Release feature X” or a key result such as “write a documentation article for module Y”.
This ties into other issues, but is the quickest way for people to dismiss OKRs as pointless – and when set up like that – they kind of are.
Your everyday work is not an objective, just as your personal objective for a year should not be “breath”. This is just there – assumed. OKRs are meant to be ambitious, to take you, the team, the product, the company to the next level. And anyhow, you already have tools were you track your tasks – so repeating them again is just bureaucracy.
The best way to go about anything (not just OKRs) is to start with what is it that you want to achieve. Like a child, you can recursively ask yourself “yes, but why?” until you come to a meaningful level of abstraction. This will become natural to you after 3-6 months (and there is a huge benefit even just in that), but when you are just starting, you need to do this consciously.
- Objective (take 1): Implement service for sending e-mails
- Yes, but why?
- Because I want to notify users when someone comments on their post
- Objective (take 2): Implement a system for notifying users when someone comments on their post
- Yes, but why?
- Because I want them to know when something happens that is related to them
- Side thought: Maybe it should also support SMS and Push notifications? Perhaps I should use Twillio
- Objective (take 3): I want to let users know when something related to them happens
- Yes, but why?
- Because I want them to be more engaged
- Objective (take 4): I want to increase engagement of our users
- Key result 1: Average users log in to the application 3 times per week
- Key result 2: Average user has 6 touch points in the application per week
- Key result 3: Implement 4 different methods for users to be notified
So, we can see from this example, that when we started with a simple task we faced several problems until we came up with Objective (take 4):
- Our objective was not ambitious – it was a task
- It was not measurable, other than in binary implemented / didn’t implement way
- It was almost impossible to come up with meaningful key results for it
As we worked our way with “yes, but whys?” we’ve come up with a much better objective:
- Our objective (take 4) is ambitious and measurable (engagement can increase, decrease or stay unchanged)
- It was relatively easy to come up with key results
- We were able to link desired results and effort in key results
Now, having that objective in mind, we can go tactical and start opening tasks to accomplish this objective.
OKRs play very well with agile, as a matter of fact they are natural evolution of agile.
When executed right, OKRs bring a lot of benefits to the company as a whole, but also to the engineering organization specifically.
Implementing OKRs is not the simplest thing in the world, but it is more than a worthwhile effort. If the task at hand is not underestimated and there is an understanding that it will take time for an organization to truly adopt it – all will be good.