Agile Goal Setting with OKR - Objectives and Key Results
The Agile Manifesto is wrong.
That's right, there is an article on InfoQ saying that the Agile Manifesto is wrong. But hold your pitchforks for now. I love the Manifesto, but one of the 12 Principles is wrong:
Working software is the primary measure of progress.
Agile Manifesto, 2001
This is wrong. This is wrong now and was wrong in 2001. The primary measure of progress should be business results, not just working software.
And by the way, this principle conflicts with the first one:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
So we shouldn't be measuring working software but valuable software. That is 100% correct. But what is valuable? How do we define value?
Value means different things for different people, depending on their points of view. There are several techniques for handling Business Value in Agile Projects, including Value Points, Business Value Modeling and others.
But most of them are simply estimates and not real measures of value, which can only be measured after the feature is shipped.
In January/2015 Ken Schwaber wrote, describing Nexus, his framework for scaling Agile:
In our case, a Nexus is 3-9 Scrum Teams that are working on a single Product Backlog to build an integrated increment that meets a goal.
Not a word about what is that goal and how to define it.
We need a way to set clear goals that are shared among different stakeholders and the team.
What is wrong with Goal Setting
Static Planning. That is how I call the traditional, annual planning process. We all know how it goes: there is a corporate retreat where the "strategic thinking" happens and the company goals for the year are defined. Then over the next weeks, the goals cascade through the organization, creating a detailed and fixed plan for the year for the company.
The static model carries the assumptions that (1) all steps of the plan can be defined in detail in advance; (2) the vast majority of the plan will be correct; (3) market conditions will remain mostly the same; and (4) changes in the plan will be small and may be dealt with in a review in the middle of the year - where a new detailed static plan will be created.
The cascade analogy itself literally refers to a one-way top-down phenomenon - a waterfall.
In contrast, dynamic planning embraces change and works in smaller planning cycles in an incremental, iterative model. Dynamic planning assumes that market conditions and the plan itself will change.
If your teams are working on one to four week iterations (or sprints), getting out of the building to talk to customers, testing hypothesis through validated learning, how can you use a static set of goals defined in an annual waterfall process that could have been devised by the Kremlin?
The answer is, you can't.
There must be another way.
In his article on MITSloan Management Review called "Should You Build Strategy Like You Build Software?", Keith R. McFarland writes:
Because strategy can only capture a company’s best thinking at a given point in time, strategy (like a software program) needs to be refined and improved as people gain and distribute new experience and knowledge.
Given this reality, sound strategy development processes should enable a company to create and adapt strategy quickly and iteratively… and allocate resources in changing environments.
So although we have been using Agile/Lean mindset and processes tactically, we are still using waterfall mindset and processes for goal setting. This needs to change.
But how can we implement a new approach? McFarland mentions the use of "strategy scrums" but a more formal framework was still missing. Enter OKR.
OKR: an Agile Goal Setting Framework
OKR (Objectives and Key Results) is a goal setting framework created by Intel and adopted by several Silicon Valley companies. Google is the most famous case, having adopted OKR in it's first year. Twitter, LinkedIn, Dropbox and Oracle are among other adopters.
All star venture capitalist John Doerr, who introduced Google to OKR, has a great tip for setting goals:
I will ________ as measured by ____________.
So an OKR can be thought of a commitment stated as:
I will (Objective) as measured by (this set of Key Results).
So one OKR has two components, the Objective (What we want to achieve) and a set of Key Results (How do we know if we are getting there):
- What we want to achieve.
Using aspirational Objectives is highly recommended. Nobody gets out of bed in the morning to "improve conversion by 10%".
Key Results (a small set per Objective)
- How do we know if we are getting to our Objective.
- Success Criteria that show if we are progressing.
- Metrics (recommended) or Milestones.
As an example, let's imagine a technology company that wants to increase customer engagement and satisfaction:
Objective: Delight our customers
- Recurring visits: average of 3,3 visits per week per active user.
- Reach a Net Promoter Score of 90%.
- Non paid (organic) traffic of 80%.
- Engagement: 75% of users complete a full profile.
What's unique about OKR?
- Simplicity: In order to enable frequent goal setting cycles (Intel used to set OKRs monthly), the process is extremely simple. The OKRs themselves are supposed to be simple and easily understood.
- Shorter cadence: Instead of using an annual static planning process, OKR uses shorter goal setting cycles (usually every quarter), enabling dynamic planning and faster adaptation to change.
- Open Source: OKR is an open source framework so companies adapt it to each culture and context, creating different versions of it. This is a great benefit since OKR is easily adaptable, but may mislead those looking for a step-by-step recipe.
- Stretch Goals: Goals that take the team out of the comfort zone and make them rethink the way they work to reach maximum performance (read more).
- Separation from compensation and evaluation: Decoupling goals from salary and promotions is key so that the team may go for hard and aspirational goals (read more).
The Practice of OKR
The main objective of OKR is to create alignment in the organization. In order to do so, transparency is key. OKRs are public to all company levels — everyone has access to everyone else's OKRs. All OKRs, including the CEO's, are usually available on the Intranet.
OKRs exist to set clear priorities and to focus the organization. In order to to that, you should have few OKRs. Each individual or team should have up to 5 objectives and up to 5 Key Results per objective - less is more here.
Incremental, Adaptive Goal Setting
OKR usually has a dual cadence:
- High-level goals for the company are set annually.
- Detailed incremental goals for the teams and individuals set at shorter goal cycles (iterations) that usually last a quarter but can also be set in 30 or 45 days.
In the beginning of the year the company defines a small set of high-level OKRs - preferably with input from the team - without setting detailed plans for the whole year.
In the beginning of a goal cycle, each team reviews its results from the previous iteration and then sets detailed goals for the next goal cycle. In a parallel process, individuals and teams define goals that are linked to the organization objectives and validated by managers, in a system that is simultaneously bottom-up and top-down.
From the company OKRs the teams are able to get clear direction and understand how they can contribute to reach those goals. About 60% of the OKRs should be defined by the team.
Goals that haven't been achieved in the previous cycle are reavaluated so they can be included in the next cycle or, if not necessary any more, discarded.
In order to set their OKRs, individuals and teams debate with each other to work out interdependencies and create horizontal alignment. If a team needs something from another area, they can discuss it and set common priorities or even delay the initiative for the next goal cycle.
Since OKRs are transparent, if one area of the business is out of alignment with the others it can be quickly noted by the other teams and fixed.
Reinforcing Alignment: Shared OKRs
In order to reinforce alignment, shared OKRs can be created among different teams, creating shared success criteria between them. So instead of splitting a single initiative among teams and have them set separate goals - which can lead to teams losing sight of the real objective - a single shared OKR is created among the teams.
For example, imagine that a product team wants to launch a new product and needs that the platform team develops new features while the business development team signs content deals with partners.
Objective: Successfully Launch Acme Product
- 500.000 Daily Active Users of the free version.
- 8% conversion rate from free to paid customers.
- Net Promoter Score of 75%.
- Less than 5 critical or blocker bugs reported by users.
- Achieve at least 40% revenue share with 5 of the target content partners.
Instead of having 3 different goals that could be individually achieved without generating the desired business result, this single OKR is shared between the teams. Each team has different tasks, but the same OKR - the same definition of success.
For the duration of this OKR, a virtual team will be created among the three areas that will meet regularly to track progress.
How OKR complements Lean and Agile
OKR brings discipline to validated learning
Steve Blank wrote in his article:
Use the Business Model Canvas to frame hypotheses, Customer Development to get out of the building to test hypotheses, and Agile Engineering to build the product iteratively and incrementally
But how do you know if you are being successful? What do we consider a "validated hypothesis"? We need clear, shared success criteria for validated learning. So I would add:
…and OKR to track if you are going in the right direction.
OKR defines Success Criteria beyond features
Agile projects are commonly evaluated by the velocity they deliver features (with "quality"). But a team that delivers features but fails to achieve the desired business results will never be considered successful.
OKR coach Christina Wodtke has a great tweet about "success":
Success is not checking a box.
Success is having an impact.
If you complete all tasks and nothing ever gets better, that's not success.
In fact, delivering features that do not positively affect the selected metrics (Key Results in OKR parlance) may generate negative returns. The new code may have bugs, will have to be maintained and the product itself will become more complex.
This is why I’m so happy to see the resurgence of OKR’s. When used properly, they help to reframe this situation from output (features on roadmaps) to outcome (business results).
OKR helps avoid the “shower temperature” problem
If you keep turning the shower tap, the water will never get to the temperature you want. It is the same thing with innovation, if you keep pivoting all the time, you will never get to where you want.
Shit hits the fan, but that does not mean you shouldn’t use the same discipline.
OKR enables self-organizing teams
The best architectures, requirements, and designs emerge from self-organizing teams.
But how do you actually implement self-organizing teams?
In order to have a horizontal, high-alignment, high-autonomy organization, formed by self-managed teams, you have to set a “True North” for the organization. You have to give the teams clear direction.
A set of OKRs for each team will do just that.
OKR connects the team with the business and it's customers
It is very easy for the team to get lost in technicalities of writing code and design. But when you start talking about business results in a bottom up process, you get team members to start asking why they are doing what they are doing.
If you keep talking about delivering features how do you expect the team to think about the user? Or the business?
How OKR complements Scrum
OKR gives autonomy to the team
In some companies the Product Owner is called a “Proxy Owner” since she/he simply brings back and forth the feature list that have been prioritized by the top management. How can you give her/him the mandate to manage the product? How can you make sure the team has autonomy?
If the role of the team is “to deliver the features the customer/management wants” that will never happen. The mindset needs to be “the role of the team is to achieve the success criteria as described in the Key Results and agreed with the customer/management. Let’s give them the autonomy to do that”.
OKR helps prioritize the product backlog
Even though you have to focus on delivering business results and not features, you will still have to prioritize the product backlog.
But how is the Product Owner/Manager is supposed to do that? She/He is supposed to use “perceived value” as the criteria, but this is still subjective. OKR can act as the missing piece, a simple, clear framework to decide which features to work on.
As Cagan wrote about product scorecards (now being replaced by OKRs):
One of my favorite benefits of these product scorecards is that they can often help you eliminate a good portion of your backlog/roadmap. If a feature idea doesn’t speak directly to one of the top KPI’s [Key Results] on the product scorecard [ OKRs], it’s generally off the list.
I hope that this article was able to show that OKR can be a great framework to create alignment and improve communication between teams, complementing Lean and Agile in several dimensions. It is a light, simple and straightforward technique, taking only a few structured conversations to set goals.
In order to know more about the practice of OKR, please join us at OKR Alliance, a global non-profit peer to peer group dedicated to encouraging the adoption and effective practice of OKR.
Are you using OKR or planning to? Do you have any questions? Please post it on the comments and let's have a conversation.
About the Author
Felipe Castro (@meetfelipe) is an OKR Coach and Partner at Lean Performance, a boutique advisory firm focused on helping companies develop organizational cultures that are Results-Focused and Data Driven. Felipe has a BS in Computer Engineering from Pontificia Universidade Católica in Rio de Janeiro.