Balancing agility and discipline

What Hacker News says

1. chazuJul 2021
   I suggest Accelerate, Balancing Agility and Discipline, The Phoenix Project and the OG Continuous Delivery book by Jez Humble and David Farley.
   thread
2. blubOct 2018
   Happy to see people questioning agile. There are two books which the skeptics might find interesting:

   * Agile, the good bad and ugly by Bertrand Meyer

   * Balancing agility and discipline by Boehm

   thread
3. BadassFractalJan 2012
   I feel you got it backwards. The whole idea behind agile is to treat programming as a craft and to focus on the people, as opposed to treating development as a production line.

   Some good readings on the subject: Extreme Programming Explained, Agile Software Development Ecosystems, Balancing Agility and Discipline.

   thread
4. SloopJonJul 2021
   I don't recall encountering this specific 100x claim, but I do recall Steve McConnell making a similar case early in Code Complete. In chapter three, he has a chart showing that the average cost of fixing defects post-release is 10-100 more expensive than during requirements, which he supports with the following citations:

   "Design and Code Inspections to Reduce Errors in Program Development" (Fagan 1976)

   Software Defect Removal (Dunn 1984)

   "Software Process Improvement at Hughes Aircraft" (Humphrey, Snyder, and Willis 1991)

   "Calculating the Return on Investment from More Effective Requirements Management" (Leffingwell 1997)

   "Hughes Aircraft's Widespread Deployment of a Continuously Improving Software Process" (Willis et al. 1998)

   "An Economic Release Decision Model: Insights into Software Project Management" (Grady 1999)

   "What We Have Learned About Fighting Defects" (Shull et al. 2002)

   Balancing Agility and Discipline: A Guide for the Perplexed (Boehm and Turner 2004)

   I only have one of these (Dunn), and it's boxed up in the attic, so I can't readily check their sources, but I somehow doubt that all of these simply launder the study under discussion.

   I don't want to trivialize some of the good points that Hillel Wayne makes about soft-science research applied to software productivity, but he would have us dismiss all of these citations out of hand, simply because they predate capital-A Agile, which of course changes everything. That doesn't strike me as a particularly compelling approach either.

   Show morethread
5. mixmastamykJul 2016
   Table and Figure 3.1 in Code Complete support the conclusion and is well cited:

   Source: Adapted from “Design and Code Inspections to Reduce Errors in Program Development” (Fagan 1976), Software Defect Removal (Dunn 1984), “Software Process Improvement at Hughes Aircraft” (Humphrey, Snyder, and Willis 1991), “Calculating the Return on Investment from More Effective Requirements Management” (Leffingwell 1997), “Hughes Aircraft’s Widespread Deployment of a Continuously Improving Software Process” (Willis et al. 1998), “An Economic Release Decision Model: Insights into Software Project Management” (Grady 1999), “What We Have Learned About Fighting Defects” (Shull et al. 2002), and Balancing Agility and Discipline: A Guide for the Perplexed (Boehm and Turner 2004).

   Joel on Software also has a convincing narrative on the subject. Therefore I'm not in a big hurry to replace the image, though I will put it on my todo-list.

   Show morethread
6. BadassFractalJan 2012
   It really depends on the kind of project you're working on. Some modern Agile authorities (see Balancing Agility and Discipline: A Guide for the Perplexed) will tell you that you should tailor the process to your specific requirements. They would never recommend that you use XP for the development of life-critical software that has hundreds of engineers working on it.

   Agile is born from rapid prototyping and makes a lot of sense for that environment. If you're doing work where one day you might be developing one thing, and the next day you might be working on a completely different product altogether, then reducing the cost of change is the only thing that makes sense. If you're not, then don't use pure agile, it doesn't make that much sense.

   There's obviously an issue with one size fits all approaches to agile, and as agile matures people realize that more and more, instead of forcing you to do everything by the book. The point is, as you get more and more experience with driving software projects, you need to be smart enough to understand what will make sense and what won't.

   Show morethread