Team Self-Discipline
Just as individuals have responsibilities to the teams that they belong to, teams themselves have to be self-disciplined to work within a larger self-organizing framework. The behaviors required of teams closely parallel those for individuals:
- Be the right team.
- Accept accountability for team results.
- Engage collaboratively with other teams.
- Work within the project self-organizing framework.
- Balance project goals with team goals.
A team that is unwilling to work within the established framework disrupts the work of the larger project in the same way that individuals who are unwilling to work within the team framework do.
Basketball players have a signa lightly closed fist tapping against their chestthat signals "my bad." They are taking responsibility for a mistake, admitting the mistake to their teammates and implying a commitment to do better next time. Teams that are accountable strive hard to deliver on commitments to other teams and admit failure when it occurs. But there is an important aspect of accountabilityassignment versus sign-onthat determines whether accountability will truly take root. Managers who bemoan a team's (or an individual's) seeming lack of accountability should look first to themselves. Did they assign a deliverable and a date to the team, or did the team sign on and accept the date? Managers often assign impossible tasks and then wonder why the team doesn't accept responsibility. One of the powerful aspects of the commitment-accountability protocol (which I describe in the next section) is that it defines a commitment between two teams that they each enter into freely .
Just as individuals have a responsibility to fully participate in their team's activities, teams have a similar responsibility to participate with other teams within the larger project. For example, when a team estimates how many features it can deliver in an iteration, its members must factor in time to coordinate with other teams. Team members will undoubtedly serve on coordination teams (e.g., the architecture or integration teams). Feature teams will have to interact not only with the customer team, but also with other teams. For instance, a team may utilize a component or information from another feature team, or it may supply a component or information to another feature team. The same trust and respect that form a foundation for individual interaction also apply to team interaction.
Most managers understand the rough guideline that doubling staff size on a project increases throughput by 25% to 50%. [2] Large projects can have appallingly low productivity rates. Why? Coordination, meetings, documentation, approvals , rework due to miscommunications, and more add activity and time to any project. Capers Jones (1991), a consultant and author on software metrics, reports that on large software projects, one-third of the cost could be attributed to paperwork. Unmanaged, the collaborative practices of APM can blow up in a team's face. The larger the project team, the more need there is for collaborative interaction, but also the greater possibility of collaborative paralysis. The project manager in particular must constantly take the pulse of the organization as to the effectiveness of every type of interaction. For example, meetings that served the team well in the early iterations may not be needed as the project progresses. A collaborative structure isn't something to be set up and then ignored; it needs to be constantly monitored and adjusted.
[2] This percentage depends on the size of the initial team (the percentage would be higher for a team that went from 2 to 4 than for one that went from 25 to 50) and the type of work being done.
Finally, teams have to align their own goals with those of the project. There will always be too much to do and too little time, and the tendency will be to work on one's team goals rather than on project goals.