Zhang Le: The Golden Triangle of R&D Efficiency and Practice in the Field of Demand and Agile Collaboration｜Review of Live Streaming

On July 27th, the first course of ONES R&D Management Master Class officially started. The lecturer invited in this issue is Mr. Zhang Le, a senior technical expert in Tencent DevOps and R&D efficiency, who shared the theme of "The Golden Triangle of R&D Efficiency and Practice in the Field of Demand and Agile Collaboration". Through the framework of the "Golden Triangle", the importance and key elements of R&D efficiency are discussed to help enterprises achieve efficiency improvement.

The following is the main content shared by Mr. Zhang Le that day.

Nowadays, enterprises such as the Internet, software, and digitalization are developing rapidly, but the issue of R&D efficiency is often ignored. With the increasing scale and complexity of enterprises, how to maintain a high level of R&D efficiency and help enterprises improve efficiency is the core question to be answered in this topic.

What is the goal of efficiency? Based on business goals, we generally plan for two elements - ideal functionality and quality, and ideal workload. At the same time, if there is an ideal, there will be reality, so there will be actual functions and quality, and actual workload. Usually, there is a certain gap objectively between the ideal and the reality, which leads to a gap between "efficiency" and "effectiveness". Therefore, R&D effectiveness should pay attention to both input and output; it should pay attention to both efficiency and effectiveness.

R&D efficiency, in a word, is more efficient, higher quality, more reliable and sustainable delivery of better business value. Efficiency refers to the dimension of efficiency, and high quality and reliability refer to the dimension of effectiveness. On this basis, we must also pay attention to sustainability, which can continue to empower business success.

We have determined the goal, how will it be implemented next? After researching many companies at home and abroad, I found that they all focus on these three dimensions of R&D effectiveness: effectiveness platform, effectiveness practice and effectiveness measurement. Therefore, I organize these three parts into a model, and call it the "Golden Triangle" of R&D efficiency.

Let’s briefly explain the relationship between the three: performance practices include management practices, engineering technology practices, organizational practices, etc. We need to extract these practices and deposit them on the performance platform; in turn, the performance platform undertakes the implementation and implementation of the practice. At the same time, we need to gain insight into the data generated in the R&D process through performance measurement, find bottlenecks based on the measurement results, and then further optimize performance practices and performance platforms. Therefore, these three constitute an enhancement loop that can reinforce each other and continue to iterate. It is an organically integrated community. I call it the "Golden Triangle" of R&D efficiency. Of course, only this high-level model is not enough, let's see how it works.

The first corner of the "Golden Triangle" - Efficiency Practice. It consists of four parts: the conception stage, the development stage, the release stage, and the operation and maintenance stage. The conception stage is the stage where product exploration is carried out and relatively clear requirements are formed; the research and development stage should be product-oriented, not project-oriented; followed by the deployment and release stages of engineering excellence, and application-oriented The operation and maintenance phase of the center.

Next, let's take a look at the practice maps corresponding to these four stages:
Conception stage: product planning, impact map, demand structure, etc. R&D stage: agile collaboration, branching model, continuous delivery, etc. Release stage: environmental governance, release strategy, online experiment, etc. Operation and maintenance stage: cloud-native infrastructure, chaos engineering, monitoring and observability, etc.

In fact, R&D activities can be divided into two different parts - the first half is dominated by unique creative activities in R&D activities, including requirements analysis, design and coding, etc. It is characterized by a high degree of uncertainty and requires continuous exploration. and experimentation, this is the scope of agile practice; after the code is submitted, it will gradually flow to known and deterministic activities, which can be repeated many times, have excellent practices, and can be automated Process, which is the domain of lean practices, engineering, and technical practices. Therefore, when talking about whether the R&D process should be industrialized and standardized, it should actually be divided into two different parts to discuss. Software is a product produced by agile production lines on a lean assembly line.

The second corner of the "Golden Triangle" - performance platform. What is the performance platform? Many companies say that we need a one-stop DevOps platform. Engineers do not need to enter multiple portals. All in one platform can complete requirements management, code management, pipeline, deployment and release, monitoring log management, etc. But in fact, in many so-called "one-stop platforms", there will be a problem: all functions are available, but the platform is pieced together, and engineers are not easy to use. The root cause is that it is not organized according to specific scenarios and lacks the main line of R&D activities. As I often say, a product must have a soul, and the key to the success of the R&D efficiency platform is to use the R&D scenario as the main line to run through functions and logic.

Based on this, I drew a graph. The first main line is "agile collaboration with feature flow as the core" - taking the flow of requirements and features as the overall driving force, and pulling cross-functional teams (front-end, back-end, testing, operation and maintenance) to communicate, align, and collaborate ; The second main line is "change-based delivery flow" - to undertake the implementation of requirements, you must also create feature branches, write code, test, deploy and go online, etc. What is changed here is the smallest unit of application release, which is used as the main line to run through a series of engineering activities in the R&D life cycle, and the landing form can be what we often call "pipeline"; "——Combined with the mainstream model in the cloud native era, establish the required infrastructure and the associated model of the components, and align them with the application life cycle, so as to better complete the subsequent deployment and operation and maintenance automation, and ensure the system's reliability. stability.

One of the advantages of the "one-stop platform" is that the activities and information of the entire R&D link can be interconnected. For example, in the online release sheet, a lot of information can be associated, what are the requirements, what are the code submissions, whether they have been tested, whether the associated version can be built, which environment to deploy to, etc. These information will be aligned and transparent. ; another advantage is state linkage. For example, when we associate a branch with a requirement, we turn the requirement into a state of development; when we initiate testing or release, we turn the requirement into a state to be tested or released, so as to achieve interconnection and automatic linkage.

The third corner of the "Golden Triangle" - performance measurement. A lot of data is generated in the R&D process, and we can use it to evaluate, analyze, and improve to help companies improve R&D efficiency. This is the necessity of doing efficiency measurement. I divide performance measurement into five refinements, namely: measurement infrastructure, measurement indicator system, insight analysis model, measurement product construction, data-driven and experimental thinking.

Let's take a brief look at the Cube model of metrics, which I call the "magic cube" of the performance metrics system. It is not a plane, but a three-dimensional one. You can raise the "business value" in the figure below. It can be seen that it is actually a cube, which has a "result surface" and a "process surface". From the "result side", we need to consider efficiency, quality, cost and value, which can be summarized as "more, faster, better, and less" we often say. There are many indicators of results, such as demand lead time, demand throughput, online defect density, and so on. In order to achieve this target, we still have a lot of process work to do, all of which also depends on the "process aspect", such as the improvement of collaboration capabilities, engineering capabilities, technical capabilities and organizational capabilities. Therefore, we need to do an overall evaluation and drive based on the result indicators, and drive specific improvement activities through the refinement and analysis of process indicators.

In addition, there are many models in efficacy measurement to understand. For example, the five flow indicators of value flow analysis are flow efficiency, flow rate, flow time, flow load and flow distribution. Using these five metrics together can tell a complete story about the R&D value stream and answer essential questions about delivery efficiency.

The most important and difficult thing in software development is knowing exactly what to do. How to make requirements more reliable, how to organize requirements more effectively, and how to achieve efficient and agile collaboration across roles are overwhelmed, causing headaches for many engineers. Therefore, in order to improve effectiveness from the beginning, we propose six practices in the areas of requirements and agile collaboration.

Let's take a look at the circulation process of the six practices: first, make a reasonable and appropriate product plan through the "three-step product method"; after the plan is in place, you can use the influence map to map business goals and product functions; then , and then use the story map to build a panorama of requirements, so as to avoid over-focusing on parts and losing a global understanding of requirements. Then, the requirements are decomposed layer by layer, so that it is continuously passed down, and the division of labor and collaboration is efficient based on their respective R&D workflows. Finally, the requirements are effectively clarified by the practice of instantiating requirements, providing high-quality input for R&D, and finally entering into agile collaboration.

Let’s take a closer look at these six practices:

First, product planning. We anchor product goals, determine demand value, and develop roadmaps. How to measure the value of a need? There are two major elements here, one is business value, which is related to revenue and costs, and is divided into several dimensions: increasing revenue, protecting revenue, avoiding losses, and reducing costs to increase revenue; the other factor is the information value discovered in the development process, This reduces future feature risk in development and opens up new business opportunities.

Second, the impact map. We make business goals correspond to specific functions, and we can use methods that affect the map. In fact, it can be understood as these four words - Why (what is the business goal that needs to be achieved or achieved), Who (which roles will affect the achievement of business goals), How (how to achieve business goals through these roles and impact) and What (what needs to be done to achieve these effects).

Third, user stories. It helps us build a demand panorama map. Requirement splitting can easily lead to the problem of "seeing the trees but not the forest". The user story map is a way to maintain a clear demand panorama during the process of splitting requirements. For example, when using software to take a taxi, the passenger must call the car first, and then the driver can take the order; after receiving the order, the driver can go to the departure place, and the evaluation can only be made after the trip is over... Therefore, if any function is not placed in the corresponding scene to go See, it's all siloed, and there's no way to find context, and you can't determine version planning and prioritization.

Fourth, demand structure. The delivery of requirements is not as simple as a requirement entry or a user story. It requires different levels of consideration and splitting logic. We generally divide it into three layers: business requirement layer, product requirement layer and technical implementation layer. Business requirements carry business value, and business personnel are generally responsible for collection, creation, and maintenance. The core of attention is how to receive, plan, and implement this demand; the product requirements layer carries the specific functions of the product, and is the product integration and testing. The basic unit of the project is generally the level that the product manager is concerned about; the technical implementation layer is basically the front-end and back-end tasks, which are more concerned by the role of the engineer.

Fifth, instantiate requirements. Illustrating requirements with examples is the basic requirements practice of lean and agile development. It helps teams analyze, clarify, split, and communicate requirements to provide high-quality input for development activities. The core has three steps - the first step: determine the goal, describe the background, clarify user problems and business goals; second step: list user operations and steps; third step: clarify business rules, express scenarios and business in the form of examples rule.

Sixth, agile collaboration mode - Scrum and Kanban. Many teams have heard of Scrum, but getting it right isn't easy. In 2020, the "Scrum Guide" introduced the concept of "Product goal", which has the same meaning as the product planning and goal orientation we just talked about. To make a product, first of all, the overall goal should be clear, and of course the goal of each sprint should be clear. Also note that in Scrum mode, "self-management" is also important. Many people think that "self-organization" is unorganized and undisciplined. In fact, the self-management of Scrum is to participate in the whole process around the product goal to ensure that it can operate smoothly.

In addition to that, we have Kanban mode. It is the application of Lean in the software development process, and there are many principles, such as work visualization, management flow, explicit process rules, collaborative improvement, etc. I won't talk about it in detail today. In the second and third courses, I will explain the scenarios and cases of Scrum and Kanban in detail.

Finally, let's talk about how to organize a good organizational structure, which has four key teams. The first is the business team. They are business R&D and are solely responsible for the results. The primary goal is to achieve business needs. The business team needs to always remember: "Why do we set out?" That is, we must clarify our pain points. If the pain point is to deliver faster, then you need to take the initiative to take on some technical debt; if the pain point is to improve stability, such as online payment services that require high concurrency, quality is the first, and for efficiency, normal performance is good. Therefore, we must start based on goals and start with the end in mind.

The second type of team is the tool team. For example, the DevOps platform and the performance platform should provide high-quality and efficient services. The people on this team have two considerations. First, the largest group you serve is engineers, and you should give engineers the best support; second, the so-called one-stop platform must be organized according to R&D scenarios. As I just mentioned, agile collaboration centered on features, delivery flow centered on change, and operation and maintenance centered on applications. So what are the common anti-patterns? Its anti-pattern is the "forced push of tool platforms", forcing everyone to use tools through administrative orders and imposing a specific R&D model on users, which is not desirable.

The third type of team is performance specialists or agile coaches. It is introduced and implemented through a series of methods and practices to form a joint force, so that the R&D efficiency practice can be continuously promoted and implemented. At the same time, they should organize successful cases and performance improvement experiences into a performance improvement knowledge base.

The fourth type of team is the organizational management team. Their main responsibilities are to promote major issues of research efficiency as a whole, formulate the company's unified code specification, promote the company's unified coding style, popularize code quality awareness, and promote code culture, etc. However, let's not blindly promote consistency across the board and do not over-control.

Finally, I would like to give you a sentence: "Don't lie flat, don't roll in, and walk steadily and far." Really improve efficiency, let good ideas, good methods, and good technologies go deep into daily R&D work, help us become more efficient, and make our lives better.

The first season of ONES R&D Management Master Class is still going on. Courses such as "How to Improve Efficiency in Lean-Agile Portfolio Management" and "Methods and Practices for Efficient Collaboration in Large Software Teams" will be launched soon. Pay attention to the ONES video account, more live broadcasts are coming soon!