Customer Reviews

Balancing Agility and Discipline: A Guide for the Perplexed

5 star:		(6)
4 star:		(7)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

Balancing Agility and Discipline focuses on saying out loud what people in the trenches have been thinking all along. There's still no silver bullet -- we need a well balanced tool bag instead of a multipurpose hi-tech hammer.

The authors start the journey by describing the fundamental differences between traditional, plan-driven approaches and the latest agile methods. This is a great introduction and paves the way for the discussion to follow. However, occasionally the text uses the term "agile process" too loosely when really talking about the extreme characteristics of XP.

Next, Boehm and Turner set out to describe a typical day in the life of two teams; one agile and the other not so. However, these stories didn't quite reach the level of detail I was expecting.

The authors continue by presenting two case studies of projects where a plan-driven method was streamlined using agile techniques and an agile method was scaled up with some plan-driven elements. The subject is of great interest and the authors' approach is definitely valid.

A decision tool for customizing an appropriate mix of agile and plan-driven ingredients is explained. The tool itself is largely based on Boehm's earlier work and focuses on risk management. The authors illustrate the mechanics of the tool by presenting a family of applications of varying levels of stability and complexity. The rationale behind the thought process for composing the optimal method is valid and built on well-known truths.

The last third of the book is populated by numerous appendices. The first appendix introduces some popular agile and plan-driven processes and maturity models in the form of two-page summaries and comparison tables. The summaries serve as useful reminders but nothing more. The rest of the appendices, however, provide a short but valuable collection of tools for balancing the software development process and some empirical data on the costs and benefits of agility.

In summary, I would classify Balancing Agility and Discipline as a suggested reading for both agilists and sceptics. It's not necessarily a classic but it certainly serves as a useful reminder of things the industry has learnt the hard way and shouldn't be taken too lightly. Agile methods promote retrospectives. Boehm and Turner suggest extending that retrospective a bit farther.

This book addresses a critical and current discussion on how to balance agility and planned methods. Not only does it discuss project characteristics that identify the homeground of an individual project, but it also identifies agile practices that can be introduced into a traditional planned project, and discusses the use of planned techniques that may be needed to scale up large or critical agile projects. This is very useful material - and most certainly addresses current industry needs.

As an Asst. Professor of Software Engineering I have recently noticed a trend amongst the organizations in which my graduate students work. Several of these organizations that have historically employed traditional "waterfall" style lifecycle models are now experimenting with pilot projects that employ agile methods. They are not however deploying cookie cutter agile methods, but are selecting those agile practices that meet their own needs. My students explained that early prototype projects had indicated that applying agile processes resulted in better defect removal early in the projects.

Boehm and Turner's book addresses exactly these issues, and shows that agile and planned methods can be applied synergistically. Equally importantly the book reports on the small yet growing body of empirical results that support certain agile claims and challenge others. This provides the reader with critical information for determining which agile practices they may wish to deploy.

This book clearly reflects the years of experience both authors have had in industry and academia. As the creator of the spiral lifecycle model and the well known cost estimation model COCOMO, Boehm has a track record of correctly measuring the pulse of the industry and providing insights that have had a lasting impact. Once again, Boehm has written a book that I believe has identified a critical market trend and can provide invaluable insights for organizations seeking to find just the right balance within their own software development projects.

Excellent book that discusses plan driven vs agile development methods.
The authors conclude

1. No silver bullet.
2. One approach is better than the other depending on the project characteristics.
3. Future trends are toward 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. People, communication and expectations management are more important than methodologies.

Probably the best description I've read of what make a process agile -- iterative, incremental, self-organizing, and emergence. The authors also have excellent appendices which give informative thumb nail sketches on the different agile methods. Two other features of the book I really appreciated -- margin summaries and well documented endnotes. The plan driven discussion focuses on PSP. Here, I would have preferred more discussion on traditional project management.(eg. PMBOK, CPM scheduling). Overall, very informative.

This book succeeds brilliantly in two areas, but comes up a bit short in the third.

First, as far as distilling how plan-driven and agile-driven development methodologies are different (and the same), it is wonderful. They use five "critical factors" to determine a project's relative suitability for choosing one type over the other. I believe about 40% of the book is spent here.

Second, using the above information, the authors discuss how to ascertain and mitigate project risks, given the size and type of the application being developed, as well as the cultural (agile v. plan-driven) leanings of the development staff who will be working on it. This is mostly done at a "process framework" level. The premise of the book is that each project is somewhat different, so rightly they do not prescribe a process. I believe another 40% of the book is spent here.

Third, the book presents a number of charts showing how much impact plan-driven and agile-driven processes have had. Here I just feel like Boehm lent the book a bunch of his data. Although it is very useful data, it isn't detailed enough. It could have used an additional Appendix describing another project (there are three case studies already) more concretely. Especially in terms of the schedule, defect reduction rate, etc. metrics that are in one of the appendixes.

Overall, I highly recommend this book.

Agility and discipline are not absolutes, but should be dosed out appropriately based on your project. The risk-management approach explained in this book is familiar to most business management folks, and provides a framework for making the right decision. This is a great way to cater a methodology to your project.

There were some "day in the life of" sections in this book that felt like fake stories -- it was almost like reading a DeMarco novel. Entertaining, but not entirely convincing. Also, contrary to Lean approaches, this risk management framework doesn't seem to lend itself to self-tuning as the project moves along (unless I missed something). There's a lot to be said for measuring how effective you're being and reacting to changes in your environment and product. The idea of doing all of your risk assessment up-front and choosing your methodology for the life of the project sounds exactly like the kind of thing that any "Agilist" would claim is not going to work!

Great text. I really enjoyed reading this book by Boehm and Turner. Especially enjoyable was reading Grady Booch's comment in his forward that "there's a delightful irony in the fact that the very book you are holding in your hands has an agile pair of authors yet requires three times as many forewards as you'd find in any normal book". The material of this text is centered around the dimentions affecting method selection that the authors provide as the five critical factors involved in determining the relative suitability of agile or plan-driven methods in specific project situations. In most situations, the authors indicate that some mix of these methods will be needed after risk assessments are performed for each of the five factors. The radar plots provided that depict different levels of these five factors for example projects aid in understanding how projects differ. What is unfortunate is that the metrics for each of these factors (personnel, dynamism, culture, size, and criticality) are not explained well. Size, the number of personnel working on any given project, is the only concrete metric. However, I think the reader needs to understand that determining the level of each of the other four factors is really not meant to be exact. In fact, the presentation by the authors of various projects, although sometimes a bit detailed for the subject matter, help in the understanding that these metrics are relative. For example, unless personality tests are administered to all project personnel, it can be quite difficult to determine the level of Culture (the percent who thrive on chaos versus order), but guestimating an approximate level for this factor is probably good enough to get a sense whether agile or plan-driven methodologies are more appropriate. Of the first few chapters of the text, I think the first two chapters that provide a background to the balancing agility and discipline problem are the most effective, followed by the chapter six summary chapter that lists the top conclusions of the discussion. The appendixes to this book, which comprise almost one-third of the text, are also very informative. Thirteen software development methodologies are presented side-by-side in Appendix A to enable the ability to compare each, although admittedly some of the methodologies are covered more extensively than others. And in Appendix E, some interesting industry statistics are presented from various studies, including a discussion on how much architecting is enough for a particular project, although there is some overlap with the well-written, thorough, recently-released text by McConnell called "Software Estimation: Demystifying the Black Art" (see my review). Overall, this book fits a gap on the software development bookshelf, and I am sure that other works of this genre will be released by other authors over the next couple years, as writing on this subject matter is still in its infancy.

Sometimes we want to have things to be black and white, but working at extremes has shown to be the failure path.
That is why IT systems have buffers, project plans have slacks, and mathematical models are most precise when they are fuzzy.
That is why we are most happy with systems where form follows function and the interface follows the user. In the same way Barry displays ways to pick an appropriate method for each project making clear that there is no single solution, but that all models aim at advantages and disadvantages.

Ask a plummer:
- picking the right tool will help to finish the task in the quickest and most reliable manner.

Ask a Karateka or a boxer:
- if you are well-balanced you are unlikely to fall over and happy to sustain hits.

Barry makes sense of it all for IT projects, lists existing knowledge and in my view his book is building the foundation of acceptance for agile methodologies and combining them with proper methods for documentation and project management with a focus on preemptive risk management.

He favors to approach projects by looking at the risks and how to overcome them thus solving the biggest problem in IT projects: "taking a risk-driven approach is a pragmatic means of reconciling the strengths and weaknesses of disciplined and agile methods." (Boehm, B. and Turner, R. (2004), p. xiv)

I was perplexed, by the clarity and and combinations of the principles listed in this book, which is indeed very well balanced and applicable.

This book was written in 2004 by Barry Boehm and Richard Turner, but the fact that it is already on its 6th reprint tells something about its value. This is a very pragmatic book that tries to put in perspective agile and plan-driven software development approaches. By the way, the funny thing is that the word "waterfall" is rarely mentioned in the book. This may be due to its negative connotation and also to the fact that Barry Boehm favors a spiral approach. The book has also adopted a clever structure with a first "quick-read" part of 150 pages that provide the core of the material and then 100 pages of appendixes to treat some parts more specifically.

After a comparison of agile and plan-driven approaches, the book illustrates its vision of these two processes by presenting two project case studies. It offers also a risk-based approach for making methodology decisions that integrate agile and plan-driven practices. Even the book is not recent, it has the advantage of confronting agile and plan-driven approaches in a relatively objective way. Therefore, it is a very recommended reading for people that want to improve their software development process without wanting necessarily to be a "purist" of a particular approach. It is also a book where people that have already made their choice will be able to consider the "other" software development process with a different view and also gain a better insight on their own strengths and weaknesses.

I don't think most people understand how hard it is to product a book like this. People are happy to sell their methodology, and promote their views and experiences, but it's all anecdotal. This book is a dig for hard facts. I hope it's updated regularly with newer data.

One reviewer asked for more of a practitioner approach. Wow, what a waste that would have been. This book is geared to looking at the outputs of what practitioners are doing. To actually present a methodology would have been bizarre.

Dry and academic? Not for me. I so desperately wanted some bloody facts to counter all the hype, I would have been angry at anything but a measured, fact-focused book.

It's a shame that academics are more tightly integrated with practice. At least our fads would be fact based.

I like the pragmatic tone of the book, its structure, "day in the life" pictures, case studies, and conclusions. Yet the authors indulge some Agile misconceptions and their case is riddled with straw man argumentation.

Right from the start they set up a false dichotomy between agility and discipline, as if Agile is not a discipline or not disciplined--the authors define discipline as "process mastery, preparation, and courage." Agile done right is all this. And who hasn't seen undisciplined "discipline" (process-heavy approaches is what the authors intend here).

The key to success, they argue, is balancing agility and discipline--what Agilist wouldn't agree?--by using their "risk-driven approach" as a "pragmatic means of reconciling the strengths and weaknesses of disciplined and agile methods." This requires assessing project personnel, criticality, size, culture, and dynamism to customize an agile-discipline hybrid that minimizes risks.

Most Agilists I know are pragmatists, not purists, and do, in fact, use hybrids as needed. The "risk-driven approach" advocated here is a helpful way to quantify the risks and work towards a hybrid. But one caution: "Balancing agile and plan-driven methods requires exceptional people." Agreed, and the authors admit that because you need, and therefore find, more exceptional people in an Agile environment, you're more likely to find success by scaling Agile up than by paring plan-driven methods down.

Other helpful points of clarification for "the perplexed:"

- Agile is an "adaptive rather than predictive mind set."
- "Agile is `planning driven,' rather than `plan-driven.'"
- Agile defines quality as customer satisfaction vs. "specification and process compliance."
- Agile's rapid growth and adoption is due to today's dynamic business environment and to "the resurgence of the philosophy that programming is a craft rather than an industrial process"
- "Personnel turnover is a project's number one risk."

Examples of straw man argumentation:

- "The approaches have become adversarial." I've seen some healthy debate but most practitioners are looking for common ground.
- "The primary difference between agile and plan-driven development practices deal with the design and architecture of the software. Agile methods advocate simple design, one that emerges as functionality is implemented." The authors spill a lot of ink demonstrating that simple may not be sufficient. Yet just a few pages earlier they point out: "Agilists speak of a `mentality of sufficiency'--doing only what is necessary." "Simple," then, actually means "sufficient" to the experienced Agilist.
- The authors point out that Agile refactoring risks turning into costly redesign. And a plan-driven approach, where quality is defined as compliance to outdated specs and rework is common, improves on this how? Later they admit that Agile done right looks at each user story in context of the big picture.
- They complain that getting all the stories done and integrated--particularly "tasks that fall between story cards"--often requires "police" action that "conflicts with agile philosophies." What they call "police" action I call "management" action and, yes, I admit it is often required.

All in all, this book is recommended as it adds to the conversation and moves it in the right direction: whatever works! We've got too much work to do for infighting.