Regarding people getting burnt out because there’s no time between iterations, there are two concepts that are used in XP to avoid this. Firstly, sustainable pace says you shouldn’t be doing all that work after 5pm, you are fresher and more productive if you go home on time. If you find your team is burning out you are not working at a sustainable pace and you need to find ways to reduce stress and burn out - how you do that will depend on the particular team.

The other important concept is slack. Having slack in your schedule each iteration allows you to do the continual maintenance and additional testing etc that you saw happening after work hours. The key thing is to admit to yourselves and the rest of the business that these tasks exist, they take up time and they are very important so you have to leave time in the schedule for them to happen. If you find they aren’t happening, pull back the amount of work you take on for each iteration to give you more time to do them.

Agile methods depend on doing all of the practices together - implementing or focussing on each one as it becomes important. In other words, you may not roll out all the practices at once (it’s too much for the team to handle all at once) but as you see problems cropping up, roll out or improve the practice that solves that problem. In the case of your missile guidance you needed better customer acceptance tests, better unit testing and a better QA system backing up the customer. In the case of your burnt out team, you needed more slack and a focus on sustainable pace. Agile methods provide the building blocks to solve these problems, you just need to be sure you continuously review what you’re doing and adjust your processes to constantly make things better.

Basically, if after 6-12 months of doing XP you’re still doing it the way it says to in the book, you’re not doing XP because you’re not doing the review and improve part of XP that is so critical (mostly this comes through in retrospectives).

What do I mean by “final” testing? Take this scenario: the theme of a 30 day sprint is to produce a core component of a graphical display that a range saftey officer at a missle range will use to do his job during a launch. Stories are knocked out one by one until only a couple remain on day 29 of the sprint. Developer Joe is working late that night and runs into trouble. He has to change some base classes used by all the other stories in order to finish his story. He changes them, and the CI system runs all the sets of tests at midnight for the final build. Everything compiles and passes. Out pops the golden egg: an InstallShield script runs, and bam! a CD is cut.

After the sprint demo, the software gets installed at the missle range (it has been “tested”, right) and then used in production. Nobody ever takes the CD and installs it and does any further testing- after all, the next sprint has already started! Does this seem like a good idea? I don’t think it does but agile doesn’t seem to have an answer for this.

The fact that a new sprint starts as soon as one ends really led to burn out. There was never any “down time” to do any cleanup, maintenance, additional testing, etc. Agile says you do this stuff as you go along. In my experience this isn’t always the way it works out, and when it doesn’t you’re in trouble. You start utilizing hours upon hours after 5pm to take up the slack and eventually, people start quitting.

Brian, you’re quite right to say that it’s rediculous to expect TDD to result in perfect, bug fee code. But did you miss the recommendation for acceptance testing? In all of the agile approaches I know, the QA period covers the entire iteration, working in parallel with development. It’s too important to leave as a final phase, and is less effective when left as a final phase. Better to catch problems as early as possible, when they can be dealt with systematically instead of by brittle patches, and before more code is built on top of them. The “throw the completed design over the wall to QA” approach has never worked well, in any field.

The theory sounds great and it might even seem to work great over the first couple of sprints. However, we found ourselves hurt by an entirely new set of problems with Agile. For example, we were always overloaded with maintaining a complex, automated build, unit test, integration test, and acceptance test environment.

Some developers spent more time trying to do TDD than actually writing code. This wasn’t always a lack of experience, either. I’m a firm believer that some code doesn’t lend itself to TDD. I also don’t think a rule that mandates 100% test coverage is feasible.

Pair programming never resulted in a large improvement in productivity, even over the long term. We never got twice the productivity from a pair.

The products severely suffered from the lack of a QA period. A QA period is strictly forbidden, and as a result the system never got tested properly. It is ridiculous to say that TDD will result in perfect, bug free code.

The products often suffered from architecture problems. Since you only design a month’s worth of a system at a time, the “big picture” often got missed and you ended up with a patchwork system and no mechanism to go back and clean it up.

Senior developers were often overworked doing the work that managers usually do. When they say “the team self manages” that really means that senior guys have to step up and do a lot of “people management” since there is no manager to do it.

We had adopted the methodology 100% and had a lot of resources to help us including some big names from the industry. There are always answers given to all the things I mentioned above. Regardless, we had a talented, committed and qualified staff but in our retrospectives we always sat around talking about how it wasn’t working.

I have my own theories about how to develop software efficiently and effectively, but I’ll save that for later :)