I have previously posted separately about Strategy Deployment and OKRs and Kanban. This is a guest post by Matt Roberts on OKRs and Kanban that brings the two together.
With a degree of confidence, I am going to assume that you know what Objective and Key Results or OKRs are. As a goal-setting framework, it has become a favourite amongst agile engineering teams and becoming mainstream across all types of teams and industries now.
What is sometimes not appreciated is how OKRs are the perfect focal point of Kanban. Where Kanban optimises the execution, OKRs describe the future desirable end-state of the activity and via measurable outcomes.
If you were to take an example Product / Engineering OKR like:
- Objective: Build a next generation banking application
- Key Result: Get 200K users to deposit money weekly
- Key Result:: Get 20% of users to set financial goals
What can sit alongside this is a Kanban where cards can be selected and completed based on their alignment. Progress against the OKR can be discussed at an agreed cadence and work continually optimised.
When working with OKRs and Kanban it is easy to overcomplicate things by arguing that cards link to multiple OKRs, which may sometimes be true. However complicated linking comes with a thought and time overhead and can slow us down. Where possible the “Keep It Simple” approach targeting a Kanban to a single OKR works really well.
As with any framework, it’s so easy to over-think OKRs. What we want is simply a good measurable outcome for the work being done via sprints, epics etc. to target. A goal to focus productivity and enhance the learning loop/retrospective.
Solving the activity based Key Result problem
One of the challenges that those that are new to goal setting and OKRs face is they are able to describe activities easily, but measurable outcomes are harder. What using Kanban and OKRs does is provide a place for work and a place for outcomes. Both being visible, part of conversations and both agile by their nature.
The other benefit of this is learning loops are optimised when an outcome is measured. We did this work, this epic, this sprint and this changed or didn’t as the case might be. If you do work and don’t get to see the outcomes you don’t know if it works and don’t get to learn what works and what doesn’t work.
Making goals and work visible across teams
Of course, having stakeholders from a range of different teams is a great way to focus on delivering customer value. OKRs have transparency as a core pillar in the same way Kanban and other agile ways of working have, so adopting both together makes sense. Not only is execution aligned but goals are as well.
More information, ideas and collaborative decision making
The final thing I’d want to share to reinforce the synergy between OKRs and Kanban is that to set OKRs teams have got to share information about opportunities and challenges, whether they are KPIs that are not where they should be, systems and processes that need to be improved or a project that needs to be delivered.
From this pool of information, conversations about what should be focused on and what should be left on the backlog can happen. After which the conversations can continue to align execution. OKRs and agile working can, should and need to synchronise. The best ideas and the most important and valuable work will be done as a result.