James Shore

in 99 words

Any big change is a challenge. When adopting XP, expect the first few months to be chaotic, and a little painful, as everyone gets up to speed. Give yourself four to nine months to feel truly comfortable with your new process.

If you can, adopt XP all at once. This works best when you have a brand-new codebase. It's the easiest way to learn.

When applying XP to an existing project, take an incremental approach. Start by introducing the structural practices. Follow up with the technical practices, paying down technical debt and chipping away at your bug backlog.

as haiku

freshly turned soil--
fertile, waiting, it smells like
possibility

Inside This Section

• Go!
• Sidebar: Extreme Shopping
• The Challenge of Change
• Final Preparation
• Sidebar: Second Adopter Syndrome
• Applying XP o a Brand-New Project (Recommended)
• Applying XP to an Existing Project
  • The big decision
  • Bring order to chaos
  • Pay down technical debt
  • Organize your backlog
  • Fix important bugs
  • Move testers forward
  • Emerge from the darkness
• Applying XP in Phase-Based Organizations
  • Mandatory planning phase
  • Mandatory analysis phase
  • Mandatory design phase
  • Mandatory coding phase
  • Mandatory testing phase
  • Mandatory deployment phase
• Extremities: Applying Bits and Pieces of XP
  • Iterations
  • Retrospectives
  • Ten-minute build
  • Continuous integration
  • Test-driven development
  • Other practices

Commentary

Brian Marick is right. Joy, Ease, (Self-)Discipline, and Skill are the missing elements of the Agile Manifesto.

In the early days, the joke was, "XP is like teenage sex. Everybody's talking about it... but nobody's doing it." There weren't a lot of people using XP or agile development, but the ones who were got really fired up about it. They were seeing big successes, getting very excited, and making nuisances of themselves by telling everybody they met how great it was.

Now, I see a lot more people using agile methods, but the excitement--what Brian Marick calls "Joy"--isn't there any more.

I think that's because the term "agile" is so vague. Anybody can pay lip service to the manifesto and claim to be agile. People are adopting the title without actually changing their work habits. Maybe they're tossing on a layer of monthly or biweekly planning, daily meetings, and calling it "Scrum." (It's not.)

I'd like to see more rigor in people's practice of agile development. If you're going to use Scrum, don't just give it lip-service... take it seriously! Make a real commitment to a Sprint Goal, really give the team authority over its work, really hold the team accountable for delivering on the goal at the end of the Sprint. Similarly, if you're going to use XP, really use pair programming for everything, really form a cross-functional team, and really get everybody into the same room.

I might be fighting against human nature here. Every message gets diluted as it spreads. Gerald Weinberg calls this "The Law of Raspberry Jam: the broader you spread it, the thinner it gets." So perhaps it's the fate of agile development to become diluted and wishy-washy.

I hope not, though. If you really want to be successful with agile--if you want to experience Joy at work--you have to make real changes. Those changes will probably be painful. It's worth it. Join us.