XP Refactored by Stephens and Rosenberg

In their book “Extreme Programming Refactored: The Case against XP” Stephens and Rosenberg (2003) outline their reasons for not liking XP as it is published, but they also outline what they do like and how risk can be reduced when using an XP like process.   I found their book rather long (and the humour rather unentertaining) but they made some good points and I made a few notes about their conclusions.


Stephens and Rosenberg (2003) comment on the various XP practices, attitudes, values and tenets.

The Planning Game

The release plan is useful – broad view of progress with activity broken into fixed iterations. Estimating the effort for tasks and tracking project velocity are also useful.

Short Iterations

One month iterations (a la Scrum) are better than 1-3 weeks as they provide less distractions. However, progress should be tracked weekly regardless of length of the iteration.

Small Releases

Small releases are good because they provide useful feedback on the usability of the system, helps people form a view on how useful the functionality is, and helps generates requests for changes (faults and/or enhancemens) to the functionality. But not all releases have to be production ready. Most releases should be for internal consumption as production ready releases require more effort.


Metaphor is not a replacement for architecture.

Simple Design

Over engineering is bad but so is excessive refactoring. Do enough upfront architecture and design. Document it. This should be done by the developers on the team, not an architect who then leaves the project.


Refactoring is a useful practice, in moderation. Use refactoring to improve the quality of existing code. Don’t use it as a replacement for design, and don’t do it continuously.


Automated testing is good. Developers should test their code, and having a customer test is a good thing too, but you also need a separate test team.

Requirements Documentation

Handwritten “Stories” on index cards are insufficient documentation. Needs something fuller, stored electronically, and signed off. Possibly start with a short high level spec and break this into parallel subprojects which are fleshed out over time.

Colocated Team

Colocation is a good idea, but is hardly ever possible. Even when it is possible you need more documentation than XP suggests; when colocation isn’t possible you need a lot more documentation and more phone calls.

Pair Programming

Pair Programming is useful for solving hard problems, but shouldn’t be mandatory. It is not a replacement for code reviews.


Prototypes are good. Do them as early as possible and do as many as needed to give confidence in the design.

Continuous Integration

Frequent integration is better – say once a day. This gives developers a chance to tackle bigger chunks of work and ensure they are working before the automated integration + test happens.

Sustainable Pace (40-hour week)

A sustainable pace is good, but there will be spikes in work flow.

On-site customers

An on-site customer is alright, but remember there are many sources of requirements (e.g. other users, management, project sponsor i.e. the person with the cheque book).

Collaborative Coding Standards

Coding standards are good. Should cover layout and good programming practice.

Additional Practices

Stephens amd Rosenberg (2003) suggest some addition practices.

The Stopgap

Get a release out early without putting the project into maintenance mode.

Additional Roles

– Technical Team Leader – like a coach but can say “just do it!”
– Quality Assurance, i.e. tester
– Interaction Designer


Document the design.

Individual Ownership

Individual ownership is an effective alternative to collective ownership.


Stephens, M., & Rosenberg, D. (2003). Extreme Programming Refactored: The Case against XP. Apress.