James Shore

in 99 words

Agile development is popular, but that's no reason to use it. The real question: will agile development make your team more successful?

Success is usually defined as delivering on time, under budget, and as specified. That's a flawed definition. Many late projects are huge successes for their organizations, and many on-time projects don't deliver any value. Instead, think in terms of organizational, technical, and personal success.

Agile development is no silver bullet, but it is useful. Organizationally, agile delivers value and reduces costs; technically, it highlights excellence and minimal bugs; personally, many find it their preferred way to work.

as haiku

"Should we be agile?"
"Try these leeks," Sensei replies;
"We picked them today."

Inside This Chapter

Download this poster!

• Why Agile?
• Understanding Success
• Beyond Deadlines
• The Importance of Organizational Success
• Enter Agility
  • Organizational Success
  • Technical Success
  • Personal Success

Behind the Scenes

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, as authors, 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 this first chapter of the book. 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.