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 teams avoid this “bogging down” by realizing that not all
future needs are worth worrying about today. Many future needs may be
best handled by planning to adapt as they arise.