How do OKRs (Objectives and Key Results), Scrum, and Agile come together? Many people struggle to understand the relationship between these three concepts, often equating OKRs with Agile or confusing Agile with Scrum. Especially when some organizations introduce both OKRs and Scrum as their agile methodologies, employees may not fully grasp how they interact.
Your AI-powered meeting assistant — Huddles
The Birth of the Waterfall Model and Agile
OKRs were initially applied in the tech industry and software development, often in conjunction with Agile software development. In many cases, Agile software development is used interchangeably with the Scrum framework, leading to confusion. However, this isn’t entirely accurate.
To understand the concepts of OKRs, Agile, and Scrum, it’s important to first grasp the origins of Agile.
This leads us to the Waterfall model, a predominant model in the working world for the past few decades.
The Waterfall model describes a linear process model in project management, primarily in software development, where the development process is divided into sequential project phases.
Only when the previous phase is completed based on predefined, measurable criteria or milestones can the next phase begin.
The most common variants of the Waterfall model include the following five phases (as shown in the diagram below):
- Planning: Requirements analysis and specification.
- Design: System design and specification.
- Deployment and Maintenance.
It’s evident that the Waterfall model is a linear and static structure, which results in highly rigid processes and objectives, inhibiting agility right from the start. This type of workflow made perfect sense in the 1970s when external environments were more predictable.
In fact, Waterfall thinking was based on four major misconceptions:
- We can foresee all the steps of a plan in advance in detail.
- Most of our plans will prove to be correct.
- The market environment won’t change or will change minimally.
- Change is minimal; a biennial review is sufficient to address any potential changes.
However, the linear and static nature of the Waterfall model has become largely outdated in the increasingly complex business world today. New paradigms and methodologies like “Agile,” “Scrum,” or “OKRs” offer more suitable answers to the new challenges we face.
What is Agile
The term “Agile” was coined by three scientists from Lehigh University in Bethlehem, Pennsylvania. According to their perspective, agility refers to a particular form of organizational management characterized by forward-thinking, flexibility, and proactiveness in everyday work.
They believed that “traditional” organizations tend to work in a way that is process or project-oriented. The resulting strict hierarchical systems may increasingly hinder and paralyze organizations in the modern, unstable market realities.
To distinguish themselves from traditional organizational cultures, they defined six dimensions for agility that must be present in an organization to be considered “Agile.”
These dimensions are as follows:
- Agile Vision and Mission.
- Customer-Centric Organizational Structure.
- Iterative Process Objectives.
- Employee-Centric Leadership.
- Agile Personnel and Management Tools.
- Agile Organizational Culture.
In February 2001, 17 software industry experts gathered at a ski lodge in Snowbird, Utah. After several days of discussions and debates, they collaboratively authored the “Agile Software Development Manifesto.” The term “Agile” began to gain traction, and the methods discussed at that time were specifically related to software development, eventually leading to the development of methods like “Scrum.”
What is Scrum
Scrum is a project management framework that ties various events (meetings), artifacts (such as the backlog), and roles (responsibilities) together through specific rules to facilitate agile work in software development.
The term “Scrum” originally comes from sports, describing the Scrum formation in rugby matches.
American software developer Ken Schwaber formalized Scrum in 1993, where he wrote, “Scrum acknowledges that the software development process is unpredictable. Given cost, functionality, time, and quality, the best software is that which does the most for the least.”
Scrum is primarily based on the concept of “sprints”:
- A Sprint represents a defined time unit during which the team commits to specific tasks.
- Sprints typically last from one week to one month.
- Each sprint ends with a review, meaning the Scrum team – as well as other key stakeholders – reviews the progress made at the end of the sprint, laying the foundation for the next sprint.
- After the review, a new item is selected from the product backlog, and a new sprint begins, addressing new key tasks one after another.
- During the Sprint, there is a daily Scrum stand-up meeting where the team briefly reports progress. The daily Scrum stand-up meeting should not exceed 15 minutes.
From this image, we can intuitively see the framework process of Scrum. It typically begins with addressing an item, such as the product backlog in the image, to define a sprint cycle, plan for the sprint period, and resolve issues one by one. During this period, there are daily sprint goals, and a daily Scrum stand-up meeting is conducted. At the end of the sprint cycle, an evaluation of the employees’ performance is carried out, and decisions regarding rewards (such as salary increases) may be made. After the evaluation, a retrospective is conducted.
It’s worth noting that Sprint Review and Sprint Retrospective are commonly used Scrum events worldwide. Although similar – both occurring at the end of a sprint – they are distinct and separate.
The Sprint Review primarily involves showcasing the work just completed in the recent sprint. It can be informal, presented to internal team members, or a more formal meeting that invites stakeholders beyond the core team. Regardless of how the sprint review is conducted, the work should be fully demonstrable and meet the team’s defined quality standards for review. The team can celebrate their achievements and receive immediate feedback from the sprint review participants.
The Sprint Retrospective often takes place after the review and is a time for the team to reflect on the work just completed, acknowledge areas of success, and make suggestions for improvement. It should be action-oriented, and individuals outside the project’s periphery do not need to and should not participate.
By adhering to these rules and through the interaction of Scrum elements, agile work can be achieved at the operational level (project and product management).
OKR and Agile
But what about the other aspects of agility mentioned earlier? This is where OKR comes into play. When a company is trying to move towards agility, OKR is often the missing piece of the puzzle, as many organizations rely solely on Scrum. This is because Scrum is about operational agility, while OKR is about strategic goal-setting. However, combining these two agile approaches is the perfect foundation for creating a truly agile organization.
OKR stands for “Objectives and Key Results” and describes a management system that is centered around goal orientation, is more modern, and flexible in its approach. Objectives are qualitative and inspirational, and their achievement is measured and controlled through key results.
Unlike Scrum, OKR is not an agile software development methodology; it carries the same “agile” spirit as a concept in itself. When understood and applied within an organization, OKR helps make the organization more agile for several reasons:
1)More Frequent Goal Setting:
In many organizations, it is common to define goals annually and assess them once a year. However, in the modern and fast-paced work world, this is clearly a slow pace and hinders an organization’s responsiveness. OKR has shorter definition cycles (we recommend quarterly), allowing for at least four opportunities in a year to respond to external influences or internal strategic adjustments, enhancing the company’s agility.
2) Transparency and Improved Communication:
To enable a company to effectively respond to a constantly changing environment and restructure itself, two things are necessary: all information must be available (transparency), and the system components (employees and teams) must be able to share information with each other (communication). OKR creates transparency by making objectives visible and communicable. They create transparency by having all teams carefully examine the company’s OKRs and aligning their team OKRs with them, thereby carrying out the company’s mission and strategy. OKR planning, reviews, retrospectives, and weekly OKR check-ins also facilitate internal team and interdepartmental communication, shortening the feedback loop. All of this contributes to agility.
OKR emphasizes consistency. In traditional linear work modes, leaders assign tasks and set deadlines, which not only fails to promote agility but also doesn’t inspire intrinsic motivation in employees. However, without this standardized control, when the day ends, everyone may be running in different directions, leading to potential chaos. So, to achieve more agility, organizations need to address the issue of consistency first: companies do not micromanage employees, but employees can still work toward the same direction. OKR accomplishes this. OKRs align with strategy at the top and execution at the bottom, allowing all members to move in one direction while maintaining agility and autonomy. The “goal vector” is no longer mutually counteracting but rather coordinating and supporting each other.
4) Autonomy and Self-Organization
Another advantage of the OKR framework is its impact on agility through increased autonomy and self-organization within the company.
Simply passing down objectives from the company or department to lower levels in the hierarchy can reduce motivation, especially limiting the ability of “bottom-tier” teams in the organizational chart to take effective action. In OKR, the transition to more self-organized teams is achieved by independently setting team goals. This transformation enables teams and individuals at every level of the hierarchy to be more action-oriented, with increased autonomy and independence. This makes them more responsive and flexible, without the need for extensive approvals from superiors. Teams closest to the market can respond directly to new developments without being slowed down by internal approvals and bureaucratic processes.
Furthermore, collectively formulated OKRs within teams can help them feel a stronger connection with each other. They can clearly see the alignment between their work and the company’s vision and the significant value their work generates, which motivates them intrinsically. If top-down task allocation were used here, employees would lose the meaningful purpose and benefits of intrinsic motivation.
5) Focus on Results, Not Outputs
Unlike Scrum, OKR is not about creating an output but about achieving results. The defining characteristic of results is their actual measurable value to the customer. Outputs do not necessarily possess this value, making them easier to plan. In simple terms, OKR is not about what work you’ve done; it’s about the actual value your work has produced, as measured by its Key Results (KRs).
Therefore, OKR positively impacts customer-centricity, which is one of the six dimensions of agility. This results-oriented approach requires a deep understanding of customer needs and a willingness to open up to the external environment, establish feedback loops, and communication channels with customers, making the organization more agile and flexible in its interactions with the outside world.
As mentioned earlier, OKRs and Scrum can be used together. When these two frameworks are appropriately combined, they create a perfect synergy for overall agility, becoming powerful tools for agile organizations. However, it’s essential for everyone to have a deep understanding of each objective, the purpose behind it, and internalize it. Additionally, it’s recommended that organizations define OKRs first, as they have a longer time frame compared to Scrum sprints.