OKR and Agile: Stop Waterfall Goals

Many companies struggle to fit OKR and Agile, although both seem to share the same philosophy. Teams using Agile often resist adopting OKR since it appears redundant to them. 

The source of this struggle is a misunderstanding about OKR and Agile itself. When used correctly, OKR and Agile are a powerful combination. They can create Value-driven teams and transform how organizations work.

I have been talking about OKR and Agile in some of the world’s leading publications and conferences. This article summarizes what I have learned. 

Read it Later – Life is Too Short for Waterfall Goals

The Feature Factory

Agile was created to deliver software. It was an alternative to waterfall development for managing software projects.It focuses on managing deliverables (stories or features) and not value (business outcomes).

In fact, there is not a single ceremony in Agile for tracking results.

The Agile Manifesto itself is misleading as it tells people to measure deliverables. “Working software is the primary measure of progress,” the seventh principle states.

The assumption all working software is valuable is obviously wrong. Some projects will deliver value and others won’t. Users will adopt some features while others will fail.

Most organizations are stuck in the “feature factory” model. Teams have no focus on delivering value. Developers are “just sitting in the factory, cranking out features, and sending them down the line,” as John Cutler described.

Marty Cagan highlighted the dire consequences of feature factories:

“The teams are just there to flesh out the details, code and test. They have little understanding of the bigger context, and even less belief that these are in fact the right solutions.  

[They have] little regard for whether or not the features actually solve the underlying business problems. They measure progress by output and not outcome.”

More than 15 years after the manifesto, most companies still use Agile for delivery only. Scaling frameworks usually do not help. They take the path of least resistance and concentrate on improving software development. As such, very few organizations ever achieve business agility.

Delivery Agile

I like to think of organizations as a stack with five layers. They are Culture, Strategy, Tactics, Operations, and Goals.

The Organizational Stack
Goals permeate all other layers, as they reflect how the company works and behaves.

The organizational stack for traditional companies is below:
The Traditional Stack

In the traditional stack the layers are:

  1. Culture is top-down and command-and-control.
  2. Strategy uses annual static plans.
  3. Goals follow a waterfall approach.
  4. Tactics work with big bets and long feedback cycles.
  5. Operations use waterfall development and project management.
Often, when companies adopt Agile, they use Delivery Agile. They merely replace the bottom layer of the stack:
Delivery Agile Stack

Delivery Agile utilizes Lean and Agile at the operational layer only. Agile displaces waterfall development while the teams run scattered experiments. The experimentation culture is not present. Although a few A/B tests occur here and there, many high-risk assumptions remain untested.

Since the other layers remain unchanged in Delivery Agile, its benefits are smaller. There is a waterfall legacy that is in direct conflict with organizational agility.

Read it Later – Life is Too Short for Waterfall Goals

Waterfall Goals

When it comes to setting goals, the waterfall mindset is still the norm. Organizations use an annual, top-down process to create a set of static goals. This is in direct conflict with being agile.
Waterfall Goals follow a static planning model. Usually, it starts with a retreat where the executives create annual company goals. Then goals cascade through the organization, creating a fixed plan for the year.

Can you think of a more top-down waterfall analogy than a cascade?

The static model carries several assumptions:

  1. We can define all the steps of the plan in detail in advance;
  2. The vast majority of the plan will be correct;
  3. Market conditions will remain mostly the same;
  4. Changes will be small. We will deal with them with in a review in the middle of the year. We will then create an updated detailed static plan.

Waterfall Goals are project-based

To make things worse, waterfall goals do not focus on value. They revolve around a set of projects approved by management.

Frederick Taylor would rejoice to see that his teachings are still in use today. “The work of every workman is fully planned out by the management at least one day in advance,” he wrote.

In the Taylorist approach to Agile, teams exist to deliver projects. The executives plan the work, in true feature factory fashion. This model slows companies down, makes it harder for them to adapt, and increases risk and waste.

Most, if not all, scaling frameworks work within Delivery Agile. They are elaborate approaches focused on using Agile to deliver waterfall plans.

From Static to Dynamic Planning

The followers of the static model are like the Kremlin’s central planners. They created top-down 5-year plans believing they could predict the future.

In contrast, dynamic planning embraces change. It works in smaller planning cycles in an iterative model. Dynamic planning assumes that market conditions and the plan itself will change. More than that, our understanding of the problem will evolve as we learn, and our plan has to reflect that.

As Kent Beck wrote, “The only way it’s all going to go according to plan is if you don’t learn anything.”

You want teams to work in short iterations and test hypotheses. So how can you use a static set of goals defined in a waterfall process that could have been devised by the Kremlin?

You can’t. So although we are using Agile for delivery, we are using waterfall for everything else. This needs to change.

Full-Stack Agile

To reach business agility, companies have to be Full-Stack Agile. They have to replace all layers of the traditional organizational stack:

Full Stack Agile
In Full-Stack Agile, the layers change:
  • Culture is based in creating aligned autonomy with the teams. Instead of controlling detailed plans, it follows the principle of mission. Leaders “specify the end state, its purpose and the least possible constrains.”
  • Strategy is data driven, iterative and focuses on validating hypotheses.
  • Goals follow an Agile model, using OKR (Objectives and Key Results).
  • Tactics run safe-to-fail experiments with short feedback cycles.
  • Operations use Agile development.

Refactoring the Organizational Debt

Technical debt is an understood problem by most engineers. Teams acquire technical debt by taking shortcuts. Those make the code harder to change and incapable of scaling. Technical debt is paid later, with interest.
To fix technical debt, you have to refactor the code. This improves the internal structure without adding new features.
The waterfall legacy that permeates Delivery Agile creates organizational debt. And just like its sibling, it makes companies harder to change and is paid with interest.
To become Full-Stack Agile, companies have to fix the organizational debt. They have to refactor all the layers of the stack. But that is easier said than done, as many have tried and failed. What would be the best approach?

From  “Mindset” to “Plumbing”

A lot of people in the Agile community believe that the only solution is to focus on a mindset shift. It seems as if we could just change the mindset of the organization, all the problems would go away. In fact, several luminaries wore a t-shirt that read “Agile is Mindset” during a conference.
Focusing on mindset change alone can be harmful, as it is not actionable. “’Mindset’ seems to be replacing ‘values’ and ‘mission’ as the latest action avoiding platitude,” wrote Dave Snowden.
The alternative is to focus on practical actions that change how companies behave.

As Stanford’s James March reminds us, “Leadership involves plumbing as well as poetry.” While “poetry” is important, most organizations forget the plumbing: their systems and processes. Changing the plumbing is often messy and takes time, but it pays for itself.

There is one tool for business agility that can change the “organizational plumbing.” The tool is OKR (Objectives and Key Results), the goal framework used by firms like Google, and Spotify.

The big difference from traditional planning methods? OKRs are set and evaluated frequentlytypically quarterly. Furthermore, rather than cascading down the organization, OKR is bi-directional. Teams create their OKRs in alignment with the company goals and then hire them with the managers.
This approach provides a much more engaging environment for teams. They now feel responsible for the goals they help set, which they track on a fast weekly cycle.
If used correctly, OKR can enable organizations to become Full-Stack Agile.

Creating Value-Driven Teams

The key to becoming Full Stack Agile is to focus on value. The challenge is that the system is optimized to deliver tasks planned by executives. Unfortunately, Agile was also optimized for delivery, creating the feature factory model.
This obsession with delivery runs deep. It starts with the use of working software as a measure of progress and continues today. Scrum is, after all, “the art of doing twice the work in half the time,” as the title of Jeff Sutherland’s book states.
There is a column missing in Kanban boards: “Did it work?”, as this illustration from John Cutler shows:

Agile Forgotten Column

“Done” only matters if it adds value.

In fact, features that do not improve the metrics may generate negative returns.The new code may have bugs, will need maintenance and the product will be more complicated.

Although the Manifesto is misleading, one of its authors wrote about outcomes:

“The key to [defeating] waterfall is to realize that agilists value Outcomes over Features. The feature list is a valuable tool, but it’s a means not an end. What really matters is the overall outcome, which I think of as value to the customers.”  Martin Fowler

Why are you working on that?

Henrik Kniberg has a great slide about what drives each team:

What are you working on and why?

The first option represents the feature factory. The assumption is that the team is incapable of deciding what to build. They work on something because somebody told them to (“Sam”). It follows the taylorist principle of separation between planning and doing. It is both demotivating and incapable of driving innovation.

The second approach is the other extreme, where teams work on things for no other reason than “they feel like it.”

The third option is the Value-Driven Team. A team that focuses on delivering value and understands how they can make an impact. They have a clear purpose and a line of sight between their work and the company strategy.

The Proper Way to Use OKR

Like any other tool, OKR can be misused and become a to do list. But, if you want to focus on value, your goals have to reflect that. You have to use Value-based Key Results:

Value is like a joke: you don’t get to tell the other party if it’s good or not.

Value-based OKRs are not about simply measuring outcomes. You have to understand what is valuable to your customers and your organization.

The examples below show the difference between the two types of Key Results:

Key Result Examples
When you use Agile with Activity-based Key Results, it creates friction. Agile teams already have roadmaps, so why do they need OKRs? Every time I meet teem struggling to connect OKR and Agile, they are focusing on activities.
Using Value-based OKRs can be transformative. It can be the missing link between Agile and Lean. In can bridge the gap between product and engineering.

Changing the Language

Even the nomenclature that Agile uses focus on delivery. We need to abandon concepts such as the definition of done, burn-down charts, and velocity. Instead, we need to focus on value. Instead of acceptance criteria, we need success criteria – with OKR.

From Opinions to Data

It’s not data that drives standalone Agile. It’s the HiPPO: the Highest Paid Person’s Opinion. The concept is brilliantly illustrated in the book How Google Works:

HiPPO How Google Works

There is a flawed assumption behind Agile. The model is based on the stakeholders telling the teams what needs to be done and then reviewing the work.

Ron Jeffries described a hypothetical conversation with a stakeholder (emphasis mine):

“Every week you get to tell us what’s most important to you, and we’ll tell you what we think we can accomplish. A week later, you have it in your hands. […] You could ship it out if you want to.”

The stakeholders decide what to do and if work will ship, following the taylorist model. The assumption is that they know what is valuable and their opinion is a measure of actual value.

But data shows otherwise. For example, a paper published by Ron Kohavi analyzed the results from a set of ideas at Microsoft. Only 1/3 created a statistically significant positive change in the desired metrics.
Instead of collecting data and measuring what works, Agile asks the HiPPOs what to build. And they have an error margin of 66% or more.

Many companies are still using the “voice of the customer” model. In this model someone represents the end customer. It made sense in the past, when collecting data was hard. But nowadays it is just another waterfall residue.

Replacing HiPPOs with Experiments

The fact is that teams don’t need someone to be the voice of the customer. They can interview customers and measure behaviors. OKR can replace the HIPPO with experiments that allow the team to learn and iterate.
It enables teams to adopt Hypothesis-Driven Development, as described by Barry O’Reilly:

We believe

Will result in

We will have confidence to proceed when

In this model, the review is not about showing deliverables anymore. The team uses the review to discuss the metrics and the main hypotheses to improve them.

Read it Later – Life is Too Short for Waterfall Goals

Enabling Autonomy

Command and Control is still here.

The command and control mentality still permeates Delivery Agile. The stakeholders decide what to build. As a result, the teams are working on something “because Sam said,” and will stop “when Sam is OK with it.”

You need your team’s full contribution. So, they need to understand the business problems and have a voice on what to build. As Marty Cagan wrote, “If you’re just using your engineers to code, you’re only getting about half their value.”
To enable autonomous teams, you need to give them the freedom to decide how to achieve the desired outcomes. The purpose of the team has to change:

The Feature Factory’s Purpose

A Value-Driven Team’s Purpose

Delivering the features the stakeholders want

Achieving the agreed Value-based OKRs.

As Mary Poppendieck wrote:

“Perhaps the biggest shortcoming of agile development practices is the way in which teams decide what to do. […] for the longest time, answering these questions have not been considered the responsibility of the team.”

Teams don’t have to implementing a waterfall plan conceived by the stakeholders. They can can discover valuable products using dual track Agile and design sprints.

Additional OKR Material