Aligning Scrum Team Topology to Strategy with OKRs and Product Goals
I know. Could I at some point fit more popular expressions into the title? I could incorporate Digital Transformation, Cloud, AI, and Machine Learning for impact. Be that as it may, genuinely, I needed to share a few experiences around how to adjust your Scrum Teams to your methodology utilizing OKRs and Product Goals.
Driving Change Using OKRs
We keep up with execution by following the soundness of Key Performance Indicators (KPIs). We use Objectives and Key Results (OKRs) to drive execution change. Targets point towards the ideal state. Key outcomes measure progress towards that ideal state. This presentation change could be about our item or the capacity to develop/make that item. (Hole among understood and hidden esteem/capacity to enhance in Evidence-Based Management (EBM) terms.
By setting OKRs we’re normally focusing on an intricate issue – the space where Scrum and Empiricism flourish.
Achieving OKRs using Empiricism and Scrum
We stay aware of execution by following the adequacy of Key Performance Indicators (KPIs). We use Objectives and Key Results (OKRs) to drive execution change. Targets point towards the best state. Key results measure progress towards that optimal state. This shows change could be about our thing or the ability to create/make that thing. (Opening among comprehended and secret regard/ability to upgrade in Evidence-Based Management (EBM) terms.
By setting OKRs we’re ordinarily zeroing in on an unpredictable issue – the space where Scrum and Empiricism thrive.
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.
User stories, any other form of Product Backlog Items and even the Sprint Goal should be considered options – meaning they are optional.
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
Likewise, OKRs reflect the essential heading at one point in time. We could learn something that would recommend an adjustment of the Key Results or even the actual Objective. The continuous straightforwardness given by running towards an OKR upgrades the experimentation that could drive these acknowledge and is an empowering agent for vital readiness.
Numerous associations neglect to see this point of view. They consider OKRs as though they’re firmly established.
The problem with activity/output-based OKRs
Numerous OKR professionals battle to sort out some way to break a yearly methodology/OKR into significant results situated quarterly OKRs. As a matter of course, they break the enormous result into execution steps a.k.a action/yield/achievement OKRs. It’s the undertaking the executive’s outlook once more – we acquire the exemplary work breakdown structure (WBS) into the OKR system.
Returning to the patient excursion digitization exertion. Numerous associations would characterize an underlying OKR for picking an EMR framework. This is an illustration of a movement. It doesn’t convey business esteem all alone. When we set this OKR it’s harder to consider options that could hinder the requirement for an EMR framework to accomplish the ideal results.
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. This might work fine for some OKRs. But some OKRs are simply too complex to successfully achieve this way.
OKR-Driven Team Topology
A superior methodology may be to consider the degree of intricacy each OKR exists in. Then, make centered cross-practical Scrum Teams around the most mind-boggling OKRs. You could refer to this as “OKR Driven Team Topology”.
Every single one of these groups would zero in on an OKR and have that as their Product Goal. Their Product Owner would have responsibility for OKR. This group would be THE group to converse with about this OKR.
On the off chance that an OKR requires a bigger number of individuals than would fit one Scrum Team consider framing a Nexus (or some other lithe group of group’s construction) around this Product Goal. Or on the other hand, perhaps you can part the Objective and have separate Scrum Teams chipping away at each Key Result (KR). There are various potential geographies.
The central issue is to attempt to hold the result directly to the channels where individuals work to make usable significant Increments. In your Sprint Review, Inspect the Increments made with an eye toward your OKR. Adjusting could mean changing strategies of how to accomplish the OKR or in any event, changing the Key Result or the actual Objective.
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 each time. 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 deliver on the strategic outcomes that matter the most.
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 the topology should look like this (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 are 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?
No Comment! Be the first one.