The comment I get again and again about my presentations and workshops, OKRs and others, is “passionate.” And it is true, I’ve been passionate about this thing which gets called “agile” for over 15 years. Now I know “agile” has become a dirty word in some circles, all I can say is “That’s not my agile.” My agile is about engaging everyone, about engineers doing quality work, a more orderly and effective work environment. This type of agile creates benefits like meeting deadlines, satisfying customers, a more orderly work environment and ultimately happier workers and an improved return on investment.
When I stand in front of people and talk I’m talking to my former self, the coder I was 20 years ago who struggled with all the same problems engineers struggle with today: unclear requests, too much work, weak management and yes, technology frustration. That’s why I’m passionate.
So why do I get excited about OKRs? And why did I write a book about them? – especially odd when know I was originally an OKR skeptic.
Let me honest: I’m not really passionate about OKRs. I’m passionate about what they can do for agile and how they can help those doing the work. OKRs are more than a very useful tool to add to the agile toolkit. Sure it is a very useful tool but they also address problems in agile.
First off OKRs are big, not small. Agile works best in small – remember diseconomies of scale? – small teams, small stories, small releases, … this is great for effectiveness but it looses track of the big things. The outer Matroska. Well, OKRs give us a mechanism for thinking bigger.
Second, standard agile (e.g. Scrum, XP and even Kanban) has no widely accepted solution to mid-range planning. We used to talk about “release plans” but since the arrival of continuous delivery that doesn’t make sense. People struggle to produce mid-range plans that are accepted by others. OKRs can plug that hole.
These two issues intersect when it comes to backlogs, in particular Scrum Product backlogs. All those small things clog up a backlog and without some planning mechanism merely obscure the truth. Put simply, backlogs don’t scale. Backlogs are useful when we are thinking days in advance and counting product-backlog-items (PBIs) in single digits but they fail when they contain hundreds of PBIs and extend years into the future. Again, OKRs can help here.
Third, OKRs provide a framework for elevating the conversation to more senior leaders and executives. These people lack their own agile context, their time is scarce and they don’t want to be bothered with small things which last a few days. But without their involvement and affirmation teams lack “air cover” from above and struggle to escalate issues upwards.
Not only do OKRs provide a communication interface to the senior team but the same mechanism facilitates communication and co-ordination with other teams. Done right OKRs create an API for the team and can push more authority down to the teams furthering self-organization.
When teams set their own OKRs we create a powerful feedback mechanism, a strategy debugger. (Conversely, cascading OKRs down a hierarchy destroys their power and undoes many benefits of agile working.)
In other words: OKRs allow agile to grow up.
That in a nutshell is why I think why agile needs OKRs, and why I’ll be writing more about OKRs.
