Balancing Agility and Discipline: A Guide for the Perplexed

Barry Boehm, Richard Turner (2003)
Review date: November, 2009
Summary

Only six chapters are needed to make comparisons between agile and more plan-driven methods. The first two chapters are about introduction, definition and more "formal" comparisons between agile and non-agile methods. They outline the methods' characteristics and properties, and do a good job in emphasizing their differences and similarities.

In chapters three and four, real applications of both approaches are presented: a day of work using XP and TSP, and two case studies.

Chapter five is the authors' contribution to the field. This is where they show how to choose between agile and more rigorous development by performing a risk calculation. Several risk-areas are identified, and the approach is chosen depending on how a presumptive project would perform in those areas. Three main risk areas are identified and broken down into finer-grained risks:
Environmental risk: risks related to a project's general environment
  • Technology uncertainties
  • Many diverse stakeholders to coordinate
  • Complex system of systems
Agile risks
  • Scalability and criticality
  • Use of simple design or YAGNI
  • Personnel turnover or churn
  • Not enough people skilled in agile methods
Plan-driven risks
  • Rapid change
  • Need for rapid results
  • Emergent requirements
  • Not enough people skilled in plan-driven methods

Finally, in chapter six, a conclusion is presented, where the authors argue that none of the methods are silver bullets and that combinations of the methods will eventually emerge as winners.

Being an exception, this book contains read-worthy appendixes! Appendix A compares no less than 13 different development methods ranging from extremely agile to very rigorous. Each method is briefly described and categorized.

How much architecture is enough? The topic of appendix E is to answer this and similar questions. Here empirical studies of several projects are discussed and conclusions given about how much up front design is needed, based on actual studies performed by different researchers.

It's worth mentioning that this book has an impressive list of references to further reading. Very much above average, which is why this is mentioned in the first place.

Opinion

This is one of those books that I will be praising. Although it's written six years ago, it feels very up to date. Not all its predictions have come true, but that's not really relevant.

First of all, I need to give the authors credit for conciseness! Six chapters and 200 pages of actual reading. That's it. While reading, I felt that some sections could have been made shorter, but on the whole the authors demonstrate great skill in getting their message through cutting down no more trees than necessary. I also find the use of the appendixes very professional: their contents are relevant, but can be omitted if one wishes so. In fact, I'd say that the book's worth reading for the sake of appendix A alone. It's very nice to be handed a list of thirteen different development methods along with brief introductions.

I can also pick some gems:

In the very beginning, main concepts of agile and plan-driven methods are put in tables and described. While these things are far from unfamiliar to me, I liked having them presented in a compact manner.

The CRACK acronym was not familiar to me. Collaborative, Representative, Authorized, Committed and Knowledgeable - all properties of good customer representatives. This is very basic, but apparently I haven't read enough literature about agile methods to pick that one up. Shame.

Not only do I like memorable acronyms I also like metaphors, and the book points of the obvious differences between plan-driven and agile: plan-driven methods can be thought of as mimicking a production-line environment, while agile methods emphasize craftsmanship. This in itself is trivial, but for me it confirmed some earlier experiences. It's not often that developers working in plan-driven organizations refer to themselves as software craftsmen, and there exits people that want to order software products as if they come from an assembly line. This has nothing to do with the book; it's just some personal experience.

Of course, the main message of this book also provides some insights. Before introducing the risk calculations, the authors provide a simple model for characterizing the project as agile or plan-driven; a five axis diagram, where the following characteristics are plotted: Personnel, Dynamism, Culture, Size, and Criticality. Now, depending on the score in these dimensions, the project is best performed as agile or with a more formal method.

As far as I'm aware, the authors' risk-based calculation for picking the level of agility in a project, hasn't taken off (though I might be ignorant). However, the risks themselves are sound and worth remembering. This is in fact why I included them in the summary.

While making my pass through the text, I also found another phenomenon I could relate to strongly enough to include it here. In chapter four, there's a case study of a bigger project that could be made to scale by adding some plan-driven elements to an XP approach. Shortcomings that needed to be addressed by adding some formalism were classified as project smells (similar to Martin Fowler's code smells). The particular smell I chose to focus on was the discrepancy between done and done done. Even though the authors didn't use this terminology, they identified the need to make the process of delivering a piece of functionality more formal and plan-driven. I've had first hand experience of cases where a story card was finished (done) but couldn't be delivered because of unaddressed integration or testing issues. Chapter four contains other similar smells as well. Good reading.

A final gem is a graph based on empirical data from various software projects. This graph shows sweet spots at which a certain level of up front architecture/risk reduction is done plotted against project size.

Having discussed all my gems, there are two last things I want to comment on. First, the book often returns to the fact of tacit knowledge being a key driver and success factor of agile projects. Many XP practices aid in spreading and maintaining this knowledge. While this is trivially true, I've never thought of this in such terms. Just an insight. Second, the book keeps referring to Cockburn level 1-3 people over and over again. This is simply a skill classification, but it's seldom books keep emphasizing that a certain percentage of level x people will either make the project fail or succeed. While true, of course, it's worth keeping in mind.

Hmmm... I never intended to write that much about this book. Much of the above is better classified as "thoughts" and not "review", but I can live with it, since my ultimate purpose behind reading all books is to get the thinking going. As you see, this book has made me think about a thing or two, and I guess it would do that to the majority of readers. Combined with the fact that it's short, I really recommend it.

Who should read this book

If you're interested in getting an overview of many software development methods, or if you wonder what the fuss with agile and non-agile is all about, this book will come in handy. Hard core practitioners of either approach benefit from getting a nuanced picture presented by this book. Finally, those who want a framework for software project risk assessment may find something here.




News

  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.