Consider the poor executive leader. Having devised the long-term corporate goals and created a brilliant strategy, the insurmountable problem is: how do they get the strategy delivered? How does the strategy become action?
Strategy probably feels like someone else’s problem to the teams at the other end of the organization struggling to deliver their backlog.
In popular imagination, this is simply a problem of telling people what to do. But in a post-pandemic, post-agile twenty-first century populated by millennials and Gen Z, simply telling people what to do doesn’t work – if it ever did. We know people work best when they have a voice in deciding what to do, and we know that harnessing all the brain power – and neurodiversity – means allowing everyone to take part.
Those workers spend their days far from strategy, mired in the quagmire of getting the Scrum-style backlog done. Getting one work item done is hard enough, but when the backlog of work to do is measured in hundreds, even thousands, of items, then strategy is an afterthought.
Yet, these two problems are frequently different sides of the same coin. Teams can’t execute against strategy because they are suffering from the tyranny of the backlog.
Solve Backlog Tyranny with Objective Driven Agility
This is where Objective Driven Agility (ODA) can help. ODA connects strategy with execution while overthrowing backlog tyranny by combining OKRs with Agile working.
The majority of teams have some sort of work-to-do backlog. This is probably held in an issue tracking system, but it could also be in Excel or, in the old days, a pile of physical cards sitting on someone’s desk.
Now a short-term backlog is not really a problem. A “sprint backlog” list of work items to focus on in the next few weeks can be a productive way of working.
Tyranny of the Backlog
Backlogs measured in hundreds of items, stretching months and years into the future, are the problem. Teams become lost in the backlog, and strategy is forgotten.
Product Managers, Owners, and similar are frequently reduced to cherry-picking “the biggest bang for the buck” to do. Their job is made miserable because everyone who ever made a suggestion thinks theirs should be next.
Worse, most organizations believe success is an empty backlog with every item done. Teams become feature factories, and output is put ahead of outcomes. In theory, product leaders should choose backlog items to advance strategy but faced with competing demands. Is it any surprise they don’t?
OKRs and ODA: The Perfect Combination to Success
Adding Agile-friendly OKRs plugs this gap. OKRs sit below the strategy (which may endure for years) and above the short-term (weeks/sprints). OKRs are a tool for both delivering strategy and influencing.
Having set broad goals and strategy leaders ask teams: “How can you help?” They deliberately leave white space to be filled by the teams.
Teams reply with their OKRs – usually set and reset every quarter. Teams set OKRs with respect to the leadership’s goals and strategy plus their own knowledge, customer contact, understanding of what customers are asking for, and a myriad of other facts.
Use this checklist to create a set of OKRs to effectively guide your organization toward success.
These OKRs are offered up to the leadership – and peer teams – who provide feedback. Draft OKRs can be discussed. Teams explain why they have chosen these goals. Leaders can explain why they see the world differently. Perhaps one side has information the other doesn’t, or perhaps one side has not explained themselves clearly.
Once the final OKRs are set, the teams focus on these OKRs to the exclusion of everything else. In ODA, the OKRs take priority over any backlog. Every time someone needs to decide what to do next, every planning meeting, every replenishment meeting, the question is: “What do we need to do now to advance on our quarterly goals?”
Use Kanban Zone’s OKR Kanban board template to monitor your progress more effectively.
Any backlog becomes secondary. In the extreme, you might dispense with it altogether. Although this is a radical idea for many, there are companies that do just this. Periodically, they stop, review their real goals, and reset.
If teams need to do support work as well, this is covered by OKRs, as is team improvement and technical debt work. Every few months, the team pauses to review progress, closes out one set of OKRs, and agrees on new ones for the next period.
Outcomes and customer needs come to the fore while respecting engineering. The engineering question changes from “How long will it take to do Foo?” to “How much of Foo can we do in the time we have?” There are always multiple solutions to any problem; rather than deciding which request to do based on how long each might take, engineers decide how to address needs based on the time they have.
That, in a nutshell, is Objective Driven Agility.
This was a guest blog. Please review our guest blog disclaimer.
Learn to Work Smarter, Not Harder!
Get our top articles weekly.
Table Of Contents
Discover many more posts…