It's What You Value
XP is a whole new way of life. Now, that may be an exaggeration, but what other development approach is built on values that you can apply to developing software, giving presentations, building web sites, and just about any other collaborative endeavor? This basis in values is another reason why the implementation of XP can be customized for a client or development shop. Look at the values in the following sections to see what I mean.
Communication sounds like a fairly innocuous value. You do it all the timereports, emails, snail mail, documents, and maybe a fax or two. In the XP sense of the word, however, communication means talking and listening. It's hard to say much more about it than that! In fact, in XP the core practices require communication:
- Unit testing
- Pair programming
- Task estimation
- Planning game
Feedback in XP is concrete feedback about the state of the system. No more "90%" complete tasks; we know these don't work. Developers are so optimistic (about estimates and work-complete, at least) that sometimes it's hard to know how the project is tracking. To reduce this optimism, you need real metrics! During the lifecycle the team tracks a few key metrics and uses them to measure velocity. Continuous integration gives minute-by-minute, build-by-build feedback on the state of the system. You're not measuring document product progress; you're measuring delivered functionality to the customer. Isn't that what it's all about?
Courage can mean facing impossible odds and throwing yourself into the fray with no regard for personal safety. Sounds like a normal day at the cube farm to me! Thankfully, the XP courage is a boldness to act based on a strong, automated test harness and is not about recklessness endeavors into the unknown. XP-ers have changed the development mindset of tentative, uncertain coding into development at top speed. Simplicity is another key value that supports courage; team members understand the system and have hard metrics that support source refactoring.
Courage without the other values will result in another mess of tangled code, complexity, and poor maintainability.
Simplicity is hard. XP rejects the idea that designers should build in future requirements (read: guesses) up front, and that project plans should be mapped out for the entire lifecycle. If change is just as easy tomorrow (addition of new features, etc.) as it is today, why not postpone development until the customer's need becomes real?
What's the simplest thing that could possibly work? This is the constant question that XP team members ask when faced with a design or implementation "fork in the road." In the final analysis, simple systems are easier to communicate about, have fewer integration points, and scale better.