What do you think?
Rate this book
Balancing Agility and Discipline: A Guide for the Perplexed
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.
Hardcover
First published August 1, 2003
14 people are currently reading
238 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 12 of 12 reviews
September 4, 2024
For a technical book that’s over 20 years old — even in the face of 20 years of advancement in software development processes — this book was high-level enough to still be relevant. Every day I deal with the consequences of people who are over-committed to doing things their favorite way in complete defiance of practical evidence. This book advocates neither Agile nor plan-driven methodologies over and above the other. The best software developers are adaptable to any methodology. The core thesis of this book is that Any Methodology Works When It Is Adapted To Its Needs. The sheer reality is that Agile, plan-driven, and hybrid methodologies have all produced both resounding successes and catastrophic failures. What environmental factors contribute to that, so we can pick our methodology responsibly?
I found this book while working my way through the bibliography of the SWEBOK. I’d say there’s a very good reason it counts Balancing Agility and Discipline as a central reference for the whole field of software engineering.
I found this book while working my way through the bibliography of the SWEBOK. I’d say there’s a very good reason it counts Balancing Agility and Discipline as a central reference for the whole field of software engineering.
November 9, 2024
As of 2024, this twenty year old book still has some sound common sense things to say about when agile software development methodologies work, when they can fail, and when and where it makes sense to add some heavier processes to the development as a whole or to parts of the product being developed.
Ostensibly the authors compare agile software development approaches like XP, Scrum, Lean and Crystal to plan-driven (their term) more heavyweight approaches like RUP and TSP/PSP and try to characterize the critical success factors for the deployment each kind of approach and when these factors suggest a hybrid approach is better suited to a particular software development project. The characterization is based on careful if somewhat subjective risk assessment, as set forth in a tentative and simplified form of Boehm's work on COCOMO II.
The first chapter (Discipline, Agility, and Perplexity) quickly reviews the basis for each approach, acknowledges the need for agility to deal with uncertainty in a growin number of developmen and puts to rest a misconception about discipline – mainly that the only disciplined approaches are heavyweight approaches with their emphasis on lots of upfront analysis and masses of documentation. As the authors point out, developer discipline is key to many agile approaches -which explains why they prefer to term the two approaches agile and plan-driven.
The second chapter (Contrasts and home grounds) describes the application (primary product goals, size, environment), management (customer relations, planning and control, project communication), technical (for requirements elicitation, development, and testing), and personnel (customers, developers, culture) characteristics for each approach, and some common misconceptions about them. The characteristics are boiled down to five contrasting critical success factors which are then mapped onto five axes of a Kiviat diagram to make it easier to identify whether a particular software development project is better suited to one or the other approach or whether the project does not fall quite so easily into one of the two approaches.
Chapter three (A day in the life) provides a better intuitive feel for the use and shortcomings of both approaches by using two representative excerpts from development cases, one using PSP/TSP, the other using XP (eXtreme Programming).
The fourth chapter (Expanding the home grounds: Two case studies) provides two good examples of what happens when the development is not cleanly suited to one approach or the other. It is a key chapter.
The following chapter (Using risk to balance agility and discipline) is an attempt to show how key risk analysis of development projects can be used to show where and how to step outside a purely agile or a purely plan driven approach. It is a key chapter which, at a distance, looks quite promising but which becomes blurry when looked at more closely, what appear to be crisp characterizations become suspiciously crisp and dissolve into subjective intuitions dressed up as objective measures. The authors describe a “family”of three agent-based systems -incidentally, the word “family”is misleading and the three examples do not correspond to a software product line or family. The three examples are set up so that one is best suited to an agile approach, another to a (mainly) plan-driven approach and the third, and largest to a hybrid. However the largest product is so large and complex that quite frankly it looks like an overambitious project destinied for failure – personally, I need a lot more convincing that the project is feasible than the breezy overoptimistic “analysis” provided by the authors. In spite of all this, the authors make their point -some projects require a hybrid approach and it is worth looking at how this can be accomplished.
A short chapter Conclusions, which adds some thoughts on the organizational dimension of hybrid agile and plan-driven approaches to the book's conclusions, ends the book.
Five very different appendices are untidily stuffed into the book. Appendix A compares thumbnail two page sketches of 13 agile or plan-driven methods. These sketches are not very helpful if you know next to nothing about the methods. Appendix B redundantly provides the Manifesto for Agile Software Development -it is also quoted in extenso in the body of the book, while appendix C provides a four page, and for the reader who relatively new to it, an opaque overview of Capability Maturity Models (CMMs). Appendix D, unhelpfully titled Tools for Balancing presents three sections, one proposing “anchor point”milestones for the spiral software development model, another on John Thorp's interesting update to cost-benefits analysis, the Benefits Realization Approach,
In short this is a nicely written, tantalizing book on an important subject that requires more work.
Ostensibly the authors compare agile software development approaches like XP, Scrum, Lean and Crystal to plan-driven (their term) more heavyweight approaches like RUP and TSP/PSP and try to characterize the critical success factors for the deployment each kind of approach and when these factors suggest a hybrid approach is better suited to a particular software development project. The characterization is based on careful if somewhat subjective risk assessment, as set forth in a tentative and simplified form of Boehm's work on COCOMO II.
The first chapter (Discipline, Agility, and Perplexity) quickly reviews the basis for each approach, acknowledges the need for agility to deal with uncertainty in a growin number of developmen and puts to rest a misconception about discipline – mainly that the only disciplined approaches are heavyweight approaches with their emphasis on lots of upfront analysis and masses of documentation. As the authors point out, developer discipline is key to many agile approaches -which explains why they prefer to term the two approaches agile and plan-driven.
The second chapter (Contrasts and home grounds) describes the application (primary product goals, size, environment), management (customer relations, planning and control, project communication), technical (for requirements elicitation, development, and testing), and personnel (customers, developers, culture) characteristics for each approach, and some common misconceptions about them. The characteristics are boiled down to five contrasting critical success factors which are then mapped onto five axes of a Kiviat diagram to make it easier to identify whether a particular software development project is better suited to one or the other approach or whether the project does not fall quite so easily into one of the two approaches.
Chapter three (A day in the life) provides a better intuitive feel for the use and shortcomings of both approaches by using two representative excerpts from development cases, one using PSP/TSP, the other using XP (eXtreme Programming).
The fourth chapter (Expanding the home grounds: Two case studies) provides two good examples of what happens when the development is not cleanly suited to one approach or the other. It is a key chapter.
The following chapter (Using risk to balance agility and discipline) is an attempt to show how key risk analysis of development projects can be used to show where and how to step outside a purely agile or a purely plan driven approach. It is a key chapter which, at a distance, looks quite promising but which becomes blurry when looked at more closely, what appear to be crisp characterizations become suspiciously crisp and dissolve into subjective intuitions dressed up as objective measures. The authors describe a “family”of three agent-based systems -incidentally, the word “family”is misleading and the three examples do not correspond to a software product line or family. The three examples are set up so that one is best suited to an agile approach, another to a (mainly) plan-driven approach and the third, and largest to a hybrid. However the largest product is so large and complex that quite frankly it looks like an overambitious project destinied for failure – personally, I need a lot more convincing that the project is feasible than the breezy overoptimistic “analysis” provided by the authors. In spite of all this, the authors make their point -some projects require a hybrid approach and it is worth looking at how this can be accomplished.
A short chapter Conclusions, which adds some thoughts on the organizational dimension of hybrid agile and plan-driven approaches to the book's conclusions, ends the book.
Five very different appendices are untidily stuffed into the book. Appendix A compares thumbnail two page sketches of 13 agile or plan-driven methods. These sketches are not very helpful if you know next to nothing about the methods. Appendix B redundantly provides the Manifesto for Agile Software Development -it is also quoted in extenso in the body of the book, while appendix C provides a four page, and for the reader who relatively new to it, an opaque overview of Capability Maturity Models (CMMs). Appendix D, unhelpfully titled Tools for Balancing presents three sections, one proposing “anchor point”milestones for the spiral software development model, another on John Thorp's interesting update to cost-benefits analysis, the Benefits Realization Approach,
....for determining and coordinating the other initiatives besides software and IT system development that are needed in order for the organization to realize the potential IT system benefits, which helps system engineers and business analysts make explicit “chains” of business and operating assumptions and expected business outcomes for a software system or, in general, an IT systtem, once it is implemented – a fascinating proposal that points to gaps in current agile and plan-driven approaches. Appendix D's third section is another unclear overview, this time to the Schedule as Independent Variable (SAIV) process model which I recommend readers to skip. Appendix E, Empirical Information, is mainly about some pertinent software development data on plan-driven software development, and to a lesser degree agile development captured for Boehm's COCOMO II software economics model.
In short this is a nicely written, tantalizing book on an important subject that requires more work.
March 14, 2011
Het boek beschrijft eerst de inhoud van Agile methoden en hun onderliggende principes en aannames en plan-driven methodes zoals CMMI. Vaak staan deze aanpakken (of in ieder geval hun supporters) lijnrecht tegenover elkaar. Deze schrijvers doen dat niet. Ze nemen veel karikaturen weg die ontstaan zijn door halfbakken implementaties van òf Agile (de beroemde Scrumbut's) òf CMMI (de beruchte mindless bureaucracies). Vervolgens wordt aanbevolgen om iedere situatie te analyseren op 4 aspecten: Applicatie, Management, Techniek en Personeel. Op vasis daarvan ontstaat een inzicht in de projectrisico's. En die bieden dan de basis voor een gefundeerde keuze tussen Agile en CMMI of om er een combinatie van te maken.
Alles bij elkaar dus een zeer nuttig boek.
Alles bij elkaar dus een zeer nuttig boek.
August 20, 2013
Quite cool, nice comparison between traditional and agile.
May 3, 2015
Good analysis about the balance between agility and discipline. But, it doesn't provide a clear-cut path to decision-making.
November 23, 2020
Oh well - actually this book wasn't what I expected at all. So you can say I am even more perplexed after reading it, than I've been before.
Here we have more a comparison of management techniques for projects, then for any help regarding the real title of the book. Still, it was interesting to read about reasoning when to choose this or that and what agile approach means for bigger companies and about the constraints on people.
Actually I've never heard about the Cockburn Scale before, so I probably have to dig a bit further into it.
Here we have more a comparison of management techniques for projects, then for any help regarding the real title of the book. Still, it was interesting to read about reasoning when to choose this or that and what agile approach means for bigger companies and about the constraints on people.
Actually I've never heard about the Cockburn Scale before, so I probably have to dig a bit further into it.
previously-read-owned
December 6, 2022Draft Copy provided a USC CSE Conference, Mar 2003
August 19, 2020
I had high hopes for this book but ultimately, I felt it fell flat. It contracts Agility and Discipline when nothing could be further from the truth. The real contrast should have been Agility vs Planning. It is ironic that the our software development methodologies for 30 years (or more!) were based on a planning model resembling soviet 5 year plans than an effective model for incremental change. If you're trying to understand why waterfal failed, this isn't the book to show you. Read Extreme Programming by Kent Beck to really understand Agile methods.
December 12, 2008
Finally, a book which puts all that agile and waterfall stuff into perspective.
To all you self-righteous evangelists: do your customers a favor and read this first...
Check out Tim Korson at qualsys-solutions.
I appreciated his lecture - with a similar, nuanced message as in the book - at ICSPI 2006.
To all you self-righteous evangelists: do your customers a favor and read this first...
Check out Tim Korson at qualsys-solutions.
I appreciated his lecture - with a similar, nuanced message as in the book - at ICSPI 2006.
June 8, 2011
The appendix was the most valuable section of the book.
There were many bewildering charts that added little to my understanding, but it was an excellent introduction to the various software development methodologies and how they can be applied to different organizations and problems.
There were many bewildering charts that added little to my understanding, but it was an excellent introduction to the various software development methodologies and how they can be applied to different organizations and problems.
Read
February 4, 2013Great book in understanding the spectrum of agile and disciplined projects (in my world, FAA-certified software/hardware). It presents the pros & cons of both approaches with respect to project size, schedule, complexity, etc.
Displaying 1 - 12 of 12 reviews