Making OKRs and Scrum work together: an Agile Management guide
This article is based on the presentation I gave at Conference Agile Spain (CAS) in Barcelona in November 2019 titled Making OKRs and Scrum work together: an Agile Management guide. Copying an idea from Galo Navarro, I went through the slides typing what I spoke over them, edited the text, and added some of the most relevant slides in between paragraphs.
Introduction
In this article we describe the challenges of adopting OKRs in Agile teams (that mainly use Scrum) and how our team in Adevinta has overcome them.
Adevinta is a leading online marketplaces specialist in 16 countries. Our marketplaces help everyone and everything find new purpose: we help people find jobs; buy, sell or rent apartments; buy and sell second hand items,… In Spain we own very well know brands like Fotocasa, Habitaclia, Milanuncios, Coches.net or Infojobs.
We also have a global services department split between Barcelona and Paris and this part of the organization is where I work at. I manage a team of Data Engineers working on building and governing curated datasets (Business Intelligence at scale) and serving them to our internal clients.
But, what are the issues Scrum teams face when introducing OKRs? Our team has iterated on the Scrum methodology for the past 5 years (when OKRs were introduced in the company) adapting all ceremonies and artifacts to suit the OKR methodology.
For those of you new to OKRs, OKRs isjust another goal setting strategy. One of the main differences between OKRs and other goal setting strategies is that OKRs should be ambitious. If you complete all of your objectives in a quarter (which means you grade them at 100%) it means that you have not been ambitious enough; the sweet spot should be between 60%-70% accomplishment.
Other characteristics is that they are public to the rest of the organization and once graded, these grades are taken as data points to learn and iterate over in the following quarters. Finally, they should not be tied to employee evaluation or performance bonuses as you risk teams going sideways and game the OKRs.
When using OKRs together with Scrum, we have identified 3 main challenges:
- How to manage maintenance tasks
- How OKRs translate into work
- How to keep the big picture
Let’s go into detail in each one of them.
How to manage maintenance tasks
In an ideal situation prioritisation problems are supposed to be fixed during a sprint planning, as suggested by Vivian Pennel in his article: Growing a feature team using lanes.
But one, three or six months ahead into development you will start having external change requests. Also, you will start accumulating technical debt. This is when prioritisation problems arise and you need to change how you prioritise new functionalities, small change requests and fixing technical debt.
While you can try to reduce sprint length or use Kanban to fix this problem, what really worked for us is that we started using a technical and a fast lane also after reading Pennel’s article mentioned above.
What is a lane? A lane is a subdivision that you do in your team, a sub team. What this sub team (or lane) does is to focus on a specific topic for a specific amount of time, and after this period, you rotate your team members between lanes.
What is the fast lane? It is the lane that handles small requests or bugs that need to be solved quickly. These tasks should take less than a week to complete and the lane itself acts as a buffer for the team: it prevents interruptions caused by bug reports or any other unexpected event.
Another relevant lane for maintenance work is the tech lane. The tech lane focuses on debt management and the engineering roadmap. It is dedicated to complex and deep technical topics that can take several weeks to complete.
If the effort to be done in one of these lanes is significant or is an external request from another team (this is usually the case for migrations or initiatives to reduce cost) it makes sense to include this effort as part of the OKRs.
For us, a concrete example was when we had to migrate all our big data jobs from a Hadoop based infrastructure to Kubernetes. Since we invested a significant time and effort in this initiative it made sense to include it in our OKRs for the quarter.
How OKRs translate into work
How OKRs translate into work requires us to introduce a new type of lane: the strategic lane. This lane focuses on work that provides business value. While dedication to lanes will depend on team size, the strategic lane will usually have more members of the team than others. That’s why it can be split into sub strategic lanes that can parallelise delivering business milestones in equal priority.
In order for the strategic lane to work with OKRs, you should assign the highest priority Key Result (KR) to the sub team working in the strategic lane, see the following image for the full recipe on how OKRs translate into actual work.
Now, what is the relationship between this highest priority KR and Scrum? Key Results can be mapped to tasks, user stories or epics.
If the Key Result is an epic it is because the KR is a large effort: it will contain several user stories and probably more than one person can focus on it. If your Key Result is a user story it is a medium effort and it will contain several tasks; the work may be parallelizable. Finally, if you have KRs that are tasks, it is going to be a small and quick effort and it means that one person alone can do the task.
We’ve been in the situation of having Key Results as tasks, scoring 100% accomplishment in just one sprint. A similar thing happens when KR are User Stories. What has worked best for us is to have Key Results mapped as Epics.
Where things can go wrong
We have identified three points where things can go wrong when adopting the previously explained lanes together with OKRs and Scrum:
The first one is the lack of clear prioritisation. If it is difficult for your team to identify which is the highest priority KR from the list, you have a problem. The root of this can be organisational or product related, but someone in your organization should be able to tell what your team needs to focus on first (maybe this person is you!). If this is not clear, the strategic lane will not be focusing on the work that is providing the highest value to your product and your organization.
Another problem arises when you start working on several KRs in parallel. You have to be very careful to not finish the quarter with half the progress done in multiple Key Results. In this case you will need to move this work to the next quarter or worst, the work will be stopped and tech debt will pile up in your system.
Finally, you can decide to not implement fast nor tech lanes or implement them wrongly. This mistake is easily identified by the strategic lane having to focus on solving bugs or handling requests: you have failed protecting the strategic lane against interruptions.
How to keep the big picture
The last challenge we have faced when using OKRs in our Scrum team relates to how your Engineering Manager needs to adopt an Agile Management mindset.
Since neither Scrum nor OKRs address the role of line management, we needed to iterate and adapt to make it work. What we have sensed is that teams are very focused on their daily tasks and it is often difficult for them to relate to the OKRs, usually because (in our case) they didn’t participate much in its definition.
Because we want team members to actually see the global picture and how they are impacting the organization we needed to modify our Scrum processes and ceremonies. At the center of these changes was the creation of a quarterly OKR tracker. You can find 3rd party solutions that can do the job but you can also start easy by doing it in a spreadsheet, like we did.
In the rows you have to list all the Key Results you have planned to deliver this quarter and in the columns it has been useful for us to include the following columns:
- Name and id of the KR
- Description including a list of tasks or user stories in order of priority
- Size of the KR (in t-shirt sizes)
- Priority
- Status with latest update date
- Mid-quarter status
- End-of-quarter status
- Confidence score
- Detailed tasks accomplished by sprint
If you are not using a tool for this, updating this spreadsheet can be a very manual effort. For us it felt this way but having a one-pager to summarise the status of our efforts has provided a lot of value to the team and the organisation.
Once you have the tracker done, you don’t have to keep it for yourself: you need to show it regularly to the team in order for them to actually own the OKRs.
During every backlog refinement sessions we show and go through the OKRs one by one with the team. A small group of people look at the tracker days before the grooming meeting and decide which tasks will be groomed in the next refinement session based on Key Results priorities. We call this meeting the pre grooming meeting.
During the next day we write these tasks and tag them with a pending-grooming tag and we share them with the rest of the team as a pre read for the backlog refinement session.
As we’ve said, during the grooming meeting the first thing we do is to show the OKRs tracker to give context, after that we groom and refine the tasks.
Other changes we have done to the Scrum ceremonies is to run the demo and the sprint planning ceremonies by lanes. Since we have a very well organised grooming meeting, planning is usually very fast.
Lessons learned
Through iteration and adaptation we’ve learned that having a fast lane and a tech lane in your team are very valid options to manage both maintenance tasks and technical debt. Team size is indifferent as you can always dedicate a percentage of your total capacity for these lanes.
Another learning is that the strategic lane should focus on the highest priority Key Result of the quarter and you should only work on one KR at a time. We’ve put several people working on multiple KR at the same time and it has not worked: tasks are left unfinished and tech debt accumulates.
Finally, you need to slightly change your Scrum ceremonies to introduce OKRs with the help of a quarterly OKR tracker.
Our final advice is to iterate and adapt. Instead of building hypothesis about what could improve the performance of your team, test them and learn; you can call this changes experiments. This makes it ok to not know everything upfront and it will help you be more creative too.
