[Agile practices] lightweight installation: reduces the start time of the Agile Software Development Team

Face the reality: team changes

In the past few years, I have worked with many teams, some of which are long and some are short. I have noticed that all of these teams face the same problem, that is, the team members are always changing. In general, changes behind any project lead to such changes: for example, employees are sick or on vacation, project demand increases, and new projects or only employees want to change their current jobs. However, agile practices such as daily standing meetings and paired programming cannot be provided to new employees with sufficient information if there are not enough context scenarios. This is because agile practices cannot directly provide the learning needs of new team members. Therefore, I suggest using other practices to effectively reduce the "Start Time" of new members ".

Apply the queuing theory to the team

In the manufacturing industry, the period from order to delivery is basically divided into four parts, including:

• Setup: the time consumed when the product is waiting to enter the run stage.
• Run: the time consumed when the product enters the process from the pending stage. Sometimes it is divided into two parts: processing time and waiting time.
• Move-the time consumed when the product is moved to the next stage.
• Queue-all time consumed before the product enters the next setup stage.

When you apply the same concept to a team and new members of the team, you can draw a conclusion as shown in:

Since the last two parts (moving and waiting time) of the period from order to delivery do not affect an independent project, therefore, our focus is usually on the first two parts (start-up and operation time ). For new members of the team,StartTime refers to the time it takes for him to integrate into the team and make full use of his abilities. Among them, the team needs to recruit and train new people and teach them various skills until they can exert their maximum potential. All the time and effort made for these things constitute the start time.Running timeIt is related to the efficiency of the member's work in the project.

In his mythical man-month, Brook explained in detail how new people join the project, especially projects that are already in trouble. In addition to the time required by newcomers to understand the project, the book also emphasizes that the addition of more people will produce more communication expenses. The progress of the project will be further delayed. The expenses used to communicate with other team members are usually extended throughout the project process. To sum up, the total overhead incurred by adding new employees can be shown in the following chart:

Most of the processes are committed to promoting the team's cooperation and helping reduce the cost of project operations. However, they all ignore one thing and reduce the time required for new people to familiarize themselves with the environment-for example, how fast New members can join the team or how strong the team's ability to handle member changes.

Agile practices focus on running time rather than start time

"Learning" is an integral part of every Agile Methodology. Most of them focus on short-term feedback loops, self-reflection, and continuous improvement.

However, after a person enters the project for a period of time, the demand for learning will become quite different.

For new team members, the process of digesting information usually brings more problems. As I said at the scrum standing meeting, "I did it yesterday ......" This will trigger more questions for new people, for example, "What are they talking about? What is the relationship between this and what I know ?" The effect of pairing programming will also change. If the new person on pairing has a general understanding of the entire project, the effect will be better. But if it is only for one user story, the effect will be poor. After all, it's hard to see the whole leopard at this time. I have seen that many new employees in the team are frustrated when there is no clear clue to link them together in the face of a large amount of trivial information fragments.

What new users need to learn is about the Project Overview (larger context ). They need to find the knowledge they should know, gradually understand the vocabulary related to the field, and integrate into the team and its culture. The more complex the project is, the more people you join. This stage will take a longer time.

After learning about the project overview, you need to learn more in-depth knowledge. With the information contained in the overview, other information becomes more accepted. Agile practices such as daily standing meetings, peer programming, test-driven development, and so on, all the information they provide is truly useful only in a larger scenario. These agile practices do not directly focus on the different learning needs of new team members. What should you do? The answer is: apply other specific practices to reduce the "Start Time" of new team members ".

Use the "onboarding policy" to reduce the use time

Some technologies are briefly listed below. In my team, new employees find this helps them grasp the necessary context scenarios and understand the information provided by other agile practices:

• Backup email-- Send an email to the new employee to explain the background of the project, so that they can read some materials before their formal work, or exercise and learn the skills and knowledge related to the project.

• A broad vision of business problems --Open a meeting to inform new Members of the value and driving force behind the project. Let them get a little familiar with Domain-related terms and put their work in a larger context.

• Customized Architecture --Charts can be used to place trivial concepts into larger concepts. In this way, we will discuss how to integrate and analyze the knowledge.

• Project Transparency-- Openly announce the areas known by the team for improvement. Focus on how to improve and make plans, rather than blindly seeing how bad the problem is.

• Small tasks-- Divide a complex task into a large number of small tasks so that new team members can understand what the project team members are doing without much trouble. Make sure that each task can be completed independently.

• Mutual Learning --Let people with similar roles work together to share their new knowledge and any skills that may be useful to others. Such meetings should focus on learning and sharing skills.

• From students to teachers-- Try to ask new members to help other team members. Ask new members to explain concepts to other team members so that they can consolidate their knowledge and improve their thinking methods.

• Respect personal differences-- Make the learning process suitable for everyone. Use charts, documents, CRC cards, or anything to help them build an overall project view.

• Easy to beat-- Give each member sufficient space to make mistakes in a safe environment. If you learn some lessons by yourself, you will be more impressed.

It is no longer difficult for team members to rotate across different projects

Agile practices strongly recommend "Learning", but they only focus on reducing "running time" rather than "starting time". Therefore, agile is not very effective for new team members. After understanding the different requirements of new members for learning, they can use some specific "Attach policies" to solve the problem directly. Then use other practices to continuously reduce the "Start Time ".

Most people will experience some induction procedures when they join a new company. How effective is the one you use in the project?

About the author

Patrick Kua is a software development engineer, training mentor and coach at thoughtworks. Patrick is passionate about creating value for his team. Patrick is also enthusiastic about those who enjoy their lives. He believes that it would be better if he could combine his favorite things with his career. Over the past three and a half years, he has guided, led, and participated in many practical agile teams.

View Original English text:A leaner start: cing team Setup Times

Introduction to translators: Han, ThoughtworksConsultant from the company, graduated from Beijing Institute of Technology. He focuses on Java SE application, Ruby language, Eclipse plug-in development, and agile development method practices. He has translated Java concurrent programming practices and ant in action version 2. Participate in infoq Chinese site content construction. Please email China-Editorial [at] infoq.com.

Original article published onWww.infoq.com/cn/articles/pat-kua-onboarding-new