<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-HYO1lwAFOxlT7ncq8EjSng" name="new_guideline,_Jq64EJjsEduad8I_c-ogIA" guid="-HYO1lwAFOxlT7ncq8EjSng" changeDate="2011-09-07T11:10:42.016-0700" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    Good software development teams are made up of a collection of people who collaborate effectively. How the project team&#xD;
    is staffed, by either adding or removing people, will greatly impact the team's productivity.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When staffing a development project, consider the following advice:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Include people who fit into the existing team culture. Good teams do not just appear magically one day, but instead&#xD;
        are grown and nurtured over time. Invite people onto the team who will add value and, furthermore, who will not be&#xD;
        disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing&#xD;
        team and they do not seem to be able to change.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        People should want to be on the team. People are far more productive when they are working on a project that they&#xD;
        believe in and want to see succeed.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Build your team with &quot;generalizing specialists&quot;. A generalizing specialist is someone with one or more technical&#xD;
        specialties who actively seeks to gain new skills in their existing specialties as well as in other areas,&#xD;
        including both technical and domain areas. Generalizing specialists add value to the team because they have&#xD;
        specialized skills that you need, while at the same time appreciate the full range of issues that a general&#xD;
        understanding of the software development process and the business domain offers.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Include stakeholders. Stakeholders, including business stakeholders (such as end users) and technical stakeholders&#xD;
        (such as operations staff), can add significant value to your team. Instead of just interviewing them to gain&#xD;
        information from them, or asking them to review your work, why not include them as active participants on the team?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,&#xD;
        particularly when they have specific skills and experience that existing team members do not have. It can often be&#xD;
        very effective to bring a specialist into the team for a short period of time to help with a specific task (such as&#xD;
        installation and setup of an application server, the development of an architectural spike, or simply taking part&#xD;
        in a review).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Assess available knowledge and skills. Give people opportunities to evolve their skills. At the beginning of a&#xD;
        project, the team may not have the full range of skills that it needs, or perhaps a few individuals may not have&#xD;
        the skills required to fulfill the roles they are filling. This is a very common risk taken by the majority of&#xD;
        project teams for the simple reasons that you often cannot find the perfect combination of people and, even if you&#xD;
        could, you still want to provide people with opportunities to grow as professionals. Determine skills improvement&#xD;
        objectives and set up a plan to achieve them. Perform an assessment at major project milestones to track progress&#xD;
        against objectives.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Remember Brook's Law. Adding people to a late project will only make it later [&lt;a&#xD;
        href=&quot;./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#BRO95&quot;&#xD;
        guid=&quot;_JlTPUM6aEdyuBO4ZIzcyig&quot;>BRO95&lt;/a>]. The corollary is that removing people from a late project may speed&#xD;
        things up [&lt;a href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html&quot;&#xD;
        guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>AMB04&lt;/a>].&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists&#xD;
    are available (although there is nothing stopping a specialist from becoming a generalizing specialist), perhaps there&#xD;
    are not as many opportunities for people to try new things as they would like, or perhaps the stakeholders are not&#xD;
    available to be active members of the team. The advice above is designed to lead to as high-performing a team as&#xD;
    possible, but even partial adherence to this guideline will improve the team.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>