Five misunderstandings about agility

Misunderstanding 1: Agile has high requirements on people

When trying to implement agility, many people say that agility is too demanding for people. We don't have such conditions. We don't have such people, so we can't be agile. But is agile really so demanding on people?

Software is still a kind of creative activity. The technical level and personal ability of developers play a decisive role in the quality of software, various processes and methods only help developers, testers, and other roles to better cooperate and generate higher productivity. No matter what method is used, the level of development personnel is always a major factor.

From another perspective: How much process and method can help developers? For developers with low technical level, agile methods and traditional methods are similar to each other, so there is no obvious effect, and sometimes there is a reverse effect; with the improvement of the technical level of developers, agile methods can unbind people, encourage innovation, and the effect will become more and more remarkable.

Agility does not have high requirements on people, and it will help you cultivate all kinds of required capabilities. The premise is that you are in a truly agile environment.

 

Misunderstanding 2: agility does not have documentation or design.

This misunderstanding has never been stopped since XP, and XP encourages "not to write documents when necessary and significant ". The "necessary and significant" mentioned here is a judgment standard, and not all documents are written. For example, is the user manual "necessary and significant "? This depends on the customer's requirements. if the customer does not need to write, the customer does not need to write it. If the customer needs it, the customer must write it. For example, do the architecture design documents need to be written? Complex to write, not complex to write. Generally, architecture design only requires simple documents. For some projects, a simple UML diagram is enough. Therefore, whether to write or not depends on the significance of this document, the proportion of output and input, and the specific project conditions. In actual operation, all the members of the project team can vote and avoid being determined by a certain person (such as lead.

As for the design, XP pursues continuous design rather than non-design. This is actually to share the design work in daily work, continuous design, improvement (Reconstruction), so that the design remains flexible and reliable. As for pre-design before coding, Kent Beck and others do not implement any pre-design development methods, but for our "non-master" developers, the necessary pre-design is still needed, but not too much or too detailed, and there must be preparations that will thoroughly subvert the future.

 

Misunderstanding 3: Good agility and poor other methods

When talking about agility, some people call out what is best as long as it is agile practice, but when talking about methods such as cmme, it is not good, no matter what it is, it is not good everywhere, it seems that agility is totally different from other methods. Newton said that I was standing on the shoulders of giants. Agility also draws on the advantages of other methodologies and stands on the shoulders of giants. Agility still maintains many practices and principles that have a long history, but their expressions are different.

On the other hand, there is no good link in the method, and the good and the bad depend on whether it is suitable for solving your problem. Each method has the problem that he is best at solving and the best environment to use. When the demand is stable and the software complexity is low, the waterfall model can also work well, agility is suitable for projects with high changes and risks-this is exactly the common feature of many projects.

Therefore, choosing a method or process is not based on its agility, but on its suitability. To know whether something is suitable, you must try it before knowing that nothing that has not been tested by practice is credible.

Misunderstanding 4: agility is XP, and scrum.

XP and scrum are only two of the many agile methods, and there are many other agile methods. Different ways, agile methods seem very different, but they are called Agile Methods because their ideas and principles are the same, this principle is the agile declaration. To learn agility, you must not only learn practice, but also understand the principles after practice, not only how to do it, but also why and when not to do so.

Even if you fully apply XP or scrum to your project, you will not be able to succeed if you do not see it. What suits others may not be suitable for you. Agile practices and methods give us a starting point, but they are definitely not the end point. The best way for you is to explore and find it in your actual work.

Misunderstanding 5: agility is good, so I need to set standards and all projects must follow standards.

No two projects are the same, customers are different, personnel are different, requirements are different, and nothing is even the same. It is impossible to solve different environments and problems in the same way. The method is to serve people. We should find the most suitable method for the project team, instead of determining the method first, and then let the team adapt to this method. Therefore, there is no uniform method suitable for all projects. Any attempt to unify all project processes is incorrect.

At the same time, with the development of the project, the deep understanding of the needs, and the deep understanding of the technology, the processes and methods suitable for the project will gradually become unsuitable. At this time, the team should make timely adjustments to the process to ensure the quality and efficiency of the project. Agility is dynamic, not static, because the world itself is changing. It is unrealistic to use the unchanged method in a changing world. Silver bullet never exists, and will not exist in a limited future.