Integrating Scrum with Corporate OKRs
Aligning technical delivery to business goals
Scrum has become the default approach of development teams, and OKRs the default approach of management teams, so it is entirely likely that you will find yourself needing to integrate the two at some point.
Scrum and OKRs both start and end in the same place — making sure the business gets what it needs when it needs it, given those needs can change on a dime. They are both founded on worker empowerment—bottom-up self-determination rather than top-down autocracy. They both function through short, results-oriented iterations surrounded by transparency and accountability. They both deliver continuous improvements through feedback.
Moreover, each framework can be described on one side of a single sheet of paper — neither is a complex system. So on the face of it, integrating the two is simple, a straightforward task — just give the instructions to everyone, stand back, and let the magic happen!
So What’s The Problem?
As they say, the proof is in the pudding. Companies that have good governance and strong cultural values will have no problems working with either of these systems, or both together. But companies with no problems do not implement new company-wide methodologies just for something to do.
So we need to pay attention to why the new framework is being implemented, what are the problems it is expected to fix.
Are there broadly acknowledged, fundamental issues that everyone is paying attention to, or is it just a tactical response to surface symptoms—silo’ed development teams, workflow bottlenecks, too many production roll-backs, and so on?
If it’s the latter case, then it’s well worth digging into how these issues arose, what the root causes are, to avoid some nasty surprises down the road.
So many companies today are legacy organizations, cobbled together from multiple mergers, repeated down-sizings and hostile takeovers. Corporate culture, what’s left of it, is horribly garbled, everyone left to fend for themselves. The mission statement is just another wall poster, not reflected in people’s daily behavior. Fundamental values like accountability, transparency, respect, sometimes even honesty, are things that got lost in the shuffle.
Or companies have grown rapidly: the latest hires have little understanding of or attachment to the core values of the founders, and growing pains are laying bare the fault lines or blind spots in the business model.
How do we deal with that?
Now, OKRs and Scrum are both great ways to overcome these issues, get the corporate culture back to a good and happy place, and restore balance to the Force.
But that requires buy-in at all levels of the food chain. Workers, middle managers, upper management and the C-suite, all need to have pretty much the same picture of what the problem is, how these new things are going to fix it, and, as importantly, what issues they won’t fix.
So rolling out OKRs, or Scrum, or both, is very much a hearts-and-minds operation. We need to persuade workers and managers that this new thing will work for them, that they can behave in a different way and get a different outcome; that this new way of working will not jeopardize their standing, their bonuses or their jobs, but will actually improve all those things.
This requires trust, and trust is exactly what is lacking in some of these environments. Upper management may be fully bought in, but low level employees will just try to keep their heads down, hoping this too shall pass. They are stuck in their discomfort zones, convinced it will be even more painful if they step outside them.
If that is the case, approaches beyond just rolling out the core frameworks are vital. If you don’t have experience with corporate dysfunctionality, then turn to resources like Patrick Lencioni’s “Five Dysfunctions of a Team.”
And middle managers can also feel very threatened: these frameworks empower workers, and provide transparency across the company into what’s going on with their teams, so what is a manager’s role in this new environment? Are they just being squeezed out, made redundant?
We need to help these middle managers to understand that their job is not going away, but evolving, moving from telling people what to do, to helping them do things. They will become mentors and coaches to their direct reports, and advocates for them to senior managers. And a key role is looking across the organization, coordinating activities outside silos, across teams.
As with any evolution, any behavioral change, this will take time and patience: focus on culture and behavior. Help people understand the key principles underlying both OKRs and Scrum — worker empowerment and self-direction, accountability and transparency, identifying and fixing problems without blame or shame, agile responses to changed circumstances.
By achieving small wins, we can build trust and work our way up to the big wins. It may well require four or five iterations, or more, before the corporation as a whole gets comfortable, and learns to trust the process.
Why Scrum needs OKRs
Scrum has one big limitation: it will not help with corporate silos — in pure Scrum, there is nothing in the framework itself to tie together different teams, to reconcile competing goals or coordinate cross-dependencies.
All that falls on the Product Owners, if they are even aware of it, making them the single point of failure if they miss something, the exact opposite of what we are looking for in a fault tolerant system.
On paper, Scrum obfuscates this issue by declaring that the entire organization needs to respect the Product Owners’ decisions. In any real corporation where given managers have sufficient authority to be solely responsible for their decisions, they will not have the time to engage with individual Scrum teams, and will be spread too thin to be effective.
Furthermore, Scrum doesn’t balance resources across the organization. It works as a throttle —this is how much work that can be accomplished by this team with this many resources.
But there is nothing to help decide how many resources should be assigned in the first place, how big the team should be, or how many teams applied to any particular goal. The company needs a way to picture the demand across the organization, to balance the supply against that
OKRs to the rescue!
Why OKR needs Scrum
OKRs depend on granular measurements of progress towards the key results: this is an essential part of the feedback loop, to get early warnings that key results are in jeopardy or will be missed.
But it is difficult or impossible to track progress toward a big bang, yes/no result. Major technology installations, company-wide upgrades, big software releases — all of these can take more than one OKR cycle, sometimes even more than a year, to fully deliver. How do we track those things in a measurable way?
What is needed is something that converts these big waterfall projects into small enough steps for progress, or the lack of it, to be instantly obvious.
Scrum to the rescue!
Nuts & Bolts
More than anything, the value of Scrum is keeping technology groups accountable to the business, closely aligned with evolving business goals.
This where OKRs fit in, providing a clear and well-understood signal of what the business wants. This is perfect input into the Scrum Backlog — this is what we want, and this is how we will be able to tell if we got it.
The OKRs simply become Epics in the Product Backlog, the big picture things that will be divided and divided again until the resulting Stories are actionable within one Scrum Sprint.
The cycle for OKRs is typically quarterly (sometimes monthly); for Scrum teams, the Sprint cycle is usually weekly or bi-weekly (sometimes monthly).
But Scrum also has the concept of Releases, a longer cycle generally consisting of six sprints, with the last Sprint used for a deeper look back and planning activities for future Releases. In some cases, it may also be used for actual releases or catch-up activities.
So for companies with a longer OKR cycle and shorter Sprints, the Release cycle is likely the best way to align Scrum with the OKR cycle.
Another major benefit of well-implemented OKRs is goal discipline. Any number of corporate disasters stem from trying to hit some target at any cost, trampling vital competing goals in the process — Boeing’s 737 Max 8 is the latest horrifying example, the single-minded focus on avoiding pilot re-training utterly eclipsing passenger safety, individual teams recognizing the issue but too silo’ed to give it the attention it needed.
By pairing key results, OKRs ensure the company is not giving up something important just to hit a number. These are results that both need to be achieved at the same time, for either to be valuable to the business.
For example, a key result might be increasing the amount of data processed, with its pair being to keep constant or reduce the number of associated processing errors.
This is a huge benefit when a lot of stories in the Backlog are “keep the lights on” maintenance, as they so often are for legacy teams being converted to Scrum. The company needs to reflect that effort somewhere in its top level goals and resource assignments, and paired results ensure that it’s not given short shrift and forgotten.
And this helps in Backlog Review: every Story on the Backlog should fit into an OKR Epic. If not, then the orphan Stories lead to a useful conversation — should this Story be dropped as irrelevant to company goals, or is there some vital objective that the company is overlooking, a key result that needs to be added or updated to reflect it?
Reconciling The Differences
However, there is still a critical difference in approach between OKRs and Scrum that we need to reconcile.
The end product of Scrum is steady state — a predictable output, a reliable pace that the business can comfortably make forecasts against. Through iteration, Sprint capacity becomes well understood, and on average Sprints will come to deliver a consistent number of Story Points every time.
The Release plan then provides a reasonably definite delivery: this is what you will be getting this cycle, most likely, if you don’t change your minds. Individual Sprint outcomes will ripple up and down, but together over the Release, by intention they will deliver 100% of the Release plan, all else being equal.
By contrast, OKRs are designed to be aggressive, with “reach” goals: the corporation is only expecting only 60–80% of the key results to be met (the specific percentage being set at the corporate level based on risk tolerance). This is partly because people respond well to inspirational goals. But just as importantly, failing to reach the goal is itself a useful result: the failure flushes out the weak points that can be fixed in following cycles.
This discrepancy is something Product Owners, Scrum Masters and managers need to pay close attention to, making sure they reach goals of the organization do not disrupt the steady cadence of the Scrum teams.
Of course, the granular nature of Sprints plays a key role in tracking progress towards those reach goals. It will become obvious early on if specific key results are unlikely to be met in a Release, thereby enabling the kind of conversation that is so important to both OKRs and Scrum— why not? Can we adjust something to still hit the result? What can we improve next time around?
Scrum and OKRs are both iterative, agile methodologies, and mesh well together: OKRs provide solid business goals as input to Scrum, and Scrum provides detailed tracking towards key results in return. But do be aware of the gap between steady state Scrum and OKR reach goals.
Make sure you understand the root causes of the issues the corporation is trying to solve by rolling out these frameworks, and build trust within the organization by focusing on culture and behavior, and the core principles underlying the two processes.
Adapting to OKRs and Scrum will require conceptual changes for most people, new mindsets and new behaviors. And that will take time to implement as employees and managers wrap heads around the new paradigms.