[Enlightened] the combination of tradition and agility

This year, from a very formal project to an agile management project, it is not entirely agile, but the project owner has an agile lineage, therefore, it is inevitable that a traditional project is mixed with agile ideas and methods. At the beginning, I started to look at agile projects. What about the document? What about the process? If this is an obvious phenomenon, the leaders will surely look at it. Why is there no blame? This must have been a cause. At first, I still don't know that this is agile management. So I am determined to observe every management detail of the leadership. Here is my experience.

■ Appease the strong donkeys in agile projects

If agile management is required, it is best to be a new person or a brilliant expert in the project team. A newbie is a blank piece of white paper, and he does not have any resistance. He thinks this should be taken for granted. A master has a strong personal management capability and a strong coding capability, which can be restricted to its full potential. However, if someone from a traditional project team comes out of the Agile Project Team, he will make a lot of criticism on the Agile Project. This is not good, and it is not standard. After all, it takes a little time for me to see through the management methods of a project. Therefore, for projects that implement agile management, remember to placate everyone from a traditional project. Such people may think they have a complete management system, however, these systems tend to be slow with agility. It is essential to appease these strong donkeys and instill your agile thoughts.

■ Agility is not equal to no specification

Agility also requires specification. After all, not all projects are composed of a group of big cows. The battle will naturally be instantly accepted by any specifications. If there are new people in the project and there are no specifications, the Yellow River will flood, it's not enough. Agility is built on trust, but do you dare to trust the code written by new people? Impossible. Therefore, normative constraints are like river channels. If there are a large number of documents, a large number of standardized rivers are constructed by reinforced concrete. Then the agile specifications are just to dig yellow sand and divert traffic.

■ The weak team needs to be strong

If there are many new users in the project, they need a very powerful header. This header can take on most of the requirements with their own strength. When new users do not understand the requirements, they can find the first consultation, and get answers quickly. In this way, the agile power can be utilized. Without such a powerful header, most of the requirements need to be confirmed by the customer, and the development speed will be greatly reduced. For general projects, if there is little technical requirement, managers can get away from coding and fully understand the requirements. Such agility is fast, but it is also very risky. Once the head is sacrificed, the project will be irretrievable. Therefore, this kind of agility will keep a person in the project, if the project cycle is short, still can afford. If a project lasts for a long period of time, its memory will be forgotten and the project will also be stuck without supporting documents.

■ Combination of agility and tradition

In fact, the best solution for most projects is the combination of agility and tradition. The heavyweight traditional development process is meticulous in every detail, while agile is highly dependent on people. For projects with high quality requirements, the best combination should be the combination of the development process and agility of traditional projects. As for how to implement it, managers are required to be familiar with the differences between agile and heavyweight development processes.