Planning and Scanning: Keys to Agile Project Management

[BA Forum Moderator]

Opinion by Jim Highsmith, Cutter Consortium

FEBRUARY 11, 2005 (CUTTER CONSORTIUM) - Agile software development and
project management (ASDPM) is geared toward managing uncertainty --
uncertainty related to "ends" (customer objectives and requirements)
and uncertainty related to "means" (technology and people).

One way in which ASDPM deals with uncertainty is frequent replanning
based on progress to date and new information gathered during
development iterations. Project teams deal with information they know
(certainty) and information they don't know (uncertainty). The positive
aspect of agile methods is that they encourage dealing with the
uncertainty early in a project and focus on working software or
products rather than documentation to ensure that the information
gathered is very realistic.

Unfortunately, these very aspects of ASDPM can also have potential
negative outcomes -- sloppy planning and reactive thinking. All agile
projects combine aspects of anticipation (early 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 should already know (or should
know with minimal effort). For example, spending a week at the
beginning of a project defining customer requirements and constructing
a skeleton data model may significantly improve the quality of a plan
and the speed of development.

Second, while developing adapting skills is 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
would 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 shortsightedness -- a common theme of agile
critics.

One solution to this potential problem of placing too much emphasis on
adapting over anticipating is to expand our practices to include both
planning (working with what we know) and scanning (looking ahead to
learn the unknown as quickly as possible). This is actually my
definition of anticipation -- planning and scanning.

Scanning can take several forms: experimenting and managing risks,
assumptions and 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 whether a design
will work -- 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 could take the form
of throw-away code. In hardware, development experiments may take the
form of engineering breadboards or simulations.

Managing risks is another form of scanning. Since risks are defined as
probabilities of something happening, they essentially identify
potential information states. A risk that a key resource person has a
50% chance of being pulled off the project identifies a potential
information state: not having the person in the future. The project
team can try to mitigate the risk early or it can prepare responses.
These are all alternative project plans.

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's proved 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 with 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
decisions to be made. For example, a team may identify that in order
for the project to continue on schedule, the key architectural
decisions must be made within four 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. In the
previous example of assuming Web-hit rates, the team could identify
this as a key assumption that needed to be validated one month prior to
making the final architectural decisions.

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 terrible
consequences for a project. Combining good planning and scanning with
an ability to adapt when necessary provides a powerful project
management combination.