4

I recently read John Doerr's book about OKRs (objectives and key results). While doing so, I was asking myself whether and how the process would fit in my company. We are currently using Scrumban: The teams collect user stories from customers and other sources, prioritize the stories, split them into tasks and work on these.

I can well imagine using OKRs at the company level and using them as one input during elicitation and prioritization of user stories. But according to Doerr, OKRs are used down to the level of the individual, so that everybody sets and publishes his own OKRs every quarter. To me, this is at odds with Scrumban and agile principles in several ways:

  • Team vs individual: In my understanding of agile, goals and commitments are mostly on the team level and it is an internal matter of the team how the individuals cooperate to reach them. This contradicts everyone setting his own personal OKRs.
  • Daily work vs OKR key results: An agile developer in Kanban mostly takes tasks from the prioritized backlog and works on them. If he has personal OKRs, doesn't that conflict with the priority in the backlog? Or is each backlog task a key result (probably not, as there are way too many in a quarter)? Are only certain tasks from the backlog key results (then why not just declare them top-priority)? Or is a key result something more abstract, like "finish at least 50 tasks this quarter" (which does not seem motivating and a bit arbitrary)?

So my question is: How can OKRs be put to good use in a Scrumban setting without introducing conflicts or duplication of information? Do individual level OKRs work at all in Scrumban? How did you make it work in your specific situation?

The question OKRs as a new Waterfall shares some similarities with mine, albeit the focus is a bit different and the answer relates mostly to the company level.

Improve this question

3 Answers 3

Reset to default
4

TL;DR

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

etc etc

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.

Case Study

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.

Improve this answer
1

Great question! I have read Doerr's book only partially so far - and a couple of other articles. From that, what I have understood is that Key Results cannot be tasks or projects themselves. Even if there's a one-to-one correspondence between a Key Result and what must be done (the task or tasks) to achieve that result, they are separate and distinct. So, even if you define OKRs at the team level, they are simply that - the results or outcomes - and must be identified separately from what the team members DO to achieve them. If you do this and track the OKRs separately (not on their Kanban/ Scrumban board), they should have no confusion making out one from the other.

One of our customers - a large South American retail organization - uses our Kanban product (SwiftKanban) in a Portfolio Kanban context using OKRs. They have defined OKRs at the highest level (they call it the Portfolio level) which are of course Organization-level Objectives and Key Results. These are defined and tracked as cards on the Portfolio Kanban board. Each OKR can have one or more "Strategic Initiatives" at a lower level Program Board - which is where high-level work items (Initiatives) are defined that support those OKRs. At the lowest level, they have team-level boards that track Epics and User Stories (and tasks under each) that come out of the Initiatives at the Program level.

So, basically, they have a 3-tier Kanban board hierarchy that looks like this -

enter image description here

They may not have implemented OKRs strictly as defined in the book, but they credit the way they set it up and used them for being able to rapidly pivot during the April-June 2020 quarter to scale up their eCommerce capabilities.

Hopefully, these give you some ideas to model your OKRs in your context.

Improve this answer
0
0

I believe that objectives can work well with agile development if they are aligned with agile values.

For example:

  • Responding to change over following a plan - objective is to reduce lead time
  • Working software over comprehensive documentation - frequency of value releases
  • Individuals and interactions over process and tools - demonstrating collaboration, innovation and team work

As with all such objectives you need to be careful they don't end up in gaming or manipulation that is not beneficial to the organisation.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.