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.
No comments:
Post a Comment