The need for a coach in XP (Irrational Software)

In the article Feature Driven Development and Extreme Programming, Steve Palmer 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 is 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”. In these two areas (code ownership and inspections) the XP coach must ensure that collective ownership doesn’t degenerate, as well as play the role of the FDD chief programmer by doing additional code inspections besides those happening during pair programming.

XP requires both knowledge about the process (which I think is difficult to obtain from the XP literature only) and a fair amount of discipline – and there are certain areas where not being sensitive to 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, or the clarity of the code written (where FDD-like code inspections might be of use).