A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis. A small minority of team members may be part-time contributors or may have competing responsibilities.
The notion of a team entails shared accountability: good or bad, the outcomes should be attributed to the entire team rather than to any individual.
The team is expected to possess all of the necessary competencies, whether technical (programming, designing, testing) or business (domain knowledge, decision-making ability).
Roles and responsibilities do not matter as much as results: a developer may test, perform analysis or think about requirements; an analyst or domain expert can suggest ideas about implementation, and so on.
Common Pitfalls
- the most elementary error is to equate “group” and “team”, to think that a team results automatically from having people work together
- a team should have at least three people (two is a pair), and will generally not exceed ten or so
- a single person may be a contributor to more than one “project” simultaneously, but it is highly unlikely that they will consider themselves as belonging to more than one “team” at the same time
Origins
- 2004: Kent Beck proposes “Whole Team” as the new denomination for the practice previously known as “On Site Customer”
Academic Publications
Tuckman’s conceptual model (“norming, forming, storming, performing”) is probably the most often cited with respect to the dynamics of Agile teams.
However, several competing and more recent models exist. One study specifically concerned with software teams found suggestive empirical validation of their TWQ (Teamwork Quality) framework as a factor correlated with project outcomes; the TWQ construct is composed of Communication, Coordination, Balance of Member Contributions, Mutual Support, Effort and Cohesion.
