Much as we might like numbers and rational arguments, we humans are emotional and illogical creatures. Especially when it comes to making decisions that affect our lives... and few things affect our lives as much as the way we choose to do our work. After all, we spend more than a third of our waking hours at work.
Maybe that's why the question of adopting agile development can be so emotional for people. To make matters worse, there are no good statistics about the effectiveness of various methods, agile or otherwise. I've never seen a one that had any weight to it. There are just too many variables--the quality of the people, the type of work being done, the language and tools used, the work environment... not to mention that we don't really know how to measure productivity, which makes comparing methods rather difficult.
So: an emotional response to the idea of agile development, combined with a lack of objective data, positive or negative, about its value. How can we, writing in The Art of Agile Development, convice somebody to use agile development? Should we even try?
When I talk about agile development in person, this process is much easier. First, I don't try to convince anybody to adopt agility. Instead, I listen and ask questions. People invariably focus on the points that concern them the most. That gives me a chance to ask them questions about their fears (although they're rarely described as "fears"). Often, I'll gently correct misunderstandings. Sometimes I describe how a complementary practice helps resolve the problem they're concerned about. And quite often, as when people talk about the difficulties of distributed agile development, I'll admit that a problem is difficult with no easy answer.
Above all, though, I listen. I can't convince anybody to do anything. But people are quite good at convincing themselves to do stuff if you let them talk through their fears.
In a way, that's what we're trying to accomplish in the first chapter of The Art of Agile Development. It's titled "Why Agile," but that's not really what we're talking about. Maybe it should have been titled "Why Not?". In the absence of objective data--and I wonder if there will ever be such a thing--the only way to tell if agile development is a good idea for a particular team is to try it.*
*That's not entirely true. From experience, I know that some teams will have an easier time than others. But I can't prove it. This wasn't the right chapter for a nuanced discussion of what makes our approach to agililty easy or hard. We put that discussion in chapter four.
So that's what we did. This chapter is really an invitation for the reader to set aside her fears and give agile development a try. We make no promises about whether or not it will work. (In fact, we start out by saying that agile development isn't a silver bullet.) Instead, we provide a framework for evaluating success and we provide some ways that agile development has helped other teams. Then we let it go. Our readers have to make their own decisions about why they want to adopt agile development. We can't do it for them.