OKRs as a new Waterfall

Question

I'm a software developer and I don't have deep knowledge of the best practices around Objectives and Key Results (OKRs), so I base my question mostly on how they are used in my company.

Every quarter we have an OKR week where we add personal OKRs based on what we plan to finish this quarter. My OKRs are mostly epics from issue tracker, so there's a little bit of duplication that bothers me. But that's a small thing.

What really bothers me is that I get a waterfallish vibe from the whole idea of planning things for 3 months in advance (and then the first line of real code makes this plan outdated). It might work well for stable, old companies but for us as a startup it doesn't seem to provide much value as things tend to change very fast (ironically, this time it happened the next day after OKRs for a quarter have been finished).

I'd like to know if I'm correct in my attitude or may be I'm just missing something?

Answer 1

My understanding of OKRs is that they are designed to focus on making people clear on the expected outcomes, not necessarily how you get there (i.e. completing a specific epic).

For example:

Objective: Increase monthly recurring revenue

• Reduce churn by 3%
• Migrate 5% of freemium customer base to tier 1 subscription product
• Reach net average 1,000 additional subscription users per month

--

So perhaps the epic you're required to complete helps solve 1 or all 3 of those key results, it's not a key result in itself.

It's fine to have an individual objective of completing that epic in a set period of time, perhaps OKRs just aren't the right framework or process for that on an individual level.

Good luck!

Answer 2

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.