5 Tips for OKR’s with Agile - with Allan Kelly
OKRs and Agile work well together in the tech world. They combine to give organisations the sweet spot of strategic success and operational efficiency.
See the video on youtube: https://www.youtube.com/watch?v=NEeLffrGf58
A goal-setting framework used by individuals, teams and organisations to define measurable goals and track outcomes, the OKR framework worked well for former CEO at Intel, Andy Grove, by answering these key questions:
Where do I want to go? This answer provides the objectives.
How will I pace myself to see if I am getting there? This answer provides the milestones or key results.
Author, consultant and a former frustrated software developer, Allan Kelly is trying to change the world of digital agility. In his segment in Lithe Talks, he broke down the 5 key tips for combining OKRs with Agile and their crucial role in companies’ success.
OKR Tip 1: Test-first management for the team
Think of it as a test-first iteration. In the same way when writing code, the unit tests are written first, think of OKRs as a test-first for management – the objective is the outcome you wish to bring about, the key results are the acceptance criteria for that outcome.
This involves asking quite a few questions:
How are you going to test this thing?
Determine what the acceptance criteria is going to be, and consider the objective or most importantly, the outcome. What is the outcome you’re looking for?
Then stress test how you will meet that outcome.
Having a clear timeline around the objectives is a key consideration as well. What are the tests going to be? Define these at the start of the quarter and spend the rest of the quarter executing that. Then at the end of the quarter, assess if the test has been passed.
This way you create an API for the team and determine what outcomes and outputs they are going to achieve.
OKR Tip 2: Whitespace OKRs over cascading OKRs
There is a tendency to look at OKRs with a view of how traditional management hierarchies run. Usually, a leader at the top of an organisation will give objectives to those reporting under them and then that objective cascades down the different levels within the organisation.
Allan characterises this approach as “cascading OKRs”: the idea that you can take your OKRs, and then you can pass OKRs to the people below you.
This is counter to how Agile is meant to work. This is stepping back into the land of command and control and is dictating what to deliver; it doesn’t promote self-organisational work and self-management.
Rather than use OKRs in a top-down fashion, leaders need to talk about the destination, about where they are heading, and the purpose of the organisation. There might be multiple missions and multiple teams and they need their leaders to outline the strategy but not fill in the details.
There needs to be deliberate whitespace which teams then fill by setting OKRs to describe what they will do in the next period to advance on the purpose and mission
This might seem negligent initially, but without this whitespace, teams will have no autonomy and objectives and instructions will cascade down the organisation. One thing to be aware of here is that this isn’t the ‘bottom’ telling the ‘top’ how things need to go.
This is looking at the teams’ valuable skills and products and collaborating with them to assess what OKRs to set and with constant feedback loops between leadership and adjacent teams.
Senior leaders set massive goals for the organisation and teams respond accordingly. If the teams don't respond and are railroaded into one set of OKRs or another, they're not really going to feel ownership of those OKRs; they aren't going to be enthusiastic about them.
You want whitespace OKRs moving up to the organisation – you need whitespace OKRs, rather than management by objective OKRs coming down the organisation.
OKR Tip 3: Review OKRs every sprint
Review your OKRs every sprint.
This is usually suggested as a cyclical activity, for example, do it once every quarter or every 6 months. However, and this is where Agile and OKRs can work really well hand-in-hand, if you have regular sprints that you review your OKRs and assess the checkpoints of where you are and if you’re still on track.
In the sprint review, every sprint should be building towards your OKRs. Any progress against OKRs, isn’t something that happens in addition to the sprint; OKRs can be used to reinforce decision-making and ideas, and are the driving force behind the sprint.
OKR Tip 4: Think acceptance criteria
Key results can be seen as the small pieces that will make up the bigger objectives.
But it is better for organisations to consider key results as acceptance criteria: what metrics and other criteria do you need to see movement?
For example, if we consider an airline booking system, the outcome might be improving the airline ticket purchasing process and improving revenue by 10%. The key results, however, could be two-fold: one being to generate more sales or it could have to do with reductions in average booking times, fewer abandoned carts and fewer booking query calls to helplines. All of these are key results that can contribute to the end outcomes.
These are conditions that can be tested and optimised and this way of working assumes that there are improvements that can be made to the system. This encourages teams to decide what the improvements will create progress against all the acceptance criteria.
OKR Tip 5: OKRs over backlogs
OKRs are just-in-time story generators. Think of OKRs rather than backlogs.
Every time you need a new piece of work, every time you need a new story, every time you go into a planning meeting or replenishment meeting, instead of going and rummaging in the backlog, look at the OKRs and talk about what the story is that would move forward on the OKR.
OKRs are this story generating machine and every time you need a story, you turn the machine on, you generate some stories, which means you can think strategically.
We end up getting so lost in the backlog, that we lose all strategic thought and focus on outcomes. So, by putting OKRs at the centre of the work, and by always testing whether the work being done will build towards an OKR, it keeps you strategic.
Does this mean you throw your backlog away? Sounds radical!
Allan is of the opinion that when you work with OKRs, you don't necessarily need a backlog because your measure of success is not how much backlog you’ve worked through but rather:
1) Is there progress being made against the OKRs, and
2) Is it adding benefits to the company's purpose?
If using OKRs sounds interesting, or you want to improve the OKRs you have been setting within your organisation, you may be interested in joining one of Lithe’s upcoming OKR masterclasses.
Lithe Transformation’s work has helped to reduce cost, increase output of products and services, improve culture, working morale, remove silos between teams, create higher alignment, and autonomy through phases of extreme growth for established and scale up companies in financial services, insurance, fast-moving consumer goods, and in the public sector.
Allan Kelly’s book “Succeeding with OKRs in Agile: How to create & deliver objectives & key results for teams” is for sale here: http://amzn.to/3iWOH9O
Credits to this article go out to: Allan Kelly, Russ Lewis and Amna Hasan