I used to be plagued by nagging concerns about certain omissions and shortcomings of extreme programming (XP). Over recent months, I have come to the conclusion that my thinking on the topic was flawed; I used to criticize XP for not addressing a variety of issues such as the integration of testers, domain modeling, story generation, etc.

It is not that I wanted XP to be an overblown process, specifying roles and practices for everything related to development. But, for example, there is an assumption that the customer just knows how to generate good stories (those with high business value) in XP. The customer creates stories, prioritizes them, and knows when to extend, revise or remove stories from the project. There is no guidance for the customer as to how to be a "good" customer.

A thought solidified for me in a recent blog post, regarding the role of testers in XP. I realized that XP is a coding / developer centric process. Eight of its twelve practices are directly about the creation of code; the remaining four support the developers in their work. Story generation and other concerns are outside the scope of XP.

In my opinion, this is a strength, rather than a shortcoming. Software development is about producing software, so it is natural to start with a process that is about generating code. XP is lean and focused on this task; there is little fluff. It allows the project team the freedom to add complimentary processes that support other activities and roles that may become necessary or require assistance.

For example, scrum (a project management centric process) is compatible with XP. For teams that have greater project management needs (or an available project manager), scrum can be added to the development process. But if it's not needed, then there is no need to be encumbered by the extra process.

I think this encourages a "on-demand, just in time" addition of process. The advantage of this approach is that the development process is kept lean. Starting with RUP for is like managing your development process in waterfall fashion; you preemptively specify all your project's process requirements and devise a design.

Alternatively, active process refactoring, facilitated by techniques such as retrospectives, allow the development process to evolve with the needs of the team and their context. This allows a team to adhere to the YAGNI principle (You Ain't Gonna Need It) of simple and lightweight process.

Unfortunately, process refactoring does not have the benefit of automated unit test / change detection suites. In XP, such tools make refactoring safe; you get immediate feedback as to what you broke and what dependencies exist; process refactoring can be riskier.

For me, this idea feels right; it comforts and helps alleviate many of the concerns I have regarding applied agile development. I think the next step is to identify process "smells" and their possible refactorings. (I have done some work related to this. See my Implementing Agile Process wiki section or the Agile Process Pattern Catalog.)