Balancing Anticipation and Adaptation

A big part of an organization’s becoming agile is finding the appropriate balance between anticipation and adaptation, as Jim Highsmith wrote in Agile Software Development Ecosystems. The following figure shows this balance along with activities and artifacts that influence the balance.

When doing up-front analysis or design, we are attempting to anticipate users’ needs. Because we cannot perfectly anticipate these, we will make some mistakes; some work will need to be redone. When we forgo analysis and design and jump immediately into coding and testing with no forethought at all, we are trying to adapt to users’ needs. All projects of interest will be positioned somewhere between anticipation and adaptation based on their own unique characteristics; no application will be all the way to either extreme. A life-critical, medical safety application may be far to the anticipation side. A three-person startup company building a website of information on kayak racing may be far toward the side of adaptation. Foretelling the agile preference for simplicity, in 1990, was speaker and author Do-While Jones.

I’m not against planning for the future. Some thought should be given to future expansion of capability. But when the entire design process gets bogged down in an attempt to satisfy future requirements that may never materialize, then it is time to stop and see if there isn’t a simpler way to solve the immediate problem.

Agile project management approaches avoid this “bogging down” by realizing that, while some anticipation is necessary, not all future needs are worth worrying about today. Many future needs may be best handled by planning to adapt as they arise. For more information on this topic, see Succeeding with Agile: Software Development using Scrum.