Agile Goal Management: Using OKR to Set Stretch Goals and Achieve Higher Team Performance

The traditional, annual planning process is called static planning. In this approach, there is a company consensus in which the strategic thinking will be done and the company goals for the year will be defined. Afterwards, in the following weeks, the goals circle through the company, creating a detail, fixed plan for the year for the entire corporation. 

Usually, the plan should be revisited in 6 months, but some companies skip this step since it will take a lot of time.

In the Agile environment the teams use 1- 3 weeks sprints, and in this period they go out to talk to the clients, test the iterations, and learn what works and what went wrong; thus you will NOT be able to apply static goals defined once a year.

Since the plan can only define the company’s views at a given moment of time, the plan (as for a software program) should be reviewed and upgraded, as people obtain and spread the new knowledge and expertise.

In today’s conditions the strategy development processes should enable the corporations to create and adapt strategy quickly, and allocate resources in changing environments.

Objectives and Results Approach

“Objectives and Key Results” (OKR) is a methodology for defining a goal created by Intel and accepted by several global enterprises.

E.g: Objective is to satisfy the clients.

Key Results: site visits: active users make on average 4 visits per week; fulfill a Net promoter score of 85%; non-paid traffic of 80%; involvement: 70% of users create a full profile.

Rather than applying a static plan with fixed yearly goals, the OKR method deals in quarterly (and sometimes monthly) goal cycles, providing an agile, iterative approach to goal definition.

The success criteria are different for different companies – for some it is the creation of a big technical contribution, for others it is the market success. In fact, every project, investor and initiative should define the criteria for success.

One of the main aspects of the OKR approach is that it enables the creation of shared success criteria. In a very simple process, it defines the expected goals and directions where do we want to go.

1. Permanent learning
You should apply a Business Model canvas to define hypotheses, customer development to test the hypotheses, and Agile methodology to build the project iteratively and incrementally. But in order to obtain a “validated hypothesis” you will need clear, shared success criteria for validated learning. So one of the most relevant things to apply is OKR – it will enable you to track if you are going in the right direction.

2. Success criteria definition
Agile projects are usually measured by the velocity they deliver features (with “quality”). But a team that delivers items, but fails to achieve the desired business results – will never be considered successful. In reality, delivering items that do not positively affect the selected metrics (Key Results in our terms) may produce negative returns. The new code may consist errors, it should be maintained and the product itself will become more complex.

3. Agile manifesto improvement
Time has passed since the Agile Manifesto introduction, so it is time to evolve on one of its principles: working software is the primary measure of progress. The primary indicator of progress should be the business outcomes, not just working software. And the OKR is the right choice for that.

4. Floating goal problem
If you make frequent changes, you will never produce the desired outcome. It is the same issue with the development process: if you keep pivoting all the time, you will never get to where you want.

5. Self-managed teams
If you want to have a horizontal, self-alignment, self-guided company, consisted of self-managed teams, you will have to set a clear direction for the teams. An application of the Objectives-key-results approach for the teams – will help you to do that.

6. Team connection with the customers
Your team can easily get lost in technologies for development and writing code, but if you define the business outcomes at the beginning, your team members will start asking why they are doing, and not what they are doing.