Agile Fundamentals: The Feedback Loop

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

When you improve a little each day, eventually big things occur. — John Wooden

photo credit: mister b 1138

A few weeks ago I had a discussion with some colleagues on the adoption of Agile within large corporations. The consensus was that Agile was almost always adapted rather than adopted — that is, companies exclude those practices that conflict with corporate culture, modify those that seem too impractical or wasteful, and sometimes substitute those internal practices that seem a decent and familiar substitute.

Various schools of Agile thought have different reactions to this adaptation, all negative. The XP folks particularly don’t like it.

These [thirteen] practices support one another…and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.

I agree that it definitely helps to follow a particular Agile approach closely in the beginning. Once you have the basics down, you can start to improvise. But it helps to know the fundamental principle which, in my opinion, underlies all of the agile practices, no matter what the flavor. So, the first three commandments of Agile software development are:

1. Feedback loop
2. Feedback loop
3. Feedback loop

Pair programming is about the feedback between two developers that improves code and design quality. Test driven development is about designing testable software that then provides you with feedback when you change the system. Iterative development is about getting feedback from incremental releases of your software. Iteration retrospectives are quite obviously about garnering feedback about how the team and process worked or didn’t work.

Whenever something isn’t working in your project, try to identify the source of the problem and design a feedback loop to monitor and adjust that source. But be careful. Not all of the feedback is about the same thing. Iterations and releasing software early and often is feedback intended to improve the software product, while iteration retrospectives are intended to improve the development process. They both are about continuous, gradual improvement. However, these aren’t band-aids or crutches, they are not about fixing something temporarily, but about making it better for the long haul.

Sometimes, the problem isn’t the absence of a feedback loop but the fact that it is too long or too arduous. When something doesn’t work, you want to know about it now, not in a week. You want it to fail fast. That’s why we have short meetings, or scrums at the beginning of every day and why we try to release software every 1 or 2 weeks. Also, the feedback has to be dead simple to get, which is why we automate as much of it as possible. Continuous integration is a good example of this.

Armed with this understanding of the feedback loop, you can now safely adjust an agile process to fit your corporate culture. Feedback has to be quick and automated if it is to be successful. So, if your primary product user travels internationally much of the time, you need to shorten that feedback loop, perhaps by recruiting a proxy user that our international traveler trusts. On the other hand, substituting your company standard practice weekly status meetings for a daily scrum is an example of substituting longer and more arduous feedback. Nobody wants to sit through a 2-hour status meeting once a week, so the practice degrades over time. Five to ten minute daily scrums, on the other hand, are as easy as they are useful.

It sometimes takes a little experience and noodling to figure out what exactly you are trying to improve. You’re seeing a high bug rate and lots of build breakages. What is the cause? Perhaps a pair of developers is checking in the code every week instead of several times throughout the day. It is breaking the changes of some other developers. The solution might be to put in an automated system in your continuous integration server that warns the team if a particular developer hasn’t checked anything in a while or if they have checked in a huge number of files.

Getting the entire team to be agile feedback detectives is really the way to go. Pride of ownership and self-interest — a good process means no software death marches — will go a long way toward engaging everyone in process improvement.

I’d love to hear from you about whether you agree that the feedback loop is the core principle of agile, and also any stories — funny, uplifting or sad — about adapting agile in a corporate environment.