Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Fixing OKR Theater using Scrum

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

 

OKR Struggles

I encounter many organizations that are trying to improve the alignment between strategy and execution with the OKRs framework (Objectives and Key Results). There’s good intent there, but more often than not I see anti-patterns like:

  • OKRs that look more like tasks than strategic objectives – especially by the time they reach working teams
  • OKRs used to micro-manage teams and individuals rather than empower and enable them. 
  • Too many OKRs that are set without any respect/consideration of the ability to actually deliver them in a sustainable way while dealing with other work happening in the organization
  • Defining OKRs and then forgetting about them until its time to grade them. (Even worse, some organizations don’t even bother with a serious consideration of how they did on their OKRs…) 

OKR Theater

These anti-patterns aren’t an inherent problem with OKRs. They are what you could call “OKR Theater”. They are what you get when you start to focus on the mechanics and forget the principles/spirit/reason you used the technique in the first place. OKR Theater has the potential to become a member of a big family – Scrum Theater, Agile Theater, SAFe Theater, and Lean Theater, Six Sigma Theater, you get the picture. It’s the sort of thing that happens when a good thing gets spread too thin and the people implementing it lack the depth and experience the original practitioners had. It’s what the late Jerry Weinberg called “The Law of Raspberry Jam” – “The wider you spread it, the thinner it gets.”

Dealing with the OKR Theater

This sort of theater is here to stay. What can we do though? One step that seems to help is to try to recall Why we are doing something – in this case, OKRs – and whether they are achieving the expected outcomes for us. To feed this snake its head – what was the Objective that we set out to achieve with OKRs, what were the expected Key Results, and are we seeing indications that this is heading in the right direction? 

OKRs (and Scrum…) thrive in the Complex Domain

Next, we need to reflect on what kind of environment we’re operating in. Some of our work happens in a simple or complicated space where we could set OKRs, figure out a plan, execute it successfully, and celebrate. 

Alas, OKRs are typically about challenging the status quo. Going beyond “running the business”. This could entail building new products, opening new markets, unlocking efficiencies, changing our organization, digital transformation, or scaling an existing business or product way beyond where it is right now. More often than not, these are complex problems where what we know is dwarfed by what we don’t know. 

This is exactly the environment where Scrum thrives. Does that mean we need Scrum to implement OKRs? Scrum is definitely a great way to solve complex problems when you can organize a multi-disciplinary focused team around a certain goal and is indeed a great way to go achieve an OKR. But it also goes beyond that. We could benefit from applying Scrum’s underlying theory to move from OKR Theater to a more effective OKR operating system. 

OKRs should be set and managed in a way that enables Empiricism, Self Management, and Continuous Improvement. 

Let’s look at how the Scrum Values can be useful when trying to effectively implement OKRs:

  • An organization should limit the number of OKRs it askes people to focus on. It has the mindset of “Stop Starting Start Finishing” when it comes to OKRs. It considers how to set up teams such that they’re able to focus on one OKR rather than having to work on a complicated matrix of objectives touching many teams in the organization. 
  • Openness – can enable people working on the OKR to find and surface better ways to achieve the desired Key Results than initially planned. Or to suggest different Key Results (KRs) should be aimed at. Or even the Courage to come back and say that the Objective should be reconsidered. 
  • An organization leveraging OKRs should be committed to using OKRs as an alignment framework rather than a micro-management tool in disguise. Using OKRs this way is harder so everyone should be committed to experimenting with how to organize work, how to set OKRs, how to track and grade OKRs, all in a fashion that is aligned with the intent of achieving strategic alignment in an environment of uncertainty and scale. 
  • This requires respect for the framework. It requires teams to respect the direction provided by the OKRs set by their leaders. It requires leaders to respect the ability of the various teams to find effective ways to achieve the set objectives even if its not necessarily how they would go about achieving that objective. 

Now let’s turn to the specific anti-patterns I mentioned earlier and see how some Scrum concepts can help:

Do your teams have OKRs that look more like tasks than strategic objectives? 

Step back from the tactical OKRs and ask Why? What’s the intent here? What are we trying to accomplish? THAT should be your Objective. 

Like a good Product Backlog Item / Goal, An Objective that focuses on the WHY/WHAT leaves the details of HOW negotiable for the team to figure out based on the reality discovered in the trenches. What we’ve learned over the years in crafting good Product Backlog Items, Sprint Goals, and Product Goals can come in handy when crafting OKRs. 

Do you have KRs that seem like a list of deliverables rather than results? 

This is a sneaky one. Aren’t deliverables what we’re looking for here? In some cases deliverables are fine. But remember – we are frequently operating in the complex domain when trying to achieve the sort of objectives set using OKRs. And in these environments, we don’t necessarily know what deliverables would actually achieve the results we’re looking for! 

We might have a situation where we achieved our deliverables but haven’t achieved our objective…

Therefore Key Results should come from the answer to the question “How will we know we actually accomplished this objective?” They should refer to some evidence-based measurement of outcomes or at least highly aligned leading indicators. 

OKRs used to micro-manage teams and individuals rather than empower and enable them. 

I can’t forget that client who told me ages ago “To tell you the truth, I see Scrum as a way to micro-manage my teams”. He was the only one open enough to say it, but I see similar behavior all around. Some people are aware that they’re using Scrum this way. Some just can’t get out of their micro-management mindset and see Scrum via this prism. 

Unfortunately, A similar pattern occurs with OKRs. Leaders might or might not be aware that they’re setting OKRs in a way that “tunnels”/overly constrains teams and individuals. 

Focusing OKRs on WHY/WHAT and KRs on outcomes rather than deliverables is a good first step towards empowering teams to solve problems. 

Making sure teams understand the wider mission/OKRs and then come up with their own OKRs is an important next step. A leader is welcome to inquire or even advise a team on what OKRs to set. A leader would probably do well not to get involved too much in any further details. 

Look at a similar structure in Scrum. The Scrum Team involves Leaders as Stakeholders in setting the Product Goal. Sometimes a team is set up around a Product Goal. 

The Leaders are Stakeholders that have transparency to the Product Backlog as well as the Increment created by the team. The Sprint Review is an opportunity for inspecting both and providing feedback that will then be considered and perhaps reflect in the Product Backlog influencing future work. But planning and monitoring the work is the domain of the Scrum Team. The stakeholders trust and respect the Scrum Team’s ability to create value and proceed towards their Goal. They let the team focus on the work. 

A similar structure should be considered when implementing OKRs. 

Too many OKRs that are set without any respect/consideration of the ability to actually deliver them in a sustainable way while dealing with other work happening in the organization

In Scrum, teams consider their historical throughput, their capacity, their way of working, when figuring out how much work they can do in the Sprint. They figure out their forecast for the Sprint. 

Similarly, when setting OKRs, the people who will be involved in achieving these OKRs should be the ones figuring out a realistic and sustainable set of OKRs to focus on for the time period. Setting OKRs isn’t done on a Sprint by Sprint level, so it is more like the activity of “Release Planning / Forecasting” in Scrum. 

Defining OKRs and then forgetting about them until its time to grade them. (Even worse, some organizations don’t even bother with a serious consideration of how they did on their OKRs…) 

OKRs are typically set on either a quarterly or annual basis. In many cases, teams struggle to keep this high-level guidance in mind as they go about planning their work week-to-week. 

We’ve learned that keeping the Product Goal and Product Backlog transparent and always available to the Scrum Team and Stakeholders helps with alignment and consideration of what is important for the team to focus on. 

Similarly, in the OKR context, the OKRs should be transparent and always available to everyone working on them. 

If using Scrum to do the work, The OKRs could actually become items on the Product Backlog or even a Product Goal in some cases. They should be considered in the Sprint Review. The team should be asking itself whether it’s making appropriate progress towards its OKRs and whether anything needs to change with the work or with the OKRs. 

The first step in dealing with OKR Theater is recognizing OKR Theater…

Fixing OKR Theater isn’t trivial. There are other anti-patterns beyond those identified above. Creating the conditions for the successful healthy implementation of OKRs takes focused leadership over months if not years. It all starts with the ability to recognize the theater and setting your sights on something better. 

We are leveraging our vast experience in Agile/Scrum/Flow to help our clients go beyond OKRs as a buzzword towards OKRs as a way to achieve strategic alignment leveraging empiricism, self-management, and evidence-based measurement. If you need help realizing the potential of OKRs or helping your teams work effectively within an OKR Theater, maybe we should talk

Subscribe for Email Updates:

Categories:

Tags:

SAFe Release Planning
Limiting Work in Progress
Scrum and XP
Agile Assembly Architecture
Lean Budgeting
Certification
Acceptance Test-Driven Development
Sprint Planning
Certified SAFe
Rapid RTC
Scaled Agile Framework
ROI
Scrum Master
Pomodoro Technique
RSA
Sprint Retrospectives
RTE
Agile Project
Risk-aware Product Development
Agile Project Management
Kanban
Presentation
An Appreciative Retrospective
Agile India
Continuous Improvement
Systems Thinking
ATDD
Nexus Integration Team
Scrum Values
Jira admin
predictability
Agile Exercises
Spotify
SAFe
Amdocs
Managing Projects
Portfolio for Jira
NIT
What Is Kanban
Continuous Integration
Agile in the Enterprise
Agile Basics
Nexus vs SAFe
Frameworks
Advanced Roadmaps
QA
Risk Management in Kanban
IT Operations
System Team
Rovo
Scrum Master Role
BDD
Coaching Agile Teams
Agile Outsourcing
Team Flow
Large Scale Scrum
Atlassian
LAB
Kanban Kickstart Example
Nexus and SAFe
Lean Agile Management
Manage Budget Creation
Software Development Estimation
Reading List
Entrepreneurial Operating System®
Agile
Agile Games and Exercises
Continuous Planning
Webinar
Agile and DevOps Journey
Daily Scrum
TDD
Code
Agile Marketing
Legacy Enterprise
Releases Using Lean
Achieve Business Agility
System Integration Environments
Managing Risk on Agile Projects
Release Train Engineer
Agile Risk Management
Keith Sawyer
Sprint Iteration
speed at scale
Development Value Streams
Lean-Agile Software Development
The Kanban Method
Confluence
Nexus and Kanban
Scrum.org
Jira
Risk Management on Agile Projects
RTE Role
Kaizen
Continuous Deployment
EOS®
Scrum
Implementing SAFe
Agility
Planning
Agile Israel
SAFe DevOps
Tips
Lean and Agile Principles and Practices
Retrospectives
Test Driven Development
Hybrid Work
Program Increment
PI Planning
Enterprise DevOps
Scrum Guide
Story Slicing
Games and Exercises
Introduction to ATDD
Process Improvement
SA
Software Development
Agile Mindset
Professional Scrum with Kanban
Kanban Game
Tools
chatgpt
AI
System Archetypes
Principles of Lean-Agile Leadership
Professional Scrum Product Owner
Product Ownership
Implementation of Lean and Agile
LPM
Agile Release Planning
Kaizen Workshop
Agile for Embedded Systems
Legacy Code
Artificial Intelligence
Kanban Basics
Agile Community
ARTs
Applying Agile Methodology
Product Management
Quality Assurance
Nexus
Effective Agile Retrospectives
Engineering Practices
User stories
SPC
Video
Agile Israel Events
Jira Plans
Lean Agile
Lean Agile Organization
Agile Contracts Best Practices
ScrumMaster Tales
ART Success
Atlaassian
Lean Software Development
AI Artificial Intelligence
Lean-Agile Budgeting
Lean Risk Management
DevOps
Agile Product Development
Slides
Introduction to Test Driven Development
WIP
Scrum Primer
agileisrael
Operational Value Stream
Elastic Leadership
PI Objectives
ALM Tools
Agile Release Management
ATDD vs. BDD
Agile Testing Practices
AgileSparks
lean agile change management
Agile Development
Lean Startup
Scrum With Kanban
Business Agility
Built-In Quality
Agile Product Ownership
POPM
Value Streams
speed @ scale
Kanban 101
Lean and Agile Techniques
Professional Scrum Master
Continuous Delivery
transformation
A Kanban System for Software Engineering
Agile Program
LeSS
Change Management
GanttBan
Jira Cloud
Agile Delivery
Agile Techniques
Agile Games
Iterative Incremental Development
Lean Agile Basics
Self-organization
Lean Agile Leadership
Covid19
Accelerate Value Delivery At Scale
Perfection Game
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart