Skip to content
Facebook
Twitter
LinkedIn
WhatsApp
Email
Print
Further Reading
March 6, 2023

Scaled Agile at Work: Governing Transformation and Innovation with OKRs

Developing complex software systems for large enterprises in a truly agile way presents us with challenges on many levels: cultural, organizational, financial, infrastructural and architectural. In our blog post series, we look at various problems of scaled agility from a holistic company perspective and try to give practical suggestions for improvement.

Objectives and Key Results – OKRs for short – are on everyone’s lips. Easy to understand at first glance, in practice, false expectations are repeatedly entertained. 

We sharpen the concept by distinguishing it from related ideas and describing where and how OKRs can be used effectively in agile organizations for sustainable transformation and innovation – with the necessary commitment. Our extended OKR scheme helps define high quality OKRs for different contexts and how to integrate them into modern agile steering tools. Data recorded both manually and automatically via technical sensors can be taken into account.

Getting Things done with OKRs

Applying data literacy to business life: Set dedicated goals, make them objectifiable and then track them. This is how Objectives and Key Results (OKRs) could be summed up.

In general, OKRs are a goal-setting framework for defining, tracking, and ensuring progress towards a strategically embedded business outcome.

Measurable progress towards a strategic goal.
Measurable progress towards a strategic goal

In the context of scaled agility, OKRs can be used for setting and aligning goals at different levels of an organization. These can be bold company-wide strategic goals such as “we want to gain a market share of 35% for on-demand insurances in Europe by the end of next year”, or rather near-term product-related objectives, e.g., “we want to see an 10% increase of user loyalty (come-back rate) each month”.

In addition, transformational goals regarding changing one’s own organization can be expressed very well in OKRs: “In 2 years, we want to be the top employer for young talents in Germany”.

But there is more to say on OKRs in an agile context – and that’s what our article is all about: How do OKRs at different levels relate to each other? Who defines them and when should overambitious objectives be corrected? How can OKRs be used for evaluating Minimum Viable Products (MVPs)? Can OKRs replace (agile) roadmaps? Finally, one of the questions we get asked most: how can “Management” ensure that OKRs are followed up upon by the teams? What role do OKR tools play in this respect? Do we need them to establish an OKR culture?

History of OKRs in 30 Seconds

OKRs were first introduced by former Intel co-founder and CEO Andy Grove in his book “High Output Management“, published in 1983. OKRs became widely known when Google adopted the framework in the early 2000s to improve productivity and accountability. Google started using OKRs back in 1999 with 40 people in the company till today with around 60.000 employees. The message is clear: OKRs can be used by organizations of any size.

What makes OKRs special?

To better understand the true nature of OKRs, it can be helpful to look at what OKRs are not.

  • OKRs are not the same as MBO[1] (Management by Objectives)
    MBOs are annual individual or team goals, which are supposedly objectifiable and measurable and set in a dialogue between supervisor and employee, cascading from top to bottom. For OKRs there are different levels, from strategic-superordinate to specific-operative. However, the coordination is bidirectional, with more autonomy and decision power in the respective context, and the goal may (and should) be adopted over time, if conditions change. Typically, OKRs are reviewed every 2-4 months. The decisive difference, however, is that OKRs should develop a driving, visionary power. They also focus more on the process of achieving goals by defining metrics (key results). A goal can and should be formulated in an (over)ambitious way, and if the goal is not achieved in the end, there will be no loss of salary or other disciplinary consequences.

  • OKRs are not KPIs (Key Performance Indicators)
    Both measure performance. While OKRs focus on a few key goals (“less is more”) and a strategic direction related to business outcome, KPIs are rather used for generic standard goals and for measuring and verifying the operational status and health of a system (e.g., control tower or DevOps pipeline).

  • OKRs are not the same as BSC[2] (Balanced Score Card)
    Unlike OKRs, which focus on specific goals, BSC is a more holistic management framework, which looks at a company’s performance from four overall key perspectives (financial, customer, internal process, learning and growth) and the derivation of output-oriented goals in each of these sectors.

  • OKRs are not PI Objectives[3] (Program Increment Objectives)
    PI Objectives are used as binding agreements between businesses and teams on the implementation of concrete deliverables (outputs). OKRs, on the other hand, set ambitious outcome goals.

The Art of OKRs in Agile

Over the last few years, we have developed the following generalized OKR scheme, which has been proven effective in practice and useful for training, in projects and as a blueprint for defining OKR dashboards (tools). The scheme helps provide clarity about context, purpose and direction, while also emphasizing measurability and tracking.

Extended and generalized OKR Scheme.
Extended and generalized OKR Scheme

Context: OKRs can be applied at different levels (contexts) of an agile framework, from company and portfolio to an individual team, where OKRs at lower aggregation levels should consider and/or refine OKRs at higher levels. Therefore, they can be perfectly used in an agile organization as they support alignment, accountability, focus and commitment on prioritization.

Purpose: OKRs can be applied to define and track aspirational goals in two ways: for delivering valuable customer solutions (innovative) and for internal change programs (transformational).

Metric & Plan: The KR part is defined by a metric or formular plus a plan. A plan is defined as a series of triples (time, target value, current value). Depending on the nature of the metric, current values may be generated automatically by some sensors (e.g., webpage return rate) or need to be provided manually by some OKR responsible (e.g., market share).

An important application of OKRs is in the evaluation of MVPs (Minimum Viable Product). Both the benefit hypothesis of a large development initiative (e.g., Portfolio Epic in SAFe) addressing the full product implementation and the leading or proxy indicator addressing an MVP can be modelled as a single OKR:

  • with a single metric and a plan with (at least) two target values,
  • or by two metrics, where the first one represents the proxy indicator at MVP time.

By the way, NFRs (non-functional requirements) should not be modelled by an OKR. Although technically possible by using our scheme, NFRs represent binding quality constraints and not aspirational goals on their own.

So overall, we see that OKRs and scaled agility go together beautifully. The fact that OKRs should be adjusted regularly also fits well with the agile culture of “Inspect & Adapt”. 

We can now also answer our question from the beginning of the article: how do we deal with overly ambitious goals? They are adjusted in dialog as part of an Inspect & Adapt meeting. It’s that simple!

Enforcing OKRs – really?

This section is about agile steering with OKRs.

Of course, OKRs can and should not be enforced. OKRs are not defined centrally and with a certain degree of self-sufficiency, but in mutual alignment between the levels. As always in agile, OKRs assume their power from agreements between affected people and roles.

But how can commitment be achieved? How can “management” be sure that the OKRs will ultimately be followed and implemented by teams?

In our opinion, essentially through four measures:

  • Limiting the number of OKRs (less is more),
  • Participation or empowerment in OKRs at various levels,
  • Transparency and easy accessibility of the OKRs and their metrics including visualization of progress along the plan for everyone,
  • Ritualized regular evaluation and updating of OKRs through consultation between the relevant stakeholders as part of the existing agile events at portfolio, program and team level.

One question from the beginning of our article regarding the context of agile steering remains unanswered: 

Can OKRs replace roadmaps? We firmly believe that this is not the case, even if OKRs themselves contain a plan. Unlike result-oriented OKRs, roadmaps define concrete results. 

Both concepts complement each other.

Interactive OKR Dashboard: steering with OKRs

How can we, in practice, work effectively with OKRs, i.e., integrate the previously mentioned success factors transparency, accessibility, and adaptability into our daily work? Our answer: an interactive OKR dashboard can make all the difference.

In small organizations, an Excel spreadsheet can be of great help. In larger companies, there will be no way around a specific OKR tool or a professional controlling tool.

Let’s have a look at an example dashboard, which we implemented on top of MS Power BI. The figure shows OKRs for our application co.bo (compliance bot). This is an Office add-in within the framework of MIP (MS Information Protection) for the AI-supported classification of documents into confidentiality classes. The fields highlighted in red are the objectives, the metrics are displayed in gray boxes, and the plan (the target values) is marked in blue. Each metric and its target values are also represented graphically.

Interactive OKR Dashboard with Microsoft Power BI.
Interactive OKR Dashboard with Microsoft Power BI

What features must a tool provide to be used as an interactive OKR dashboard? In our opinion, it should ideally have these five characteristics:

  1. Modular visualization: OKR objects that can be placed flexibly on a dashboard encapsulate the OKR scheme and present associated metrics in a visually appealing way. Target values and target/actual deviations should be particularly emphasized. Filters can be used to set the scale and visible time window of the metric.
  2. Input of actual values: Actual values can either be automatically displayed via the connection to external sensors (in our case via MS Azure Logs) or entered manually by an authorized role.
  3. Plan adaptation: The plan (target values and measured values) can be adjusted.
  4. Near real time: The values shown are evaluated and updated regularly.
  5. Feedback: Comments and feedback on values or malfunctions can be easily shared via a button.

Key Take-Aways

OKRs are a powerful tool for agile companies on their way to holistic business agility. They foster communication, transparency, and alignment between stakeholders and experts from different areas regarding the strategy and how to execute it at each level. In addition, OKRs promote responsiveness, because they can constantly be re-evaluated and adapted to market changes, if needed.

A generic OKR template in combination with a flexible OKR dashboard can extremely helpful.  

Nevertheless: 

More important than tools is a good understanding and feeling for the quality and quantity of OKRs. When in doubt, the following applies: less is more! 

It is important to focus on what is strategically essential. Only then can OKRs develop their full power and contribute equally to the effective agile control of internal transformations and innovative customer solutions.

Sources

[1] Peter Ferdinand Drucker: The Practice of Management. Harper & Row, New York 1954

[2] Robert S. Kaplan, David P. Norton: The Balanced Scorecard – Measures that Drive Performance. Harvard Business Review,1992

[3] Scaled Agile Framework: PI Objectives, https://www.scaledagileframework.com/pi-objectives

Other articles of the series:

Matthias Besch

Matthias Besch

metafinanz (Allianz Group)

Michael Spiller

Michael Spiller

metafinanz Informationssysteme GmbH

Stefan Hanslmaier

Stefan Hanslmaier

Capgemini Invent

Add a document to this circle
Document Source *
Maximum file size: 50 MB
Please ensure that visibility permissions for the document are set to Visible to Everyone with a Link. Only Circle Members will have access to the link.
Describe the document in 140 characters.
Connect this document to a meeting?
This document will be connected to this Circle. Check this box if you also want to connect it to a particular meeting.
Edit this circle
Allow members of the EnTranCe Community to apply to this circle as members? Setting this to 'No' will not affect your ability to invite new members.
This will control the URL of the circle
How often does this circle meet? E.g. once a week, once every two weeks, or once a month, etc.
Maximum file size: 5 MB
Maximum file size: 5 MB
Please select 1 to 3 OPFs
Add a New Revision Document
Document Title *
Document Source *
Upload a File *
Maximum file size: 10 MB
Share a Link *
Please ensure that visibility permissions for the document are set to Visible to Everyone with a Link. Only Circle Members will have access to the link.
One-line Description
Describe the document in 140 characters.