It’s stabilizing feedback that keeps a simple amplifier working as an amplifier, rather than pegging the output at the maximum positive or negative voltage. The feedback mechanism observes the output and applies a small correction to the input to counteract overreactions. Because the feedback is swift, only a small correction is needed. In fact, if the feedback were delayed, the output would tend to swing back and forth, oscillating around the desired value.

In iterative software development, we use feedback to keep the project on task. Feedback from our unit tests lets us know if our code does what we intend. Feedback from our acceptance tests lets us know if our code does what the Customer wants. What could possibly go wrong?

“The feedback they use is information about the product, not information about the process in general. An effective manager needs to know much more information, much earlier, than the product alone can provide. A more general focus to improve software quality and productivity is on the process, as taught by Deming and others…. An ideal improvement program combines this focus with the idea of small improvements to achieve successful change with a minimum of instability. As we’ll see later, this approach can also be carried out at the cultural level, above the level of particular processes, let alone the product level. Wherever we look, people are discovering that the same control model is needed at all levels; and with it, they are acquiring the ability to think and observe in terms of nonlinear effects and then to act in concordance with those observations and thoughts.”

from Quality Software Management: Systems Thinking by Gerald M. Weinberg

What can go wrong is that, while we’re trying to produce the software with feedback, we may be trying to execute the process of producing software without similar feedback. Hence various posts by Rachel Davies, David Christiansen, and even Steve Yegge. The adoption of Agile Software Development has reached the point where people are adopting it as a prescriptive methodology. This is what Jerry Weinberg terms a Pattern 2 or Routine development culture, “We follow our routines (except when we panic).” This is like driving with your eyes closed, and Agile practices will perhaps fail faster than heavyweight methodologies because it doesn’t have the heavy paper flywheel to slow things down.

To be effective with Agile development (or to be generally successful with any software development methodology), you need to get to the point where you’re looking at how well that methodology is working for you, and make adjustments as needed. In other words, you need to reach a Pattern 3, or Steering development culture, “We choose among our routines by the results they produce.”

How do you make that transition from a culture that follows a recipe to one that steers to a goal? Well, one excellent suggestion is to read Quality Software Management: Systems Thinking. Another is to have frequent retrospectives and talk about the issues.

updated 3/29/2021 to point a couple dead links to archive.org