XP Lessons From the Field

• When developing stories, don't forget performance and quality standards when thinking of "done" - Too often we think of done as just what the immediate product owner wants, but the larger organization has some concerns too. Don't forget them when writing your acceptance criteria.
• Localize software to be built to the architecture's applications layer - Recognize when you're writing application layer code and when you're creating frameworks. They're different types of work, and different techniques can help you do them.
• Become experts at breaking down stories - This, more than anything else, is what teams learn when they start doing agile: how to make smaller pieces of useful work and deliver on them. Stories must be small enough, and they must have an owner. Also be careful about pairing up people who don't get along.
• Consider performance considerations as soon as you start working - refactoring for performance can be a real time-killer. If performance issues are part of the acceptance criteria, best to address them immediately and not incur technical debt.
• If you pair-program, rotate people - Some people won't get along. Everybody has different skill levels. The best way to level the team is to rotate the pair-programming assignments.
• Try pairing up during the stand-up for the work for the day - this gives you maximum flexibility to adjust the people to match the immediate situation.
• Getting a user/customer to be resident full-time is almost impossible in most organizations - If you're lucky enough to get one person as a product owner, the trick is effectively managing your time with them.
• Focus on working product reviews instead of paperwork reviews - Anybody who has worked on an agile team knows this, but it's good for nothing else other than a sanity check.
• Version control is more important - With continuously changing and running product, it becomes even more important to have a structured, quick, efficient version control and release process
• Nightly builds of working code is critical - Some teams have moved beyond this to have continuous integration, where the code is always building. But from this survey the bare minimum is nightly builds.
• Create and maintain a release plan - You should always have a list of functionality that is being released on a regular basis. Acceptance test for releases should be created by the actual users, not anybody on the team. Tradeoffs are made when necessary to meet the plan. Mature agile teams create and manage release plans. Simple as that.
• Standards should embrace design and reuse considerations in addition to what is necessary for pair programming, refactoring, testing and continuous integration - This should be self-evident. Say it over and over again: agile does not mean we are not doing design!
• Make sure that those assigned to the team add value - watchers and checkers should be put to work developing product instead of offering critical remarks
• Use retrospectives to shape and adapt work patterns - If you're not changing what you're doing from sprint to sprint, you're doing something wrong.
• The 40-hour work week is a dream - While in theory no developer should have to work extra time, what these teams found was that the time spent refactoring on XP projects keep increasing as the code base grew. As a coach, some teams are this way and some teams aren't. In my opinion, it all depends on whether or not somebody is balancing big-picture analysis and design with sprint-level analysis and design. Too many times teams want one or the other, and what's really called for is balance. There's been too much snake oil sold on both BDUF (Big Design Up Front) and the YAGNI (You Ain't Going to Need It) camps. Real performance involves the right balance of each.

I hope you find these useful. These are the survey's conclusions; the commentary is mine. You're welcome to read the entire 11-page document for more information. If nothing else, they should make for good conversation-starters the next time you get started on an Agile/XP project.