The need for a coach in XP

In the article The Case Against Extreme Programming, by Matt Stephens (which I’ll probably get back to later, but basically my opinion is that most of what he writes is based on misconceptions about XP, although there certainly are many things he’s right about) there was a link to a comparison between Feature Driven Development and Extreme Programming, written by Steve Palmer (I think), which made me think about the need for a coach in XP.

He walks through a list of areas where there are differences between FDD and XP, such as team size (that XP, as it’s described in the literature, doesn’t scale, while FDD does), design (big differences between the two), code ownership, inspections, etc. As for code ownership, Palmer writes that “collective ownership usually degenerates into non-ownership as the number of people involved grows”. He goes on to describe the class ownership concept that FDD uses, where each class are owned by a programmer (if I understand correctly), and writes that it solves the problems that collective ownership does, “while keeping the well established benefits of individual code ownership.”

Regarding inspections, Palmer acknowledges that pair programming is better than no inspections, but that FDD has some advantages over XP: “fresh eyes to look at the code, ... [and] a chief programmer present to ensure the techniques learnt are good techniques” (that is, in XP, knowledge transferred between pairs). In these two areas (code ownership and inspections) the XP coach is important for ensuring that collective ownership doesn’t degenerate, and playing the role of the FDD chief programmer by doing additional code inspections besides those happening during pair programming.

XP does require both knowledge about the process (which I think is hard to obtain from the XP literature only) and a fair amount of discipline – and there are certain areas where not being savvy about the dynamics of XP could impact the work negatively. The need for an experienced coach should not be underestimated.

A coach is needed to guide the process, to make sure the team stays “on process”, by being alert about things like collective ownership, the level of communication within the team and with the customer (see the post about stimulating communication), or the clarity of the code written (where FDD-like code inspections might be of use; the PDF introducing FDD might be interesting).