Lean identification and elimination of wasted ideas and models in the R & D process

Based on Lean Thinking and lean software development, this article provides an in-depth analysis of "waste" in the development process. Waste is divided into waste and necessary waste. The waste needs to be eliminated, and the necessary waste can be compressed. Based on the daily R & D process, this article analyzes how to identify these waste, how to eliminate the waste of inventory and how to reduce the necessary waste, and provides ideas and models.

I. Theoretical Basis

The lean thinking comes from the manufacturing industry. The software industry has been introduced for only 10 years. At present, many concepts are still in the theoretical stage, and it is difficult to directly apply and promote them in the actual R & D process. Many lean ideas I personally think are of reference value to the software industry. For example, the topic of this article is "eliminate waste ". Waste in software development can be summarized as follows:

• Partially completed: partially completed but not finalized
• Features not applied: features developed but not applied by the customer
• Additional process: Processes and intermediate products not required during development
• Re-Learning: Personnel and link changes lead to repeated re-Learning
• Information Transfer: transfer of tacit knowledge information is always accompanied by information loss
• Task Switching: multi-task operations may result in lower efficiency
• Resource dependency: Job stagnation caused by dependency between tasks and resources
• System defects: Solving defects is a waste.

These waste phenomena come from the Toyota Manufacturing System (TPS) and are mapped in the software industry. Although advocates of the lean software development process summarize these waste phenomena for us, however, there is no clear practical method for how to identify these waste to eliminate and compress these waste. We need to observe these waste phenomena in the daily R & D process to find a way to eliminate and compress the waste in the actual R & D process.

2. How to identify waste?

We have the idea that the next step is to take actions. The first step is to identify waste in the R & D process. I personally summarize the following pattern to identify waste:

1. Value flow chart

Value Stream mapping (VSM) is the main tool used in lean thinking to eliminate waste. Its function is to help us find out which stages of the R & D process are wasted, how much time is spent in creating value throughout the lifecycle, and how much time is a waste of memory. The value flow chart of the traditional software development process can be abstracted as follows (the concave part of the coordinate below represents the time when the value is generated, and the protruding part represents the wasted time ):

In reality, the mainstream development models are usually between waterfall and agility. Therefore, each team may have their own set of interpretations on the method and effect, But no matter which development mode or its variants are used, we can all get such a value flow chart. It is a best practice of Lean Thinking to identify waste by analyzing the time interval in the value flow chart.

2. Project input filtering

The R & D process is usually oriented towards products. Enterprise applications or semi-Internet semi-enterprise applications are implemented and implemented through projects, which makes the project line an important input in the R & D process, the requirements and plans proposed by project managers from the standpoint of the project line and the customer are often different from those of the product line and R & D line. If you do not enter the R & D stage, the input will inevitably lead to waste. How to control input from projects through planning and analysis, so that project line requirements can be consistent with product lines as much as possible is an important aspect of reducing R & D costs and eliminating waste, so project input is also a source of waste.

3. Conference focus

We have to hold such meetings or meetings frequently. is meeting a waste? I personally think it is sometimes true. Meetings that may cause waste usually have some commonalities. Typical examples include:

• The input and output are ambiguous.
• Lack of host or host is not good at guidance
• Meetings are not result-oriented and cannot form effective decisions
• The agenda of the meeting is vague and cannot be converged
• Although an agreement can be reached at the Meeting, there is no specific work arrangement and owner system.
• There is a lack of tracking and monitoring mechanisms even if there are work arrangements
• The meeting-related materials were not fully prepared and were not delivered to participants in advance.

A meeting Meeting with the above characteristics will not produce substantial results to a large extent. After the meeting is completed, it will need to be held for the second time. If it is difficult to grasp the waste, but the time is still the atmosphere of the team, we need to analyze and identify to see if we have the above "smell" in our daily meetings ".

4. Comparison of Data Transmission effectiveness

Currently, the mainstream R & D management methodology generally holds that communication and collaboration are the key factors for successful R & D, and the effectiveness of the data transfer process lies in communication and collaboration. If there are two R & D teams in which data is transferred from one person in the team to another in terms of time or space, the combat effectiveness of the two teams is undoubtedly different. Data transmission may be inefficient or even unreasonable in terms of communication modes, media, tools, and other aspects. waste continues to grow in these areas, consuming the combat power of R & D teams.

5. Management Activities

Some people say that if the team is "self-organized", we do not need to manage it. Although this sentence sounds reasonable, it may not be too illusory. However, starting from the management work itself, it is indeed a waste of identification to analyze whether redundant or unreasonable management activities exist in the work flow, document management, task allocation, and other aspects. Management requires costs, and better management and finer management require more costs. However, the management process itself may also need to be restructured like code with the evolution of the R & D process and team, the premise of restructuring is that we need to analyze and sort management activities, find out the waste and eliminate or compress it.

6. Process Execution, whether it is a good management model and concept, or a R & D model suitable for the team. To achieve satisfactory results, it should be implemented at the bottom. Execution comes from many aspects, such as a reasonable team structure, excellent talents, efficient tools, and a good team atmosphere. These are usually not fields that can be determined by technology, but it actually affects the team's execution. The process itself may be appropriate, but it is often a waste of effort that cannot be avoided but needs to be compressed because it cannot be executed by people or the efficiency is reduced due to improper use of tools.

3. How can we eliminate pure waste?

Through the identification work in the second part of this article, the waste in the team has been shared with everyone. A large part of the waste is a pure waste, which needs to be eliminated through some ideas and work models. I personally summarize the following nine practices to eliminate waste:

1. Timing of project line intervention

First, let's look at the peripheral interfaces of the R & D team. Here we regard the project line as another work line tied to the product R & D line, so that the time for the project line to intervene in product R & D is very important. Refer to the Value Stream chart mentioned in "how to identify waste". We can see that the first step is to propose development requirements for the project line, and then hold a demand review meeting in the second step, the third step is to officially start technical development. If the timing of project line intervention is inappropriate, there may be a time interval between Step 1 and step 2, and there may be a time interval between Step 2 and step 3, on the one hand, the time interval between steps is a waste. In the second step, if the technical development is delayed after the demand review, there are variables in demand management and risk management, the form of these variables is that the step content needs to be adjusted or even re-transmitted, resulting in waste.

2. R & D scope management

Scope management is a focus that is easily associated with eliminating waste, because scope determines the development workload. From the perspective of project management, avoiding "gold-plated scope" and potential changes in scope "is a topic of scope management. From the perspective of the R & D process, at present, the concepts such as "simple design" and "emerging design" are also favored by more and more R & D teams. On the one hand, the R & D scope management should focus on the functional requirements raised by the project/product team that are unnecessary and do not meet the product strategy, and should also be reviewed within the development personnel, check whether there are over-design or other phenomena.

3. Efficient Decision-Making

Decision-making is the source of action. If the source is ungrasped, all subsequent steps may be a waste. This is a perspective of decision-making. Another perspective is that decision-making is correct, but whether the decision-making process is efficient.

A major concern of decision-making is the decision-making support process, including data preparation before decision-making, personnel arrangement, and product research. The necessity of this process is to ensure the correctness of decision-making, this process is usually led by the company's senior leadership and cooperated by the R & D team. On the other hand, in the above "how to identify waste", we mentioned a practice called conference focus, which can usually be an entry point for us to eliminate waste of decision-making. Individuals require the use of meeting invitation emails for all meetings. This meeting invitation email forms an email template at the department level, which describes the input, output, and agenda of the meeting, this allows attendees to prepare for the meeting and review after the meeting. For details, refer:

XXXX personnel are scheduled to hold the XXXX meeting.
Meeting input:
1. XXXXX, please refer to SVN address
2. XXXXX
Meeting Agenda:
1. dominated by XXXXX and XXX
2. dominated by XXXXX and XXX
Meeting output:
1. XXXXX: implement personnel and schedule
2. XXXXX
Please make preparations before the meeting. If you have any questions, please contact me.

A meeting with clear topics, complete input, and responsible person orientation can ensure the efficiency of decision-making and avoid waste.

4. cross-functional teams

Cross-functional teams are used to eliminate waste arising from ensuring information effectiveness during information delivery. The cross-functional R & D team members mainly include the project line, product line, technical line, and quality assurance line. All work is carried out around a certain product line/platform, make sure that you sit together and can communicate face to face in real time. In the Internet development environment, cross-functional R & D teams may also include operations, customer service, and other roles, but sales, marketing, and other related personnel are usually not in this team. This is actually a team structure with a strong matrix, where everyone stays at the same level of understanding and working pace. Many of the waste identified by "data transfer effectiveness" and "process execution" can be eliminated through this practice.

5. Root Cause Analysis

Defects are the biggest waste. Bugs are inevitable during development, but these bugs may be inevitable. In many cases, they are not a problem of developers or technology, the root cause analysis aims to help us find out whether there is any inevitability behind the error, and then analyze these inevitability and provide solutions to avoid the occurrence of similar bugs again. Common root cause analysis tools include five why and fishbone diagrams.

6. Product Function Standardization

Standardization has many meanings. project management standardization, product function standardization, and development process standardization all belong to this category. Here we will focus on the standardization of product functions. When a product is oriented to multiple projects, product standardization is an essential task to eliminate waste. As you can imagine, if each project has different inputs, these inputs are similar, but if there is no standardized platform for products, to get a project, you have to copy some code and spell a function in the East. Not only does the development cycle become longer and lead to waste, but the system will also generate bugs due to standardization, leading to further waste. In the face of product line functions in the development phase, developing a set of product line functions is usually a good practice to generate a framework based on the product line each time a project arrives. If the product line is already mature, the product platform can be put on the agenda to provide a way for the project line to adapt to the product line, minimizing secondary development caused by the project line.

7. Technical Review

There are some useless technical reviews on the Internet, but I personally think that technical reviews are useful in eliminating waste. Personal Understanding technical review includes formal technical review and informal technical review, which can effectively eliminate waste. For example, the product manager should discuss the product UI style and user interaction with UED after designing the product requirements and before throwing them to R & D. This is an informal technical review, it helps to eliminate problems before the development process. Similar requirements review and code review are all part of the formal technical review, helping us correctly grasp the direction during the R & D process, avoid development costs caused by repetitive requirements and code maintenance.

8. Process asset Construction

Process asset construction is an organizational activity. It is embodied in the R & D process to eliminate the "re-learning" cost of team members. For details about R & D process asset construction, refer to my article lightweight R & D knowledge management-how to help R & D personnel to build assets in the process. The lightweight processes and practices mentioned in the article can greatly ensure that new personnel training, development handover, system maintenance, and other problems are exposed, thus eliminating waste.

9. Process Reconstruction as mentioned above, we have to go through some procedures, which is often a waste. Because the process requires people, time, and supporting steps, if the process is too complex and the implementation cost is high, such a process is usually in the form, and a process without output is a great waste; on the other hand, if the owner, execution time, and specific steps of a process are unclear, the process will inevitably be mixed with everyone's understanding and willingness, the execution of the final process becomes a process of mutual competition, and execution becomes a source of waste. The process is also time-sensitive and needs to be adjusted as the team members and product strategies change, no matter which of the above two situations, process refactoring is like code refactoring, which requires regular/irregular adjustment and optimization.

4. How to compress the necessary waste?

The main practice of how to eliminate waste is described above, but some waste is usually necessary and inevitable. For such waste, our idea is to compress as much as possible, the following are seven practices of Data Compression waste:

1. Code Quality

In the practice of eliminating waste, the "root cause analysis" we mentioned focuses on eliminating the inevitable factors that cause product quality problems, it usually involves factors in the development process and environment deployment pipeline. In addition to these inevitable factors, the improvement of product quality requires the efforts of the Quality Assurance Department. However, in lean thinking, quality management through testing is inefficient and not promoted, lean Thinking advocates built-in quality. Personal Understanding should at least establish quality awareness within technical developers. Typical scenarios where developers despise code quality and lead to waste include: the R & D team did not establish the separation principle between the development environment and the test environment. After both the front-end and back-end developers complete code development, they submitted the test through simple joint debugging, the integration test is not carried out in the exclusive development environment. As a result, the testing service cannot run in the test environment. Developers and testers must negotiate and adjust the service multiple times to make the deployment successful, this is one aspect; on the other hand, because developers do not fully perform self-testing, many problems that should be discovered and resolved during the debugging phase are finally exposed by the testing team through the internal testing process, here, the extra cost required for process operation is actually a waste of compression.

2. Visualization

Visualization is also related to the effectiveness of data transmission. Although we can eliminate waste through practices such as "process asset construction", communication costs are a real waste and need to be compressed. I personally think that visualization is a practice that needs to be promoted. The transparency of information is also highly respected in agile and other methodologies. Visualization usually requires a certain amount of media and works with a certain degree of collaboration process and reporting system. You can refer to the series of articles "transparent information" in R & D scope and time ". The role of visualization is to provide an information radiator for the team and relevant stakeholders to ensure that everyone has a unified understanding of the scope and progress of R & D.

3. Process Automation

From the perspective of process improvement, process automation is a starting point that can be continuously attempted and explored, promoting the improvement of development efficiency and reducing errors and waste caused by human factors. In daily work, Process Automation influences the internal and cross-team collaboration processes of the R & D team in a subtle way, including program development, function testing, system deployment, and service release, we use ant, Python, and other scripts or tools such as Jenkins to automate process construction.

4. Parallel Engineering

Although parallel engineering is hard to grasp, it may often be used unconsciously. For example, after the demand review, developers write code and testers prepare test cases, and develop interaction protocols and interfaces in the front and back ends at the same time. Parallelism is the concept of batch. By reasonably arranging personnel and order, you can convert the originally required tasks into parallel tasks to improve efficiency. I personally think that the difficulty of parallel engineering lies in the management interface and system integration. If we can ensure the stability of interfaces and the cost control of system integration, parallel engineering can be compressed and wasted in some cases.

5. Short iteration short iteration is an agile idea and a lean idea, that is, to solve the problem as soon as possible by exposing the problem as soon as possible. Because software development is a creative task, the more problems are exposed later, the higher the repair cost, the greater the waste. We can describe the short iteration image as follows (from Zhang xianzhou, the author of lean software development art ):

Through this, we can clearly see the value of short iterations in the compression waste process.

6. Feature Granularity

The feature granularity discussion focuses on balancing R & D management activities. The granularity of feature can be divided into the following methods: module> function line> function point, that is, the system of any scale divides the range to the Function Point level through three levels, the granularity of the R & D team is one function point. I personally think that the function of a system is between 20 and 20 ~ 50 may be optimal. Too little increase in information transfer costs between developers, resulting in an increase in management activity costs. Both situations should be avoided as much as possible.

7. Single-piece flow (single-piece flow) is a key word in lean thinking. It means that semi-finished products should not pile up in the queue. Semi-finished products in software development generally refer to code implementation requirements, code that has not been tested, documented, or deployed, or errors that have not been fixed. The thought behind the single-piece stream is the idea of continuous integration and continuous delivery, which is not easy to achieve. However, the feature-level code submission, daily deployment, and efficient closed-loop testing process can improve the single-piece streaming level to a certain extent, this compresses the necessary waste caused by Service Release and system integration.

V. Summary

This article identifies and eliminates waste in lean thinking in the R & D management process, we also sorted out how to effectively identify, eliminate, and compress waste based on my daily experience. The concepts of deferred decision-making and overall optimization mentioned in lean thinking need to be further understood and applied to the process of calendar R & D management.

Lean identification and elimination of wasted ideas and models in the R & D process