James Shore

in 99 words

You'll need support, from managers and colleagues. Work together, in the same room, and include business experts. Keep the team small--five to twenty people. Don't ignore practices: they're more important than they seem.

A brand-new codebase and a language that's easy to refactor are best for learning. Try to include an experienced coach, and an experienced designer. It's best if everyone gets along.

You don't have to do any of these if you don't want to. (We provide alternatives.) But you'll have more success, and more fun, if you fix your environment rather than compromising your work.

as haiku

slippery, muddy--
where grass died, pepperbushes
provide fragrant blooms

Download this poster!

Inside This Section

• Is XP Right For Us?
• Prerequisite #1: Management Support
  • If management isn't supportive...
• Prerequisite #2: Team Agreement
  • If people resist...
• Prerequisite #3: A Colocated Team
  • If your team isn't colocated...
• Prerequisite #4: On-Site Customers
  • If your product manager is too busy to be on-site...
  • If your product manager is inexperienced...
  • If you can't get a good product manager at all...
  • If you can't get other on-site customers...
• Prerequisite #5: The Right Team Size
  • If you don't have even pairs...
  • If your team is larger than seven programmers...
  • If your team is smaller than four programmers...
  • If you have many developers working solo...
• Prerequisite #6: Use All the Practices
• If practices don't fit...
• Recommendation #1: A Brand-New Codebase
  • If you have preexisting code...
• Recommendation #2: Strong Design Skills
  • If no one has strong design skills...
• Recommendation #3: A Language That's Easy to Refactor
  • If your language is hard to refactor...
• Recommendation #4: An Experienced Programmer-Coach
  • If you have no obvious coach...
  • If your leaders are inexperienced...
  • If you're assigned a poor coach...
• Recommendation #5: A Friendly and Cohesive Team
  • If your team doesn't get along...

Behind the Scenes

There's this odd balancing act when you write... or at least, when I write. I find myself having to balance truth and clarity. Sometimes, absolute truth isn't very clear. Sometimes, clarity isn't totally truthful. I have to compromise on being factually correct in order to achieve my real goal: helping the reader.

Let's say that I was writing a "how to" book for the stock market. If I wanted to be totally truthful, I would say, "buy low, sell high." But that's not very helpful, is it? It's a platitude. Readers need more.

On the other end of the spectrum, I could be very helpful by saying, "Buy 300 shares of WidgetCorp and sell them in exactly three weeks." That's helpful advice! It's clear, concrete, unambiguous. Minor problem, though: it probably wouldn't work. Clear, but not truthful enough. Bummer.

This is the choice Shane and I faced. Truth? Or clarity?

Well, we wanted to write an especially hard-headed, practical book. We felt that agile development was "crossing the chasm"--that the audience for agile books was changing from early adopters, who were primarily interested in experimenting with the latest and greatest, to the early majority, who are primarily interested in ideas that help them do their job better. That meant we had to be very direct. Clear; pragmatic; hands-on. That was our goal. We chose clarity.

Okay, what happened to the truth? Well... I'll admit it. We lied. Sort of.

When providing a how-to guide, as we are, you generally have to pick one way of doing things. You can contrast various approaches, but that limits how much you can say about any one of them. In our case, we wanted to go into a lot of detail--334 pages of detail, in fact. Imagine what the book would have been like if we had tried to cover all of the other ways of doing agile development, too.

Although we had to pick one way, it couldn't possibly work for everyone. That's what makes the term "best practice" such a cruel deception. How can any practice truly be "best" in all situations, for all people? Best for who?

So we ended up writing a book that was, at its core, not entirely truthful. When we tell you that you should pair program and have everybody sit together, we could be lying. It's really only true if you're all in the same location, have a nice open workspace, and everyone involved has agreed to do so. We tell you that you can eliminate requirements documentation; it's only true if you have an on-site customer and are performing certain other XP practices.

That's what this section--"Is XP Right For Us?"--is all about. We're crossing our fingers behind our backs. We're providing context--describing what needs to be in place for our advice to work.

(Then, just because we know people won't read everything we wrote (gasp!), we repeat all of the important assumptions in the "Contraindications" portion of each practice.)

Truth? Or clarity? We chose clarity, and then fudged it by telling you how we were lying. I think all authors have to make this trade-off. Too often, the lies remain hidden, and you end up with "best practices." By making our assumptions visible, we risk scaring off some readers... but I think that, by doing so, we make our advice a lot more valuable, and a lot more likely to succeed.