OKRs and Agile process

Does your organization use Objectives and Key Results (OKRs)? 

How do OKRs work in an Agile development process?

Lets think and blog about this.

Objectives and Key Results recap: 

• an Objective is "a clearly defined goal and 3-5 key results - specific measures used to track the achievement of that goal" - wikipedia
• A key result must be measurable e.g. %, $, number and easy to answer if it was achieved or not.
• Objective vs goal? basically the same but Objective has added specificity. But its what you want to achieve
• Originated at Intel, popularized at Google and now lots of other companies including where I work for years.

Objectives are often defined by senior company & product leadership and then cascade down to be decomposed by departments and groups and ultimately teams/squads. Often the Objective is for multiple quarters.
A key part of the Agile process is frequent delivery of software (often every day or week), learning from releases and being flexible (agile) to new changes.
The typical Agile process and OKR process can easily have a gap in timescale and scope. I have seen objectives and KRs that are too grand a scale for Agile development process. The end result is OKRs are disconnected and separate from what an agile team/squad is doing. OKRs are something separate. Engineers may not know what KR or Objective the work they are doing relates to (or vaguely know). There is a breakdown in traceability and inability to answer: why? what problem are we solving? what is success? what effort and resources were needed to deliver an OKR?

So how do we integrate OKRs goals into an Agile process?

1. delivering outcomes/results over delivering working code/features;
Agile teams have to go from a feature factory model of "I'll build what product tell me to build" to "we're building this to achieve this kr and this objective". Yes release working code often, but it must be in service of a measurable result/outcome.
Teams need to go from activities such as "we're redesigning the checkout flow" to results "we want to increase customer conversion by 5%" and "reduce abandoned carts by 20%" and "reduce customer service checkout calls by 25%". 

Bill Campbell - Trillion Dollar Coach "if you ever tell an engineer at Intuit which features you want, I'm going to throw you out on the street" i.e. telling people what to do is not good for innovation, instead tell them the problem and let them come up with the solution.

This is an important mindset change: give teams problems to solve rather than solutions to build. Part of the gap in Agile is "agile is intentionally about the making, not the choosing". Agile does focusses on software delivery not necessarily building the right thing. Remember, Marty Kagan said "half of all product ideas are not going to work"

Engineers need to know the larger business context, the problems to solve and understand how it ties to their day to day work and buy in/modify okrs. What is the responsibility of Product, Engineering Manager and engineer/designer in this?

Reality check: How many agile team have been given an objective and KRs and asked to come up with solutions to meet those? How many teams have brainstormed solution options and ran experiments? Or discussed if the KRs are even correct/complete?
How many have been told 1. what to build and 2. the KRs that will serve? Or simply just told what to build?

In addition ORKs should not just be 1 way down. Should be bi directional. Using the checkout flow example, if the team looks at the results required then maybe redesigning the checkout flow is not the way to achieve the KRs. Maybe there's other solutions or simpler solutions to achieve the results desired.

Achieving this requires ongoing effort and communication and a linkage of objectives and key results down to an engineers work (see #3)

I think this is a great article which crystalizes and articulates better than I and in more detail this mindset change

2. decompose OKRs; Quarterly ORKs only don't work with an Agile development process. A natural remedy is to break down KRs into smaller deliverables
e.g. "Objective: integrate with all UK POSs within 1 quarter"  has to be broken down further into smaller deliverables (sub objectives perhaps) with their own KRs which squads can iterate on and deliver to customers and get feedback sooner. The team has to commit to these (is it achievable? does it make sense?)
I recall the guys who developer basecamp had a rule: release a feature in 6 weeks and allow 2 weeks following for support and tech debt. Still can have more frequent releases (and should) but a key to me is you shouldn't exceed the 6 week guideline. Likewise the OKRs have to be decomposed to measure release outcomes sooner (and change course if needed).

note: this Objective & KR decomposition is critical because many KRs are still too large/high level (imo) for an agile process with frequent release cycles

3. add traceability and buy in; after you give the team the problem to solve and results to achieve, operationalize it using their day to day tools. Create a jira epic for each Objective, in the description list the KRs. Then link in addition epics or stories for the work to be done for that Objective or to meet that KR. The appeal of such is it establishes clear linkage/traceability between ORKs and work the squad is doing. Now we can more clearly see what features need to be developed to support the ORK (using tools we use every day such as jira)
One can assign engineer owners for each epic so they have a career growth opportunity by having to own the objective and kr(s) they're then responsible for.

This is also a very good 30 mins video by Felipe who is a good speaker so it's a good learning opportunity.
What do you assign to teams? solutions to deliver or problems to solve?
"Love the problem, not your solution"
"we need to respectfully unlearn the Agile Manifesto" why? because agile is intentionally about the making, not the choosing and stakeholder opinion is not a reliable indicator of success or value (ok, poof! mind blow a little)
How measure progress

• waterfall process - the plan is how we measure value; follow the plan
• agile process - working software is the primary measure of progress; follow the stakeholder
• outcome based - outcomes are the primary measure of progress; follow the evidence
• by asking "what will be improved?" changes the conversation
• 
  
• one technique to help to outcome based is to separate activities from key results and group then into 2 different buckets
• bucket 1: identify the goal and key results 
• bucket 2: identify ideas (activities) to meet the results, could/should be multiple ideas which could be experimented on to see what works
• ...this is cool imo because it's a simple way for the team to have discussion and generate ideas
• measuring activity output (velocity, releases etc) can be easy to measure but it is not the same as measuring results which is often harder
• velocity in the wrong direction is just waste
• if you launch a feature and it does not change the key result then you have not succeeded
• "so what" question; what is the benefit? what is the difference to the customer?
• the so what questions it's a way to move from thinking about activities to thinking about results
• In an experiment driven organization low amounts of experiments succeed, msoft data showed only a third of experiments yielded positive results.

An interesting question is also how do you know you have the right Objectives? or the right key results? You could have the right Objective, meet the key results but not have the outcome you want.