What are OKRs, and are they agile?

I have to admit, in all my reading, writing, and work experience, I was unaware of the concept of "objectives and key results," or OKRs, until very recently. As a track reviewer for Agile 2016's enterprise track, I was even more surprised how often I saw OKRs mentioned in the submissions — close to a dozen times. I also didn't know that Google, Linkedin, Oracle, and Netflix have all stated that they use OKRs to align and govern their teams. Which made me wonder what they are.

Now that I know, I'm going to explain the gist of OKRs, their origins, and how they fit in with agile.

Are OKRs just KPIs by another name?

Most of us are familiar with key performance indicators, or KPIs. These are typical process indicators. For example, the percentage of projects that ran on time, the number of stories that were completed in the last sprint, the percentage of same-day call resolutions, and so on. Those are measures of process. What they don't measure is outcome.

Star Wars Movie PosterLet's look at a simple example. Imagine the movie Star Wars Episode IV: A New Hope organized as a software project. Star Wars ran $2 million over budget, with an initial projected budget of $8 million and a final price tag of $10 million. That is a 25 percent cost overrun. The project was also late. Scheduled for a Christmas 1976 release, Star Wars actually came out in May of 1977, about 50% late, as measured against the original schedule. According to the Standish Group's CHAOS report, Star Wars would be a "challenged" project.

Except, of course, that it was the most profitable film in box-office history to that date, earning $786 million in box office receipts. That record would stand until 1997, when it would be broken by Titanic, coming in at $2.2 billion worldwide. Titanic was also six months late, and $100 million over budget, which was a 100% increase — qualifying Titanic as a "failed" project.

The world has judged Star Wars and Titanic as not only wildly profitable (the Star Wars franchise was recently sold to Disney for $35 billion, meaning Disney expects to earn much more in profit from it), but also as culturally significant cinema. Star Wars and Titanic are the sorts of movies one can mention in an article on business management.

So while KPIs can measure process, and balanced score cards might look at outcomes as one part of a list of numbers, OKRs are all about the outcome, or the measurable results on the business.

OKRs force the people doing the planning to stop and ask the question, "What will success look like for this endeavor in terms of cash, customers, and competition?"

But that's not all. Here's a brief description of how OKRs work.

The basics of OKR

OKRs can work at any level, from corporate to individual. The higher levels are graded once a year, while smaller groups might be graded more often. Grades are based on an outcome (such as profitability), on a scale of 0 to 1, where 1 is accomplishing 100% of the goal for the time period.

These goals cascade down from the company vision to how teams support that vision. We call this a cascade because these goals are negotiated. Departments can propose a different measurement or a different goal. That means a team can own its goals and plans, instead of having a goal dictated to it.

Henrik-Jan Van Der Pol, creator of OKR tools, points out that having too many objectives leads to a diluting effect and suggests having just five objectives measured by four key results (hence the name, "objectives and key results"). The objective is what we want to do, and the key result is how we know we have arrived. This forces the team to describe how the actions they are taking will impact the business.

If the team is working on a quarterly basis, then it will define objectives before the quarter starts and key results very early — likely in the first week of the quarter. Because the plans are adjusted quarterly, the team can change them quarterly instead of being judged against a plan that is a year out of date by judgment day.

OKRs are not tied to individual performance. Instead, they tie team performance to company performance, allowing the team to align. Because they are public, OKRs allow team members to push back on any initiative, any idea, any meeting that will detract from an objective without contributing to a different objective.

Rick Klau, a partner at Google Ventures, listed these additional requirements for OKRs in a Google tech talk:

  • Objectives are ambitious and should feel somewhat uncomfortable.
  • Key results are measurable; they should be easy to grade with a number (Google uses a 0-1.0 scale to grade each key result at the end of a quarter).
  • OKRs are public; everyone in the company should be able to see what everyone else is working on (and how they did in the past).
  • The "sweet spot" for an OKR grade is 0.6-0.7; if teams consistently get 1.0, their OKRs aren't ambitious enough. Low grades shouldn't be punished. See them as data to help refine the next quarter's OKRs.

The example Klau gives comes from John Doerr, an early investor in Google. Doerr uses the example of a football team, operating as a business. The team's senior management has OKRs about filling seats. The PR department wants to get the team mentioned a certain number of times on local and national news. The general manager wants to win games. The offensive team has goals for completed passes, yards, and low turnover, while the defensive team is looking at interceptions and sacks. The player-level OKRs are designed to help provide the results on the higher-level vision — people in seats and championship wins. 

At Google, every employee's current objectives, along with the history of performance, are listed on the company directory, right next to name, phone number, and email address.

But where did OKRs come from?

While the idea of objectives and results didn't originate at Google, it did start in Silicon Valley. Andy Grove, a co-founder and CEO of Intel, introduced the idea in his 1983 best-seller, High Output Management. The book suggests that the value that a manager brings is a function of the value of the team they manage, plus the influence the manager has on other teams. If that's true, then every hour of a manager's day should be spent improving the output of the team. Grove goes on to suggest ways to improve performance, like one-on-ones and task-relevant maturity, where a manager is hands-off if the person has experience at a task and hands-on when the person lacks experience. For setting goals, Grove suggests management by objective (MBO), which has been around since the 1950s, with OKRs as the way to implement MBO.

Intel's success basically started Silicon Valley — the silicon was the hardware of the chips, not software. Grove gave the OKR method a significant amount of the credit, including the credit for making the switch from producing memory, which was becoming unprofitable, to producing CPUs.

After writing High Output Management, Grove continued as CEO of Intel and taught at the Stanford Graduate School of Business for 24 years. Time magazine named him Person of the Year in 1997. Doerr, an early Intel employee and top salesperson, went on to become a venture capitalist, investing in a little company called Google when it was one year old. It was Doerr who brought OKRs to Google. The success of Google, and the way it credits the idea, has caused it to resurface.

But are OKRs agile?

Objectives provide a vision for what needs to come (the "what"), while allowing the team to decide how to get there. That means teams can focus on responding to change instead of following a plan, and they will be judged by their outcome according to some standard, not according to schedule conformance. OKRs are negotiated and can change via a back-and-forth process sometimes called "catchball" that is designed to be more collaboration than contract negotiation. By leaving the "how" to the team, OKRs focus on outcome and people, not process and tools.

Like any other method, OKRs could be implemented poorly, as a top-down performance indicator. Metrics for results are hard, and if you look, I expect you can find people that list key results as vanity or process metrics, such as number of site visitors or story points accomplished. It is unfair to judge a method by the abuse of that method.

OKRs will not replace human wisdom, but still, that list of values does mirror the values of the Agile Manifesto. To the extent that they help a company govern itself in a more agile way, a way that responds to change, I believe it is fair to call OKRs agile — as one of the best ways we know. So please, if you want to push agile software upstream, take a look at OKRs. And keep looking for other methods. OKRs are an improvement, but they are also far from perfect.

Topics: Agile