- Paperback: 300 pages
- Publisher: Addison-Wesley/Pearson Education; 01 edition (11 Aug. 2003)
- Language: English
- ISBN-10: 0321186125
- ISBN-13: 978-0321186126
- Product Dimensions: 17.8 x 1.8 x 23.4 cm
- Average Customer Review: 4.0 out of 5 stars See all reviews (4 customer reviews)
Amazon Bestsellers Rank:
965,110 in Books (See Top 100 in Books)
- #1589 in Books > Computers & Internet > Computer Science > Programming > Software Design, Testing & Engineering > Software Architecture
- #1613 in Books > Computers & Internet > Computer Science > Programming > Software Design, Testing & Engineering > Functional Programming
- #2586 in Books > Computers & Internet > Software & Graphics > Software Design & Development
- See Complete Table of Contents
Balancing Agility and Discipline: A Guide for the Perplexed Paperback – 11 Aug 2003
|New from||Used from|
- Choose from over 13,000 locations across the UK
- Prime members get unlimited deliveries at no additional cost
- Find your preferred location and add it to your address book
- Dispatch to this address when you check out
Customers who bought this item also bought
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
If you are a seller for this product, would you like to suggest updates through seller support?
From the Back Cover"Being a certified bibliophile and a professional geek, I have more shelf space devoted to books on software methods than any reasonable human should possess. Balancing Agility and Discipline has a prominent place in that section of my library, because it has helped me sort through the noise and smoke of the current method wars."--From the Foreword by Grady Booch"This is an outstanding book on an emotionally complicated topic. I applaud the authors for the care with which they have handled the subject."--From the Foreword by Alistair Cockburn"The authors have done a commendable job of identifying five critical factors--personnel, criticality, size, culture, and dynamism--for creating the right balance of flexibility and structure. Their thoughtful analysis will help developers who must sort through the agile-disciplined debate, giving them guidance to create the right mix for their projects."--From the Foreword by Arthur Pyster
Agility and discipline: These apparently opposite attributes are, in fact, complementary values in software development. Plan-driven developers must also be agile; nimble developers must also be disciplined. The key to success is finding the right balance between the two, which will vary from project to project according to the circumstances and risks involved. Developers, pulled toward opposite ends by impassioned arguments, ultimately must learn how to give each value its due in their particular situations.
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.
About the Author
Barry Boehm has been trying to balance agility and discipline in software development since 1955. The TRW professor of software engineering and director of the USC Center for Software Engineering, he earlier served as director of the DARPA Information Science and Technology Office and as a chief scientist at TRW. Dr. Boehm's contributions to the field include the Constructive Cost Model (COCOMO), the Spiral Model of the software process, the Theory W (win-win) approach to software management and requirements determination, and his classic book, Software Engineering Economics (Prentice Hall, 1981).
Richard Turner, a research professor in engineering management and systems engineering at the George Washington University, approaches balanced software development and acquisition with broad industry and government experience and a skeptical attitude toward best practices. In support of the U.S. Department of Defense, he is responsible for identifying and transitioning new software technology into the development and acquisition of complex, software-intensive defense systems. Dr. Turner was on the original author team for Capability Maturity Model Integration (CMMI) and is coauthor off CMMI Distilled, Second Edition (Addison-Wesley, 2004).
Top Customer Reviews
After providing useful contrasts and similarities between agile- and plan-driven approaches, the authors summarise the following as key factors in the decision as to which approach to use in a particular project. These factors are:
- Size. Agile approaches discriminate towards small products and teams. Large products and teams will favour a plan-driven approach.
- Criticality - in the sense that failure of the system under design causes loss of life and/or large monetary loss. Projects of high criticality will favour a plan-driven approach.
- Personnel. Generally speaking, agile approaches require workers that are more highly skilled than plan-driven ones. The rationale is that in the latter, the development process is more highly proscribed and hence easier to learn.
- Dynamism. This factor relates to the stability of the project environment; where the business environment is highly dynamic and system requirements are rapidly changing, then agile-driven approach is favoured. In highly-stable environments, the additional overhead of putting in place the infrastructure to deal with rapid change may not be necessary.Read more ›
For developers of large, critical and Software Intensive Systems-of-Systems (SISoS), ignore these gentlemen at your peril!
Most Helpful Customer Reviews on Amazon.com (beta) (May include reviews from Early Reviewer Rewards Program)
Sadly, my experience has been that most who claim to be using Agile are simply making it up as they go, the poor results are soon to follow.
The refreshing part of this book is that it objectively gives the reader the pros and cons of Agile and more formal development process, then not only gives a framework for picking the right tool for the job, but guides in the appropriate blending of specifics to meet the demands of your particular type of project uncertainty.
If your mind is already made up, skip this book.
If you are trying to make reasoned decisions based on compelling logic, this one is worth the read.
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.
The material of this text is centered around the dimensions 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 of 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.
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.
Look for similar items by category
- Books > Computing & Internet > Digital Lifestyle > Online Shopping > Amazon
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Functional Programming
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Software Architecture
- Books > Science & Nature > Engineering & Technology > Production, Manufacturing & Operational