Objectives and Key Results (OKRs)
How we measure success
The problems with deploying new tools
Putting any new tool into an organisation carries big risks. Even where the adoption of a new tool is successful, it can be unclear where the business value is. These are the typical failure patterns associated with not having a clear goal:
Progress is tracked by tasks completed, such as how many repositories the tool is attached to, rather than a desired business outcome.
Without clear objectives, teams may work towards conflicting goals without realising it. For example, one team is focused on increasing code quality while another wants to deliver faster regardless of cost.
Without understanding the current state measurement, there is no way to demonstrate improvement.
Without stretch targets, teams set low value targets that match what feels safe rather than pushing for better results.
Without regular checkpoints, problems go unaddressed leading to an unnecessarily high cost before course-correction.
Introducing OKRs
Objectives and Key Results (OKRs) are a simple but effective way of ensuring you get value from your investment. They solve these problems in a very elegant way. They follow this easy to read format:
Objective - e.g. Reduce / Increase
Key Result 1 - From x to y by z date [stretch / committed]
Key Result 1 - From x to y by z date [stretch / committed]
Firstly, the objective starts with an adjective. We are trying to achieve something, and this succinctly describes our strategy. For example, reduce the number of defects in the live environment.
Next, we can have 1 or more key results.
x is the baseline data starting point.
y is the value you want to reach.
z is the date by which you want to achieve it.
[stretch / committed] - This is how we tackle the problem of “aiming low”. A committed value is when you aim for a single outcome. For example, you want to achieve security compliance, and it is either a yes or a no. Stretch is where you cannot guarantee the outcome. For example, reduce the number of defects in the live environment. You cannot guarantee the number you can reduce it by. Let’s say you have 15 per month. If a team is asked to guarantee results, you may see them aim low and set this to 14, with a stretch target, they could aim for 5 and drive much better results.
A full example:
Reduce the defect rate in the live environment
From 30 hours on average per week spent on defect fixing by each team to 10 by June 2025 - stretch
From a customer satisfaction score of 3 out of 10 to 5 out of 10 by June 2025 - stretch
Here we are looking to reduce defect rates. As the defects can vary in size, we decide to measure the amount of time spent on each. Additionally, we discover that the defect rates have a direct impact on customer satisfaction. Now we have a major business impact to focus on.
How we implement OKRs
If you’re buying CodeScene for the first time, this is how OKRs map to our delivery stages:
We ask what you are trying to improve. This starting objective may evolve through discovery, but it gives the engagement clear direction from day one.
We gather the data needed to confirm your objectives and establish the baseline measurements we will track progress against.
We work alongside you to reach your objectives, reporting progress against your key results throughout.
Regular touchpoints surface new opportunities for improvement. Analysis of your CodeScene data drives the next set of objectives.