Succeeding with OKRs in Agile
from Allan Kelly
Last updated
from Allan Kelly
Last updated
OKRs are about goals bigger than the next story. OKRs prioritize purpose and strategy over backlogs. Objectives are big goals; key results are smaller goals that build towards the objective.
Does your agile team get lead astray by burning fires? Do you struggle to keep your agile team focused?
Bottom up
Don't impose OKRs from above
Don't set OKRs top-down
Organization
OKRs are a team sport
True north
Use OKRs to guide and fight to stay on course
Don't stick blindly to OKRs as the world around changes
Leaders
Build psychological safety / make failure an option
Make completely clear what the organization's priorities are
Reviewing
Ask questions as :
How does this create value ?
How will this be measured ?
Are these goals ambitious enough ?
Are the goals too ambitious ?
Team
Make the team responsible for setting their own OKRs and delivering them
Money
Do not link OKRs to bonuses and remuneration
OKRs = Objectives and key results
Objectives are Big Goals
Key results are smaller goals that build towards the objective
Goals bring focus
Focus is powerful
OKRs = "Test Driven Management"
Decide what you want (Objective)
Next set a series of acceptance criteria : key results
Get on and develop
Don't consider yourself done until you can pass the tests and meet the objectives
Dissecting OKRs
OKR is something you and your team wish to achieve
Good OKRs are outcome-focused
Not about measuring progress towards a goal
Are all about delivering outcomes that add value
Each result should be useful in and of itself
An objective should have its own wholeness that is more than the sum of its parts
Whole objective should create more value than simply the value of the Key Results added together
OKRs get reviewed at the end of each quarter
The real benefit is in the outcomes delivered
Ambition over estimation
The aim of OKR
Not to do everything
The aim is to be ambitious (push further)
Teams are not normally expected to complete 100% of their OKRs
70% is more common
With OKRs teams are encouraged to aim high
Not impossibly high
BUT high enough to be challenged
3 reasons why OKRs work well with an agile approach
Fill a need at the mid-term planning level
OKRs are essentially a test-first approach
OKRs enhance communication
Mid-term planning
Glue between the short-term daily / sprint planning and long-term plans
Test-Driven OKRs
Each Objective has a set of Key Results
Each of these Key Results is a test
Has the result been achieved
Each Key Result should be measurable
Test first approach
Creates focus
Tells you when to stop
Stop when the tests pass
Communication
Easier to communicate what a team is doing
A means of communicating status and progress
Success motivates continuation
Some things are more important than OKRs and sometimes those things can't be measured.
Management by Objective - Peter Drucker (1992)
Managers decide strategic objectives
Effort & Resources
OKR - Andy Grove at Intel
Extended MBO with a focus on delivery
Outcomes should be things in their own right
Not proxies for something else
Outcomes should benefit customers
Value and benefit are synonous
People tend to associate 'value' with a number
Benefits fits more easily when talking non financial value
Value comes in many different forms
Learning is valuable
Knowledge on new tech for example
Feedback is valuable
Extend our existing knowledge
Risk reduction is valuable
Increases the probability of delivering value
Money
"Money is the best form of feedback"
In Grow the Pie
Taking a board-level 'stakeholder-value' approach to value
Rather than a narrow 'shareholder' value view
Grow the pie so that there is more for all
Compelling evidence that pursing a larger pie for all
creates non financial value
benefits society
brings financial rewards too
Quarterly writing of new OKRs is a strategy question :
What are the strategic priorities for the next quarter ?
What does the team aim to do ?
What targets will the team set for itself ?
Prioritization is not just about deciding what to do
It is also deciding what not to do
Everything that is not in the OKRs is lower priority (by definition)
OKRs operate within a cycle : prioritize, focus, execute, review
Are you setting utility OKRs or aspirational OKRs ?
One team may embrace ambition and aim high
Other teams may value predictability and set goals they are confident can be achieved
Mark aspirations
Some teams mark objectives or key results that they feel to be aspirational
Aim of OKR = create focus
Self-defeating to set too many OKRs
Teams exist to share work
TowarD a common purpose
OKRs serve to provide that purpose
OKRs serve to help say "NO"
At least "Not Now"
3 is the maximum (Allan's recommendation)
This rule of thumb serves both for the number of O and the numbers of KRs
All OKRs are not equals
Some might be higher priority
Possible to prioritize Key Results independently of objectives
Example : KR1 of O1, KR1 of O2, KR2 and KR3 of O1, ...
Warning : it complicates matter
In sprint or days per OKR
Priority does not correspond to the capacity allocated
No specific time to set them
Should not be set weeks and weeks in advance of the quarter they will apply
Just a few weeks :
2 or 3 should be fine
Profit is a side effect of delivering on that purpose and creating value
First thing to write = Objective
Something the organization wants / values
Something that contributes towards the bigger goals that leaders have outlined
The thing you are trying to achieve
Perhaps the thing you are trying to build / create
A change you are seeking to make
The objective doesn't need to explain the problem in detail
Make the value the objective brings obvious
Example :
Retool the delivery pipeline to facilitate CD
VS Increase ROI by reducing TTM with a new delivery pipeline and continuous delivery practices
Use the "so that"
Avoid boxing yourself into a specific approach or solution
One OKR for the team per quarter : nominated by the team to increase productive capacity
Testing trouble : time
Some OKR can be measured after a specific amount of time
Can be marked as achieved
Final judgement for a later date
Deliver value with each KR
Fight against dominos
Don't accept dependencies
Test-driven
KRs are the tests against which the objective will be measured
Example :
Make the site easy to use OR The site is secured
Turn into testable statements
New users can complete a purchase on the site within 5 minutes without cursing
Experiments
Phrasing a key result as an experiment can be a useful way of attempting something with an uncertain outcome
Exemple : Run 3 experiments to increase page views
Success is doing the experiment itself and absorbing the learning
Like this it makes safer for the team to take on risk
Hypothesis-driven development
Template
Outcome of those KRs = learning
Time-boxed
Experiment for 4 weeks for example
Survey
Make changes to people
Test it with a survey
2 schools :
OKRs are additives
Add more work
A new way of injecting work
OKRs are everything
OKRs = origin of all work and all organization
OKRs everywhere
"Will this contribute to achieve the OKR?"
Sprint planning with OKRs
Planning meeting needs to include a full review of the current OKRs
Direct the team to the highest prio OKR
Avoid the temptation to do a little of everything
2 approaches :
Backlog first
OKRs first
Success
No longer burning down the backlog
Delivering OKRs
Choose Sprint Backlog items derived from the OKRs
Might be KRs themselves
Problematic in an OKR driven world
Does not generate new business benefit
Option 1 : suppress BAU
Force BAU to go away
Option 2 : reduce or remove BAU
Set an OKR to reduce BAU
Think about google
Community support portal for example
Option 3 : make BAU better
Make the work better
More efficient with better quality
Option 4 : Objective 0
BAU in the OKRs
Objective 0 -> keep the existing system operation within the historic range
Add a 4th OKR for BAU here
3 horizons in terms of planning :
Now : sprint planning looks a few weeks into the future
Soon : OKRs look to the next few months
Later : looking months and years into the future
Can create valuable learning
Don't expect plans not to change
What if thinking
OKRs form a link between the big and possibly nebulous strategy and the specific-code face work of agile teams
Don't forget technology
Technical excellence and consistently high quality = key strategy for agile teams
Technical liabilities over technical debt
Better metaphor
Debt has a good side (buy houses, ...)
They need to set the context of work through culture, big goals and strategy elements
They need to embody and live the culture as role models for the teams
They can promote behaviors and decisions in line with the culture
It is the myriad of tiny daily decisions that managers make that bring culture, goals, strategy into being
OKRs require supportive culture
Psychological safety
Failures will happen
"if you aren't failing, you aren't trying"
Delivery culture
Culture needs to value delivery
Not hours worked, not partially done work
Delivery = actual working products being used by actual customers
Utility mode vs aspirational mode
Don't link remuneration to OKR outcomes
Once money is attached to OKRs
People feel compelled to chase 100% success
Easiest way = reduce the target
Look at employee behavior instead
What behaviors would you like from your team members ?
What kind of behavior makes work go more smoothly ?
As with agile, you need to find you own way to OKRs [...] be prepared to experiment.
MBOs
OKRs
What
What and How
Annual
Quarterly or monthly
Private and siloed
Public and transparent
Top-down
Bottom-up or sideways
Tied to compensation
Mostly divorce from compensation
Risk-averse
Agressive and aspirational
Color
Status
Meaning
White
Not started
Yellow
On course
Green
Achieved
No more work needed
Red
Troubled
Problems encounter
Purple
Abandoned
Team has accepted the goal will not be achieved
