Succeeding with OKRs in Agile
Once set, OKRs should be the focus of all work.
Whether OKRs are met or not is almost secondary. OKRs are a hypothesis for the coming quarter, a best effort guess at what will advance purpose. At the end of the quarter, review and adapt - what could be more agile?
ARPANET became the internet in 1981, the same year IBM launched the PC.
Managers must look at outcomes.
Enhance independence even at the cost of redundancy and duplication.
Goals bring focus, and focus is powerful. But focus also means blinkered vision, which carries dangers - but if we aren't blinkered we may be overwhelmed. Software engineers might recognize this as abstraction.
Outcome is described in terms that speak to the customers.
Achieving a key result should deliver some benefit - some value - to someone.
A team may have a long-term plan or a roadmap, a mission oar vision statement, a business plan or statement of the market opportunity, maybe a job to be done, or a customer problem the team is addressing. Such plans usually start beyond the current quarter and may look years into the future.
In the middle between long and short-term planning lies a problem.
OKRs potentially provide a way of balancing the demands of here and now with the need to steer to some kind of course. By focusing on the quarter OKRs can provide mid-term goals, consistent enough over several sprints to achieve meaningful results, but flexible enough not to mislead the team.
OKRs are high-level implementation of test-driven development.
It tells you when to stop: stop when the tests pass.
Focus only happens when you have partial blindness: As with a camera lens, focusing on one thing means not focusing on others - it means some things move out of vision. Of course that is dangerous, but how is one to focus if one is constantly looking at everything?
When you attain focus you can do amazing stuff. Better still, when your whole team can focus on the same thing at the same time, things can really move.
Say "No" - or at the last say "Can it wait?"
All these tools give us an opportunity and a reason to say "No" to work that detracts from focus. Because OKRs are bigger, because OKRs may be approved by more senior people, because OKRs are important and involve other people, then OKRs provide more leverage to say "No, I can't do that right now."
"Vanity metrics".
Always strive for outcomes rather than proxies. Know the people your outcome will benefit: Preferably be able to name them.
Remember that money itself is a feedback mechanism: When customers part with cold hard cash in return for your outcome it is a form of feedback. A customer paying $100 for your product indicates that the customer is prepare to give up the other things that $100 could have provided.
Outcomes should benefit customers, the wider business and even society itself. Although it is easy to talk about businesses as monolithic blobs, all organizational entities are collections of people. Ultimately benefits flow to individual people.
Maybe an outcome makes someone's job easier, more productive, more satisfying or just more fun to do. Sometimes the benefits accrue to managers to are responsible for a process, product or group of employees.
Disadvantage that people tend to associate 'value' with a number.
Economists like to say that 'profit is the reward for risk'.
Joke that 'Money is the best form of feedback'.
Is it better to achieve one Key Result completely and progress the other, or is it better to advance both but complete neither?
Here's why this is wrong. Objectives and key results are designed to convey goals - what we're trying to achieve, by when and how we'll measure success. Building, launching and promoting features and products are not the goals. The goals are the benefits we expect to gain from these actions.
Every day an architect spends thinking about work that they expect to happen next quarter is a day not spent doing the work of this quarter. Of course pre-work may be wasted if the objective changes or gets pushed back.
However there is a more insidious problem here. While performing pre-work like this may appear rational and conscientious, it can be self-limiting. Looking at the work in advance may discourage people from taking on ambitious work or deliberately reducing the goal.
Then there is the problem with effort estimates, which are notorious for being wrong. What if your analysis and estimates indicate that the work will take more than the quarter? Should you reduce the target ? To do so would be to reduce your ambition.
When crafting an objective, make the value the objective brings blindingly obvious.
How might we approach this?
One objective per quarter nominated by the team that will increase productive capacity.
Dominos: When one fall, they all fall. Good old waterfall.
Delivering value with each key result, just as with user stories, implies the target result is a vertical slice that delivers value in its own right. It helps too if the result is independent of other work; sometimes that isn't possible, but you should at least try and make it so.
While it may be true that customers want more, and engineers see little extra effort, this is an example of diseconomies of scale. Taking in a second card increases the amount of testing needed, and if a defect is found then there is more complexity, and possibly more code, to consider and maybe fix.
You don't need a super-accurate measurement - a rough one is better than none. To measure engineers' complaints, buy a large jar and some ping-pong balls. Every time someone hears an engineer complaining they drop a ping-pong ball in the jar, then count the balls weekly.
Increase customer page views by 10% => Run three experiments to increase page views.
Experiments mean that something is done, not that something is completely finished or finally decided. They just mean that something is done and the outcome is reviewed. Experiments can be particularly useful when dealing with people and process changes: Experiment with a new workflow and visual board. Experiment with rotating on-call responsibility between team members; each team member should be on call at least twice.
Since OKRs are set, reviewed and reset on a regular basis, every OKR exists inside a time-box. Even the most open-ended OKR will get reviewed at the end of the quarter.
Building in breaks - especially overnight breaks - allows for serendipity, individual reflection and sense-making. How often do things look different in the morning? How many insights come in the shower? Or walking the dog? People sometimes also find it easier to change their position when given time to think.
Pin down key dates in advance and agree them with others.
Starting earlier provides more time for talking, worrying and not focusing on the current quarter and its OKRs. It's far better to pack all OKR-setting activity into a short period towards the end of a quarter and allow most of the quarter to focus on the current OKRs.
Perhaps more importantly, things change. Starting the OKR-setting process earlier increases the changes that something will change between the first discussion and the last, invalidating decisions. Instead, remember the agile principle of the last responsible moment.
It's important not to overstate the benefits of ideas.
The execution and delivery are what's key.
Having worked with OKRs, I am in the second school of thought. To my mind, all decisions flow from the OKRs and build towards achieving their goals. Throw away your backlog, incorporate business as usual into OKRs and don't do anything that isn't set out in the OKRs.
Seek to cover eventualities in OKRs.
Planning meetings need to include a full review of the current OKRs.
If it becomes clear that the work to be done on an item during this sprint will not utilize the whole team, then advance to the next. During the meeting, focus exclusively on this item until it becomes clear that work will not utilize the whole team. Don't waste time talking about OKRs that are not the focus of the coming sprint.
Avoid pre-work if you can: A little bit of pre-work on objective #2 while focusing the sprint on objective #1 may look attractive, but time spent on #2 detracts from #1.
Avoid diluting focus by allowing experts to work on their chosen area.
In crafting and agreeing OKRs each quarter, seek to deliver real value. Then, in each sprint planning meeting during the quarter, wipe the sheet clean and ask "How can we make progress on delivering our OKRs?"
Take Jeff Bezos' "Day 1" approach: Imagine this is the first time you've asked this question. Don't be constrained by previous ideas, previous work and sunk costs. Given the resources and time you have right now, what is the best thing you can do to move towards your goal?
OKR-first approaches revisit the idea of a sprint goal.
Business as Usual supports ongoing business. Fixing bugs is BAU. Customers expect the software to work and to continue working.
Fixing ten bugs is an achievement, even if the bugs should never have existed.
BAU is more about revenue protection than revenue growth.
Service Level Agreement.
Having an objective zero keeps all the work in one place.
Expose the tension. Once exposed, this tension can be addressed properly.
There are times when clinging to OKRs in the face of change is wrong. This is a judgement call. If you go off-piste, regroup later and assess the impact on the OKRs.
Think about what might happen and learn from what does happen for next time.
Track work that doesn't relate to OKRs, understand where the work originates and how it effects the team. Then decide what to do.
OKRs act s a planning glue between long-term plans and short-term sprints.
OKR roadmaps (discussion documents that pull multiple plans and opinions into a form that feeds into quarterly planning more easily) can be useful for integrating multiple inputs to create hypotheses about what the team will work on in the future.
Strategy represents overarching principles and goals, makes a conscious decision as to how reactive to be add acts as a filter to assist and accelerate decision-making.
OKRs connect the overarching strategy with regular sprints. Rewriting them revisits the strategic intent and strategy. Further, they help to codify and communicate strategy and allows stakeholders to question it.
Strategy makes it easier to decide what not to do.
Leaders can promote behaviours and decisions in line with the culture they wish to create, simply by saying "Thank you", praising good work and acknowledging effort. Verbal praise can be enhanced with occasional surprise rewards.
It's the myriad of tiny daily decisions that managers make that bring culture, goals and strategy into being.
OKRs should cascade up, not down.
OKRs can help where a company is attempting to transition to a more aspirational culture. However, the are not enough on their own: The organization also need to provide psychological safety.
Don't add OKRs late in the process.
Ensure OKRs are testable.
Do not link financial bonuses to OKRs.
Do not link OKR achievement to any form of payment.
Comments