Barry Boehm and Richard Turner have produced an important and balanced book about agile versus plan-driven methods. Unfortunate title, perhaps, and a few things to disagree with, but highly recommended.

image

Balancing Agility and Discipline: A Guide for the Perplexed.

Barry Boehm, Richard Turner

The senior author’s name alone is enough to ensure that this book will be read by people we would like to influence. Fortunately Boehm and Turner have done a rather decent job of describing agile methods, plan-driven methods, how they work, where they are applicable, and how they can play together. There are things to question and perhaps disagree with, and there is much to agree with.

The authors make clear at the beginning and throughout the book that successful development, whether agile or plan-driven, requires discipline. They chose, I believe unfortunately, to use the word discipline in the title instead of plan-driven, the term used in the bulk of the book.

A Few Disagreements

I believe that the authors make a bit too much of the need for good people on an agile project. They hold that an agile project cannot sustain people of Alistair Cockburn’s “Level -1” and that plan-driven projects can. And they hold that an agile project needs Level 2 or 3 people throughout, while a plan-driven project needs them only at the beginning. I’m not convinced that this is quite true. Or, it might be a matter of project size.

Boehm and Turner draw some conclusions from Amr Elssamadisy and Gregory Schalliol’s paper on “bad smells” in Extreme Programming, taking at face value some of Amr and Gregory’s conclusions about what was needed to shore up the areas where their project had problems. I acknowledge the problems, but believe that I would have tried some more agile solutions rather than falling back, as Amr and Gregory recommend, on more plan-driven approaches. On the other hand, they were there, and I was not.

The authors say, referring to Amr and Gregory’s paper:

In this case, the "customers" were one step removed from the actual end users. They compounded their limitations by doing less homework on the real needs in the early iterations, perhaps because they thought their other customer functions were more important. Putting blind trust in "the customer is always right" adage can be risky if the customer doesn't fully understand and appreciate the end users' needs. A good deal of early coaching is needed to get on-site customers to appreciate and perform the role of end-user representatives. Otherwise, the on-site customers can become examples of the point in Chapter 2 about the main source of tension in agile methods being between collocated and non-collated customers.

While this is true, the authors seem to conclude that a plan-driven fix would be appropriate to the situation. However, any such fix would imply a very different staffing and budgeting approach to the project. It might well be more effective and less costly to improve the ability of those in the customer role to perform it well.

I feel that in a number of places in the book, the authors fall into the common trap of “it can be done this way, therefore it should be done this way”, even though they rightly warn us all that this is a trap. When it comes down to it, our biases and expectations rule us all in ways we don’t always expect.

One more example, still referring to the same paper:

A second smell illustrates one of the likely side effects of fixed schedules and diseconomies of scale: "Everyone says that all the story cards were finished at the proper times, but it still takes 12 more weeks of full-time development effort to deliver a quality application to the customer." This is related to the previous smell, in that there is a large gray area called "integration" in large systems between zero-defect story completion and acceptable system delivery. And there are other gray areas between "zero defects" and "zero defects plus documentation and standards compliance".
The recommended solution [from Amr and Gregory] was to "Create a precise list of tasks that must be completed before the story is considered finished, and then police it regularly and honestly." This conflicts with agile philosophies such as "Managers in organizations either have a fundamental trust of people or they don't -- there is no middle ground," and "Trust people, mistrust communication" (where "communication" presumably includes plans and standards.) It illustrates the tension between the agile ideal of small teams, where there's always enough time for everybody to talk through gray areas, and large-project practice, where this would just consume too much time, implying more efficient, objective approaches are needed.

Again, we all see that the problem occurred. However, there might be more “agile” solutions to try, such as improving automated tests for system integration. Certainly no one should object to having a task checklist, but might object to “policing” the list. It seems to me that the mantra of any team ought to be “Trust, but verify”, in spite of recent use of the phrase in a political arena we may find odious.

Many Agreements

Overall, the book is quite well-balanced, and makes points that we should all wish to make so clearly and well. Under the heading of “Future Applications Will Need Both Agility and Discipline”, we find:

Large projects can no longer count on low rates of changes, and their extensive process and product plans will become expensive sources of rework and delay. As the use of agile methods progresses from individual early-adopter projects to enterprise-coupled mainstream applications, the Brooksian software development werewolves of complexity and conformity will be waiting for them. Thus there will be a higher premium on having methods available that combine agility and discipline in situation-tailorable ways.

In aid of this, the authors offer six conclusions, of which the above is one. The full six are:

  1. Neither agile nor plan-driven methods provide a silver bullet.
  2. Agile and plan-driven methods have home grounds where one clearly dominates the other.
  3. Future trends are toward application developments that need both agility and discipline.
  4. Some balanced methods are emerging.
  5. It is better to build your method up than to tailor it down.
  6. Methods are important, but potential silver bullets are more likely to be found in areas dealing with people, values, communication, and expectations management.

A Good Book, Worth Your Time

This one is a keeper. While it is hard for a hard-core XPer like me to completely agree, the ideas are well thought out and well supported.

Get it.