Last time we left off at the XP practices. In the second edition, Kent Beck doubles the original 12 practices and groups them into Primary Practices and Corollary Practices. The primary practices are relatively independent, that is, they add value to software development without needing any supporting practices. They should be all you need to get started experimenting with XP.
The primary practices are:
- Sit together - maybe not all in one big room, but being physically closer together improves communication
- Whole team - teams are cross-functional, able to handle delivering the entire application. Nothing is "thrown over the wall"
- Informative workspace - big visible charts in a common area not only deliver info, they are social focal points for the team
- Energized work - work at a sustainable pace because lots of overtime doesn't increase productivity
- Pair programming - yes, it's still here, although in this edition Kent spends a good amount of time talking about respecting personal space ("personal hygiene and breath issues are very important")
- Stories - stories are customer-visible units of functionality (like Feature-Driven Development). For more on user stories, check out Mike Cohn's book User Stories Applied
- Weekly cycle - plan work a week at a time
- Quarterly cycle - quarterly planning includes retrospectives, identification of bottlenecks, and a focus on the big picture
- Slack - pretty much the same as the ideas in Tom DeMarco's book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
- 10-minute build - the build should be automated, and it and all its tests should run in under 10 minutes. I wonder if the Windows team will ever get their builds this fast?
- Continuous integration - developers should check in several times per day to reduce integration headaches
- Test-First programming - also known as Test-Driven Development
- Incremental design - start simple and grow as needed, keep code quality high and technical debt low
The corollary practices are practices that are more difficult to implement, or that require the safety net of one or more primary practices. These practices, however, can substantially improve a team's performance that only uses the primary practices.
The corollary practices are:
- Real customer involvement - I guess since the CHAOS report says that a lack of customer involvement is the number one reason why projects fail that this is pretty important, but you need to have your house in order before inviting the guests in
- Incremental deployment - strangle legacy applications
- Team continuity - keep effective teams together. Sadly this is lost on most managers as they feel the need to disperse successful teams in a misguided attempt to spread "best practices"
- Shrinking teams - basically all projects go through a lifecycle where staffing needs will vary depending on the stage of the project. Be aware of this, and shrink teams when necessary
- Root-cause analysis - don't eliminate a defect until you know what caused it
- Shared code - any team member can improve any section of the code. I haven't seen this work out too well in practice, but maybe it's just my experience so far
- Code and tests - the code is the design and is the source of truth, everything should be subservient (i.e., automatically generated) to it whenever possible
- Single code base - try to keep the number of development branches as low as possible, although I think you should branch when you need to
- Daily deployment - only if you have a low enough defect rate
- Negotiated scope contracts - see more on agile contracts here
- Pay-per-use - a suggestion to better align developers' and customers' interests
That's a lot of practices! And we've only vaguely referenced the idea of the "whole team". So who should be on the team? That's a discussion for next time.
From Extreme Programming Explained: 2nd ed