The Art of Agile Development

Chapter 1. Why Agile?

Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on.^[2] I know of one company that has already changed its name to Agili-something in order to ride the bandwagon. (They called me in to pitch their “agile process,” which, upon further inspection, was nothing more than outsourced offshore development, done in a different country than usual.) I fully expect the big consulting companies to start offering Certified Agile Processes and Certified Agile Consultants—for astronomical fees, of course—any day now.

Please don’t get sucked into that mess.

In 1986, [Brooks] famously predicted that there were no silver bullets: that by 1996, no single technology or management technique would offer a tenfold increase in productivity, reliability, or simplicity. None did.

Agile development isn’t a silver bullet, either.

In fact, I don’t recommend adopting agile development solely to increase productivity. Its benefits—even the ability to release software more frequently—come from working differently, not from working faster. Although anecdotal evidence indicates that agile teams have above-average productivity,^[†] that shouldn’t be your primary motivation. Your team will need time to learn agile development. While they learn—and it will take a quarter or two—they’ll go slower, not faster. In addition, emphasizing productivity might encourage your team to take shortcuts and to be less rigorous in their work, which ...