Agile Project Management Tips #8: Increase Communication by Pairing

Many Scrum proponents endorse creating cross-functional teams, but they do not always describe in detail the team mechanics. The high-level description is usually something like “Scrum relies on a self-organizing, cross-functional team. The Scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved.” (see Cohn, What is Scrum Methodology?) As a result, team members may end up creating their own personal silos, with developers writing code, testers checking it, the business analyst reviewing, all without collaboration. Consequently, the hand-off points become discrete, and the communication between team members is limited.

Similar to cross-functionality, many Agile evangelists also point to pair programming as a way to create better code with fewer bugs than when programmers work alone. But, why limit pairing to only developers? By pairing developers with testers or testers with the technical writer, or the business analyst with the developer, you can achieve benefits similar to pair programming for the entire team.

For example, we occasionally have the developer write the rough draft of the user documentation. This process helps the developer better understand the user workflows and often uncovers gaps in functionality. Moreover, as the technical writer sees early versions of the system, he can look at it from the point of view of documenting user workflow and suggest changes to the UI to improve usability.

In the same way, asking a developer to sit with the tester while creating the initial test plan increases the informational bandwidth between them. The developer can point out areas that may need more scrutiny or were touched in development but not obviously connected to the main functions of the code. And, the tester may notice areas where the developer may not have fully understood the implementation of a feature. As they create the test plan, the developer may recognize that the tester is not working with the same mindset and steps that he assumed while writing the code.

These pairings are a great way to shorten the loop. Throughout the development process, the goal of the Scrum framework is to increase participation, ideas, and the general quality of the product through shortened feedback loops. This means each minor iteration of the process should have feedback, and meeting face to face is the best way to accomplish this.

Managers and Scrum Masters can do the following to make pairing sessions successful:
  • Make sure that the team has time to pair and suggest including pairings as tasks attached to stories. This raises the visibility of the pairings and allocates the time.
  • Ensure that both sides get encouragement. Developers like to show off their code, but can be protective of it. If the interaction is confrontational, it will not work and will not become a habit. The Scrum Master should plan to attend the first couple pairings and encourage a positive outcome. 
  • Keep the sessions concise. When working on complex problems, pair programming and other types of pairing is useful, but difficult. It is two different minds working together on the same problem and sometimes people pull in different directions. Set aside time for the pairing, but avoid forcing the issue. Let the team self-organize.
The result of pair programming, testing, writing, and other sessions is that members of the cross-functional team will get a better understanding of the specialties of the other members in their group and seeing other people’s perspectives helps everyone create better solutions.