There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.

So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.

The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.

I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. As Kelly Anderson puts it,

The core of any successful human endeavor is timely and accurate feedback. Human beings learn from feedback. Some may argue that it is the ONLY way humans learn. If you believe the neural networks folks, it’s ALL feedback.

I have some minor quibbles with that statement, though I fundamentally agree. Sometimes we get lucky and hit the target without feedback. As Kelly later says, “Give a trained marksman a good rifle, and he can hit the target with the first shot.” This is an example of a good first guess.

Also, I don’t think the importance of feedback is restricted to human endeavors. Control systems work by comparing the actual with the desired, and using some portion of the resulting error measurement as an input to the system to reduce that particular error in the future. Amplifier design controls the gain by the same method, feeding some of the output back to the input. In both of these cases, there is an inversion of the signal being fed back, hence the technical term “negative feedback.” That’s the mathematical “negative,” not a value judgment. In Jerry Weinberg’s Quality Software Management: Systems Thinking and Peter Senge’s The Fifth Discipline: The Art & Practice of The Learning Organization, the authors show how this feedback is essential in managing and learning. This is true even with self-organizing teams. Feedback is the basic means of steering, so that we correct as we go rather than just close our eyes and head in the direction we initially chose.

So, if feedback is important to the practice of Agile, but is used in all controlled processes and isn’t solely the domain of Agile, what makes Agile, Agile? As Jeff McKenna stated years ago,

Why, it is the taking of small steps.

If feedback is applied frequently (or continuously), a control system will track the desired output much more closely, with smaller errors and, therefore, smaller corrections. If you’re driving a car and adjust the steering wheel only every 10 feet, your path will be rather jerky compared to that if you adjust the steering wheel every foot. Of course, it’ll still be much better than if you would adjust every 100 feet. Working in smaller increments allows you to adjust to minor perturbations before they become major ones.

Feedback also needs to be timely. Delays in feedback cause control systems to become unstable. They cause amplifiers to become oscillators–howling out of control like Jimi Hendrix’ guitar. If you adjusted the steering wheel every foot, but based on the input you received 10 feet ago, you’ll weave down the road like a drunk driver. (In fact, delayed reaction time is exactly why drunk drivers weave down the road.) Ten feet ago, you might have been on the right side of the lane, so you decide to adjust the wheel to the left. If you’re now on the left side of the lane, that “correction” is exactly the wrong thing to do, increasing the error rather than reducing it. It’s inevitable that your adjustments become larger and larger until you run off the road.

Kelly also points out that “Inaccurate feedback is also destructive.” Destructive might not always be the right word. In an amplifier, for example, if the amount of feedback is different for different frequencies, the amplifier becomes a filter. That may be what’s desired, or it may not. You could, for example, ignore the end-user feedback about the aesthetics of your software, but pay attention to feedback about the functionality. That would arguably produce a better functioning product, if not a pretty one. As function is, perhaps, a more objectively measured attribute than aesthetics, this might be a good trade-off. Or, it might not.

Agile chooses, as a desired goal, working software that meets the Customer’s needs. Note that, for practical reasons, this Customer role (Product Owner, in Scrum), is a proxy for all the stakeholders who desire the creation of the software. If the person(s) filling this role make “bad” choices that don’t represent those stakeholders, that would illustrate the destructive “bad feedback” that Kelly mentions. Suppose that Customer desires elaborate design documents rather than software? Or measures lines of code produced rather than useful functionality? If you think about this, you can see where the XP testing practices promote working software that meets customer needs rather than the predictable outputs of such misguided measures. The feedback must be aligned with our real goals.

Feedback that is only produced by the completion of the desired software, though, would be neither timely nor frequent. Don Wells has an excellent graphic of feedback loops that operate on different time scales. Good pair programming gives us feedback from our pair about many aspects of our programming. Unit tests give us feedback that our code does what we think it does. There is feedback at all levels of software development. Then, also, retrospectives give us feedback on our software development process. The feedback must be pervasive.

What about the other XP values? Ultimately, I think they all resolve to feedback, too. Communication is how feedback happens. Simplicity makes feedback more frequent, and also enhances the communication. Courage allows communication, and hence feedback, to happen even in difficult situations. Respect allow communications to happen between people; without respect there is little communication even if there are lots of words.

So, what is Agile? I think it is the use of feedback that is

• frequent
• timely
• aligned with our desired goals
• pervasive

All the rest either supports this feedback, or is window-dressing.