Agile and Iterative Development, by Craig Larman

A lot of people are looking for proof of the effectiveness of agile software development methods.  Managers are looking for hard facts and data with balanced discussion on the pros and cons of agile.  Developers are looking for supporting material to convince their managers to use agile.  Customers are wondering if agile methods really benefit them and why there are so many changes to the current way of doing things.

About the Book

Craig Larman, author of the critically acclaimed Applying UML and Patterns book, seeks to fill that void with Agile and Iterative Development.  It is primarily a manager’s guide, so developers familiar with the various agile methods covered won’t find anything new.  Larman first works on iterative and evolutionary development, covering the benefits of timeboxing and incremental delivery.  This is pretty basic stuff for most educated managers, but if someone has not had exposure to it in the past it is important to review.  Then Larman moves on to agile methods and classifies them based on ceremony, which is the required and/or suggested amount and type of documentation, and cycle time, which is the length of an iteration.

The most important section is the Evidence chapter.  There are statistics, example case studies, and thought leader commentary.  These facts cover a range of project size in developers and function points, time frames, agile methods, and technologies.  The evidence helps sell agile methods with a one-two combination punch of supporting agile methods and refuting common project management wisdom embodied in the form of waterfall processes.

Although the reviews of the agile methods may not shed any new light on the practices themselves, Larman does include an interesting section on how to fail with each method.  This very effectively emphasizes the common misconceptions that non-agile managers have.  He also shows which way the method gurus envision implementing it (new test project, crashing project, etc.), and analyzes some of the method's strengths and “other” qualities.  The book is capped off with a good section on implementation tips, practices, and a FAQ.

Bottom Line

If you are a developer and your manager does not see the value in agile methods, or does not want to implement them 100 percent, buy this book and give it to them.  If they do embrace agile, first thank your lucky stars and then thank your managers with this book.  If you want to be able to cite facts and statistics supporting agile, buy this book.  But do not, under any circumstance, buy it thinking you will get something out of it development-wise.  That is not what this book is for.