What is the best team structure

In my opinion, the size of a small team is the best in the magic number 7 plus minus 2. Here and you analyze the complete team concept, that is, the team should have enough skills to complete the work. So in addition to the core development skills, the development team needs test skills, database skills, and user interface skills. However, many organizations are still considering the best team size and effective team composition.

Scott-ambler proposal: According to the project needs, can be divided into Agile small team and agile large team 2 categories. Small teams have standard scrum roles, such as scrum-master, development teams, and product owners. Small teams can also use support teams, including technical experts such as DBAs, domain experts, and testers. Large teams need the "team of teams" approach. Scott thinks: One of lean development management strategies. It is not realistic for the team to do quality assurance and documentation related work. They improved the composition of the team and added two roles. The Software Quality Engineer is responsible for the quality of the output of a sprint, and the documentation expert is responsible for creating user guides, administrator guides, and training materials. Scrum Development A discussion about the size of a team in a discussion group: Mike Cohn recommends answering the following 9 questions, all with a positive answer, which is a team with a good structure. The list of issues includes: functional teams, built around end-to-end deliverables.

A typical strategy is to organize a number of related small teams to form a larger team, the most effective way is to organize around the system architecture. Each sub team should be responsible for one or several subsystems, so that they can be responsible for delivering the working software on time, as small agile teams do. This strategy is often referred to as the "Conway Law", which was proposed by Melvin Conway in the late the 1960s and is

Steve Miller believes: In addition to the scrum recommended role, to

Likewise, Michael F. Dwyer in response

Before Ron Jeffries, I borrowed his famous "2+2=5", because these two rough ' 2 ' are a little bit bigger than the number 2. "The size of the team can be 1 people so small, or 500 people so big, based entirely on your definition of the team and the level of input to the members."

So there is a consensus that the size and composition of the team should be tailored to the specific circumstances of each project. However, how do we evaluate whether our team structure is the most effective?

Does the structure of the team emphasize its own strengths, support weaknesses, and encourage and motivate team members? The weaknesses of a team member should be complemented by the strengths of other members. Does the team structure minimize the number of people who must belong to two teams at the same time (and avoid having people belonging to three teams at the same time)? Trying to start multiple concurrent projects at the same time, or multiple tasks, can damage progress. Does the team structure keep the team together for the longest time? Should be more inclined to allow members to stay together in the long-term team design, which allows the team to maintain the feeling and contact for a long time. Is the structure of the component team used only in limited and easy to handle situations? Should the team be two pizza such that the quantity of food is enough for most teams to eat? Most well-designed teams should have 7±2 individuals. Can the team structure minimize the number of communication paths between teams? If a small change in the application is to be developed, it will lead to a lot of communication between the teams, so take a good look at the team structure. Does the existing structure encourage team communication? If a change of structure, the team is unwilling to do so? Efficient team design encourages communication between teams or individuals that they might not otherwise want to do. Does the team design support a clear understanding of responsibility? Structure should promote the concept of shared ownership and common success. Can team members make recommendations for team design? They should feel that this is the team they built.

After answering these questions, do you believe you have an efficient team architecture? What measures have you taken in the past to enable agile practices to help you achieve an efficient team architecture?