Balancing Agility and Discipline: A Guide for the Perplexed
A software developer and systems engineer join forces, using examples and case studies to illustrate the differences and similarities between agile and plan-driven methods, showing that the best development strategies combine both attributes. -Book News, Inc.
Balancing Agility and Discipline sweeps aside the rhetoric, drills down to the operational core concepts, and presents a constructive approach to defining a balanced software development strategy. The authors expose the bureaucracy and stagnation that mark discipline without agility, and liken agility without discipline to unbridled and fruitless enthusiasm. Using a day in the life of two development teams and ground-breaking case studies, they illustrate the differences and similarities between agile and plan-driven methods, and show that the best development strategies have ways to combine both attributes. Their analysis is both objective and grounded, leading finally to clear and practical guidance for all software professionals--showing how to locate the sweet spot on the agility-discipline continuum for any given project.
Review By:
12/22/2004What is the best process for your software development project? A debate is going on in the software development arena: the traditionalists swear by the well-defined processes of the plan-driven methods or discipline while the agile method supporters believe in using lightweight processes and short, iterative cycles to develop software in the rapidly changing nature of the Internet-based economy. Boehm and Turner's book, "Balancing Agility and Discipline: A Guide for the Perplexed," wades through the debate for those who are unsure of which process best supports their development processes.
The presentation and organization of the book is beneficial for someone who is "perplexed" by the specifics of the software methods. First, the authors compare and contrast the agile and plan-driven approaches. Next, the reader is given some insight into the kinds of projects that would be benefited best by each method -– what the authors refer to as the method's "home ground." The authors then build upon that foundation by giving an example of how both a typical and a not-so-typical day would be spent using each approach. Case studies in the book clearly show how projects using the agility methods and those using plan-driven methods have severe disadvantages that can affect the success of a project. The reality is that there probably are projects that won't fit perfectly into the home ground of either method. The solution –- each methodology can be altered and combined. The case studies exemplify projects that successfully integrated both approaches. But, then the question arises -– how do you determine the best way to combine the two methods so that there is a balance? The authors' response is a five-step risk-based methodology that integrates agile and plan-driven processes into a hybrid method fitting a project's unique situation. This five-step methodology is applied to three software projects to clearly show how risk affects the balance.
This book is not geared toward QA and Testing (testing is briefly mentioned). But if you're a QA professional that desires a better understanding of the different methods, the controversy existing between the two methods, and how the development field is evolving, then this book would definitely be well worth the read. The book is geared more toward project managers and developers who need to understand whether or not agile methods can be used for their particular projects.
Because of the organization of the book, it's actually a very quick and easy read. The authors include fast track summaries in the margins of each page that displays the key concepts. The main text of the book provides the basic information; the technical information supporting the main text is relegated to the appendices. I think Boehm and Turner also do a great job of objectively presenting the information.
The only part of the book I wished the authors had expanded more on was the representative examples. They didn't seem to be realistic examples, but even so, valuable information can be extracted from them and applied to specific projects.
I highly recommend this book to anyone who wants an objective view of the agile-versus-discipline debate to get a sense of what would best work for a specific project. The answer may not be one or the other, but a balance of the two may be the road for your project's success.