OKR and Agile: Stop Waterfall Goals
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.
The Feature Factory
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
In the traditional stack the layers are:
- Culture is top-down and command-and-control.
- Strategy uses annual static plans.
- Goals follow a waterfall approach.
- Tactics work with big bets and long feedback cycles.
- Operations use waterfall development and project management.
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.
Waterfall Goals
Can you think of a more top-down waterfall analogy than a cascade?
The static model carries several assumptions:
- We can define all the steps of the plan in detail in advance;
- The vast majority of the plan will be correct;
- Market conditions will remain mostly the same;
- 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
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:
- 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
From “Mindset” to “Plumbing”
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.
Creating Value-Driven Teams
“Done” only matters if it adds value.
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:
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:
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:
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.
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
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.
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.”
|
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
Resources
- Check out our Resources page for free OKR tools and templates
Articles