Statistics vs. Heuristics.
A
quite number of project leaders trust software development is a statistically
controllable process; others may not. Their subsequent strategies are
incompatible. This is one of the places where friction arises between agile and
plan-driven project leaders.
Individuals and Interactions vs.
Processes and Tools.
Some
leaders believe that with the right process, they can become immune to the
turnover of key people. Others believe that no process can offer that immunity;
the heart of good software development will always reside in the individual
people on the project. As with the
statistical approach, we are more likely to find process-centric leaders
running plan-driven projects, and individual centric leaders running agile
projects.
Responding to Change vs. Following
a Plan.
It
is a fundamental difference between the two project types whether the team is
encouraged to or penalized for responding to changes. Even though business
needs, requirements, technologies, and people are constantly moving these days,
some projects are still fixed in some combination of time, scope, and cost, and
must operate in the plan-driven range.
Project Plan as MFI or MFF.
If
the requirements or technologies are likely to change late in the game or
without notice, or the team does not have experience with the technology, then
it is a poor strategy to treat the project plan as a MFI issue. In those
situations, the agile leader's attitude that the plan is a MFF proposition
works better. The leader allocates energy to re-planning coarsely but
frequently.
Design as MFI or MFF.
A
plan-driven project team, believing that the design can be worked out in
advance (MFI), expends resources early to gain that information and lock down
the design. For those design elements that cannot be foreseen (MFF issues),
plan-oriented design teams often design the system so that a range of future
design constraints can be easily incorporated - expending extra design energy
early in anticipation of having a more adaptable design.
Many
agile designers find those resulting designs overly complicated. Agreeing that
certain issues are MFF issues, they argue that a better MFF strategy is to make
a simpler design in the first place, with less built-in flexibility. The saved
money can then be allocated to change the design on an as-needed basis.
Some
agile designers argue that the MFI component of the design activity is
negligibly small, thus little or no effort should be expended on anticipated
design changes.
Serial
vs. Concurrent Development.
There
is a fundamental difference in the strategies applied when agility is a
priority compared with when cost is the priority. As Principle No. 8 describes,
cost-sensitive projects do better with serial development when that can be
successfully executed. Unfortunately, there are so many surprises in projects
that it is very difficult to execute successfully.
Working Software vs. Comprehensive
Documentation.
One
tends to find more initiatives for comprehensive documentation on statistics-,
process- and plan-driven projects, but this is not intrinsic. Many experienced
managers use prototypes, simulators, and incremental development to reduce risk
and gain early information on both agile and plan-driven projects, feeding that
information into the plan as quickly as possible.
Customer Collaboration vs. Contract
Negotiation.
Plan-driven
project leaders clearly can improve their situation by increasing the
collaboration in their customer relations, even if they must write and enforce
contracts. This is a case in which plan-driven project leaders can employ some
of the same work practices as agile project leaders.
Project Plan and Design on Cost-sensitive
Projects.
A
detailed plan does not, by itself, confer cost savings or safety to a project.
Detailed plans and detailed designs enable an estimable base-line cost. The
manager can then tell if the cost is going up or down over time. It is not the
detail of the plan, but successful application of MFF and MFI decisions that
makes the difference in the result.