Agile Development Team Management Series 5: Splitting of large R & D teams (for those who have just attended the 3.17 MDP team management sessions, please refer)

This is the fifth article in the team management series and the ninth article in the series of "loosely Pair programming. (The team manages the topic directory and loosely pairs the programming topic directory)

Sorry, this MPD does not know that the tea break in the middle of 20 minutes is within 3 hours, so the last 10 minutes is not mentioned. I would like to add it here.

Splitting of large teams

If the team reaches a certain level, such as 40 people, how can we split the team? The answer is:Vertical SplitThat is, Division by product rather than by function, that is, Division by business, rather than development-test-support.

The reason is roughly as follows:

1. Vertical Split teams do not have direct competition or confrontation relationships, avoiding various confrontation and office struggles.

2. The internal goals of Vertical Split teams are clear, all for the profit of the business department, and the division of responsibility and benefit distribution are easier.

Of course, this will bring about some other problems, such as resource sharing, new product line and product incubator issues. However, solving these problems is simpler than solving the inherent problems of horizontal division of labor.

For example, in the figure below, the Red Team 1-3-9 develops a product, and the green and blue teams also develop a product, that is, vertical segmentation.

If the red color is the Development Group, the green color is the test group, and the blue color is the product group, it turns into a horizontal split, which is very serious.

Leaders of vertical departments want to promote their respective departments by improving their turnover, while leaders of horizontal departments tend to prove that their work is more important, with different starting points and different results.

Loosely Coupled programming seems to only solve the problem of the last micro-team, but in fact, with the help of teams 1-3-9, the team size can be divided by 4, which is difficult to achieve in general management methods.

Agile behavior of large teams

1 ~ The 5-person scale is suitable for XP (loose Pair Programming + mentoring system)

Although scrum is "suitable for 5 ~ 9-person team, but in fact, if the office environment is open enough, on the scale of five people (or even on the scale of up to nine people ), should be implemented close to XP at any time, that is, try not to be 3 ~ A small team of five people will practice every Hitachi Conference (refer to the http://blog.csdn.net/cheny_com/article/details/6933835), but place these people in an open environment managed by a last-Level 1-3 team, everyone can communicate at any time (in the green box ).

5 ~ 15 suitable for scrum

But at least 9 people, up to 40 people (This number is only a number in the legend, someone reported that Scrum was implemented in a team of 500 people, but the specific situation is unknown, it is the world of scrum.

The fine red lines in the project define a 13-person team. At the level of the last team, scrum is required for every Hitachi meeting, because it is difficult for 13 people to complete point-to-point communication.

However, you do not need to speak to everyone to hold such a meeting. In most cases, the last apprentice only cares about the work of several members in his group, moreover, it is difficult for them to describe what they do to others.

At this time, it is betterOnly let the master speakThe master did not only talk about his work, nor did he speak for the apprentice, but described it in the form of an overall group.My group's work (what was done yesterday, what was done today, and what was difficult)When appropriate, you can predict two or three days more.The apprentice does not speak, but listens to the overall work of his group, which is helpful for opening up his eyes and forming a general situation view..

Scrum of scrums (SOS) is suitable for over 15 persons)

"15" is neither a fixed number nor a statistical number. Different teams, products, and leaders have different boundaries.

Scrum of scrums traditionally holds that several scrum masters have held a special meeting in each group after each Hitachi meeting, but it is difficult to implement it in practice.

The reasons include: often not a team is equipped with a scrum master; the scrum master is responsible for only order, however, the team's progress, quality, cost, and needs cannot be summarized through SOS, which has a huge vulnerability in the follow-up project.

Therefore, we should first convene project managers at all levels of the Team (this is a role that does not exist in scrum) To summarize each Hitachi meeting step by step to solve the technical and progress of the team and other key issues.

Scrum masters can also hold SOS meetings, but they aim to summarize the management issues of team development and promote the coordination, summarization, and accumulation of scrum.