OKR and Agile: A Deep Dive into Organizational Efficiency

OKR (Objectives and Key Results) is a popular topic, and the company I work for, Youzan, has been implementing OKR since 2014. The CEO brought back this management method from a trip to Silicon Valley, and it has been in use ever since. This sharing session focuses on my experiences and insights in practicing OKR.

OKR, project management, and Agile are all methods to enhance the efficiency of a company or organization. OKR and Agile are interconnected, both involving a lot of uncertainty and requiring a balance of various factors.

Management is an art, and system thinking and organizational design are fundamental skills. When practicing Agile, you will inevitably encounter organizational design. To build an Agile team, you need specific roles. When we form a team, we start with organizational design. In large-scale Agile frameworks, organizational design is a crucial task.

You might be wondering about your role within the organization. Are you a project manager, Agile coach, ScrumMaster, or technical lead? When making decisions, are you objective? Often, optimizing within a small scope doesn't allow for global rationality. Why? We've found that regardless of the role, one's vision is limited by their work scope.

To break free from the constraints of your role and limited vision, and to see a broader range and higher dimension, you need to return to the topic of system thinking. System thinking originates from system dynamics, a field of study. One of its properties is that systems have a layered, nested phenomenon. What you see is one layer; to see a larger, higher layer, you need to step out of your current scope and into a higher-dimensional world. Practicing Agile is similar; it requires system thinking and a higher-dimensional perspective.

My Agile worldview can be described in three stages: seeing the mountain as a mountain, seeing the mountain as not a mountain, and seeing the mountain as a mountain again. Initially, when I first encountered Agile, I learned many methods and tools from courses, such as the 3-3-5 rule. At that time, I thought Agile was just about following its framework and executing step-by-step. This stage involved learning the form of Agile without understanding its essence.

Later, through various project management, organizational optimization, and efficiency improvement tasks, I began to adapt and flexibly apply the Agile knowledge and methods I had learned to actual work. For example, based on the organization's current state, using empathy to identify areas that need guidance and improvement, and then gradually integrating Agile practices. Over time, we introduced Agile elements into more areas and made some innovations. This stage involved understanding the essence of Agile and gradually integrating it.

After reflection and consolidation, we realized that Agile's methodologies are applicable to many work scenarios and can solve many problems. They are the result of countless practices by predecessors. We also began to reflect: Why do Agile? What is the essence of Agile?

I believe the essence of Agile has three aspects: priority, high-quality delivery, and flexibility. Are our priorities clear? In a team or large organization, do we have a method for doing things? What is the priority? People can only do one thing at a time; which task should be done first and which later?

The purpose of our work is to deliver and create value. High-quality delivery is one of the results of Agile.

Can our organization or team flexibly respond to external changes? If so, it is Agile, and there is no need to emphasize the 3-3-5 rule rigidly. Rigid Agile is not Agile.

To see the world above Agile, we need to look at the bigger picture and understand the essence of the problem. As the Buddha said, 'Three thousand worlds.' There are worlds beyond worlds. While practicing Agile, we should also have higher-dimensional thinking and practices.

In the process of implementing Agile, we should understand its principles rather than just learning its methods. Tools are auxiliary means for management, and in tool design, it should be the tools that adapt to the organization, not the organization adapting to the tools. In the actual operation of Agile, even if the tools are set up perfectly, if they do not match the organization's current state, they will still feel awkward to use. The methods include the frameworks and tools provided by Agile, such as the 3-3-5 rule mentioned earlier. Here, it is noteworthy to stand at the level of principles and methods, from a higher angle, to review whether all these tools are needed, to avoid rigid application, and to make Agile rigid.

Value is external. Don't assume that the Agile of an Agile team is end-to-end. Above the Agile team, there are higher-dimensional teams, such as departments, business lines, business units, or even the company. We need to look at the overall goals from a global perspective and whether they are achieved. What value does the Agile team create, including value to the company and business value?

The phrase 'value is external' is proposed by management guru Peter Drucker, meaning that anything we do is evaluated and recognized externally. Are our actions helping the company complete the Agile transformation, or are they creating value for the company? When doing organizational design, we also need to face whether external value is created.

Typically, a company's mission and vision describe the organization's form and goals, leading the company to form teams to achieve these goals. Therefore, organizational design must originate from the mission and vision. At the same time, the mission and vision are consolidated through corporate culture to strengthen organizational design. The mission and vision are macro-level, guiding the organization's development. In the process of guidance, there will inevitably be discordant elements. That is, when we are within the organization, we find organizational bottlenecks at the micro-level and then drive and influence organizational design. Of course, any redesign must not violate the company's mission and vision.

Specifically, how to implement this returns to the topic of system thinking. We need to use the system thinking approach to clearly see the organizational form, how it operates, and how the various links influence each other. Then, through coaching guidance, influence the behavior and cognition of various roles in the organization, guide the organization to adjust and optimize, which is a gradual process and cannot be achieved overnight.

In the entire actual operation process, we will adapt Agile elements according to the company's organizational structure adjustments. Our ultimate goal is to help the company improve efficiency and serve the mission and vision.

When looking at the system, we must consider the characteristics of the system we are in. What are the characteristics of a system? Adaptability. Organizations have adaptability and will adapt to the environment and self-adjust when influenced by external forces. Self-organization. The ability to shape oneself and make oneself stronger. A team is also a system and can shape its own abilities, generate new structures, and become more diverse and complex. Hierarchy. Systems have layers, such as lower-level systems and upper-level systems.

Why combine OKR and Agile? They operate at different dimensions but ultimately achieve the same goal. The difference is that Agile acts on a team, while OKR acts on the entire organization. The similarity is that both Agile and OKR are iterative, aiming to quickly test and reduce risks. Both Agile and OKR have simple rules, but in actual implementation, they will form different characteristics according to different organizational forms and environments. To master their laws, adjustments and adaptations are needed according to the scenario and current situation.

Returning to organizational design, first, the organization needs a mission that exists from the organization's creation until its dissolution. Then, there is the vision, which has a smaller time span, usually 5-10 years. Next is the strategy, which answers how the vision is implemented and achieved. The strategy's time is usually 3-5 years, and the organization needs to transform its strategy according to market changes. Then comes the goal, which answers how the strategy is implemented. Organizations usually set a goal every half year or year. Finally, there is action, which involves what actions are taken to achieve the goal. A month or even a day's action is taken to achieve the goal.

From mission to vision to strategy to goal to action, it is layer by layer, becoming more concrete and specific as it goes down.

OKR and Agile are interconnected, and their commonalities include: experiential framework. OKR principles are few, and Agile's Agile Manifesto content is not much; both OKR and Agile need to be summarized in practice, and it is difficult to replicate between different teams. variable planning. Agile's next iteration is its plan to be adjusted, aiming to frequently detect market feedback and quickly test. OKR is the same; it is not like KPI, which is fixed from the beginning but needs to be flexibly adjusted and reviewed in stages, evaluating how far away the goal is based on the completed action items, and adjusting the goal and action at any time to achieve the desired result. self-driven management. Agile is a self-organizing team, with tasks and which one to do being self-claimed; OKR is also like this, with goals being defined from the bottom up, and the entire team co-creating. can be layered. In Agile, features need to be split into user stories and tasks, and OKR also needs to be split into goals, key results, and action items. iterative progress. Both Agile and OKR are dynamic, iterative processes. In this process, they continuously review whether the value of the goal has changed, whether new high-value goals have emerged, whether the current behavior can contribute to the goal... continuously iterating and optimizing actions and goals to achieve more valuable results. focus on value delivery. We do Agile to better deliver value, and OKR's goal is also to deliver value.

The complexity of implementing OKR is related to organizational complexity. It is relatively easy to practice in a team. Like when everyone practices Agile, they will find that it is easier to promote Agile in a small team. However, when it comes to a large organization, organizational complexity is reflected.

The division of organizations is also systematic, with teams at the top, followed by business units, then business groups, and finally the group company. Incidentally, organizational complexity reminds me of the LeSS framework in Agile, which is also based on complex organizations.

Why is it more difficult to implement OKR in complex organizations? As shown in the figure above, a team is one-dimensional, with you, your boss, and your boss's boss, at most three layers, with a pure single-line reporting relationship; a business unit is two-dimensional, with many teams in a business unit, and teams may intersect, with team goals possibly conflicting or depending on each other, requiring alignment; if the relationship network within a business unit is a two-dimensional plane, then a business group is a three-dimensional space, with multiple business units (planes) in a business group, producing a large number of dependencies, and the difficulty of alignment is greater; a group is four-dimensional, with multiple business groups in a group, and the interdependence between various units is even more complex.

In the actual operation, because we consider that the real-line reporting relationship cannot be changed, we use the virtual team method to reduce dimensions, letting feature teams achieve goals and solve dependencies between teams. Through the virtual feature team method, the complexity of goals within the business unit is reduced.

At the group level, there is a more complex issue: the business middle platform. Generally, it is believed that after the business middle platform appears, all end-to-end goals are artificially strengthened in complexity because they cannot bypass the provision of business middle platform capabilities. There is also a dependency and inconsistency between the business middle platform and feature teams because the capabilities provided by the business middle platform need to be interfaced by feature teams, and vice versa, feature teams have some user-facing functions that need to be sunk to the business middle platform for implementation, resulting in goal inconsistency between the two.

Therefore, for a team, there are four goals: internal technical goals, business goals from the product team, goals from other feature teams, and goals from the middle platform. How to handle this? We use the high-frequency linkage method to improve the transparency of group-level goals and facilitate alignment between all parties.

Like Agile's weekly iteration, OKR also needs to be iteratively updated. Our approach is: within the feature team, align internal goals once a month and external goals every three months. After iterative updates, synchronize the information to the outside. Only transparency can truly achieve alignment. From this perspective, OKR is equivalent to a group-level Scrum every three months.

OKR is an organizational-level goal management that must start from the company's goals, connect all organizational links, and link them together to make the goals of various teams serve the organization's overall goals and create value for them. So, after we practice and land OKR, what can we see above the organization? Organizational boundaries. Organizations are systems and therefore have boundaries. Exploring where the boundaries are, we know where the upper-level system is. Mission and vision. Any organization has a mission and vision, and we need to see the organization's mission and vision to find a higher-dimensional world connected to the organization's goals. Value is external. Use the system thinking method to feel the value we bring to the organization from the outside.

In summary, system thinking is the bottom-layer framework for solving problems. Organizational design is the top-layer thinking for improving efficiency. OKR is a self-driven goal management method based on self-driving.