The Mainstream Mode of Agile Development: Lean Development - Weekly Sharing

Lean Development

Firstly, I list the concept of lean development and the seven basic principles, and then I express my understanding of each principle.

Overview

The idea of Lean Management originated from Toyota Corporation, which aims to continuously eliminate waste by improving processes to create value. This method has been widely used in manufacturing management. For IT system construction, the common tool model of lean development is the value stream model.

Basic Principles of Lean Development

Eliminate waste: We should spend all our time on things that can increase customer value;
Defer decision-making: We should keep the available options open according to the actual situation, but the time should not be too long;
Strengthen learning: We should use scientific learning methods;
Fast delivery: We should deliver value as soon as the customer asks for it;
Create high-quality products: We should use appropriate methods to ensure quality;
Empowering team: We should allow employees who create value-added to reach their full potential;
Optimize the whole: We should prevent the tendency to optimize parts at the expense of the whole.

Understanding of Principles

1. Eliminate Waste

We understand that waste is shameful, but in this description, Lean's proposal to "spend all your time on things that add user value" is too easily misunderstood. The most worthy consideration is What is the most important thing that can increase user value?

Delivering products that are valuable to users promptly is considered adding user value, so is that the only thing we have to do? This is too one-sided, and we need to do much more than that.

Only a healthy team can produce excellent products. The decisive battle of "accomplish the whole task in one stroke" is, of course, a charge to spare no effort, but "the road is endless and far away," and "pursuing the truth" is a long-distance process. Unhealthy teams cannot achieve long-term development, so "all time" must include cultivating a team with combat effectiveness. Moreover, as mentioned in the overview, what means do we need to eliminate waste?

By constantly improving the process, the Agile Manifesto says that "the subjective initiative of individuals and the interaction between individuals is superior to established processes and tools," which only emphasizes that the subjective initiative and interaction of individuals are more important but does not erase the importance of processes. In addition, agile does not ignore the importance of processes. On the contrary, in the principle of agile development, it is said that "simplicity is the art of reducing repetitive work," and processes are a powerful means to maintain simplicity. This is particularly emphasized in Lean development, so developing a more concise and efficient process is never a waste of time.

2. Defer Decision-Making

We should put forward as many feasible schemes as possible, which is conducive to making choices based on the actual situation. We should focus on the "time can not be too long" in the second half of the sentence.

We have spent a lot of time proposing as many schemes as possible. Although we have obtained many feasible schemes, we always choose the most feasible one according to the situation. So how do we judge whether it is the most feasible one?

Suppose we have left quite a lot of time to propose as many schemes as possible. Although we have obtained many feasible schemes, we always choose the most feasible one according to the situation. So how to judge whether it is the most feasible one?

To put it simply, we find the solution that can best meet the balance between "time," "scope," and "resources" among these solutions. Too long will compress the project's available time and impact "scope" and "resources." Delaying the decision is to find the best solution to balance "time," "scope," and "resources," so if you don't master the "delay" time well, you will concentrate on details but forget the main purpose or objective.

3. Strengthen Learning

This echoes the training of a team with combat effectiveness mentioned above. Learning is the best way to strengthen the team and maintain its vitality. As for what is a "scientific method," I think the answer should be the method most suitable for my team. Whether you want to set up book clubs, study groups, and other organizations, or hackathons, sharing lectures and other activities, it depends on your understanding of the team, which method is the most effective, and which one is the most sustainable.

4. Fast Delivery

Lean development is a form of agile development. Since it is agile development, it is necessary to mention fast delivery. Our practice in software development is to shorten the iteration cycle as much as possible and provide users with stable, operable, and valuable software in each iteration. This is the core means of agile development. This is true in lean development, and the same is true for other agile methods such as "Extreme Programming (XP)," "Crystal Method," "Dynamic System Development Method (DSDM)," and "SCRUM," But each method has its specific practice. I will discuss the practice of these methods for iteration in subsequent articles.

5. Create High-Quality Products

"A product produced by XX must be a high-quality product." When a company is given such an evaluation, if the evaluation is positive rather than ironic, it means that users have highly recognized the company. "Win in users" — a phrase with a double meaning, which is not only to say that the beneficiaries of high-quality products are users but also to say that only high-quality products can win users in the competition.

6. Empowering Team

Team, a good product can not be separated from a good team. A good team needs to be cultivated and trusted. Empowering a team can maximize the sense of ownership of the product among team members.

If you use a man, don't suspect him; if you suspect him, don't use him. We need to be wise and broad-minded, can not be allowed to let it fend for itself, and can not monopolize power so that everyone's character becomes lazy. How to stimulate the team's subjective initiative?

7. Optimize the Whole

Overall optimization should not be understood as comprehensive optimization. Optimization that is beneficial to the whole can be called overall optimization. When the degree of optimization of the local reaches enough to improve the overall effect, it is an overall optimization. This principle emphasizes that The investment in local optimization should not be so large that it delays the progress of the whole.

When you tell your superiors that I want to optimize the project architecture (you should not think that the architecture level is the whole and the R&D team is only a part of the whole project), it will take about two or three months to improve the software execution efficiency by 20~30%. Otherwise, the execution of the software will be very inefficient in the future. What reply will you get under normal circumstances?

If it is worse, you will be rejected by your superiors. If it is better, you may be asked, "What are the limitations of the current architecture?" "What benefits can the new architecture bring?", In most cases, most people can't afford to take so long to do this optimization that slows down the product progress, regardless of whether this optimization is about the part or the whole.

Perhaps after a few iterations, the problem you are worried about finally happens, and the efficiency of software operation is greatly reduced. Should we sneer at our superiors for only looking after immediate interests?

I think we should consider whether the solution we gave is really considered the whole and whether the solution is agile enough.

You open your mouth and say that it will take a few months, which itself does not take into account the whole. Technicians stop to optimize for two or three months each. Is this a three-month-long vacation for product, design, and operation? Or you come out independently for a few months. Are you sure that after a few months, you will still catch up with the iterations of the product in the past few months?

An optimization takes two or three months, which is not agile enough, and there is no guarantee that the final optimized framework can achieve the expected effect. "Unable to achieve the expected effect" is the waterfall flow model's problem. It is also the problem that agile development proposes to submit available software quickly. When you sit in the superior position, you must also consider the impact of local optimization on the overall interests. Since we are under the large project development process of agile development, the local optimization should also follow the agile principle, break it into parts, and iterate gradually.

In response to the above request to spend two or three months optimizing the framework, if the solution we propose is three to five iterations, each iteration is two to three weeks, and each version can improve the efficiency of project development by 5 to 10%. At this time, we tell our superiors about the software operation efficiency problems that may be caused by non-optimization. The possibility of superior nodding will be greatly increased.