James Shore

in 99 words

There is no "agile method." "Agile" is a marketing term created to describe a style of working. This style focuses on collaborative work, concrete results, delivering value, and minimizing waste.

"Being agile" means working in the agile style. To do so, start with an existing agile method, use it to understand the principles and practices of agile development, then adapt it to your specific situation.

This book follows that pattern. We describe one method in detail, then discuss principles and adaptation. To use this book, follow the practices carefully, note where they work and where they don't, and adapt.

as haiku

Carefully I plant.
Seeds follow rules, but Sensei
dancing, ignores them

Download this poster!

Inside This Chapter

• How to Be Agile
• Agile Methods
• Don't Make Your Own Method
• The Road to Mastery
• Find a Mentor

Behind the Scenes

I expect that our decision to focus the book on learning XP, then modifying it, will be a source of criticism. Most books on agile development try to be agnostic and inclusive, giving equal time to practices from all of the major agile methods. In contrast, we're specific and exclusive.

This may seem rather antisocial, but I think it's one of our biggest strengths. As Shane and I were writing the book, we kept telling ourselves, "this is an opinionated book." We decided that when there were multiple ways of meeting some agile need, we would pick just one way of approaching the situation. We figured there was more value in being simple and straightforward.

I'd like to say that there were times when we really struggled to choose a practice. It'd be the politically correct thing to say. But, actually, it wasn't hard at all. In my consulting work, I see teams face the same struggles over and over again. Picking practices was more of a brain dump than a research project.

That's not to say that our approach is perfect. "Best practices" are a myth. The reality is, "practices that work well under a specific set of circumstances." The practices that work well for colocated teams don't necessarily work for distributed teams, and the practices required for distributed teams are often wasteful for colocated teams. One thing I really like about our book is that we face this reality: we spend a lot of time talking about the context of our approach, and when our "one way" isn't appropriate or needs to be changed.

Ultimately, the right method for your team is customized to the needs of your team. The question is, how do you get there? While assembling a method from a menu of practices has a natural appeal, I think it's easy to get wrong. The practices have interdependencies and make hidden assumptions. That's why we suggest starting with an existing method and customizing it.

Being opinionated and antisocial is just a bonus.