The OK in OKRs

I watched Allan Kelly's Reawakening Agile with OKRs presentation at the Cambridge Agile Exchange last night. You can find a lengthy summary in his recent article for InfoQ and there's a book too, but here's a few points that caught my attention.

If you've been around the block you'll have doubtless come across OKRs — objectives and key results — and perhaps cynically think of them as the antithesis of agile working, a management tool for the top-down imposition of overcommitments.

From that perspective, promoting OKRs as a way to save agile could look a bit like the kind of sharp tactics that unscrupulous second-hand car salesmen might employ: "OKRs, one careful owner, a nice little runner, thousands of miles left in this one."

Fortunately, Allan is open about the history and specific about the contexts in which he thinks OKRs can add something. In his view, their backstory is why OKRs are also a useful hack for the kind of "mild" agile that lives in so many corporate environments. If done correctly they can be a management-friendly way to deliver more autonomy to the teams and amplify agile practices. 

And what is "correctly"? For the OKRs themselves, it's to be outcome-oriented, with measurable expectations, iterating across cycles, with the possibility of failure. Which sounds like agile, doesn't it? 

For the company culture it's that management provides goals and gives the team room to look for outcomes that contribute to them and, crucially, determine they way they'll go about achieving them. This doesn't mean teams are self-concerned islands; when interactions between teams are needed, they should be horizontal conversations to get outcomes and approaches aligned.

Quarterly is the right kind of cadence for setting OKRs, Allan says, and it's best to avoid having strict goals such as percentage of OKRs complete because, of course, they'll be gamed. Better is to review the value delivered in a quarter and adjust how the OKRs are written in the next cycle to align value delivery with the company need.

There are some gotchas, for example having OKRs on top of existing work. OKRs should be seen as a strategic tool for prioritisation, and be useful in tactical decision making at the team level. If something is important to get done, it should be in the OKRs in some form. 

If teams are spending all their time fire-fighting rather than doing work that contributes to an OKR, then there's an imbalance between what the company says is important and what it's doing. That needs to be resolved. 

Allan models interactions between teams and stakeholders as ripples in a pond during a rain shower. The drops hit the water and create interference patterns with peaks and troughs — some actions will multiply one another, some will cancel each other out, and some will sink. This is why it's important to keep communication open, to understand the motivation for the work is being done, to provide opportunities to realign and try to maximise the highs.

OKRs, he says, can provide a way to facilitate those kinds of interactions, and the good news is you can drive them off the forecourt right now.
Image: https://flic.kr/p/2kYDtiD