Most Effective Team Structure

Agile talks about small team sizes with the magic numbers of 7 plus minus 2. Agile also recommends whole teams. Whole team is a concept that recommends having sufficient skills within the team itself to get the job done. This implies that the development team has the requisite testing skills, database skills, user interface skills, apart from the core development skills. However, many organizations still struggle with questions related to the optimal team size and an efficient team composition.

The typical strategy is to organize your larger team into a collection of smaller teams, and the most effective way to do so is around the architecture of your system. Each subteam should be responsible for one or more subsystems, enabling them to work as a small agile team responsible for delivering working software on a timely basis. This strategy is often referred to as Conway’s Law after Melvin Conway who introduced it in the late 1960s, and is one of several lean development governance strategies.

Steve Miller suggested that along with the Scrum recommended roles, he found it unrealistic for the team to handle quality assurance and documentation well. They improved the team composition to have 2 more roles. Software quality engineer to be responsible for the quality of a sprint and a Documentation specialist for creating user guides, administrative guides and training material.

As Ron Jeffries may be otherwise occupied I will borrow his famous tag "2 + 2 = 5 with sufficiently large enough quantities of 2". Team size can be as small a 1 and as large as 500, it all depends on your definition of team and member involvement.

Thus there is a general consensus around the need to tweak the team sizes and composition as per the project needs. However, how do you validate that you have the most efficient team structure?

Mike Cohn suggested that answering the following nine questions and getting an affirmative response to each suggests a well structured team. His list of questions include

Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members? A team where weakness of a team member is overshadowed by strength of others.

Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)? Attempting to do too many concurrent projects or multitasking is detrimental to progress.

Does the structure maximize the amount of time that teams will remain together? Favor a design that allows team membership to persist over a longer period to let that team feeling and bonding persist.

Are component teams used only in limited and easily justifiable cases? Teams should be feature teams created around the end-to-end delivery of working features.

Will you be able to feed most teams with two pizzas? Majority of teams in a good design should have 7 plus minus 2 members.

Does the structure minimize the number of communication paths between teams? If, for making a minor change in the application, the interteam communication is high then revisit the structure.

Does the structure encourage teams to communicate who wouldn’t otherwise do so? An effective team design encourages communication among teams or individuals who should communicate but may not do so on their own accord.

Does the design support a clear understanding of accountability? The structure should enforce the concept of shared ownership and collective success.

Did team members have input into the design of the team? Team members should feel that it is the team that they built.

After answering the questions do you believe that you have an efficient team structure? What tweaks did you have to make to the Agile recommendations to arrive at your efficient team structure?

It is certainly complex to create a well functioning team. There are several dimensions to this:a) Many companies view QA as separate to development, and seem to think that you can't put the two 'types of people' together. The worry is that the 'sloppy developers' will 'corrupt' the QA people and the quality will be lower. Few seem to appreciate that the QA people are just as likely to influence the developers to better standards. b) For large products it is often tricky to create suitably 'sand boxed' parts of the product to split it between teams and still maintain a global 'look and feel'. This is actually just as true with 'prince' or similar techniques as it is for scrum, but somehow we forget to remind people of this. In many ways scrum can be an advantage here, the product owners should get together to ensure a suitable global feel to the user stories - and to include sufficient detail in the user stories to ensure the API's and GUI across the system is reasonably consistent. In fact, I have seen a failure to ensure this cause masses of problems for Symbian and its customers - there is no consistency at all between different API's. They are not the only ones with the problem.c)Many companies have developed a 'matrix management' structure, this does actually have its uses, but what it does lead to is a tendancy to move people from project to project to make best use of their current skills and avoid developing any new ones. Thus to keep a team together for the duration of one project, let alone to develop a scrum team over a number of years, is an uphill battle. Sure 'Fred' is needed for his architectural skills today, but surely you will have designed the architecture by Friday and I can have him for Joes project? We clearly understand that the architecture may change, that those skills, along with all the experience Fred had that led to him being considered an architect, are valuable throughout the project, it is especially valuable to the team to keep Fred involved as the project progresses so he can learn how well the architecture is implemented, and what its problems are

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.