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 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.
For more information on this topic, see Succeeding with Agile: Software Development using Scrum.
Tags: agile release planning
“by planning to adapt as they arise.” I like! Very well put.
This kills the misconception that agile does not plan, only “make mistakes, and adjust”. We actively make the analysis whether the problem is better to solve now (BUF Plan/Req/Design/Code) or if we await data that gives more information before deciding – i e “plan to adapt”.
This reminds me a lot about the analogous misconception about TDD though of meaning “should not think ahead”, whereas it really is “do think a long way ahead, but realise only a little at a time”.
Great point Mike. This balance is very useful is prioritizing the project as well, and helps us focus on the right questions of what’s going to have the biggest impact now, or what’s going to make the most money now.
[...] Cohn wrote someting about this yesterday on his blog. There is obviously at least one proponent of agile – with a proven track record – who [...]
[...] Balancing Anticipation and Adaptation by Mike Cohn on Mike Cohn’s Blog – Succeeding With Agile® [...]
I like what Dave Snowden calls anticipatory awareness, and how he relates it to not just a product but perhaps a project or task or initiative
http://www.cognitive-edge.com/blogs/dave/2008/05/leadership_as_coherence.php
“Trying to design long term policy initiatives on the assumption that the future is fully knowable, a dangerous mistake. Modern approaches to decision making focus on creating multiple, low risk , low cost, parallel safe-fail experiments. Those that result in beneficial results are amplified, those that are negative are abandoned. The experiments reveal the evolutionary possibilities of the system and allow us to move from a doomed attempt at anticipation, to creating a state of anticipatory awareness”
More here
http://www.cognitive-edge.com/blogs/dave/2007/06/life_can_only_be_understood_ba.php
http://www.cognitive-edge.com/blogs/dave/2006/10/a_return_to_manege_rather_than.php