A few years ago I was on a panel in Stockholm seated next to the legend herself, Mary Poppendieck. Every opportunity to hear from Mary is an opportunity to learn, and this time was no different. One question came up about scaling Agile. Scrum is always described at the team level but agile at scale is a problem that continues to plague companies to this day. The audience member asked Mary how to solve for aligning and coordinating many teams running sprints at the same time. While she didn’t purport to have a silver bullet for agile at scale, Mary shared one approach that worked for her over her storied career: give multiple teams the same goal to achieve.
Winning and Losing Together
Mary’s approach was deceptively simple. If multiple teams were given the same goal to achieve then many of the principles of agility would organically begin to show up. Teams would have to self-organize ways of communicating between each other, knowledge management, status reporting, blockers, dependencies and everything in between. Radical transparency would be required if teams were going to reduce duplication of work and in-flight learning. Teams would change their behaviors because all of them would win or lose together. If one team hit their own “goal” while the other 3 teams co-working with them on the same challenge failed, nobody “won.” The dependency on each other would force teams to cooperate, collaborate, communicate and co-create a shared understanding of the work and ultimately a, hopefully, successful solution.
OKRs at Scale work like Agile at Scale
Many large organizations ask their teams to provide team-specific OKRs. If there are 200 teams in your company, the management of 200 team-level goals can become overwhelming. Imagine if you had 500 teams!
It can also cause one of the main anti-patterns of OKR implementation: hyperlocal optimization. One team may work hard to hit their key results but the work they’re doing inadvertently hampers another team’s progress toward their own goals. Without a clear scaling strategy the first team ultimately doesn’t care about the challenge they’re posing to their colleagues because they’re on the hook for their own goals, not their colleagues’.
One way to solve this is to take Mary’s approach to scaling Agile and apply it to scaling OKRs. Instead of asking teams to provide team-level OKRs at first, we identify a set of teams who will be dedicated to the same goal and have them, as a team of teams, set their objectives and key results. This team of teams is now on the hook, as a unit, for these goals. Hyperlocal optimization is instantly communicated and dealt with because the measure of success is global for the entire group, not the individual components that make it up.
Breaking the Key Results Down Still Make Sense
This doesn’t necessarily mean that each team doesn’t have its own team-specific goals to achieve. In fact, one of the first things to ask the component teams for is a set of key results to function as leading indicators of the group’s overall key result goals. In this way each team is working towards a thing they can influence directly but they’re doing so with:
- A clear line of sight of the overall goal they’re trying to achieve
- A transparent view into how their work is impacting other teams in the group
- Awareness that if the key results they’ve chosen don’t have the impact they predicted on the group’s goals, they’ll need to adjust their goals
Don’t Scale the Process Up
What this one simple trick does is actually reduce the amount of new processes imposed on your teams. At the very least it keeps it the same. We’re not asking for more meetings necessarily or any new ceremonies. Instead we’re allowing their ways of working to evolve into a process that makes sense for the set of teams we’ve put together and the goals they’re working towards. Everything else about working with OKRs stays the same. At scale, this reduces the number of goals and activities a company has to track overall. This simplifies the management, review and decision making process for leaders.
What have you seen work with OKRs at scale? What have you seen fail? Have you tried this approach? What’s been your experience. Leave your comments in the chat.