Dybå, Tore and Dingsøyr, T. "What Do We Know about Agile Software Development?" IEEE Software, vol. 26, no. 5, 2009, pp. 6-9.
The authors surveyed the academic literature, to summarize what is known (academically, scientifically) about agile software development. Based on my experience in the field, there seems to be a disconnect between academic research and practices in the trenches. Below are some of the findings from this research, and my responses.
Some studies saw pair programming as inefficient, and some studies claimed that XP works best with experienced development teams. One study reported the further limitation, which the literature repeatedly mentions, of lack of attention to design and architectural issues.
Any development method or development process will work best with experienced development teams, particularly when compared against itself. What I have seen is that XP is great at taking a mixed team, and improving the abilities of everyone on the team. The practices of open communication and collaboration, collective code ownership, pair programming and emergent architecture all contribute. As the project progresses, each team member, no matter how junior, will have worked on many aspects of the system, each full of opportunities for learning.
Using a prescriptive development process could still lead to a lacking design and a lacking architecture. XP provides practices of refactoring, collective code ownership, test driven development and emerging architecture. These practices together allow the team to constantly improve the design, while building out only as much architecture as necessary. Diligence and attention to detail can be used or abused in any development process.
However, the on-site customer’s role can be stressful and unsustainable for long periods.
There is more than enough here for another full post. Without an on-site customer, we can regress to having long feedback cycles, waiting for emails or phone calls to be answered. We may even regress back to writing a requirements document, usually by a business analyst, and throwing it over the wall to development. The document is then ripe for mis-interpretation and other abuses by the readers. To have the right software developed, the right person needs to be fully involved and committed.
The findings regarding pair programming’s effectiveness were mixed. Several developers regarded it as an exhausting practice because it requires heavy concentration.
Pair programming provides many benefits: automatic code review, information exchange, focus, efficiency, learning. XP has another practice, sustainable pace, which offsets the intensity. The authors even note in their findings that agile team members believe they are more efficient.
One limitation that came up was that team members are less interchangeable in agile teams, which has consequences for how projects are managed.
By pairing and through collective code ownership, the team is spreading the knowledge around, so that more and more of the team members can work on each part of the system. Spreading this knowledge decreases your dependency on a particular developer for a particular area of the code.
Pair programming also makes it much smoother to introduce new developers to the team. The new developer will always be working with someone who is familiar with the code base, the design, and the entire project. This makes it easier to bring on new team members.
If the point of interchangeable developers is to maximize resource utilization, this seems like a case of sub-optimizing. The goal of a project manager should not be to make sure that each resource is 100% efficient, but instead that the team (of people) is meeting its goal: delivering the right software.
Our review identified 1,996 studies from literature searches, 36 of which we found to be research studies of acceptable rigor, credibility, and relevance to include in the review.
I may be biased by successful agile projects in which I have participated over the last ten years. I may also be biased by all of the pairs I have worked with, who taught me new things and made each task much more fun.