I was delighted to accept an invitation to come on the podcast to discuss OKRs, Business Agility, Agile, Evidence-based management and the connection to increasing value creation e.g. in the Private Equity space. Check out the podcast here or in the embedded audio below.
We discuss the role of OKRs in aligning the goals of a portfolio company and how they can be used to facilitate cross-functional collaboration and focus on outcomes. we also discuss the importance of going beyond the surface level of frameworks like OKRs and Scrum to truly understand and utilize their principles, as well as the dangers of getting caught up in the hype of the latest buzzwords and trends.
What you will learn
The connection between business agility and OKRs in private equity
The role of OKRs in alignment and focus within an organization
The principles shared by various frameworks such as OKRs, Scrum, and SAFe
The importance of understanding and implementing frameworks effectively
The benefits of dynamic team organization and shuffling based on OKRs
The value of discussing outcomes rather than specifying outputs and having conversations about OKRs
The dangers of chasing the next shiny thing without fully understanding and implementing it
The connection between agile principles and OKR success
The role of transparency, collaboration, and psychological safety in creating a successful environment for progress and continuous improvement
The challenges and opportunities in improving work environments and creating meaningful organizational progress.
OKRs (Objectives and Key Results) have become the latest management framework to suffer the fate of becoming popular too quickly, to the point where in many organizations, OKRs are a theater/charade with little useful substance or benefits. That’s a shame because OKRs have huge potential if used effectively. So let’s go about fixing your OKRs!
Why OKRs
Let’s start with the basics. What are OKRs even about?
OKRs aim to help you execute effectively on what matters most (your strategy), while overcoming silos, politics and turf wars, the ongoing grind (aka whirlwind), and other management challenges. To face all of these challenges, OKRs provide organizational alignment and focus.
OKRs – an Alignment Framework – a collaborative goal-setting methodology used by teams and individuals to set challenging, ambitious goals with measurable results. OKRs are how you track progress, create alignment, and encourage engagement around measurable goals.
Let’s now dive into HOW OKRs (used well) set you up for success and what might go wrong.
Achieving Focus – Focusing on the few Strategic Objectives
OKRs should help you focus on your strategic priorities. Having a small set of strategic objectives reduces context switching and provides a rallying cry that helps cut through silos and politics.
Choosing where to focus is hard, though. It’s much easier to define an OKR for everything – and then when everything is important, nothing is really important. and that’s exactly what we often see out there.
So with that in mind –
Avoid … mapping all planned initiatives to OKRs.
Try … rallying around 1-2 OKRs.
Working IN the business vs. working ON the business
Another way organizations drown themselves in OKRs is by having OKRs for everything.
Running the business doesn’t require OKRs. Key Performance Indicators (KPIs) can be used to manage/monitor operational work.
OKRs should be used just for development/growth work – work we do to change how we do things.
As you might imagine, This distinction helps reduce the number of OKRs significantly, leaving a set of fewer, more focused objectives.
Development/Growth/Transformational work typically involves more uncertainty and complexity than running the business as usual. In this environment, a lot is unknown – What’s the best way to achieve the goal? Does the goal still make sense?
Our way of working ON the business might need to look different than our way of working IN the business. (see this article for a deeper dive on what working ON the business might look like, leverage the perspective of Private Equity firms who focus on working on the business to maximize value creation)
This environment calls for evidence-based management – a management approach designed to improve outcomes when facing complexity through unleashing empiricism, self-management, and cross-functional collaboration.
OKRs are designed to be an evidence-based management approach. But there are a couple of key principles and practices that need to be in place for that to take place.
Rally around Outcomes (rather than managing outputs/activities)
One key aspect in ensuring OKRs enable evidence-based management is the type of goals we use. Managing outputs and activities can work reasonably well for working in the business since that work is typically operational and defined.
On the other hand, Using output/activity-based goals to work ON the business fixes plans, specifications, and designs too early. It reinforces a “factory” mindset where people focus on their deliverables rather than the wider problem/opportunity. And it lends itself to heavy-handed command and control.
For complex, uncertain work, you should set goals using outcomes. Outcome-based OKRs unleash self-management, empiricism, and people’s creativity to explore/discover. They create environments where people are empowered to work together to solve problems. This is how you should be working ON the business.
One of the challenges with managing through outcome-based goals is that you need to wait longer to see outcomes – making it tempting to manage through outputs or even activities. But remember – the role of OKRs isn’t to manage the day-to-day. It is to provide alignment around where to aim. People can use other processes to manage their work toward the OKRs.
Instead of breaking outcomes into outputs/activities, experiment with identifying intermediate outcomes. This is challenging but satisfying (TIP: Slicing outcomes is similar to identifying a Minimum Viable Product, Minimally marketable features, and Slicing Stories… so your Product leaders and Agile practitioners can help out on this front). If coming up with outcome-based KRs is too hard, Start with making sure at least the qualitative Objectives are outcome-focused and, over time, evolve from output towards outcome KRs.
Aligned Initiative over Command and Control
When leaders want to align their wider organization around their strategic goals, they often cascade OKRs throughout the organization. This strict cascading means that by the time you get to the people who will work towards the goals, they are bound to tasks/activities and don’t have the maneuvering room they need to seek the best way to achieve the goal, not to say reconsider what’s the best goal. This looks quite similar to OKR’s predecessor – Management by Objectives (MBO) which was very control-oriented. And it results in people who are disengaged. (did anyone say “quiet quitting”?)
There’s a false dichotomy that many leaders fall for, which is the belief that alignment requires control. Actually, alignment and control are two separate aspects that can work in concert to create effective management. Donald Reinertsen calls this Aligned Initiative. David L Marquet talks about Intent-based Leadership. Henrik Kniberg, in his usual brilliance, maybe nailed it best in this diagram describing Spotify’s “Aligned Autonomy” engineering culture principle (Jason Yip elaborates on this principle here).
Why does initiative/autonomy matter so much? There are two main reasons. The most important one is that in the creative work that working ON the business requires, the best solutions emerge from the people in the trenches. And by providing them with a clear goal and empowering them to take the initiative, we dramatically improve our chances of achieving the desired outcomes. A secondary benefit is that people are intrinsically motivated by being empowered and provided with the right level of autonomy.
The key, then, is to achieve alignment without strict cascading. Leaders should use OKRs to provide context and direction. To inform about why rather than prescribe what/how. Teams/groups then come up with their OKRs. The connection can be reinforced as part of the “Why Now” for each objective. Teams/Groups share their intent with each other and with relevant leaders to help ensure alignment in an environment of empowerment/autonomy.
(This might seem like a complex process to pull off… the good news is that there’s a lot to learn from agile ways of working about facilitating such processes. For example, I helped a fast-growing biotech startup create an approach for cross-company OKR planning leveraging a process similar to SAFe’s PI/Big Room Planning)
Figuring out the right Cadence
A key aspect of evidence-based management is the feedback loop. Many organizations set OKRs for the quarter and then forget about them until the end of the quarter. It’s like setting your sales quota and only checking back at the end of the quarter. Recipe for disaster, right?
The other extreme is to micro-manage OKRs to death.
It’s all about finding the “goldilocks” cadence that provides frequent enough transparency and the opportunity to inspect and adapt at the right level. There can be a different cadence for everyone involved in achieving an OKR as compared to the cadence involving all stakeholders interested in that OKR. The right cadence also provides an opportunity to reinforce/communicate strategic priorities and focus.
The Scrum framework provides one example of how such a cadence could look. Consider a cadence that involves Planning, Reviewing, and Retrospecting with a clear distinction between the team working on the OKR and its stakeholders.
Cross-functional Alignment
Leaders struggle to manage the cross-functional collaboration and dependencies many OKRs require. The coordination overhead makes it tempting to divide and conquer and cascade the OKRs into focused/defined OKRs for each function/group. The problem is that this immediately turns into output/activity focus and ends up with the same challenges described earlier in the Rally around Outcomes section. Why? Because functions cannot own cross-functional outcomes.
So what’s the alternative? To organize around OKRs. After identifying the few real OKRs, assess who’s needed to work towards each of them. If they require cross-functional collaboration, create an empowered cross-functional work team to make collaboration easier. Another benefit of organizing around OKRs is that working on a team around a clear business strategic goal with a clear, quantifiable metric that the team is empowered to have a direct impact on boosts the feeling of purpose and creates better engagement and motivation.
Disconnect/confusion between OKRs and agile ways of working
I often see teams and organizations that struggle with the relationship between OKRs and agile ways of working. They’re unsure of the best way to relate OKRs to their Backlogs and feel there’s a redundancy between the agile and OKRs cadence.
Hopefully, at this point of the discussion, you can see that OKRs and agile ways of working are very similar. Both are based on focus, cross-functional collaboration, alignment, empowerment, and empiricism.
So how do we address the overlaps?
Some OKRs map cleanly onto existing teams/groups in a product development organization. In this scenario, they can inform the creation of Product Backlog Items for the team/s to focus on (or the creation of Features/Epics in a higher-level backlog ). If a new product development team or team of teams is created to focus on a cross-cutting OKR, the OKR can become the Product Goal / Vision for this new group. In both cases, how we’re doing on our OKRs should be inspected during Planning and Review events and inform decision-making. There’s no need for an additional ongoing OKR cadence. Quarterly or so OKR review/planning can replace “Release Planning” with a higher focus on outcomes/impact. If needed, this OKR review/planning can include a “dry run” planning exercise along the lines of SAFe’s PI Planning to make sure that the OKRs are both aligned with the business stakeholders and realistic.
There’s a wider opportunity here, though. While Scrum was created as a framework for managing product development, it is appropriate for working on any complex problem. As we’ve established earlier, work to achieve OKRs is typically complex, even when it’s not product development work. The natural next step is to apply Scrum (or other agile ways of working) as the approach to doing the work towards achieving the OKR. Scrum can become the operating system for working ON the business.
All together now – OKRs AND Agility for the win
To sum up, OKRs and Agile/Scrum aren’t in conflict. Looking at OKRs with Agile/Scrum lenses reinforces the first principles that OKRs are based on. To successfully leverage OKRs, you should:
Focus on working ON the business vs. IN the business
Stop starting, start finishing – Focus on a few key strategic initiatives (maybe even just one)
Rally around outcomes rather than micro-manage outputs/activities
Provide alignment and enable initiative through empowered teams/groups
Organize around value – leveraging OKRs
Leverage agile/scrum to execute on OKRs
When in doubt – go back to first principles – Alignment, Empowerment, Focus, Empiricism
If you’re curious to learn more about these principles and how to apply them – a good place to start is the Evidence-based-management framework. The Scrum.org Evidence-based Management Training (PAL-EBM) workshop is a one-day workshop that explores this space and can be a great way to start fixing your OKRs or, better yet, get started the right way…
The title of my post may read like acronym soup but all of these concepts play a critical role in SAFe, and understanding how they’re connected is important to success. After exploring some connections, I will suggest some actions you can take while designing, evaluating, or accelerating your implementation.
KPIs and OKRs
The SAFe Value Stream KPIs article describes Key Performance Indicators (KPIs) as “the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes. “
That includes:
Health of day-to-day performance
Work to create sustainable change in performance
Objectives and Key Results ( OKRs) are meant to be about driving and evaluating change rather than maintaining the status quo. Therefore, they are a special kind of KPI. Objectives point towards the desired state. Key results measure progress towards that desired state.
Like Strategic Themes, most OKRs point to a desired change in business performance. These OKRs would be the ones that company leadership cares about. And they would be advanced through the efforts of a DVS (or multiple ones).
For example, if the business wants to move to a subscription/SaaS model, that’s a change in the operating model-a change in how the OVS looks and operates. That change is supported by the development of new systems and capabilities, which is work that will be accomplished by a DVS (or multiple ones).
This view enables us to recognize the wider application of the DVS concept that we talk about in SAFe 5. Business agility means using Agile and SAFe constructs to develop any sort of change the business needs, regardless of whether that change includes IT or technology.
Whenever we are trying to change our operation, there’s a question about how much variability we’re expecting around this change. Is there more known than unknown? Or vice versa? Are we making this change in an environment of volatility, uncertainty, complexity, and ambiguity? If yes, then using a DVS construct that employs empiricism to seek the right answers to how to achieve the OKR is essential, regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, that would still benefit from an Agile and SAFe DVS approach.
These OKRs would then find themselves elaborated and advanced through the backlogs and backlog items in the various ARTs and teams involved in this OKR.
In some cases, an OKR would drive the creation of a focused DVS. This is the culmination of the Organize around Value Lean-Agile SAFe Principle. This is why Strategic Themes and OKRs should be an important consideration when trying to identify value streams and ARTs (in the Value Stream and ART identification workshop). And a significant new theme/OKR should trigger some rethinking of whether the current DVS network is optimally organized to support the new value creation goals set by the organization.
Maintaining the Health of the Operation
As mentioned earlier, maintaining the health of the operation is also tracked through KPIs. Here we expect stability and predictability in performance. It’s crucial work but it’s not what OKRs or Strategic Themes are about.
This work can be simple, complex, or even chaotic depending on the domain. The desire of any organization is to bring its operation under as much control as possible and minimize variability as it makes sense in the business domain. What this means is that in many cases, we don’t need Agile and empiricism in order to actually run the operation. Lean and flow techniques can still be useful to create sustainable, healthy flow (see more in the Organizational Agility competency).
Whenever people working in the OVS switch to improving the OVS (or in other words working on versus in the operation), they are, in essence, moving over implicitly to a DVS.
Some organizations make this duality explicit by creating a DVS that involves a combination of people who spend some of their time in the OVS and some of their time working on it together with people who are focused on working on the OVS. For example, an orthopedic clinic network in New England created a DVS comprising clinicians, doctors, PAs, and billing managers (that work the majority of their time in the OVS) together with IT professionals. Major improvements to the OVS happen in this DVS.
Improving the Development Value Stream
The DVS needs to relentlessly improve and learn as well. Examples of OKRs in this space could be: improving time-to-market, as measured by improved flow time or by improving the predictability of business value delivered, as measured by improved flow predictability. It could also be: organize around value, measured by the number of dependencies and the reduction in the number of Solution Trains required.
This is also where the SAFe transformation or Agile journey lives. There are ways to improve DVSs or the overall network of DVSs, creating a much-improved business capability to enhance its operation and advance business OKRs.
Implementing OKRs in this space relates more to enablers in the SAFe backlogs than to features or capabilities. Again, these OKRs change the way the DVS works.
Running the Development Value Stream
Similar metrics can be used as KPIs that help maintain the health of the DVS on an ongoing basis. For example, if technical debt is currently under control, a KPI monitoring it might suffice and hopefully will help avoid a major technical debt crisis. If we weren’t diligent enough to avoid the crisis, an objective could be put in place to significantly reduce the amount of technical debt. Achieving a certain threshold for a tech debt KPI could serve as a key result (KR) for this objective. Once it’s achieved, we might leave the tech debt KPI in place to maintain health.
It’s like continuing to monitor your weight after you’ve gone on a serious diet. During the diet, you have an objective of achieving a healthy weight with a KR tracking BMI and aiming to get below 25. After achieving your objective, you continue to track your BMI as a KPI.
Taking Action to Advance Your Implementation Using OKRs
In this blog post, we explored the relationship between operational and development value streams and the Strategic Themes and OKRs. We’ve seen OVS KPIs and OKRs as well as DVS OKRs and KPIs.
A key step in accelerating business agility is to continually assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment.
Start by reviewing your OKRs and KPIs and categorize them according to OVS/DVS/Change/Run.
You can use the matrix below.
This process can also be used in a Value Stream Identification workshop for the initial design of the implementation or whenever you want to inspect and adapt it.
Find me on LinkedIn to learn more about making these connections in your SAFe context via an OKR workshop.
Improving Focus and Alignment by Organizing around OKRs and managing OKR Flow
Today, I wanted to share two quick observations about OKRs.
Too many teams working on each strategic OKR
I encounter many organizations that use OKRs. Too many of them have this crazy matrix where the high-level OKRs — those that aim to achieve the organization’s strategy — map to too many teams/functions in the organization. This creates a need to cascade the OKRs, create sub-OKRs, or other techniques which eventually create a larger and larger distance between the OKRs at the team level and the strategic OKRs. While this at least creates transparency of who’s involved in executing each aspect of the strategy, we can and should do better.
One key thing that unlocks agility and value is to “Organize around Value”. Scrum talks about each team having ONE Product Goal they focus on. SAFe has a specific principle around “Organizing around value”.
If you’re using OKRs One question to ask yourself is what is the relationship between OKRs and teams/teams of teams. If most OKRs require a multitude of teams across the organization/portfolio to achieve them, this will require a lot of coordination.
Try reorganizing into a value stream network/topology/team structure that aligns with your OKRs — where each team/team of teams can focus, and where there is clearer accountability around which team/group owns a specific high-level OKR.
Yes, you can find OKR and Agile management tools that will let you deal with complex networks of cascading OKRs, but Simplicity FTW…
Too many OKRs
Another symptom I’m seeing way too often is too many OKRs. Some of that is related to the OKR matrix I mentioned above. Some of it is just plain old push vs pull and classic wishful thinking at all levels. What could we do about that? Do we have a proven approach that can help? mmm…
Maybe we should visualize the FLOW of OKRs through the funnel of considering them, prioritizing/refining, committing to them, working on them, reviewing, achieving… How about LIMITING and REDUCING the amount of OKRs in progress across the organization at any point in time — the alignment that OKRs promise relies on focus rather than trying to boil the ocean Next, let’s manage the flow of OKRs proactively. Maybe even use some metrics like OKR cycle time, throughput, WIP, and aging. Let’s inspect the flow from time to time. We might learn a few things. Maybe we should adapt the definition of how these OKRs flow and how we’re managing them.
How many of you ARE leveraging Kanban/Flow practices to improve how your organization uses OKRs to align strategy and execution?
PS do you see how similar this would be to a portfolio Kanban? Could it be the next generation of portfolio Kanbans? ????
Aligning Scrum Team Topology to Strategy with OKRs and Product Goals
Yeah, I know. Could I squeeze more buzzwords into the title? I guess I could include Digital Transformation, Cloud, AI, and Machine Learning for effect. But seriously, I wanted to share some insights around how to align your Scrum Teams to your strategy leveraging OKRs and Product Goals.
Driving Change Using OKRs
We maintain performance by tracking the health of Key Performance Indicators(KPIs). We use Objectives and Key Results (OKRs) to drive performance change. Objectives point towards the desired state. Key results measure progress towards that desired state.
This performance change could be about our product or the ability to innovate/create that product. (Gap between realized and unrealized value / ability to innovate in evidence-based management (EBM) terms)
By setting OKRs we’re typically setting our sights on a complex problem — the space where Scrum and Empiricism thrive.
Achieving OKRs using Empiricism and Scrum
Working in self-managed empowered multi-disciplinary teams using fast feedback loops is a great way to tackle complex problems.
This is true regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, that would still benefit from using Scrum’s empirical team-based approach.
For example, if a health care provider is aiming to digitize their patient journey to streamline it and make it more efficient, part of that will be to implement an electronic medical records system (EMR). But the objective isn’t just about implementing an IT system. It’s a change in the operating model. The organization supports this change by the development of new procedures, systems, and capabilities.
Focusing on Outcomes rather than Outputs
OKRs and Scrum are both designed to focus on outcomes over outputs. Most agile practitioners would recognize the N from “INVEST in User Stories” which stands for creating Negotiable user stories that provide optionality/flexibility for learning about what’s the best way to achieve outcomes. Having said that, most agile practitioners do feel like user stories are a form of requirements — meaning they are required.
Actually, user stories, any other form of Product Backlog Items, and even the Sprint Goal should be considered options — meaning they are optional. We currently think they are valuable, but we might learn of more valuable things to focus on.
Even the Product Goal is just an option. Maybe there we will find a better Product Goal for the Scrum Team to rally around or maybe there’s another better Goal that requires a different team topology.
Be Agile about your OKRs
Similarly, OKRs reflect the strategic direction at a certain point in time. We might learn something that would suggest a change in the Key Results or even the Objective itself. The frequent transparency provided by sprinting towards an OKR enhances the empiricism that might drive these realizations and is an enabler for strategic agility.
Many organizations fail to see this perspective. They consider OKRs as if they’re set in stone.
The same sort of time, budget, scope-oriented project management mindset that is hampering so many agile teams is affecting OKR implementations as well.
The problem with activity/output-based OKRs
Many OKR practitioners struggle to figure out how to break an annual strategy/OKR into meaningful outcome-oriented quarterly OKRs. By default, they break the big outcome into implementation steps a.k.a activity/output/milestone OKRs. It’s the project management mindset again — we basically bring in the classic work breakdown structure (WBS) into the OKR framework.
Going back to the patient journey digitization effort. Many organizations would define an initial OKR of choosing an EMR system. This is an example of an activity. It doesn’t deliver business value on its own. Once we set this OKR it’s harder to think of alternatives that might obviate the need for an EMR system in order to achieve the desired outcomes.
We’ve seen it happen countless times on agile teams struggling to slice stories in a meaningful manner and not sure how to come up with a useful Increment at the end of a short Sprint.
When working with OKRs we can leverage the same techniques that help these agile teams identify valuable partial outcomes that enable us to inspect and adapt our tactical and strategic direction.
Organizing Around OKRs
Another common reason why we see output-based OKRs is the team topology.
We often see organizations defining OKRs and then mapping them to their existing teams. In this example, this will mean cascading OKRs throughout different IT and business functions. The cascaded OKR grows farther and farther away from the desired Outcome because functions/silos can’t deliver these outcomes. They can only deliver outputs. Hence, the prevalence of Output-based OKRs.
After we define these OKRs the different functions will, of course, try to collaborate but we know how hard it is to collaborate effectively across functions. And with each group focused on an output-based OKR, we lose the opportunity to align around outcomes and are back to managing “projects”. This might work fine for some OKRs. But some OKRs are simply too complex to successfully achieve this way.
OKR-Driven Team Topology
A better approach might be to consider the level of complexity each OKR exists in. Then, create focused cross-functional Scrum Teams around the most complex OKRs. You might call this “OKR Driven Team Topology”.
Each one of these teams would focus on an OKR and have that as their Product Goal. Their Product Owner would have ownership of the OKR. This team would be THE team to talk to about this OKR.
If an OKR requires more people than would fit one Scrum Team consider forming a Nexus (or any other agile team of teams structure) around this Product Goal. Or maybe you can split the Objective and have separate Scrum Teams working on each Key Results (KR). There are multiple possible topologies.
The key point is to try and keep the outcome orientation all the way to the trenches where people work to create usable valuable Increments. In your Sprint Review, Inspect the Increments created with an eye towards your OKR. Adapting might mean changing tactics of how to achieve the OKR or even changing the Key Result or the Objective itself.
OKRs and Focus
The approach I laid out above is the ultimate way to achieve focus on one strategic outcome.
Realistically, not all OKRs would map 1:1 to a team or Nexus. And that’s ok. For example, you might have 20% of your most complex/critical OKRs handled using dedicated teams with the rest of them mapped to existing teams/functions.
If that’s the approach you’re taking, make sure you’re limiting the amount of OKRs that map to each team in each time period. For example, set an “OKR in Process” limit of 3 per team per quarter. And when a team hits the limit, don’t set the OKR for this quarter. This will drive a tough but important conversation about priorities. But it will set the teams and therefore the organization for a better chance to actually deliver on the strategic outcomes that matter the most.
Having 3 OKRs per quarter that you actually achieve is much better than 6 OKRs per quarter that drag on from quarter to quarter.
NOTE: You might find it useful to start tracking flow metrics (WIP, Flow/Cycle time, Throughput, Aging) as they relate to your OKRs…
When to organize around outcomes with OKRs and Scrum
In this article, we explored the relationship between OKRs, Scrum, the teams’ topology, and outcome/output-oriented OKRs (and teams!).
A key step in accelerating agility is to continuously assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment.
This is the time of the year when many of you are drafting your annual OKRs. Take this opportunity to consider whether your current team topology (in IT/technology and beyond!) is well-positioned to achieve these OKRs.
Another opportunity to use this lens is If you’re currently trying to figure out what your Scrum team topology should look like (e.g. when starting your agile journey, extending or accelerating it). Considering your strategic focus via OKRs is a great perspective to consider in this process.
A discussion about Strategy/OKRs and how they map to team topology is now a core part of my conversations with clients and our implementation strategy workshops.
Are you trying to figure out how to connect OKRs and Scrum in a way that organizes around outcomes? Feel free to reach out and we can discuss how I might be able to help.
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…
I’m hearing from more and more companies that are using the Entrepreneurial Operating System® (EOS®) and are also looking at or practicing Agile e.g., using Scrum. In discussions with these companies, two key questions surface time after time:
My teams want to use Agile/Scrum — is that aligned with the fact that we’re using EOS® in the organization?
My teams use Agile/Scrum; can we use EOS®?
The short answer is that Agile and specifically Scrum and EOS®are mostly complementary.
EOS®, as well as Agile approaches, emphasize focus, alignment, and a disciplined approach with structured events, artifacts, and policies that limit the amount of work in process (WIP) systematically, and create better flow with cadence.
So what’s one big difference between Agile/Scrum compared to EOS®? Transparency and Empiricism
Transparency is emphasized in both but is used differently. Both approaches make the work transparent. Agile frameworks like Scrum are designed to deal with VUCA (Volatility, Uncertainty, Complexity, Ambiguity) through empiricism — an aspect that EOS® isn’t explicitly solving for. And in this environment, Transparency goes much further — it is not just awareness of what the team and individuals on the team are working on — it is the transparency of whether the product of the team’s work (whether the team is building a product or leading a company) is working and effective.
Scrum can help teams:
align towards the Vision — making the Vision or a specific sub-aspect of it their “Product Goal” (even if they’re not a Product team — it’s the overarching goal for the product of their work — be it winning deals, operating the company, growing, etc. )
plan and deliver on their Rocks and achieve Traction®- by using Product Backlogs, Sprints, and potentially concepts like “Program Increments” from SAFe, which align very well with the EOS®Quarter.
EOS® Big Rocks can map almost 1:1 to PI Objectives. For teams, We recommend having them at the team level and not as individual contributor to drive collaborative collective ownership toward results. When scaling across the organization, each team/function does have its list of PI Objectives/Big Rocks like in EOS, as well as an organization-wide list of Big Rocks / PI Objectives.
SAFe PI Planning or other types of Big Room Planning could complement EOS®Quarterly planning by involving the actual Teams and not just the function leads in the planning and accountability cycle.
Issues are very similar to Risks and how they’re managed in SAFe via ongoing ROAMing (Resolving, Owning, Accepting, Mitigating)
Scrum Sprints map to the Weekly Level 10 cycle. Sprint Review/Retrospective/Planning is an opportunity to inspect and adapt where we are within the quarter, which is especially important in VUCA. We’re not just executing a quarterly plan. We’re intentionally learning what works/doesn’t and adjusting course accordingly.
Another opportunity is to use Scrum at the leadership level — as a way to apply more empiricism to complement EOS®discipline.
All of the above could be used by the leadership team itself.
The “Product Backlog” is focused on the “product” of the leadership team’s work — which is leading the company — solving issues, growing, implementing strategies/tactics, etc. Changes in Process, People, Dealing with Issues, Advancing Rocks.
The Increment of each Sprint is not just a “Done / Not Done” answer to to-do items — it’s an actual “working change” in how the company operates. (For example — list of candidates for a VP position, draft scorecard, analysis of desired profitability range, etc. ) This Increment is ready for the leadership team to inspect, review, to adapt their plans (Product Backlog) accordingly every Sprint/Week. A leadership team could also decide to run longer Sprints e.g. Monthly, and use a weekly cycle similar to Scrum’s “Daily Scrum” to inspect and adapt progress within the Sprint. The Sprint length should match the level of VUCA the leadership team/company is facing.
The leadership Team acts as the “Developers” of the “Product.”
The PO/SM Scrum roles could map several ways –
Option 1
Visionary — Product Owner
Integrator — Scrum Master
Option 2
Visionary and Integrator™- Sharing the Product Owner role
Dedicated coach/Scrum expert as the Scrum Master
Similar to how EOS®starts at the top, Organizations NOT using Scrum yet could use Scrum to complement EOS® at the top level and then expand from there into the various teams.
This would follow the guidelines/mapping described above. In this scenario, solid Scrum Training/Coaching would be provided to the leadership team in advance of the whole organization, and they would become Scrum Practitioners better able to understand and drive what’s going on when Scrum/EOS®gets implemented throughout the organization.
For teams in an organization using EOS®…
If you’re starting to use Scrum in an organization using EOS®or if you’re using Scrum and your organization is in the process of implementing EOS®the list of mappings above will help you create some common language and reduce the conflict/confusion that might arise due to running both EOS®and Scrum at the same time.
Real/Imaginary conflicts between Scrum and EOS®
Is EOS®Waterfall?
The main aspect of EOS®that looks like waterfall is that it runs a quarterly cycle with planning the Rocks for the quarter in advance. I don’t consider that waterfall. And if care is given to making sure that Rocks focus on WHAT rather than HOW and leaves enough space to account for variability/learning, I don’t see a problem. It’s very similar to SAFe’s PI-level planning, which is again properly done with an eye towards emerging learning and adjusting course as needed while staying focused on the high-level objectives for the quarter.
How about individual accountability in EOS®- isn’t that in conflict with Scrum’s “Collective Ownership” approach? Isn’t EOS®in the way of Teamwork?
Indeed this is a potential area of conflict. But even EOS®makes several mentions of the fact that to succeed, team members need to prioritize the team’s rocks over their individual ones and support each other. When implementing EOS®, there should be an emphasis on accountability towards team rocks rather than individual rocks, even at the leadership team level.
Isn’t EOS® Micro-management under a thin veil?
The way to look at this is that EOS®allows teams to micro-manage their work — with the understanding that in a VUCA environment, there’ll be lots of surprises and emerging realities that are better addressed quickly. The Integrator role, like the Scrum Master, should lead the team through this discipline of tight-loop inspection and adaptation rather than feel a need to micromanage work or output. Learning the proper “Leaders who Serve” Scrum Master mindset would be very useful to any EOS leader if he wants to avoid EOS becoming a checklist-based micro-management tool.
Conclusion
As you can see above, as long as you understand the purpose and practices of EOS®, Agile, and Scrum and think about how they can complement each other, you can use them in tandem.
Furthermore – To maximize the effectiveness of EOS, you might want to enhance it with the empiricism / evidence-based management that Scrum provides.
If you want some help thinking through what this would mean in your context, we’ll be happy to discuss it further.
