If every time you come to the end of an iteration you have to throw away half of the stories, then something is definitely wrong. Iterations can have a moment of dramatic tension, but most iterations should finish comfortably. You might not know on the second Tuesday if you're going to make it, but when the lunch pizza comes on Friday and you push the button to run the acceptance tests, everyone should be confident of the outcome.

Are you committing to too much? Kent had a project where the programmers' guilt level was high enough that they always rounded up. "We got 38 days done last iteration with 4 people, so call that 10 days per person and we have a new person, so that's 50." They missed a little every iteration, but, more important, they got behind on testing and refactoring until finally one iteration completely pancaked. They delivered 1 (one) day to the customer. That was the wake-up call to just follow Yesterday's Weather.

Have you gotten behind on testing and refactoring? If so, you'll see debugging take an increasing percentage of time but an unpredictable percentage. The only solution we've found is to slow down, temporarily, and write the extra tests and do a little more refactoring. After a couple of iterations your speed should pick up.

Have you succumbed to the temptation to slice your estimates? It is so easy for programmers to feel guilty when the customer is disappointed and for that guilt to turn into shorter estimates, not for any technical reason, but because they want the customer to be happy (or at least stop bugging them). This doesn't work. Don't do that. When programmers make estimates, have them find comparable work and make the estimates comparably. "We have two new reports. They are both about the same as the framdoozle report we did last iteration, and that took a week. Call them a week each."

Sometimes customers simply refuse to make decisions. They won't pick the stories for an iteration. They won't specify acceptance tests. They won't answer little questions about scope.

Extreme Programming cannot work without a customer making decisions. Customers don't have to stick with those decisions. Changing their mind is one of their rights. But the decisions must be made, and by someone with a business perspective.

Sam Gentile reports on a project where the customer's boss signed a contract for extreme development. When the team got there and started exploration the customer was incensed. "I hired you to do the analysis, not for me to do the analysis. Get to it. And I'm busy, so don't ask me any questions." Fortunately the team had the wisdom to terminate the contract at that point.

Find out why the customer won't make the decisions. If his priorities are elsewhere, perhaps the whole project doesn't make sense. If he doesn't want to be publicly wrong, the best you can do is reassure him that he will get a chance to fix any errors in the next iteration.

Between the unit tests and the acceptance tests, the software produced by an extreme team should be remarkably defect free. There should be enhancement requests aplenty, but the software should work as specified.

If you are seeing enough defect reports to disrupt development, slow down until you aren't seeing them. Have a pair go through every defect and find where it occurred and what unit test should have been written to catch it, then report back to the team.

Sometimes a class of defects will turn into a design change. "We have six bugs when we run with Netscape. We have to create a browser object to isolate the browser-specific behavior."

It is so tempting to stop developing when you get uncomfortable. We're building a Web server and we've got all these tests, but they always run inside our network. Go out to Seattle Coffee, rent a station on the Internet, and try to get to the server. If we can't, because our proxy server isn't configured yadda yadda yadda, then stop until it is. Every dark corner you haven't explored with your flashlight is full of bugs.

If the eight to ten integrations you do every day are going smoothly but you have problems when you push the software to production, make the integration environment match the production environment more closely. The feedback from the little integrations won't help your planning if you don't know how much progress you've actually made.

One of the failures we've seen in XP is where the customer flits from flower to flower—a few stories from here, a few from there. The programmers blaze along, hitting their estimates, finding fabulous abstractions while refactoring, testing like mad. Then one day the project is cancelled because it didn't get anything done.

Make three- to four-month release plans that the customer presents to upper management. Are the results of those plans reviewed when the date rolls around? The big cheeses are there for a purpose—use them. Big bosses can be good at spotting misfits at a quarterly scale, "I can see that all this Web stuff is exciting, but if we don't prepare for this Federal Reserve report we're out of business."