OKRs are linked to Agile only in so much that the companies that pioneered and promoted the OKR model also adopted significant portions of the Agile Manifesto and the frameworks we consider Agile.
However, OKRs are not linked to Agile in any meaningful way. Which means, they can work fantastically well in an Agile environment or go spectacularly wrong.
They are most commonly associated with Lean Startup, not Kanban or Scrum.
What are OKRs?
OKR stands for Objective and Key Result and it is distinct from the idea of a KPI. It was invented (loose term) by Andy Grove at Intel and then through the tentacles of Venture Capitalists and Silicon Valley it was quickly adopted by a significant number of companies, especially those invested in by Kleiner Perkins.
How does it work?
Simply, an Objective is a single unifying goal that gives purpose to an organisation and helps them prioritise effectively. It is not a Mission Statement or a lofty aspiration. It is a concrete, demonstrable, audacious goal.
- Be the number one video streaming platform in the world
- Become the number one leader in Sales in the EMEA region
- Sell 100 million devices
- Increase subscriber count to 50 million within 12 months
The Key Results are the 3-5 measurements that will help you achieve the goal and provide a level of planning to the organisation level below the Goal.
So, for a goal of sell 100 million devices we might need the key results
- Open the new production facility within the next 90 days
- Increase workforce by 500 assemblers
- Produce the sales plan for North American retail stores
Those Key Results become the Objective for the lower level (So Sales adopt the Key Result sales plan for NA as their objective. They produce 3-5 key results which become the objectives of the lower level and so on all the way down to an individual worker.
In this way, every single result can be traced back to an overarching Objective for the whole company.
The Objective serves as a massive signpost to the future and lets a company disregard anything not supporting the Objective.
What about Individual OKRs?
Google promoted (and then discarded) the idea of personal OKRs. This was borne out of the idea of autonomy and mastery for teams. Once an objective is set, it was good practice to ask the teams themselves, what should our key results be? How would we measure success?
At least half of Key Results were encouraged to be bottom up, holistic.
This then became entwined with the idea of professional development, performance feedback, bonuses and setting aside some portion of your time for personal OKRs such as
- I want to run a Marathon
- I want to learn React JS
- I want to learn Operations
- I want to lose 15lbs in weight etc
In the liberal environment of Silicon Valley, personal OKRs could be tied to well being, promotion, charity etc. John Doerr talks about this in Measure What Matters by his posting his OKRs to his cubicle wall.
Google dropped it eventually and their custom built OKR platform had some problems.
But the practice still exists in other companies as they adopt the OKR guidance from Google Ventures, Medium and other popular blogs even as Google have dropped some aspects. The legend lives on...
How does this translate to Agile?
Well, quite simply, your product or service should be tied to a corporate Objective. If that feature team are working on a product or service then it should have 3-5 key results which indicate how it is supporting the corporate objective.
That is the level at which OKRs interact with Agile.
If you impose anything lower then effectively you are not using OKRs you would be using SLA's or KPI's with mandated delivery outcomes.
At any time you should be able to ask a Product Owner
How does this product/service support the OKRs of the company?
The developers should be able to ask
How does this Epic or User story support the OKRs of the product?
It is that simple and should always be that simple, nothing more complex than that.
If you are looking for an excellent case study then Gitlab publish all of their OKRs alongside their development roadmaps and even their Epics and User Stories. It is a comprehensive case study.