Common Mistakes and Misunderstandings

or, How to Fail with Extreme Programming

Error: No onsite customer; rather, use specifications written for the next iteration It is normal and acceptable to create written specifications for the iteration (for example, two use cases) if the adopted method is Scrum, UP, Evo, etc. An iterative or agile project that takes this approach can work well, but is better characterized as being based on another method (e.g., the UP) that allows written evolutionary requirements. It is a cornerstone of XP to avoid detailed specifications, use oral communication of the requirements, and onsite customers.

Error: Applying a subset of uncompensated practices; customizing before trying Many XP practices work as a synergistic whole, and it is a mistake to remove one that compensates or supports another. For example, collective code ownership isn't feasible without testing, continuous integration, and coding standards. Minimal requirements documentation isn't possible without an onsite customer. Frequent refactoring doesn't work without the tests. That is why Beck, while not wishing to be rigid, in general recommends adoption of all or most of the core practices. To quote Beck, "Do all of XP before trying to customize it."

Error: XP is just iterative development + minimal documentation + unit testing Although there is some flexibility in what practices must be present to define an XP project, it is more than this common to several IID methods. One could run a Scrum, UP, DSDM, or other evolutionary methods primarily with just these practices. XP is characterized by a larger set of practices, including pair programming, onsite customers, customer written acceptance tests, and more.

Error: Not writing the unit tests first Test-first development has a more subtle dimension than first glance, and is an important XP practice. Writing the tests first influences how one conceives, clarifies, and simplifies the design. Test-first has an interesting psychological quality of satisfaction: I write the test, and then I make it succeed. There is a feeling of accomplishment that sustains the practice.

Error: Customer doesn't decide XP is customer driven; they need to decide what the acceptance criteria are (via tests), and what stories go in a release and iteration.

Error: No customer-owned tests Ron Jeffries has said, "The failure to have customer-owned acceptance tests [in each iteration] is one of the most common mistakes in XP."

Error: Minimal refactoring The XP avoidance of design thought before programming is meant to be compensated by a relatively large refactoring effort, such as 25% of total effort applied to refactoring. Beck's point is that one can't avoid both design thought before programming and refactoring; it's either/or.

Error: Must have only one onsite customer The original XP books talked of one onsite customer in the project room. Beck and the XP leaders have since refined this to emphasize that the customer team needs to be considered as a whole, with requirements coming from perhaps many customers participating in the Planning Games. Thus, they have replaced the practice "onsite customer" with "whole team together."

Error: Many fine-grained task cards Most task cards should be in the one or two-day range of effort. Most in the "few hours" range creates unnecessary information management.

Error: Pairing with one partner too long XP pairing changes frequently, often in two days or less. Variation also helps spread the learning.

Error: Customer or manager is tracker Programmers will feel awkward reporting slow progress.

Error: Not integrating the QA team Many organizations have a separate Quality Assurance team, used to having a completed system "thrown over the wall" to them. One or more dedicated QA people need to be brought onto the project full-time the whole team practice usually to write the acceptance tests in collaboration with the customer.

Error: Post-development design documentation is wrong XP isn't anti-documentation, but prefers programming if that's sufficient to succeed. XP can support the creation of design documentation to reflect the existing code base, once the program is complete. As always, the simplest approach that can work is the goal, such as video recording an explanation.

Error: Diagramming is bad Although XP advice is minimal modeling or diagramming, such as 15 minutes before programming, a very little is acceptable.

Error: Only young pair programmers Some XP projects have suffered in the pair programming practice when most of the developers were quite young, without the patience or maturity to handle working closely with others.

Error: Pairing newbies One of the two partners should have pair programmed before.

Error: One partner going too fast When pair programming, the quicker or more experienced partner needs to be sensitive to the speed or comprehension differential of their partner, and slow down their activities and explanations.

Error: Observer can't easily see the monitor Self-explanatory, but a surprisingly frequent problem.

Error: Not willing to learn; not willing to explain For successful pair programming, an attitude of openness to learning and of explaining yourself is required.

Error: Full team (including customers) not briefed in XP and its motivations Self-explanatory.

Error: Dissenter on team XP is about communication and collaboration, and a culture of development; lone programmers who don't wish to accept it can impair the team culture and project progress.

Error: Stand-up meeting too long or unfocused Keep it below 20 minutes, and on status of tasks, not a discussion of design and requirements.

Error: Lumping into one big "bug fix" story As defects accumulate, don't group them into one task or story card; keep them with their original related cards.

Error: No dedicated acceptance tester One is needed to work with the customer on transforming their acceptance criteria into runnable tests. An exception is very small projects the tester may fulfill that role part-time.

Error: Onsite customer and Big Boss aren't aligned XP talks of the Big Boss, or the person ultimately owning or responsible for the project goals and milestones. These two stakeholders need to be in agreement.

Error: Customer writing acceptance tests isn't the reviewer of their execution A classic problem of serving different masters.

Error: Iterations too long XP iterations should be 1 3 weeks.

Error: Iterations aren't timeboxed It is a misunderstanding to let the iteration length expand when it appears the goals can't be met within the original time frame. Rather, the preferred strategy is usually to remove or simplify goals for the iteration. And, analyze why the estimates were off.

Error: Iteration doesn't end in an integrated and tested baseline An iteration doesn't just successfully end on the end date. The goal is that all the software has been integrated, tested, and baselined.

Error: Each iteration ends in a production release The baselined software produced at the end of an iteration is an internal release rather than shippable code. It represents a subset of the final production release, which may only be ready after a dozen or more short iterations. It is true that in iterative development one goal is that each iteration release is stable enough to potentiality release to production, if necessary. However, this is not the normal intent of an iteration release.

Error: Predictive planning It is a misunderstanding to create, at the start of the project, a believable plan laying out exactly how many iterations there will be for a long project, their lengths, and what will occur in each. This is contrasted with the agile approach: adaptive planning. The XP team and customer plans the next iteration, and then planning adapts iteration by iteration, based on current feedback.

You Know You Didn't Understand XP When...

Some of the key misunderstandings expressed as a checklist:

• You think you should customize the choice of practices without having first applied them all.

• You think "doing XP" means to avoid the waterfall model and develop iteratively, or just to avoid documentation, or just to write some unit tests.

• Customers are not involved in the Planning Game, creating acceptance tests, or reviewing the iteration results.

• You create a plan laying out how many iterations there will be for the project, their lengths, and what will occur in each.