(Thanks to Jurgen Appelo for this guest post - © 2010 Jurgen Appelo)

The business unit I was leading some months ago was a fine example of a complex adaptive system trying to survive. As a young start-up business, our prime objective was to find paying customers. We anticipated in which places we could find them, and we adapted when it turned out they weren’t there. (Regrettably, the second often follows the first. For many startup businesses survival is a long process of learning what doesn’t work.) And sometimes we simply experimented, not knowing whether the results would be good or bad, only to learn what worked and what didn’t.

In most agile methods, this learning takes place in the form of increments and reflections, both of which are done iteratively. An increment is a new release of a product into its intended environment, and its main purpose is to invite feedback that enables learning, adaptation (looking backward) and exploration (trying things out), while reducing the need for anticipation (looking forward) to a manageable level. The released product influences the environment, and the environment then responds to it in some (possibly unexpected) ways. The knowledge gained is used to adapt, to anticipate what will be needed in the next release, or to continue exploring when we still don’t know.

Reflections (often called retrospectives) are used to understand whether or not the project itself is operating in the right way, and how to improve parts of it in order to be more successful. The last team I worked on delivered many increments of our tools, some of which were successful, and some of which failed miserably. And we had plenty of reflections on how we ran our business, some of which were rather painful, and some of which hurt like hell.

Increments and reflections are an example of double-loop learning, a concept proposed by business theorists Chris Argyris and Donald Schön. An often cited example of double-loop learning is the simple thermostat combined with a human operator (which I will repeat here, for lack of inspiration). The thermostat adjusts itself frequently based on the information about room temperatures that it gets from the environment (the first loop, using a model of the environment). But the thermostat is operated by a human being who modifies its settings based on her earlier experiences with comfortable temperatures and anticipated changes like holidays or weather forecasts (the second loop, refining the model of the environment) [

Figure 1 - Double-loop learning versus improvement

Though adaptation is often mentioned as a key component in agile software development, we shouldn’t forget the role of exploration and anticipation in our businesses. We not only need to solve problems. We also must try new things just to see what happens, and innovate by developing solutions to issues that we think will be important (in the next release, or shortly thereafter).

We expect uncertainty and manage for it through iterations, anticipation, and adaptation. (Declaration of Interdependence)

Doesn’t Anticipation Violate Agile?

Anticipation is like alcohol. It is healthy when used in a small dose. But it is addictive, and most people use far too much of it.

Agile software development does not reject anticipation. But it tries to reduce it to the smallest possible amount, where it is still beneficial instead of harmful.

In my former little startup business, we did plenty of adaptation, exploration, and anticipation. Frankly, I did so much double-loop learning with my team that my brain thought it was a roller coaster.

Are you adapting, exploring, and anticipating too?

This article is an adaptation from a text out of the book “Management 3.0: Leading Agile Developers, Developing Agile Leaders,” by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series, and will be available in book stores near the end of 2010.

http://management30.com

http://mikecohnsignatureseries.com

References

Augustine, Sanjiv. Managing Agile Projects. Upper Saddle River: Prentice Hall Professional Technical Reference, 2005.