头图

On August 10th, the second session of the ONES R&D Management Master Class officially started. The lecturer invited in this issue is Mr. Dong Xiaohong, a consultant of ONES R&D efficiency improvement consultant, sharing the theme of "Lean-Agile Portfolio Management to Improve R&D Efficiency". Through lean and agile management ideas, discuss how to make valuable demand flow smoothly and with high quality, so as to improve enterprise R&D efficiency.

The following is the core content shared by Mr. Xiaohong.

Let me first interpret the necessity of improving R&D efficiency from four perspectives.

From the perspective of the organization, the scale of organizational development and technology-driven business differentiation have made it difficult to cope with the rapid changes in the market; from the perspective of the organization, the competition has become increasingly fierce, and the "barn effect" has become more prominent. Partial optimization is not possible. Overall optimization, it is imperative to break the embarrassment of "the big ship is difficult to turn around"; from the perspective of industry technology, all aspects of software research and development have been fully digitized. Prepared for data collection and measurement of R&D efficiency; finally, from the perspective of external resources, in the context of economic stock, coupled with the impact of this year's new crown epidemic, business development cannot rely solely on burning money and crowd tactics . With the decline of product profits, enterprises need to reduce costs and increase efficiency and improve efficiency. These are the four imperatives that I understand to improve R&D effectiveness.

When it comes to Lean, its production system has three phases.

The first stage is the scientific management method stage proposed by Frederick Winslow Taylor, which is the standard operation with a process system, which greatly improves the efficiency of the operation; the second stage is the large-scale production method, represented by Henry ·Ford, he created a Model T car that the public can afford. On the basis of Taylor's scientific management method, he proposed a more standardized and standardized mass production method, allowing the car to enter thousands of households; third The stage is the Toyota Production System, and the representative is Taiichi Ohno. It is said that when Taiichi Ohno visited the Ford assembly line in the United States, he found a lot of waste. He felt that it did not match the Japanese concept of saving. He came up with a lean production method-small-scale, small-batch "pull" production system.

Furthermore, how has Lean evolved in IT software applications? In 1996, James Womack and Daniel Jones released "Lean Thinking", and the lean production method changed from experience to theory, which further extended Lean in other fields; in 2003, Mary and Tom in "Agile Software Development Tools - Lean" "Development Method" maps lean principles to software development; in 2004, David Anderson carried out lean management changes in Microsoft's sustainable engineering team, turning Microsoft's worst-performing team into the best-performing team in 5 quarters ; In 2010, David Anderson released "The Kanban Method: The Success of the Incremental Change of Technological Enterprises". The Kanban method was born out of the Toyota Production System and Goldratt's Theory of Constraints (TOC), which is a further extension of the lean method; 2014 , In China, Huawei first began to implement the lean Kanban method, followed by China Merchants Bank.

Next, we look at the five principles of lean management, which are also the five steps of lean implementation.

The first step is to define value. We must define value from the perspective of users. For example, in software development, we put forward a requirement to think from the perspective of users whether it is what they want, rather than what we imagined ourselves. This is the definition of value.

The second step is to identify the value stream. We start with the end in mind and define all activities in the end-to-end process. Taking software development as an example, the entire process from requirement presentation to review, R&D, and launch is called an end-to-end activity, so that we can have a global vision. With a global view, we can see whether there are redundant steps, blockages, bottlenecks, etc. in the whole process.

The third step is to increase the flow. The value is flowing, and we want to make it flow as smoothly as a river. There is a more important point in this step, that is, from focusing on resources to focusing on value flow. This means that the team should focus on "whether people are busy" at the beginning, and gradually shift to "whether value is flowing", because people who are busy may not necessarily bring value. This is a very important point, and it is necessary to change the thinking.

The fourth step is demand pull. Reduce inventory, we will produce after we have orders, and use downstream to drive upstream.

The fifth step, "perfect", is not satisfied with the status quo, and continuous improvement. In the software industry, the most important thing about "perfection" is "built-in quality", which means not passing the problematic link to the next link.

These are the five principles of lean production, and its highest goal is to reduce costs, improve quality, and shorten cycle times.

Many people actually have a misunderstanding of Kanban, and only regard it as a "visual board". Therefore, it is very important to understand what "Kanban in manufacturing" is. It can help us understand the essence and eliminate misunderstandings. The word Kanban comes from Japanese and originally means a signal card used for lean processes and timely inventory replenishment planning to help companies increase production and reduce overall inventory.

In this lesson, we will focus on the Lean Kanban method. David Anderson was the first to learn from and apply Kanban practices in software development, and summed it up as a complete "Kanban Method System", including the following three core contents:

First, visualize the process. Break the work into small pieces, write a task on a card, and put the card on the wall. This can be understood as, we need to make a software, write the requirements on a card, and then put the card on the kanban wall; the kanban wall is divided into multiple columns, each column has a status, showing that each task is in the process in what position.

Second, work in process is limited based on capacity. Explicitly limit the maximum number of simultaneous tasks on each state in the process. The capabilities and infrastructure of each team are different, and the team needs to explore according to their own situation. It has two purposes. On the one hand, it shortens the cycle time by reducing the number of parallel tasks and speeding up the flow of value; on the other hand, it has the tension of exposing problems, which helps to expose bottlenecks and problems and stimulate team collaboration to solve problems.

Third, measure the production cycle. This helps to tune the process to keep the production cycle as short as possible and make it predictable. This step can help the team determine whether there are unnecessary steps in the process, whether there is waste, whether it is possible to shorten the production cycle, and so on.

After the core content is clear, let's take a look at the five practices of Lean Kanban.

The first practice, visualizing the workflow. It has three main points: what is visible is user value, what is visible is the end-to-end flow process of user value, and problems and bottlenecks are also visualized.

The second practice is to control the quantity of work in process. When the number of internal products in each link is less than the set quantity, it can be pulled from the previous link, otherwise it is not allowed to pull in new work. We need to focus on the work that has been started, on the problem areas.

The third practice, explicit definition rules. This refers to the rules for moving from one column to another in the Kanban board. In addition, other rules should also be defined, such as: requirements priority, urgent requirements and other definitions should also be displayed, so that the team can reach a consensus and execute according to the rules.

The fourth practice, managing the flow of work items. There are two main points here. One is the filling of the ready queue. The ready queue is the source of the Kanban value stream. Only by managing the source can we pay attention to the smooth flow and quality of value. The second is the daily stand-up meeting. The stand-up meeting is also an activity to manage the value flow process, focusing on the problems and blockages of the value flow process.

The fifth practice, establish feedback, continuous improvement. It requires feedback on whether the flow is smooth and feedback on quality.

After talking about the origin of lean, let's talk about the origin of agile. In 2001, 17 software developers brought their lightweight frameworks "Scrum, XP, FDD, DSDM" to the Snowbird Ski Resort in Utah, USA. They abstracted the common features in the framework, sorted out the twelve principles of agile, and wrote a manifesto for agile software development.

Meanwhile, the history of Scrum dates back to 1986. A Harvard Business Review article, "A Novel Product Development Strategy," describes a fast and flexible development strategy to meet rapidly changing product requirements. This article links Scrum to product development for the first time.

Let's take a closer look at Scrum, whose goal is to deliver value through self-organizing, cross-functional, iterative small teams. Underpinning this goal are the three pillars of agile—transparency, inspection, and adaptation. The Scrum framework also has a very important "3355" principle - 3 roles, 3 artifacts, 5 values, and 5 events:

  • 3 roles: Product Owner, Team Member, Agile Coach
  • 3 artifacts: Product Backlog, Iteration Backlog, Product Increment
  • 5 Values: Commitment, Courage, Focus, Openness, Respect
  • 5 events: iteration, iteration planning meeting, daily stand-up meeting, iteration demonstration meeting, iteration retrospective meeting

Next, let's look at Scrum vs Kanban. This comparison is not to evaluate which is better or worse, but to deepen the understanding of the two methods and learn from each other in practice. Their similarity has the following parts:

  • both lean and agile
  • WIP is restricted
  • Both drive process improvement in a transparent manner
  • Both focus on early delivery and frequent delivery of releasable software
  • Rooted in self-organizing teams

At the same time, there are 6 differences between Scrum and Kanban. We compared the 6 dimensions of change import, rhythm, control work in process, event, role, and default measurement. For details, please see the comparison chart below:

Finally, I will share with you an idea of lean and agile portfolio management that ONES does for customers. As shown in the figure below, we can see that energy efficiency, processes, methods and tools are from the perspective of "things", and organizations are from the perspective of "people". The improvement of R&D efficiency, whether it is Kanban practice or agile Scrum practice, is more about how to make valuable requirements flow smoothly and with high quality. Therefore, if we want to improve performance, we can not only rely on some management practices, but also need some engineering practices, such as continuous integration, continuous deployment, continuous monitoring, automated testing, etc., to form a closed-loop operation.

From the perspective of "things", we need to sort out the process specifications and ensure that a series of consensuses are formed in the organizational context, including unified terminology, the concatenation of business and R&D data flows, the consistency of measurement units, and so on. After we have the process specification, we use tools to solidify the process specification. In this process, we can take into account the design of some measurement and buried points, and design some indicators we want, so that the data will naturally fall into the system. Finally, by measuring the UI presentation layer, some data are displayed for various fields, continuous improvement and continuous decision-making.

It is effective to improve performance from the perspective of "things", but it is more important to start from the perspective of "people". I think there needs to be a change leader, such as a Scrum Master or a process improvement expert, an efficiency expert, and so on. These people need to have:

  • Guidance skills, such as being able to guide the team to meet effectively and guide the team to practice.
  • Coaching skills, through this heuristic questioning, allow team members to find their own goals, drive to achieve goals, and stimulate the potential of the team as a whole.
  • Of course, this changer must have self-driving force. He can influence the team, help team members succeed, and help team members shine. At the same time, this person must develop a growth mindset and allow team members to make mistakes. This culture is also very important. important.

The above is the main content I share today, I hope it can inspire you, thank you for listening.

-Q & A-

Question 1:

Netizen: Under the agile software development model, market demand will be split into multiple product requirements, and development will continue to split product requirements into smaller granularities for coding. Therefore, development teams often use product requirements to measure delivery, and R&D efficiency is improving every year. However, the market side believes that from the perspective of market demand, the efficiency has not improved. How to make the two sides reach a consensus on the efficiency improvement?

Mr. Xiaohong: The R&D side has its own continuous improvement metrics, I don’t think it’s a problem. I can see the improvement in the efficiency of the R&D side through statistics, which strengthens the team’s confidence in continuous improvement. Regarding "disapproval on the market side", it is necessary to understand the reasons for the disapproval of the marketing department. If the marketing department feels that the improvement of R&D efficiency is not perceived in the business, it can define some business indicators to lead the R&D to better support the business. Generally speaking, the indicators of the marketing department should be formulated according to the strategy and objectives of the marketing department.

Question 2:

Netizen: How to promote agility in the enterprise in the enterprise management scenario?

Teacher Xiaohong: I think there are the following points. The first point, whether you are promoting agile or DevOps change, I suggest to have a goal, which is equivalent to internal drive: why do I want to do this agile transformation, what pain points do I want to solve, etc.; the second point, as I just said , it is best to have a leader of the change, the leader can be the Scrum Master, he should coach the team how to do agile, how to implement in the enterprise, let everyone understand the principles behind this, etc.; third point, a good tool It is very necessary, it can help you to speed up the whole agile landing.

Question 3:

Netizen: Our company has been practicing agile practices for a while, but many people in the team are reluctant to hold agile retrospective meetings. What should I do?

Teacher Xiaohong: I think it may be divided into the following points. First, talk to the team members about why they are reluctant to participate in the retrospective, do they feel that there is no value? If it is of no value, then you need to check whether the retrospective is based on goals, and you need to have a clear goal; the second point may also be to chat with team members, what they expect from agile retrospectives, What would his perfect agile retrospective look like? Everyone can brainstorm.

Question 4:

Netizen: We are in the manufacturing industry, and we are in a period of agile transformation. What should we do if our employees do not cooperate well in the process of agile practice?

Teacher Xiaohong: I think it is still necessary to look at the reasons for their non-cooperation, or indirectly to check whether they do not understand the essence of Agile. Secondly, let's see if he has any good tools or methods that can better help everyone achieve the goal of agile transformation.

Question 5:

Netizen: Is the core point of Scrum "3355" necessary, or can it be adjusted according to the company's own situation?

Teacher Xiaohong: I think it depends on the different scenarios of the company. For example, when a company is just undergoing agile transformation, it still needs to comply with "3355" as much as possible; when it reaches a certain level of agile maturity, the role of Scrum Master may not be needed. I've seen a lot of client teams before, combining two iterations for a retrospective, and it worked out pretty well. Therefore, at different stages, enterprises can adopt different methods according to their own conditions.


The first season of ONES R&D Management Master Class is still going on. Courses such as "Methods and Practices of Efficient Collaboration of Large Software Teams", "Industry Trends and Five Improvements of R&D Efficiency Measurement" will be launched soon.


万事ONES
474 声望23.8k 粉丝

ONES专注于企业级研发管理工具及解决方案,产品矩阵贯穿整个研发流程,实践敏捷开发与持续交付,追踪项目进度,量化团队表现,助力企业更好更快发布产品。