|
|
|
The goals of agile processes are the same as the goals of all processes and
methodologies, to improve project success by: ensuring business objectives are
met, increasing productivity, ensuring high quality, reducing time to market,
and reducing risk.
There are three main categories of techniques that can be used to control a
project:
1. Pre-definition and pre-planning
2. Handling change and uncertainty
3. People, teams, and communication
Traditional processes concentrate on pre-definition - before doing something,
work out what you are going to do and write it down. These techniques have many
advantages, such as identifying issues up front, enabling external review, and
high-level visibility of progress and quality.
Pre-definition is an essential tool for managing many types of projects, such
as construction work, where the cost of building is much greater than the cost
of modeling, changes are difficult to incorporate later on, low-level tasks are
highly predictable and require little creativity, different groups of people
with a wide range of specialist skills need to be coordinated, and there is an
inherent order to the tasks which have to be carried out.
Historically, software development methodologies are derived directly from
large-scale military construction. But software developments projects do not
(or need not) have any of the above characteristics. This mismatch is evidenced
by the unacceptably high number of software projects, which fail.
Agile processes emphasize the other two categories of techniques. Rather than
trying to remove change and uncertainty, they accept them as inherent and
provide better mechanisms to achieve the required objectives. Rather than
trying to make success independent of people, they recognize their importance
and seek to utilize their creativity and encourage self-reliance. Even on
traditionally-run projects it has been found that these techniques correspond
much more closely with project success than adherence to the in-place
methodology.
Extreme Programming (XP) is a specific, documented approach to the software
development process. "Agile" refers to a family of approaches, of which XP is
an example. Other well-known examples are:
Scrum
DSDM
Feature Driven Design (FDD)
These approaches are all based on the precept that traditional IT methodologies
do not adequately address the main factors contributing to project success,
such as team dynamics, communication mechanisms, feedback, handling uncertainty
and change. Furthermore, they assert that traditional methodologies add an
unnecessary overhead that can contribute directly to project inefficiencies and
failure - such methodologies are therefore described as "heavy-weight".
In February 2001 the main exponents of these new approaches met to understand
how their individual processes overlapped, and to remove some of the confusion
arising for newcomers to the area caused by the range of "competing" approaches
on offer. The term "Agile" was agreed on at this time as an umbrella name
(although it should be noted that the benefits of these processes are more than
just the ability to handle change).
The group became the agile alliance,
a group of individuals, organizations, and companies who subscribe to and
promote the principles embodied in the Agile
Manifesto .
Agile processes in general are about how to manage the software develop process
to make projects more successful. Extreme Programming (XP) is unique in that it
incorporates techniques, which are specific to the development activity itself.
These techniques address one of the major problems with incremental delivery:
working and tested code has to be continually modified. For this reason XP,
while usable as a full process in its own right for small projects, has also
been integrated with other agile processes such as Scrum (see
www.controlchaos.com) and DSDM (www.dsdm.org
) for tackling larger projects.
XP (Extreme Programming) is only one example of a family of new approaches to
software development that are collectively termed "agile". However, XP has
received the lion's share of the headlines, generated the fiercest debate, and
has the largest adoption profile. Furthermore, XP is now being used alongside
other agile approaches, rather than in competition (see scrum and XP, DSDM and
XP). What makes XP stand out from the crowd is that it incorporates a technique
which could be as profound for the way that code is written as the introduction
of object-oriented techniques was in the 1980s. The technique in question is
Refactoring, which is incorporated into the more fully developed technique of
Test-Driven Design.
An agile project should cost less.
Some agile practices will clearly add to the cost. Pair programming in Extreme
Programming is an obvious example. Incremental delivery can also add to the
cost, through changing existing code, additional testing, and supporting early
releases.
These costs should be more than offset by savings elsewhere. It is inherent in
a 'light-weight' process that overheads are reduced, such as producing detailed
up-front documentation, and its subsequent maintenance. Management overhead in
particular should be significantly reduced. Any investment in quality, such as
pair programming, regression testing, keeping the design consistently high
(refactoring), continuous integration, and eliciting user feedback, should all
provide returns in the later stages of the project.
However, the major cost savings are derived by simply implementing less
functionality. An analysis of any application, which is specified up-front,
will identify a percentage of functionality, which is never or seldom used.
Indeed, it can be argued that there is a need when defining requirements to
build in a safety margin - to leave out a function that might be important
would be unprofessional.
In our experience, as a conservative estimate, non-essential functionality can
account for upwards of 30% of an applications cost, taking into account its
impact on such things as complexity, performance, and usability.
Estimating an Agile project is similar to producing a budgetary estimate for
any project. A short scoping exercise is used to produce a high-level costing
which is refined over time.
Agile techniques differ in that:
-
More emphasis is placed on the impact of team issues
-
Higher levels of communication and feedback are incorporated during the
estimation process (for example, holding planning workshops, including
on-the-fly estimation to help guide thinking)
-
The principles of prioritization would be adopted to keep focus on the key
issues
-
Detailed task and dependency planning are not considered useful, as task
definition, assignment, and interaction are much more fluid
-
Any decisions made to support the estimation process would not be imposed upon
the resultant work
Generally, agile projects would not propose doing any more detailed top-down
estimation. The degree of uncertainty across the whole set of project
parameters is difficult to predict and cannot be fully eradicated by prior
analysis.
Agile processes accept the inherent uncertainty of estimates. They propose that
effort and process is better spent making sure the error does not cause project
failure (through prioritization and feedback) rather than trying to increase
the accuracy.
Yes. Fixed price projects typically involve developing a system to a fixed
budget against a detailed scope with the developer holding the contingency and
assuming the majority of the development risk. As such, this disables the
ability to invoke one of agile's most powerful benefits - flexibility of scope.
The techniques that can bring about the largest benefits for a project involve
developing the simplest system possible to meet the users' requirements. As
these requirements evolve over the life of the project, agile techniques allow
a development to capture and embrace this change as it happens. By trying to
capture every requirement at the start of the project and then minimize change
throughout a development lifecycle, fixed price projects work against this
agility.
However, many other agile techniques can still bring benefit within a
traditional fixed price approach. Techniques such as pairing, test driven
design and others encourage communication between team members and greatly
increase quality, ultimately reducing the overall lifetime costs for a system.
If a new project is being considered there are other commercial models that
work to an agreed budget, but without the constraints of a full fixed price
environment.
The feedback concentrates on what is completed, to a releasable standard. This
makes the quality of information much higher than on traditional projects where
the criteria for 'completion' of an interim task are more subjective - when is
a specification complete?
The tasks carried out within each iteration of an agile project are broadly
constant. Information gathered for any one iteration can therefore be used to
effectively improve subsequent iterations. The manager has the choice of level
at which to monitor and intervene in the project. At the end of each iteration
if progress is less than anticipated then he may choose to monitor closely
within an iteration, although this is not usually required.
The short iteration cycles mean that problems cannot remain 'hidden' for long
periods of time. If more immediate information is required management can
easily 'dip' into the development cycle within an iteration. Daily Scrum
meetings and feedback from pair programming provide clear indications as to the
current state of iteration. Additionally experience suggests that teams with
collective responsibility, as engendered through agile, are more likely to
communicate issues upwards.
| Back to the previous page |
 |
|
|
|
Please click here to subscribe to our mailing list.
|
|
|
|
|
