Agile Goal Setting

Using OKR to link Agile Development, Customer Development and Lean Startup to the company goals

Felipe Castro
Lean Performance Library

--

By Felipe Castro, Partner at Lean Performance

Interested in OKR? Check out my OKR Guide and download free OKR resources

Wally Thinks About Strategic Planning — Dilbert by Scott Adams http://dilbert.com/strip/2014-12-17

Static Planning. That is how I call the traditional, annual planning process. We all know how it goes: there is a corporate retreat in which 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 whole company.

Usually there is a provision for the plan to be reviewed in six months but most companies don't do it, since it would take so much time.

But if your teams are working on 1–4 week iterations (or sprints), getting out of the building to talk to customers, testing hypothesis and learning what works and what doesn't work, how can you use a static set of goals defined annually?

The answer is, you can't.

Nassim Taleb, author of The Black Swan, likes to compare this model to the central planners of the Kremlin that created 5-year plans believing that they could predict the future.

There must be another way.

In his article on MITSloan Management Review titled "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.

OKR: an Agile Goal Setting Framework

OKR (Objectives and Key Results) is a goal setting framework created by Intel and adopted by Google, Oracle, Twitter, LinkedIn and Dropbox, among others.

A 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):

Objective: Delight our customers

Key Results:

  • 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.

Instead of static planning with annual fixed goals, OKR works in quarterly (or even shorter) goal setting cycles, enabling an agile, iterative approach to goal setting.

If you want to know more about OKR, read my Introduction.

Shared Success Criteria

What is success? Every group should answer this question. How will we as a group consider ourselves successful?

For some it may be to create the next billion-dollar company. For others, success is to make a dent in the universe. It could be a big technical contribution. Or simply a project that fulfills them.

In fact, every project, venture or initiative needs to answer this question. It is crucial to create the necessary alignment.

That is why one of the things I love most about OKR is that it enables the creation of shared success criteria. In a very simple process, it creates alignment regarding what is expected and where do we want to go.

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".

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, it will have to be maintained and the product itself will become more complex.

Marty Cagan has a must-read post on the subject (as well as several others). If you haven’t read his book and his blog, you should:

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 may help evolve the Agile Manifesto

Fourteen years after the Agile Manifesto, I think it is time to evolve on one of it's principles:

Working software is the primary measure of progress.

The primary measure of progress should be business results, not just working software. And OKR is the right framework for that.

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.

The use of shorter goal cycles can help avoid the problem. Of course things will go wrong but as former Zynga SVP of Product Jon Tien said in a great Spark Session video about OKR:

Shit hits the fan, but that does not mean you shouldn’t use the same discipline.

OKR enables self-managed 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?

In my next article I wrote about OKR and Scrum.

(Did you enjoy reading? Please recommend ❤ or share this article, follow me on Twitter @meetfelipe, and check out more of my work. You can also visit my website: felipecastro.com)

--

--

Felipe Castro
Lean Performance Library

Helping organizations shift from projects to outcomes with a unique approach to OKR. Founder at OutcomeEdge.