Book Review: Balancing Agility and Discipline

Recently I finished reading Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm and Richard Turner. It's the first book I've read that attempts to find a logical middle ground among all the hollering from Agile Zealots, CMM Traditionalists, and the Process Atheists. It's aimed at those interested in their development team, whether developer, task leader, or manager, and describes some of the pros and cons of Agile methods (such as XP and Scrum) and more traditional "Discipline" methods (such as RUP and TSP/PSP). Additionally, the book takes a reasonable stab at how to roll our own process.

Is it useful? Yes, but under certain caveats.

McProcess: Prepared for Convenience

The project must be willing to accept that growing their own process will be measurably better than using a "prepackaged" process. In my experience, this is not the case. Most of the time, people want the packaged solutions: all the rules and procedures are defined, it is easy to see how much of the process is really being used, and they are easy to talk about (they have a name . Like a box dinner, organizations just want to stick a process in and go. In contrast, preparing their own process implies work - deciding on individual rules and procedures, trying to determine how much can and should be used, probably getting input from all levels in the organization. There's not even a name to attach to the process.

Employee Diet

The project must have available people experiences in many different processes, and be able to judge how this or that practice will be taken by the engineers who will use them. This will help decide how much training is required to implement various practices. For example, if we want to start using pair programming, but no one in our company has ever done it, we may have to devote real resources into getting that practice started and accepted. It will be much worse if we have engineers who are experiences in pair programming, but hate it.


Chapter breakdown

Chapter 1 introduces the problem domain: software is hard, people don't understand how to make it. Disciplined methods, ala waterfall, originally proposed to solve problems by taking techniques from classic engineering. Unfortunately, that didn't work. Agile methods, developed in response to "failings" in Disciplined methods, took a less regimented approach to development, but, alas, also failed to make everyone happy. Clearly, there must be another way.

Chapter 2 gets into the mud a little and talks specifics. Both Agile methods and Disciplined methods have a "Home Ground", or characteristics that help the process succeed. These characteristics include personnel counts and skills, requirements stability, development culture, and ultimate project failure costs (lives, money, comforts).

Chapter 3 describes normal and "crisis" days for both Agile and Disciplined methods, from arrival to departure of the development and management teams. We get to see some of the style of interactions between team members for both types of methods.

Chapter 4 takes case studies for Agile and Disciplined processes. It points out where the processes failed and how these failures might be handled.

Chapter 5 proposes a method to roll our own process. Examining the risk of using one approach versus the risk of not using it can be very informative. We can rate our projects on the "Home Ground" scales and see whether they call solidly into Agile or Disciplined methods, and take steps accordingly. Most importantly, the book acknowledges we can pick and choose what pieces work for us. We can build a process from other processes, custom tailored for our project.

Finally, chapter 6 summarizes the book. Neither Agile methods nor Disciplined methods will magically solve problems; developers and management still has to use some thought to decide what process styles they should adopt. It seems to be better to make our own process from process pieces rather than take a process and trim it down.

Obey your Thirst

Ultimately, I think this technique best benefits the rare project that is interested in improving their process, but has noticed that nothing really seems to be working. The book itself has much broader range of use - any project team just getting underway will find a set of considerations in the portions of the book about "home ground", and it is certainly refreshing to read about process, agility, and iterative development without any resorting to fat-jokes.