Condensed Cream of Agile

Explaining agile development concepts to managers can be a lost cause. Craig Larman's book can help your manager see the light.

• By Mike Gunderloy
• 03/09/2006

Agile methods of software development have been around for long enough now that pretty much every developer has heard of them. After all, the Agile Manifesto came out in 2001, and there are plenty of books out there to tell you about Extreme Programming or Scrum or other methodologies. Most of those books are aimed at those of us who write the code, but Craig Larman’s Agile & Iterative Development (Addison-Wesley, 2004) has a slightly different audience, as you can tell from its subtitle: “A Manager’s Guide.” If you’re trying to convince your manager that it’s time to go to a more flexible development style in your shop, a copy of this book for his inbox might be a worthwhile investment.

A Book for Busy People
One of the nice things about Larman’s book is that it's clearly written to be read by those who don’t have a lot of spare time. You won’t find a lot of fat here; instead, this is a book that can be dipped into by someone who needs to quickly understand what this agile stuff is all about. It opens with a pair of chapters explaining what iterative and agile methods are all about, and then tells the story of a typical agile project -- not one using any of the “name-brand” methodologies, but one that mixes and matches practices to meet sensible goals. From there, you’ll find two chapters that help make the case for iterative development: one of motivations that points out problems with the waterfall model and key benefits of iterative methods, and one of hard evidence that iterative and agile methods just plain work better (including some research that shows that the waterfall method was on shaky ground to begin with). Larman goes on to summarize, in executive overview style, four of the leading agile methodologies (Scrum, XP, UP, and the lesser-known Evo), and closes with excellent chapters on tips and FAQs.

The book is also big on aids to reading within the text -- it looks like the design team was influenced by Web design, and in a good way. Sections and paragraphs are mercifully short, and there are plenty of bulleted and numbered lists. Diagrams are used to good effect in many places, and the margins are used for cross-references to other pages and to Web sites (sort of “printed hyperlinks”). Combine all this with a good index and table of contents, and you have a book where it’s easy to find the information you need without needing to re-read entire chapters.

The Methodological Core
The heart of the book is the section on the four agile and iterative methodologies that Larman presents in some detail. These sections will probably not make you enough of an expert to go forth and implement one of these methodologies in your own workplace, but they will give you enough of an overview to decide whether you want to pursue a particular line of attack (and there’s a good bibliography to take you further). More importantly, they organize the essential information about each agile methodology exceedingly well. In each of these chapters, you’ll find sections on:

• Overview
• Introduction
• Lifecycle
• Workproducts, Roles, and Practices
• Values
• Common Mistakes and Misunderstandings
• Sample Projects
• Process Mixtures
• Adoption Strategies
• Fact versus Fantasy
• Strengths versus “Other”
• History
• Recommended Reading

Several of these sections are exceptionally valuable. The common mistakes and “Facts versus Fantasy” section will help you sort out shops that are really following one of these practices from those that have just grabbed on to a few practices and slapped a label on them. The “Sample Projects” section gives some real-world success stories (sure to please any manager), while the “Adoption Strategies” section is useful in injecting new process into an existing organization. I also appreciate the mixtures section -- Larman shows how you can pick and choose pieces from among the four methodologies he evaluates without hurting yourself (and also brings out where there are essential conflicts between them). With many managers looking for things that work rather than a full revolutionary package, this is a sensible approach./p>

Reevaluating the Waterfall
One of the most interesting parts of the book is the discussion of the waterfall model. As with some other agile books, Agile & Iterative Development makes a business case that agile development may pay off very well indeed compared to waterfall development (some back of the envelope calculations give a 200 percent IRR for $100,000 invested in iterative skills development by a medium-sized company). But Larman goes beyond this to look at some of the historical reasons for the widespread adoption of the waterfall methodology, with its big design up-front and cascading series of deliverables in a single pass. He ends up with a somewhat surprising conclusion: To a large extent, it was all a big mistake!

It seems that the most widely cited article for the waterfall is a 1970 study by Winston Royce, “Managing the Development of Large Software Systems” -- and if you actually go back and read that article, Royce recommends an iterative approach with at least two passes through analysis, design, and development. Royce’s son confirms that his father was a proponent of iterative methodologies, and that the waterfall was just a caricature that was only applicable to the simplest cases.

But then the military got hold of it, in the form of the DOD-STD-2167 standard, which mandated the waterfall approach for military software (and which went on to be the basis of other standards around the world). The author of this early-1980s standard simply wasn’t familiar with iterative development, and by the time the Department of Defense endorsed iterative development in 1987, the damage was done. Now we’re all fighting against an accepted body of knowledge that turns out to be based on misreadings, wishful thinking, and not much else.

Be a Change Agent
If you’ve been itching to try out some agile and iterative techniques on your next project, but you haven’t figured out how to get them into your job, this book could be the perfect wedge. It makes a case in terms that managers can understand, without diluting the technical content at all, and it’s full of clear advice if you're ready to take action. If your boss is leaning towards trying something new but just doesn’t know how to get started, a copy of Agile & Iterative Development will be just the push to tip them over.