The word "team" is often used to refer to groups of people who have been brought together to work on an Agile project. Are they really teams, though, or are they in truth merely workgroups? In other words, is there any evidence of actual "teamwork" in their working practices, or are they just people with particular skills who happen to be available right now to do their particular thing? Agile teamwork is defined by the collaborative qualities team members exhibit in respect to themselves, and a wider team of stakeholders such as a Scrum Master and a Product Owner.
For example, here are some things a good agile team member ought to do:
Agree with other team members and the Product Owner to deliver a valuable and achievable piece of work every Sprint.
Understand the Sprint Backlog and how it correlates to the Sprint Goal.
Participate fully and actively in daily standups, planning sessions, reviews, and retrospectives.
Work with the rest of the team to meet each Sprint Goal (self-organize).
Help other team members and the Product Owner to clarify requirements, such as by writing user stories and acceptance criteria.
Pro-actively remove skill silos without being told to do so, through pair programming or cross training, for example.
Work with the Product Owner on an ongoing basis, so that work is understood, reviewed, and approved continually.
Make sure that the work done is transparent, by updating Scrum and Kanban boards.
Understand that they, and all team members, are stakeholders in the Agile process.
Estimate work so that the Product Owner and other stakeholders can plan ahead (e.g. for release planning).
Fully support and encourage the elicitation of metrics, and be able to interpret them and act on them.
Resolve outstanding or impeded work before bringing new work from the backlog into progress.
Limit work in progress so as to maximize throughput.
Act immediately on impediments by appraising other team members and the Scrum Master of any issues, and help to resolve them.
Accept personal responsibility for the team's success.
Accept personal responsibility for their work meeting the team’s Definition of Done.
Give the best, unpadded estimates that can be provided at the time. Estimates should be given and received in good faith.
On the other hand, here are some things a good team member won't do…
Cherry pick work from the Sprint Backlog. The backlog is owned by the team and work is drawn in accordance with the team's plan.
Attempt to work on more than one item at a time. A good team member will pro-actively limit work in progress.
Expect someone else, such as a Scrum Master, to update the team’s Scrum or Kanban board. Information radiators are owned by the team.
Work in a "skills silo." A good team member does not view their work as a specialty that only he or she is able to work on.
Claim that work has been completed if it does not satisfy the team’s Definition of Done.
Claim that work is complete if it does not meet the specific acceptance criteria that have been agreed on.
It's important to remember that Agile practice is not something which can be applied mechanically. Teamwork is more a matter of "being Agile" than just "doing Agile." The state of “being Agile” is underpinned by important values and the degree to which they have been internalized by team members. Examples of team values include:
Focus. An agile team delivers value in a timely manner. To do this a team member must be able to focus on the team’s goals and the work needed to achieve them.
Personal Responsibility. An Agile team member accepts personal responsibility for the team’s success, and for the quality of work done. Any problem which affects the team, and its ability to deliver value, is handled pro-actively by each person.
Team Commitment. An Agile team will commit to a goal and not to the forecast of work, such as a Sprint Backlog. All team members will share in that commitment and re-plan work in order to achieve it.
Collaboration. Agile team members will work together in order to meet the team’s commitments. They will not work in a silo. They will “go to where the work is” instead of waiting for work to come to them, and will act on problems immediately.
Transparency. An Agile team is always clear about the current state of progress in relation to its goals, the work that remains to achieve them, and any problems or impediments that may get in the way.
Valuing Feedback. An Agile team inspects and adapts its progress based on evidence, and always values feedback for this purpose.
Respect. No team member is subordinate to another but is a peer.
Teamwork is Pattern of the Month at agilepatterns.org
Intent: Get people to collaborate on work being actioned so that increments are developed as efficiently as possible.
Many hands make light work.
None of us is as smart as all of us.
Also Known As:
Motivation: There is value to be found in cooperation and self-organization. Quality improves through peer review and inspection, and rework is consequently reduced. Efficiencies of scale can be leveraged as management overhead is less for a self-organizing team than it would be for individual workers.
Structure: A team member does not work in isolation but as part of a team consisting of peers. Each member can, therefore, action work and monitor the progress of work actioned by others. Team members collaborate in iterative and incremental delivery. They are in a position to monitor their workstream and jointly inspect and adapt the process they jointly follow. They can also raise exceptions by consensus if the tolerance of appropriate variables is exceeded.
Applicability: Teamwork is not only applicable but essential to all Agile methods.
Consequences: Teamwork removes skill silos. In its most efficient implementation, all team members will be cross-trained. They will be able to “go to where the work is” and action it regardless of the skills required. The removal of these silos can be politically challenging, as some workers are constrained in terms of what they are allowed to do or simply do not wish to be cross-trained.
Implementation: Scrum recognizes both a Development Team, without skill silos, and a larger Scrum Team that includes a Scrum Master and a Product Owner. XP values teamwork greatly and pair programming is a key feature of this. DSDM is more complex and there are around a dozen business, technical, and supporting roles that make up its collaborative model.
Agile Teamwork: 3 Ways to Minimize Handoffs, by Mike Cohn
Agile Teamwork in Practice, The Agile Zone