Good software development teams are made up of a collection of people who collaborate effectively. How the project team is staffed, by either adding or removing people, will greatly impact the team's productivity.

When staffing a development project, consider the following advice:

• Include people who fit into the existing team culture. Good teams do not just appear magically one day, but instead are grown and nurtured over time. Invite people onto the team who will add value and, furthermore, who will not be disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing team and they do not seem to be able to change.
• People should want to be on the team. People are far more productive when they are working on a project that they believe in and want to see succeed.
• Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in their existing specialties as well as in other areas, including both technical and domain areas. Generalizing specialists add value to the team because they have specialized skills that you need, while at the same time appreciate the full range of issues that a general understanding of the software development process and the business domain offers.
• Include stakeholders. Stakeholders, including business stakeholders (such as end users) and technical stakeholders (such as operations staff), can add significant value to your team. Instead of just interviewing them to gain information from them, or asking them to review your work, why not include them as active participants on the team?
• Include specialists for short-term, specialized work. Specialists can still add value on an agile development team, particularly when they have specific skills and experience that existing team members do not have. It can often be very effective to bring a specialist into the team for a short period of time to help with a specific task (such as installation and setup of an application server, the development of an architectural spike, or simply taking part in a review).
• Give people opportunities to evolve their skills. At the beginning of a project, the team may not have the full range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles they are filling. This is a very common risk taken by the majority of project teams for the simple reasons that you often cannot find the perfect combination of people and, even if you could, you still want to provide people with opportunities to grow as professionals.
• Remember Brook's Law. Adding people to a late project will only make it later [BRO95]. The corollary is that removing people from a late project may speed things up [AMB04].

Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists are available (although there is nothing stopping a specialist from becoming a generalizing specialist), perhaps there are not as many opportunities for people to try new things as they would like, or perhaps the stakeholders are not available to be active members of the team. The advice above is designed to lead to as high-performing a team as possible, but even partial adherence to this guideline will improve the team.