Anyone mind if I rename OKRs? s/OKR/OAC/g
Rrather than call them Objectives and Key Results I wish, o how I wish, that I could rename them OACs – Outcomes and Acceptance Criteria
Why?
Well, two, or maybe three reasons.
First off the terms. There is an increasing emphasis on Outcomes in a lot of discussions and management teams. Indeed, if you look beyond the “agile is dead” click-bait many former agile advocates now talk about “outcome based working” or some variation. Nor is this confined to those formerly known as “agile coaches.” Indeed “product model” thinking revolves around the same idea. While many in the product community seem allergic to agile they pursue to the same idea.
This raises the question “what is the difference between an objective and an outcome?”
Personally I see little difference. Thus I define an objective as “an outcome you wish to bring about.” You might think of “objective” as forward looking while “outcome” is backward. The objective is a target, an aim, a goal, a outcome is the realisation.
Tell me again: Key results?
When it comes to “Key Results” there is some ambiguity. I don’t think “key results” intrinsically speaks to people. People don’t automatically know what is key and what is a result. At best it requires explanation, at worst it is interpreted erratically.
Perhaps because of this key results themselves are often a little fuzzy. Time and again key results are little more than a to-do list: a work breakdown or plan of action. Now I’m not saying you shouldn’t have a plan of action to achieve your outcome (objective) but key results is not the place. (Another blog I need to write, “The OKR 2-step.” I talk about it in presentations and training but haven’t blogged about it.)
Key results are the key – the important, the main, the principle, chief, first and foremost – results, the consequences, the effects, the measurable differences, you realize when the outcome is met.
At the same time key results are measurable and therefore testable. Thus in test first management the key results are the acceptance criteria.
Outcomes and Acceptance Criteria, OACs
This rename has two more benefits. Because this interpretation highlights test first management it continues the test first story which began with automated test first unit tests (TDD, Test Driven Development). Then Acceptance Test Driven Development (ATDD) into Behaviour Driven Development (BDD).
That might seem like a small benefit but in positioning OACs closer to the agile way of thinking creates distance from the past.
One great thing about OKRs is that they did not appear out of nowhere. By the time they hit the mainstream there was already a body of work discussing them. Plus at least two well-known case studies. This helped their adoption by teams and leadership, and, for better or worse management consultancies who are keen to push them.
But, at the same time it brought baggage. I really dislike some of the writing on OKRs which is too “rah rah, win one for the Gipper”. Or (to use a word I dislike) its outright “boosterism.” While that can be good for rally-the-troops it is also short on detail (how to) and sounds like another silver-bullet.
Some of the older writing on OKRs, that dating from the 1970s, actually propagates the mistakes I see in key results: like the to-do list tendency. It also comes with a command-and-control assumption that manager knows best. Under my interpretation of OKRs they are used more as a challenge-respond-discuss protocol.
So, why not?
As much as I’d love to replace OKRs with OACs I don’t think I’m ready to do it. Thats because, for all their “faults” OKRs are pretty good. That legacy has oiled their passage into management circles. Similarly, despite the flaws in the older writing there is good advice in there.
Still, I’ll continue to push my interpretation, dream about renaming them and continue talking about Objectives and Key Results.