Agile methods are geared to managing uncertainty – uncertainty related to “ends” (customer objectives and features), and uncertainty related to “means” (technology and people). One way in which agile approaches deal with uncertainty is frequent re-planning based on progress to date and new information gathered during development iterations. The positive aspect of agile methods is that they encourage dealing with the uncertainty early in a project and focus on working software.
Unfortunately, these very aspects of agile methods can also have negative outcomes – sloppy planning, and reactive thinking. All agile projects combine aspects of anticipation (planning) and adaptation (revisions based on reflections). Too great an emphasis on adaptation (we can always fix or refactor it later) means that we don’t take advantage of information we already know (or should know with minimal effort). For example, spending a week at the beginning of a project identifying product capabilities and constructing a skeleton architecture may significantly improve delivery.
Second, while developing adapting skills are critical to agile methods, too much emphasis on adapting can cause excessive rework and time delays. A simple example would be ignoring a well-known design pattern and thinking that a series of programming and refactoring sessions will create the best solution. The agile mantra, “we have more confidence in our ability to adapt than our ability to predict the future,” can lead to short sightedness – a common theme of agile critics. This is a great mantra, it just has limits.
One aid in balancing anticipating and adapting is to expand our anticipation practices to include both planning (working with what we know), and scanning (looking ahead to learn the unknown as quickly as possible). Scanning can take several forms: identifying and mitigating risk, managing assumptions, and anticipating decisions. Scanning is basically about reducing uncertainty through the systematic, proactive, and early gathering of information or identifying the information that needs to be gathered at a future point.
When teams discover an unknown, say not knowing if a design will work or not, then they can perform short experiments on multiple options (spikes) to see if one or more of the options works to their satisfaction. In software development experiments may take the form of throw-away (potentially) code. Hardware developers may use prototypes.
Managing risks is another form of scanning. Since risks are defined as probabilities of something happening, they essentially identify potential problems. A risk that a key resource person has a 50% chance of being pulled off the project identifies a potential future information state – not having the person. The project team can try to mitigate the risk early or it can figure out potential future responses. This risk mitigation should stay simple, but a little thinking ahead can avoid harmful consequences.
Managing assumptions is a second type of scanning. While risks identify potential information states, assumptions define an information state that the project team will use until it is proven to be false. For example, the customer may not know early in the project whether the volume of web site hits will be 50,000 or 100,000 per day. In order to make some early skeleton architecture decisions the team will “assume” a level of 75,000. The team is assuming a piece of information in order to proceed. However, the team needs to constantly “scan” the list of assumptions and compare them to current information in order to alert the team when a key assumption may become invalid.
Finally, but not less importantly, teams need to maintain a list of key future decisions to be made. For example, a team may identify that in order for the project to continue on schedule, that a key architectural decisions must be made within 2 months. As each key decision is listed, the team can begin accumulating information related to the decision. It can also relate this to risks and assumptions.
Proactive scanning keeps teams from falling into the trap that “adaptation” (or refactoring) will solve any mistakes that are made. While adapting is indeed a major part of agile development, it shouldn’t be used as an excuse for sloppy planning. Good project managers know that waiting until something happens can have serious adverse consequences for a project. Combining good planning and scanning with an ability to adapt provides a powerful project management combination.
