Balancing Agility and Discipline: A Guide for the Perplexed

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.

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 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 conclude1. 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.