Tuesday, April 6, 2010

What Do We Know about Agile Software Development?

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.

3 comments:

  1. The findings regarding pair programming’s effectiveness were mixed. Several developers regarded it as an exhausting practice because it requires heavy concentration.


    Kent Beck called it "Extreme Programming" for a reason: it's an extreme sport that requires discipline, but it's also rewarding if you get into the rhythms of TDD and ping-ponging (writing a failing test, passing the keyboard to your partner who makes the test pass, writes a new one, and passes the keyboard back).

    The rhythm is what makes it not just bearable, but satisfying.

    ReplyDelete
  2. 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.

    Amen - and that "100% efficiency" stuff smacks of Human Resources thinking.

    Agile requires sustainable pace and slack - just ask Bob.

    ReplyDelete
  3. @G-Hog-Chi: I completely agree that it's the rhythms of XP that make it so much fun. And more importantly, they increase your chances of a successful project. Not only the rhythms in the small scale, as you describe, but also the rhythm your team can develop when you start releasing to production every few weeks. I've been fortunate enough to experience this within a team, steadily for over a year. There's no better feeling than when all of the practices come together and become a deployed product.

    ReplyDelete