Pattern of the Month: Peer

In Agile practice, the completion of work is seen as being the responsibility of the team. Although individual team members may action a particular backlog item in whole or in part, it will be the team which owns it. This principle is ingrained to the point that — in the Scrum framework — it shapes the way in which roles are defined. Hence, you will find a role in Scrum called "Development Team," but not one filled by an individual "Developer."

Each Agile team member is considered to be a peer to the others. For this to hold true, there must be a shared sense of commitment to team goals, and an ability for those people to work together. In an efficient team, the various members will "go to where the work is," rather than waiting for work to come to them. This implies that a degree of cross-skilling and cross-training ought to be in evidence, and which is sufficient to overcome the waste that would otherwise be accrued through bottlenecks and skill-silos. Efficient peers will collaborate with regard to who performs certain tasks at certain times. Any scheduling that they agree amongst themselves will thus become orthogonal to the flow of work.

This quality of collaboration may be evidenced through pair-programming, where two members will collaborate to achieve a programming task. For example, one may author a test while the other checks the work; they might then switch over the keyboard when implementing the relevant feature. Similarly, a team which swarms regularly is also likely to consist of peers with a healthy ability to collaborate, rather than individuals in skill-silos. The tendency to increase work-in-progress to match or exceed the number of members will be avoided by such a team. Instead, the emphasis will be placed upon the joint completion of work, and not the starting of it.

Peer

Intent: Remove skill silos, encourage team responsibility and accountability

Proverbs:

• "A problem shared is a problem halved."
• "Another pair of eyes often helps."

Also Known As:

• Cross-Skilled Developer

Motivation: The quality of work done by individual team members is the responsibility of the team. Recognizing fellow team members as peers is critical if there is to be effective team ownership and quality control.

Structure: A team has a codebase and multiple team members, any of which may be a peer to another. Each unit of work that is done by a team member is validated by a unit test, and must be inspected by a peer before it can be committed to the codebase. Units of work, and their tests, can be inspected and adapted by team members, including those in the role of peer, in order to maintain quality control.

Applicability: The assignment of peers to team members is appropriate when the team as a whole cannot exercise effective and consistent jurisdiction over the work of all members. This is often the case when each team member is allowed a discrete piece of work, such as a user story or task, to action. The assignment of peers can become unnecessary when team collaboration is an entrenched practice; this can be the case with Single Piece Flow.

Consequences: The usage of peers can improve the consistency of work products, and provides a mechanism for team oversight of constituent members and quality assurance. Reduced rework is likely. Since peers are by definition reviewing the work of others, this can lead to frictions including the perception that individual performance is being criticized. Training is required in order to overcome this. There is also a danger that the use of peers will be seen as waste and the duplication of effort.

Implementation: Peers are most commonly found in two contexts. Peer Review is the ad-hoc assignment of a peer for the purposes of checking the conformance of work items to their acceptance criteria and the team’s Definition of Done. This is quite common in a Scrum setting. Pair Programming is the systemic use of peers for development and delivery; a peer will continually collaborate with a fellow on the actioning of work. Pair Programming is most commonly associated with Extreme Programming and Test Driven Development, though it may also be found in Scrum and DSDM implementations.

See Also:

• Teamwork
• Definition of Done
• Pair Programming, extremeprogramming.org
• Humanizing Peer Reviews, by Karl E. Wiegers
• Using Peer Review Data to Manage Defects, David Consulting Group