OKRs empower product development teams, freeing them from the feature factory anti-pattern, allowing them to contribute their value to the company's strategy. In this article, I will show you how: 👇
If you haven't read about OKRs before, you can read a quick introduction here.
🕑 Reading time: 5 minutes
(1/6) OKRs align teams with strategy and allow them to break away from the IT services model
Traditional organizations have mostly adopted agility in a limited way. They have seen it as a method to deliver identified projects in the strategy sooner and better, defined by the business departments.
Agility has often been installed within IT Services departments. It has not resulted in an organizational redesign with teams empowered by management to execute the business strategy.
Product Owners, who were supposed to be empowered Product Managers bridging business opportunities to technical teams, have mostly remained as "proxies" or agile project managers.
Well, OKRs are an opportunity to change this. Let's see an example:
Company OKR
Objective: Improve customer satisfaction with gym reservations.
- Key Result 1: 75% of reservations can be made by the customer themselves.
- Key Result 2: Customers find availability for 80% or more of their favorite classes.
What wouldn't make sense are these team OKRs:
- Business objective (Operations): Define an app for customers to make reservations themselves.
- Technology team OKR: Implement an app for gym customers.
Instead, when defining and aligning team OKRs, the operations and technology teams should agree on common OKRs to contribute to the company's OKRs.
Or they can also jointly define aligned initiatives or tasks that contribute to the company's OKRs.
This way of defining the work of technology teams separates them from the IT Services model, which delivers technology in response to "business requirements."
(2/6) OKRs provide clarity and direction to the Product Owner
When the Product Owner receives a request for a feature or project, it is common that they do not receive the full context of the strategy that motivated its creation.
For example, the request is "We need an AI chatbot for the website." It is supposed to reduce calls to the support department. But it is not known how it aligns with the company's strategy or other departments.
If the company's objectives for this year were:
- Objective 1: Reduce customer service time by 30%.
- Objective 2: Have better knowledge of the origin of incidents to improve customer satisfaction.
Then the Product Owner would have very valuable information to know what business problems this chatbot should solve.
This would allow them to interact with the support and engineering departments to find the best way to make support more efficient without losing coordination between these departments.
In other words, OKRs can give the Product Owner clarity on the problems to solve and the best possible direction that solutions can take.
(3/6) OKRs foster transparency and communication with stakeholders
A definition of transparency in organizations could be "shared understanding."
OKRs facilitate all teams understanding what results are expected from them and how they should collaborate with other teams to contribute to the results expected by the company.
Without OKRs, communication can become fragmented, as well as the shared vision of what each team should do and how they should collaborate.
With OKRs, planning the shared work and the responsibilities of each person is simplified. In the previous job:
- Objective 1: Reduce customer service time by 30%.
- Objective 2: Have better knowledge of the origin of incidents to improve customer satisfaction.
Support departments, engineering, and the development team understand the common goal and identify the actions each can take, as well as the dependencies between them.
OKRs have frequent check-in meetings, e.g., weekly or biweekly. It is more difficult for departments to diverge with incoherent actions or delays. Prioritization and joint coordination improve.
(4/6) OKRs foster a results-oriented team approach and reduce hierarchies
The product team may have different criteria for prioritizing Sprint work.
The simplest interpretation of Scrum says that all prioritization is done by the Product Owner. But this:
- Overloads this professional,
- Limits the contribution of other team members' criteria, and
- Can demotivate other members who "follow the Product Owner's orders."
OKRs encourage the entire team to participate in defining Objectives and Key Results. And also the joint planning of Sprint work to carry them out.
Although roles such as OKR Champion (similar to the Scrum Master) and OKR Lead (similar to the Product Owner) are maintained, using OKRs favors team self-management and a results-oriented work approach.
(5/6) OKRs give the team autonomy to challenge non-strategic requests
One of the challenges agile teams face in making contributions with a real impact on business strategy is the continuous reception of various requests from business departments.
While these requests may be important to those who make them, they may also be misaligned with the organization's strategy. And that is a problem because teams' time is a scarce resource.
Well, OKRs make it easier for Product Owners to focus on strategic objectives. Continuing with the previous OKRs example:
- Objective 1: Reduce customer service time by 30%.
- Objective 2: Have better knowledge of the origin of incidents to improve customer satisfaction.
If we receive a business request to "Add a multi-language option for customer service in other countries," the Product Owner can evaluate that this request is not aligned with strategic OKRs.
That does not mean it has to be automatically rejected. There might be capacity to fulfill this request while still delivering the OKRs. But it provides a clear criterion to distinguish between strategic and non-strategic requests.
(6/6) OKRs improve learning to align planning with strategy
Finally, another advantage of using OKRs for Agile or Scrum teams is that they reinforce learning and empiricism to define:
- how to set product and sprint goals.
- how to plan the work to achieve these goals.
The OKR method, like Scrum, requires retrospectives to improve the team's internal efficiency and relationships with external stakeholders.
Scrum retrospectives are more frequent, e.g., if we have 2-week Sprints and quarterly OKR cycles, we can have 6 Sprint retrospectives for each OKR cycle retrospective.
This helps the team's efficiency in the OKR cycles. We have more opportunities to correct the team's operations.
On the other hand, while Scrum retrospectives can focus on technical or process improvements, OKR retrospectives focus exclusively on improving the team's work results.
These OKR improvements can bring ideas like:
- Improving customer knowledge to identify better requirements.
- Improving product strategy to help prioritize features.
- Improving metrics that indicate value from the customer's and business's perspective.
Reflection and action
In this article, you have seen how OKRs can improve the effectiveness of agile and Scrum Teams' work, with advantages of using both models together such as:
- OKRs align teams with strategy and allow them to break away from the IT services model.
- OKRs provide clarity and direction to the PO.
- OKRs foster transparency and communication with stakeholders.
- OKRs give the team autonomy and allow them to challenge requests that do not align with the strategy.
- They foster a results-oriented team approach and reduce hierarchies.
- They improve learning and empiricism to enhance strategies and tactics.
If any of these reflections give you an interesting idea: put it into action!
And if you think I can provide you with my point of view: contact me! I will be happy to listen to you with no obligation.