380 Part III • Acquiring Information Systems
characterizes an agile approach, with frequent software re-
leases and rapid cycling over the systems development phas-
es of definition, construction, and implementation and their
various steps. Some see this chart as the route of a yo-yo
over time. Each release is a refactoring and enhancement of
the accumulation of prior releases; prior work is not
scrapped. The software gets better with each release. Early
releases focus more on architecture issues (the glue that will
hold the pieces together), whereas later releases drill deep
into specific functionalities. The application is composed of
the set of all releases and can be under continuous change.
There is a need for an initial step to establish an overall
architecture for the application system so that each piece can
be developed and all pieces will fit together (remember
Figure 8.1).
Agile methods are a radical change in systems
development and can be resisted by systems development
staff (Wailgum, 2007). Some see agile methods too domi-
nated by users who do not understand IT or too dependent
on the scarce resource of expert developers to be used for
many systems development projects. Individuals on the
team may be called “purple people,” because they are gen-
eralists, neither business nor IT specialists (an odd refer-
ence to combining “red” and “blue” to get purple). Others
feel that the lack of deep up-front design compromises a
sound architecture needed for robust and easy to maintain
organizational systems. Because testing occurs through-
out the development cycle, rather than at fixed points con-
trolled by quality assurance staff, some believe testing is
too ad hoc and myopic. Some believe the lack or limited
conduct of planning and documentation is a hazard. For
these and other reasons, agile methods are still emerging
as accepted approaches to systems development.
Successful projects using agile methods are making
organizations pay more attention to the potential of agile
methodologies.
Fowler (2003) recommends that agile methodolo-
gies are best suited for situations with dynamic require-
ments, dedicated and motivated team members, and
customers willing to be members of the core team and
also that the core team can be kept relatively small (20 or
fewer members).
Agileis a general term that encompasses various
specific methods and techniques. Several of the more
widely used agile methods and techniques are Crystal
Clear, Adaptive Software Development, Scrum, Feature
Driven Development, and eXtreme Programming. The
remainder of this section presents overviews of several of
these methods and techniques as a way to illustrate what
might happen on a project using the agile approach and to
illustrate some of the important principles that transcend
all agile methods.
EXTREME PROGRAMMING In one agile approach,
calledeXtreme Programming (XP),the programmers
write production code in pairs. By using simple designs
(definition and construction are fused together) and fre-
quent testing, the team produces small, fully integrated re-
leases that pass all the customers’ acceptance tests in a
very short time period (e.g., every two weeks). Each cycle
begins with users writing a story to describe their need for
the application (Serena, 2007). The cycle of analyze, de-
sign, code, and test are integrally linked and iterated until a
working solution is developed. Changes in code are fre-
quent (usually daily). Programming teams test their own
code (which is a radical change from traditional testing
methodologies). Both members of the programming pair
do coding and testing in parallel, so duties are not divided
by one person coding and the other testing. It is claimed
that such a process produces higher-quality code faster (for
those situations outlined previously). The programming
pairs then might disband to form new pairs and thus quick-
ly share their specialized knowledge and completed code.
Another hallmark of the XP approach is the obsession with
feedback and testing. As team-tested programs are re-
leased to a collective repository, any pair of programmers
can improve any of the collective code at any time, follow-
ing the common coding standards adopted by all teams.
XP focuses on the immediate problem, not anticipat-
ing future requirements. This and other factors keep the
design simple, a major goal of this technique. Three traits
characterize simple design:- The system must communicate everything you want to
communicate (i.e., be complete and self-documenting) - The system must contain no duplicate code (so
reusing code modules is essential, hence simplicity
and standards are key for reusability) - The system should have the fewest number of com-
ponents as possible
SCRUM Yes, for you rugby fans, the origins of the Scrum
agile method are in this team sport, in which well-orches-
trated movement between team members is important. A
Scrum Master (SM) organizes the Scrum team work, serves
as the team’s liaison with other teams and with clients, and
monitors team performance. Scrum emphasizes independ-
ent project teams, coordination and communication
between and within teams, iterative and continuous moni-
toring of work, and highly efficient work methods. A major
vehicle that Scrum uses for this purpose is meetings (Cho et
al., 2006):- Daily Scrum meetingA very short (5 to 15 minutes)
“stand up” session for each team in which develop-
ers on that team report on accomplishments since the