CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT

AGILE SOFTWARE
DEVELOPMENT: ADAPTIVE
SYSTEMS PRINCIPLES AND
BEST PRACTICES
PETER MESO,
assistant professor of
information systems at Peter Meso and Radhika Jain
Georgia State
University, earned his
Today’s environments of increasing business change require software development methodol-
Ph.D. degree in
ogies that are more adaptable. This article examines how complex adaptive systems (CAS) the-
information systems
ory can be used to increase our understanding of how agile software development practices
from Kent State
can be used to develop this capability. A mapping of agile practices to CAS principles and
University. His
three dimensions (product, process, and people) results in several recommendations for “best
research dealing with
practices” in systems development.
requirements and
software engineering,
the processes of system
development, and ODAY’S SOFTWARE DEVELOPMENT requirements from various sources has led to a
information systems in
underdeveloped
nations appears in
T units face old and new risks, including
shortfalls in real-time performance, ex-
growing interest in their application in devel-
oping large mission-critical software solutions
ternally performed tasks, externally fur- (Baskerville, Ramesh, Levine, Pries-Heje, &
several leading
journals.
nished components, unrealistic schedules and Slaughter, 2003).
budgets, development of wrong or unwanted In this article, we argue that complex adap-
RADHIKA JAIN is information systems (IS) solutions, obsolete tive systems (CAS) theory provides us with a
finishing up her features, and changes in requirements from theoretical lens for understanding how agile or
doctoral work in
multiple sources [including customers, tech- “Internet-speed” development of IS solutions
information systems at
nology, social factors, overhead, and competi- can be used to advantage in volatile business
Georgia State
University. In August
tion (Conboy, Fitzgerald, & Golden, 2005)] that environments. Specifically, we apply several
2006, she begins her need to be implemented at lightning speed principles of CAS theory (Anderson, 1999;
appointment as an (Kwak & Stoddard, 2004). Thus, organizations Highsmith, 1999; Kauffman, 1991) to develop
assistant professor at put a premium on software development ap- a better understanding of agile software devel-
the University of proaches that increase their responsiveness to opment methods. We then use this as a lens
Memphis. Her research business change. through which to develop a set of best practic-
interests include Agile software development methodologies es for software development to improve soft-
business process provide organizations with an ability to rapidly ware process and product quality. The Agile
management,
evolve IS solutions (Highsmith, 1999; Suther- Manifesto (http://agilemanifesto.org/) identi-
healthcare systems,
land & van den Heuvel, 2002). To date, these fies a set of values to improve overall software
software development,
and ubiquitous
methodologies have been employed primarily development. Although the principles driving
computing. Her work in Internet and Web software development these values overlap with the best practices
appears in several contexts (Glass, 2003; Paulk, 2001). However, identified in this article, this article goes a step
leading journals and the growing emphasis on these methodologies’ further to identify a more comprehensive set of
conferences. capabilities to respond to rapidly changing best practices that are grounded in theory and

I N F O R M A T I O N S Y S T E M S
S U M M E R 2 0 0 6
M A N A G E M E N T
19
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
span across the three important aspects of soft-
ware development; namely, people, product,
and process.
HEAVYWEIGHT AND LIGHTWEIGHT
A s in the
SOFTWARE DEVELOPMENT
METHODOLOGIES
To bring about some discipline to what can
past with
otherwise be chaotic processes of software de-
heavyweight velopment, many development methodologies
methodologies, have been proposed and adopted in practice.
organizations These methodologies impose a disciplined pro-
cess on software development with the aim of
often develop making it more predictable and efficient.These
their own software development methodologies can be
classified as being either heavyweight or light-
customized
weight, based on the extent to which they em-
versions of phasize factors such as (1) planning and
these named documentation, (2) well-defined phases in the
development process, (3) composition of the
agile
development team, and (4) use of well-elabo-
development rated modeling and coding techniques to gen-
approaches erate software development artifacts, among
to suit their others (Blum, 1996; Highsmith, 1999; Krutch-
en, 2001).
development
❚ Heavyweight methodologies promote up-
needs and
front overall planning of the roles to be
organizational played, activities to be performed, and arti-
environment. facts to be produced (Germain & Robillard,
2005). Proponents of these methodologies
argue that planning leads to lower overall
cost, timely product delivery, and better soft-
ware quality. Traditional methodologies such
as waterfall methodology and RUP (Rational
Unified Process) to some extent are classified
in this category (Germain & Robillard, 2005).
❚ Lightweight or agile methodologies put
extreme emphasis on delivering working
code or product while downplaying the
importance of formal processes and compre-
hensive documentation. Proponents of these
methodologies argue that by putting more
emphasis on “actual working code,” software
development processes can adapt and react
promptly to changes and demands imposed
by their volatile development environment
(Krutchen, 2001).
In addition to various named agile method-
ologies (such as eXtreme Programming [XP]
and Scrum), numerous homegrown agile meth-
odologies belong to this category.As in the past
with heavyweight methodologies, organiza-
tions often develop their own customized ver-
sions of these named agile development
approaches to suit their development needs
20 W W W . I S M - J O U R N A L . C O M
S U M M E R 2 0 0 6
and organizational environment. Although ag-
ile approaches are not a panacea or the silver
bullet, practices promoted by them shed some
light on how adaptivity can be achieved in soft-
ware development (Paulk, 2001). And although
lightweight and heavyweight methodologies
represent two extremes in software develop-
ment methodology, most development meth-
odologies used in organizations can be
positioned between these two extremes
(Bansler & Havn, 2003; Boehm, 2002).
Despite the diversity in their development
practices, agile methodologies in general can
be characterized as follows (Abrahamsson,
Warsta, Siponen, & Ronkainen, 2003):
❚ Incremental (small software releases with
rapid development cycles)
❚ Cooperative (a close customer and devel-
oper interaction)
❚ Straightforward (easy to learn and modify
and are sufficiently documented)
❚ Adaptive (an ability to make and react to last-
moment changes)
Table 1 presents a brief description of four
leading agile development methodologies.
CAS THEORY AND SOFTWARE
DEVELOPMENT
A complex adaptive system (CAS) is defined as
one that is capable of adapting to its external
environment and its internal state so that it sur-
vives despite the circumstances that befall it.
Studies of CAS are based on the holistic
premise that there is more to a holistic system
than the sum of its components and linkages
(Simon, 1996). CAS shows properties that are
truly emergent, irreducible to explanations that
take into account only those properties of its
lower level components. From a review of CAS
literature (Anderson, 1999; Arthur, Defillipp, &
Lindsay, 2001; Chiva-Gomez, 2004; Cilliers,
1998, 2000; Eoyang, 1996; McKelvey, 1999,
2001; Rhodes & MacKechnie, 2003; Simon,
1996; Tan, Wen, & Awad, 2005), the major princi-
ples of CAS can be summarized as follows:
1. Principle of open systems.A CAS is an open
system. It interacts with its environment. It
exchanges energy or information with its
environment and operates at conditions far
from equilibrium.
2. Principle of interactions and relationships.
Constituent elements of a CAS interact
dynamically and exchange energy or infor-
mation with each other. Even if only spe-
cific elements interact with a few others,
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT

TABLE 1 Leading Agile Development Methodologies

Methodology Description

Extreme programming A lightweight process targeted at development projects that are ill understood or
(XP) have rapidly changing requirements (Beck, 1999)
Empowers developers to confidently respond to changing customer requirements,
even late in the life cycle, emphasizing teamwork
Managers, customers, and developers are all part of a team dedicated to
delivering quality software
Improves a software project development process in four essential ways:
communication, simplicity, feedback, and courage
Its development process has various unique features such as requirements as
stories, pair programming, test-driven design, frequent unit testing, and
continuous integration
Primary activities in each XP iteration cycle include new design, error fix, and
refactoring (Alshayeb & Li, 2005)
Adaptive Software Places emphasis on production of high-value results emanating from the rapid
Development (ASD) adaptation to both external and internal events, rather than on the optimization
of process improvement techniques
Targets development teams in which competition creates extreme pressure (both
high-speed and high-change) on the delivery process
Adaptation is significantly more important than optimization (Highsmith, 1997,
1999)
Feature-Driven Uniquely sees very small blocks of client-valued functionality, called features,
Development (FDD) organizing them into business-related groupings
Focuses on producing working results every two weeks and facilitating
inspections; managers know what to plan and how to establish meaningful
milestones (Palmer & Felsing, 2002)
Reduces risk by emphasizing the frequent delivery of tangible working results
Provides for detailed planning and measurement guidance; promotes concurrent
development within each increment
Its motto is “design by feature, build by feature” (Coad, LeFebvre, & Luca, 2000)
Scrum A team-based approach for controlling the chaos of conflicting interests and needs
to iteratively, incrementally develop systems and products when requirements
are rapidly changing
Can improve communications and maximize cooperation
Is scalable from small single projects to entire organizations (Rising & Janoff,
2000)

effects of these interactions are propagated 4. Principle of emergent behavior. Because

throughout the CAS.The behavior of such a
system is determined greatly by the nature
of these interactions, and not simply by
what is contained within these elements.
3. Principle of transformative feedback loops.
Interactions across a CAS’s boundary result
in many direct and indirect transforming
feedback loops among the components of
the system. Change in one part of the sys-
tem is transmitted via its boundaries to
other parts of the system, causing recipi-
ents of feedback information to change or
react in some fashion. These secondary
changes (reactions) are transmitted back to
the originator, causing the originator to
change again, and so on. Within an organi-
zational context, feedback loops have the
potential to spur continuous improvement
and provide a shared sense of community
involvement.
I N F O R M A T I O N S Y S T E M S
S U M M E R
interactions among different entities of a
CAS are rich, dynamic, nonlinear, and fed
back, the behavior of the CAS as a whole
cannot be predicted simply from an inspec-
tion of its components. To understand the
implications of these interactions and make
predictions about a CAS’s behavior, the
notion of “emergence” and “emergent
behavior” is needed. Unpredictable and
novel ideas may emerge (which may or may
not be desirable) as a result of these interac-
tions, but by definition they are not an indi-
cation of malfunction. These emerging
ideas should not be censored simply
because they were unanticipated.
5. Principle of distributed control.A CAS cannot
thrive when there is too much central con-
trol.This certainly does not imply that there
should be no control; rather, control should
be distributed throughout the system.
However, one should not go overboard
2 0 0 6
M A N A G E M E N T
21
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
with notions of self-organization and dis-
tributed control.
6. Principle of shallow structure. A CAS
works best with shallow structure. This
should be interpreted to suggest that a CAS
should have some structure, but only the
T
minimal amount of structure necessary for
his
it to effectively achieve its objectives.
implies that 7. Principle of growth and evolution. In a
agile methods CAS, survival is enhanced through continu-
ous growth and evolution occurring in
used to foster minuscule increments as the system
organizational responds to emerging internal and external
environmental changes. This principle fos-
adaptation
ters adaptation by allowing the CAS to pay
must allow for immediate attention to the needs of its
dynamic and immediate surroundings. In doing so, the
effective CAS reorients itself incrementally to more
distant/remote environmental conditions.
interplay Adaptation thus occurs in minuscule incre-
among them. mental steps.
CAS AND LIGHTWEIGHT
METHODOLOGIES
Truex et al. (1999), Highsmith (1999), and
Kauffman (1995) posit that enterprise informa-
tion systems supporting today’s digital econo-
my are highly complex and exhibit a need to be
adaptive. They also point out that developing
and improving IS solutions is in itself a com-
plex-adaptive task that exhibits the basic prop-
erties of a CAS. Although there is little
published research on the application of CAS
theory in software development, there is an in-
creasing consensus that CAS informs the shift
toward agile software development methodol-
ogies. For example, Gerber (2002) states:
… by incorporating the principles of
self-organization called isomorphies,
new methodologies … including ob-
ject-orientation, eXtreme Programming
(XP), and lightweight methodologies
use some concepts and principles of
natural complex systems … that’s why
they produce better results than con-
ventional methodologies if they are ap-
plied in appropriate areas.
Highsmith (1999), in his book on adaptive
software development, suggests emergent or-
der as an alternative to a belief in and a depen-
dence on imposed order. By the same token,
Eoyang (1996) describes how CAS theory
helped unravel complicated issues that threat-
ened to stymie a customer support system’s
GUI (graphical user interface) development. In
22 W W W . I S M - J O U R N A L . C O M
S U M M E R 2 0 0 6
providing an argument for a complex adaptive
view of software development, he states:
… our old measures of product quality
and process efficiency are always unre-
alistic and frequently destructive when
they are applied to development of
complex, adaptive software products …
we must change the way we look at the
world of software development and
business processes.
MAPPING CAS THEORY TO COMMON
AGILE DEVELOPMENT PRACTICES
In this section we describe seven commonly
followed agile practices and how various CAS
principles provide insights into each of them.
The process of developing IS solutions com-
prises interactions among three dimensions:
1. Stakeholders in a development project
(people)
2. Process-related rules/guidelines used to
provide a direction to the development
effort (process)
3. Software artifacts generated as a result of
this development effort (product)
Software development evolves through a
myriad of complex interactions among these
three dimensions. This implies that agile meth-
ods used to foster organizational adaptation
must allow for dynamic and effective interplay
among them. CAS theory provides an under-
pinning for dynamic interplay among people,
process, and product dimensions and informs
how agile methods enable such interplay. The
result is a mapping of agile practices and CAS
principles, as summarized in Table 2.
Note that the first CAS principle (open sys-
tems) essentially applies to most of the agile
practices discussed below. As will be apparent
from the following discussion, agile methodol-
ogies place a heavy emphasis on open interac-
tions among various stakeholders (including
development team, management, and custom-
ers) to receive feedback and to manage the life
cycle of a development project. Agile software
development as a whole therefore exhibits this
behavior of open systems, so this principle is
not associated with any of the specific practic-
es in Table 2. Similarly, the sixth CAS principle
(shallow structure) is not included in Table 2
because it does not fit pragmatically in any one
row or apply to any one agile practice. Rather,
it provides a framework for various agile prac-
tices such as continuous frequent feedback,
minimalist design teams, etc. For example,
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT

TABLE 2 Mapping Agile Practices along Three Dimensions (People, Process, and Product)

Best Practices
Agile Product Dimension Process Dimension People Dimension
# Practice CAS Principle (Artifact) (Development) (Software Team)

1. Frequent releases Principle of Develop the software artifact Reevaluate development Reevaluate team configuration
and continuous growth and iteratively, allowing it to methodology frequently. Best frequently, scaling and
integration evolution acquire increasing practice is to start simple and transforming team composition
complexity in size and modify methodology as the need and size as it progresses through
capability in each for advanced or different various stages of development.
succeeding iteration. processes and tools emerges.

2. Need for frequent Principle of Iteratively test and validate Time-box development efforts, use Pragmatically involve stakeholders
feedback transformative software artifact, making measurable process milestones, and fellow developers by
feedback loops necessary improvements to and evaluate process carefully seeking and listening to
it. effectiveness and efficiency their comments and concerns.
continuously.

3. Proactive handling Principle of Allow the solution being Allow actual process employed to Allow actual team configuration to
of changes to the emergent order developed to be responsive emerge or be determined by emerge or be determined by
project to the emerging changes in immediate local needs. In other immediate local needs.
requirements project requirements by words, process tailoring needs to
taking into account be done to take into account
feedback gained from the contextual factors.
exercise of frequent
releases and integration.

4. Loosely Principle of Strive for componentization Use iterative, time-boxed, and/or Delegate responsibility and
controlled distributed and loosely coupled modular development process. decision making to local
development control software artifacts. development units.
environment

5. Planning kept to a Principle of Minimal product planning Process planning done where and Minimal human resource and
minimum growth and done where and when when necessary; always some stakeholder involvement
evolution necessary; limited process assessment undertaken, planning, performed where and
emphasis on but in minimalist fashion. when necessary; regular
documentation, but some assessment of efficacy of project
documentation is required. team composition and size.

Principle of Let actual solution emerge Let actual process emerge Allow for team interactions and
emergent order naturally rather than from naturally rather than from heavy working patterns to emerge
heavy planning and planning and method naturally.
solution design. engineering.

6. Enhancing Principle of Allow for manageable Allow for manageable Involvement in agile development
continuous growth and experimentation in product experimentation with various effort enhances individual IS
learning and evolution design and for learning processes and for learning from development skills.
continuous from the mistakes made. mistakes made. Learning
improvement Learning results in better increases process effectiveness
quality product. and efficiency.

Principle of Allow for comparison of Allow for comparison of agile Allow for pairing or teaming up of
interactions and artifact solutions from methods/processes from current developers. Teamwork enhances
relationships current and past efforts. and past efforts. This fosters learning, increases competence,
Comparison fosters reuse reuse and enhances continuous and enhances communication.
and enhances continuous improvement of existing agile
improvement of previously methods.
developed solutions.

7. Emphasis on Principle of path Foster an environment that Let the process that is most Let the team configuration that
working of least effort simplifies and enhances the effective for rapid production of leads to the most rapid
software product (based on Zipf, delivery of a functional, a working solution prevail. production of an effective
1949) error-free IS solution. Emphasis on not fixing emergent working solution without
process if it remains effective. forceful centralized control
prevail.

I N F O R M A T I O N S Y S T E M S
S U M M E R 2 0 0 6
M A N A G E M E N T
23
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
using minimal structure (i.e., teams without a
deep hierarchy), software development teams
are able to seek and receive feedback frequent-
ly and more quickly.
S uccessful
Frequent Releases and Continuous
Integration
Literature on agile software development sug-
completion gests that for a complex systems development
of each project to be successful it should be imple-
subsequent mented in small steps, each with a clear mea-
sure of successful achievement and with an
iteration
option of rolling back to a previous successful
boosted the step upon failure (Larman & Basili, 2003). In
development addition, conducting frequent releases is cru-
teams’ cial to accommodate constantly changing re-
quirements. Thus, adaptation needs to occur in
confidence and miniscule, incremental steps.
helped to The CAS principle of growth and evolution
reduce the provides a theoretical backing for such behav-
ior in agile software development. This is evi-
project risks.
denced in the product dimension in the form
of incremental development of artifacts. In the
process dimension, it is evidenced in the form
of time boxes — finite modular periods of de-
velopment time — comprised of identifiable
process steps and tools.These time boxes or it-
erations become more intricate as the project
matures due to the increasing complexity in
the artifact being developed. In the people di-
mension, this principle is evidenced as a finite
configuration of development personnel, the
composition and structure of which may radi-
cally alter as the project shifts from iteration to
iteration.
Grenning (2001) reported on a process-in-
tensive company that introduced XP. After this
company had launched XP, development teams
carried out monthly releases and continuously
integrated new features into the existing prod-
uct. Successful completion of each subsequent
iteration boosted the development teams’ con-
fidence and helped to reduce the project risks.
Team members knew exactly what was hap-
pening and had a good grasp of the progress
made at all times in the course of development
(Grenning, 2001). Cao et al. (2004) also ob-
served that development teams employing
agile software development methodologies fo-
cused primarily on delivering production code
that supports end-to-end functionalities rather
than developing heavily integrated software
modules. This practice was observed also at
two software giants, Netscape and Microsoft
(MacCormack, Verganti, & Iansiti, 2001). It is
24 W W W . I S M - J O U R N A L . C O M
S U M M E R 2 0 0 6
seen as a way of increasing customer support
and satisfaction (Beedle et al., 2001).
Best practices supported by the CAS princi-
ple of growth and evolution for this agile prac-
tice are thus:
❚ Develop the IS solution iteratively, with each
iteration being focused on adding some well-
defined capability to the continuously evolv-
ing IS solution.
❚ Start with a simple set of development pro-
cesses and tools and modify development
strategy in successive iterations as the need
for more advanced procedures and tools
becomes necessary.
❚ Start with a minimalist development team
and scale up and/or reconfigure team’s struc-
ture and composition as the project grows in
size and complexity.
Need for Frequent Feedback
Software development by its nature involves in-
teractions among stakeholders, development
tools, software components in the solution be-
ing developed, and interactions of stakeholders
with these tools, solution, or both. These inter-
actions are message exchanges occurring be-
tween entities related or interconnected in
some fashion to each other. Consequently,
feedback comes not only from clients and oth-
er significant stakeholders but also from mes-
sages (such as error messages) received from
the components that make up the IS solution,
from development tools being employed,
and/or from artifacts that document the devel-
opmental details within the process (High-
smith, 1999).
When a development team establishes
transforming feedback loops across a boundary
that divides the team from users, other devel-
opment agents, and stakeholders, a complex
adaptive development environment is created.
In a bid to remain responsive, the development
team frequently adjusts its focus, structure, and
composition to best address these emerging re-
quirements. The feedback loops also generate
creative tension that propels the development
team toward developing novel IS solutions that
are suited to addressing the emerging require-
ments. To take advantage of feedback and to ac-
commodate changes as a result of feedback,
software processes also need to be flexible and
easily changeable. These characteristics are a
manifestation of the principle of transformative
feedback loops in the people, product, and pro-
cess dimensions of agile software development.
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
According to MacCormack et al.’s (2001)
study of IS development at Netscape and Mi-
crosoft, seeking feedback from various stake-
holders was considered crucial to the fate of a
project. Both organizations placed heavy em-
phasis on user feedback and carried out alpha
I n a bid and beta testing to obtain feedback from poten-
tial users. These development teams had multi-
to remain ple mechanisms to accommodate feedback
responsive, the from various stakeholders. One such mecha-
development nism was to prioritize the elements of the re-
team ceived feedback and incorporate them into
subsequent iterations based on their criticality
frequently (MacCormack et al., 2001). Cao et al. (2004) re-
adjusts port that when it was not possible to seek feed-
its focus, back directly from the customers, the
structure, and development team had their project managers
and business analysts (who had direct contact
composition to with customers) act as the surrogate custom-
best address ers. In both instances, the need for feedback
these emerging was paramount.
Based on this discussion, suggested best
requirements.
practices are:
❚ Test and validate an IS solution at the end of
each development iteration to obtain feed-
back on its efficacy and on required modifi-
cations.
❚ Time-box the development process and use
measurable process milestones within the
development iteration.
❚ Obtain pragmatic involvement from stake-
holders and fellow developers by carefully
seeking and listening to their comments and
concerns.
These approaches have the potential to en-
hance programmatic and frequent feedback
elicitation that allows agile development to re-
main responsive to the emergent business envi-
ronment.
Proactive Handling of Changes to the
Project Requirements
The CAS principle of emergent order helps ex-
plain the phenomenon of unanticipated re-
quirements and capabilities evident in IS
solutions. Within the software development
context, CAS theory suggests that unanticipat-
ed and perhaps novel requirements may
emerge in software development projects. The
desirability of these emergent requirements is
context sensitive. Nonetheless, they are not an
indication of malfunction or malformation, and
thus need not be censored. These emergent
I N F O R M A T I O N S Y S T E M S
S U M M E R
requirements allow software artifact to remain
current and reflective of the changing business
environment.
One of the major attributes of agile soft-
ware development methodologies is that they
embrace changes in requirements from various
sources, even in later development phases
(Conboy, Fitzgerald, & Golden, 2005). This un-
derscores an emphasis of agile methods on
willingness to embrace emergent requirements
and unanticipated changes regardless of when
they occur in a project’s lifetime. To ensure de-
livery of a “nonobsolete” solution, it is impor-
tant that any changes to project requirements
are handled proactively by making necessary
adjustments to the development process (pro-
cess dimension) and the development team
(people dimension). This discussion implies
that the process and people dimensions con-
form to the CAS principle of emergent order.
Also, adjustments and modifications to the de-
velopment processes and the team undertak-
ing those processes shape outcomes of the IS
solution (product dimension). In this regard,
the IS solution also exhibits “emergent order.”
At Netscape and Microsoft, systemic chang-
es in a project’s definition and basic direction
were managed proactively (MacCormack et al.,
2001). For example, during the development
of a Web browser, end users were invited to
play with the browser. These users had not
used such software before. As the users played
around with the beta versions of the browser
software, they gained more understanding re-
garding its limitations and potential capabili-
ties. These users then provided development
teams with numerous suggestions for improve-
ment of the software. Had the development
teams ignored users’ feedback, neither of these
companies would have been able to deliver
browser software that was truly reflective of
their external users’ emerging requirements.
Based on the above discussion, the best
practices underpinned by the principle of
emergent order are:
❚ Allow for sufficient flexibility in a develop-
ment process.
❚ Allow for sufficient flexibility in a develop-
ment team to facilitate quick response to
immediate local needs.
❚ Accommodate emerging requirements in the
IS solution to develop a solution that is reflec-
tive of current business needs.
2 0 0 6
M A N A G E M E N T
25
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
Loosely Controlled Development
Environment
CAS theory suggests that in conditions of high
uncertainty, flexible and adaptive organization-
al units are more appropriate than rigid and
static ones. Organizational units operating in
A lthough
such situations tend to flourish when distribut-
ed decision making and control mechanisms
are utilized across a network of interconnected
on the surface
entities (Rihania & Geyer, 2001). Agile develop-
agile ment teams exhibit flexible and distributed
methodologies control structures. This type of structure tends
to be minimal and highly accommodating. This
may appear
in itself is reflective of adherence to the CAS
to follow principle of distributed control.
unplanned and Published studies on agile software devel-
undisciplined opment provide support for this principle. For
example, project managers at FinApp (Cao et
development
al., 2004) believed that deep hierarchical orga-
practices, nizational structure could lead to unresponsive
these environments with high inertia. Eoyang (1996)
reports that better quality user interfaces and
methodologies
greater efficiencies in development were
emphasize a achieved when the IS development team was
minimum, reorganized to allow for localization of deci-
sion making. Flexible work setting, focus on re-
but sufficient,
sults rather than micro-management, and
amount of empowering people who are actually doing
planning the work were seen as key factors affecting de-
veloper morale and motivation (Cao et al.,
within each
2004; Cusumano & Yoffie, 1999).
iteration. Cusumano and Yoffie (1999) also observe
that managers at Microsoft and Netscape tried
not to control the development process too rig-
idly in order to be responsive. At Microsoft,
MacCormack et al. (2001) note that developers
could exercise veto powers at the local level
based on their technical expertise in a problem
domain being addressed. At Netscape, senior
developers along with members of the market-
ing department could assign higher priorities
to their favorite features and the product man-
agers, engineers, and developers could negoti-
ate IS solution terms with their clients (the
marketing department, for example) when
things didn’t go quite as per plan (MacCormack
et al., 2001).
These observations might lead one to think
about the role project managers should play in
agile development teams. Fowler (2002) and
Blotner (2003) suggest that a manager can and
should help the team be more productive by
offering some insight into the ways in which
things can be done in an agile environment.
Grenning (2001) observed that having senior
people monitor the team’s progress at a month-
ly design-as-built review meeting accelerated
26 W W W . I S M - J O U R N A L . C O M
S U M M E R 2 0 0 6
the development process while lowering the
number of bugs. Any bugs found were made
part of the next iteration.
The recommendations for best practice
based on the above discussion are:
❚ Leadership and decision making on a soft-
ware development project ought to be
decentralized, with more decisions being
made at local units where problems are
encountered.
❚ Successive iterations in a development pro-
cess need to be fairly independent or loosely
coupled.
❚ The structure of an IS solution being devel-
oped needs to foster componentization,
loose coupling, and high cohesion within
the finished product.
Planning Kept to a Minimum
Given the volatile and rapidly changing busi-
ness environment, it’s practically impossible to
specify ahead of time everything that should go
into a new product or release. CAS theory lays
significant emphasis on the emergent order —
the principle of emergent order — accounting
for minimal planning practice to accommodate
various unforeseen requirement changes. Al-
though on the surface agile methodologies may
appear to follow unplanned and undisciplined
development practices, these methodologies
emphasize a minimum, but sufficient, amount
of planning within each iteration.
For example, XP emphasizes iteration-cen-
tric planning. Rather than planning, analyzing,
and designing for the far-flung future (which is
highly prone to change), XP exploits reduction
in the cost of changing software to do all of
these activities a little at a time, throughout the
development process (Beck, 1999). The scope
of the planning process is kept primarily to the
current iteration. Feature-Driven Development
(FDD) also advocates for detailed planning and
measurement guidance within each “design by
feature, build by feature” increment (Coad et
al., 2000). Only after executing and evaluating
the outcome of the current plan are plans for
subsequent iterations generated (Martin,
2000). These practices were observed at
Netscape and Microsoft, where managers
clearly believed that some planning, albeit min-
imal, was necessary to build complex products
(Cusumano & Yoffie, 1999).
Within the product, process, and people di-
mensions, suggested best practices are that (1)
the planning for the IS solution, (2) the actual
processes used to develop the solution, and
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
(3) the structure and composition of the devel-
opment team are best addressed within each
development iteration. This keeps planning to
a minimum and steers the focus to the immedi-
ate needs of the development project.
A nother Enhancing Continuous Learning and
Continuous Improvement
practice that CAS theory stipulates that adaptation is a learn-
is a feature of
ing mechanism. It occurs because a CAS is able
agile software to learn about changes in its environment or its
internal state and react to those changes. Addi-
development tionally, each successful adaptation is rein-
is the minimal forced for reuse in similar future situations.The
emphasis on CAS principle of growth and evolution pro-
vides a theoretical underpinning for such be-
documentation.
havior. Agile methodologies put a great
emphasis on people and their talents, skills,
and knowledge, suggesting that for agile devel-
opment to be effective team members must be
responsive, competent, and collaborative (Boe-
hm, 2002; Cockburn & Highsmith, 2001).
Adaptation occurs by continuous reactions
to changes in environmental conditions sensed
locally by specific entities within the system.
Because these entities tend to be specialized,
they need to interact with other entities to en-
act adequate behavior to bring about adapta-
tion in the CAS. Consequently, relationships
within the CAS result in information exchange
that produces learning. Different units of a de-
velopment team must interact with each other.
For example, in XP, developers with different
levels of experience and skill are typically
paired for development purposes (Cao et al.,
2004; Grenning, 2001). It is suggested that
such pairing fosters learning for all involved
parties. To facilitate this kind of learning, how-
ever, the communication capabilities of devel-
opers become crucial (Cao et al., 2004).
Various tasks within a development process are
interrelated and dependent on each other. Ef-
fective completion of one task impacts comple-
tion of others. Thus, agile methodologies’
emphasis on continuous learning and improve-
ment finds theoretical support in the CAS prin-
ciple of interactions and interconnectedness,
on the one hand, and that of growth and evolu-
tion, on the other hand.
Inferences from this discussion suggest
that:
❚ Componentized IS solution development fos-
ters reuse and enhances learning from past
successes and failures in developing effective
components.
I N F O R M A T I O N S Y S T E M S
S U M M E R
❚ Tolerance for manageable experimentation
with various approaches and focus on attain-
ment of short-term objectives enhances
learning by doing, allows the development
team to fine-tune the processes and tools
used for the development effort, and steers
the development project toward expected
outcomes.
❚ Interactions among members of the develop-
ment team and various stakeholders will fos-
ter an exchange of ideas and second-order
learning.
This practice also fosters the emergence of natu-
ral, unforced collaborative partnerships, thereby
leveraging productivity, creativity, and quality.
Emphasis on Working Software Product
Another practice that is a feature of agile soft-
ware development is the minimal emphasis on
documentation. The motivation for this prac-
tice is twofold: (1) to make the development
team more effective in responding to change
and (2) to reduce the cost of moving informa-
tion between people (Cockburn & Highsmith,
2001). Martin (2000) suggests that teams
should create detailed plans that are meaning-
ful only for that iteration. Grenning (2001) ar-
gues that a good way to protect future software
maintainers is to provide them with clean and
simple source code, rather than with binders
full of out-of-date paper, and to keep the docu-
mentation at a high level so that usual mainte-
nance changes and bug fixes don’t affect it.
Cusumano and Yoffie (1999) found that manag-
ers at Microsoft and Netscape tolerated incom-
plete documentation because they put a
premium on creating a working product.
This is an area in which CAS theory pro-
vides weak support. Hence, we borrow from
the theory of “path of least effort” offered by
Zipf (1949), who explains this emphasis on a
working product with minimalist documenta-
tion orientation:
Nothing is gained by calculating a par-
ticular path of least effort to a greater
degree of precision, when the added
work of so calculating it is not more
than offset by the work that is saved by
using the more precisely calculated
path.
Consequently, it is best to let the “path of
least effort” emerge in the course of complet-
ing a development task.This helps us understand
the agile practice of minimal emphasis on docu-
mentation, and also on formal planning, while
2 0 0 6
M A N A G E M E N T
27
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
putting heavy emphasis on building a working
product.
This discussion prompts the identification
of the following best practices:
❚ Foster an environment that simplifies and
B y
enhances delivery of a functional, error-free
IS solution.
❚ Let the development process that is most
identifying the effective at producing a working solution
correct set of prevail.
metrics and ❚ Allow for working relationships of develop-
ment team members to produce natural con-
mechanisms to figurations that foster rapid production of a
manage their working solution.
inter-
dependencies, Summary
In summary, CAS theory provides insights into
project
how agile development methods foster deliv-
managers can ery of responsive and highly evolvable soft-
effectively ware solutions. Such insights are crucial when
identifying metrics for agile software develop-
steer the
ment, because the same CAS principles may
project toward govern these metrics. The metrics so devel-
desired oped ought to capture each of the three dimen-
sions of software development; namely,
outcomes as
people, process, and product. However, as in-
planned. dicated in the previous section, these three di-
mensions are not completely independent of
each other. Thus, these metrics should be iden-
tified and developed in such a way that they in-
corporate the interactions across all of these
dimensions. For example, the principle of
emergent behavior is applicable to all three di-
mensions via the common practice of proac-
tive handling of changes to the project
requirements. This has direct implications not
only for researchers but also for practitioners.
By identifying the correct set of metrics and
mechanisms to manage their interdependen-
cies, project managers can effectively steer the
project toward desired outcomes as planned.
A key limitation of this article is that it stops
short of deriving and validating metrics for ag-
ile software development for the theory-based
best practices suggested. However, it does
present a basis upon which such metrics can
be developed. The argument here is that CAS
theory, as presented in this article, is an effec-
tive theory upon which to underpin such met-
rics. The discussion of how these theory-based
best practices could be implemented within
each of the three core dimensions of an agile
software development undertaking — people,
process, and product — provides a starting
point for the elaboration and refinement of
metrics that can capture each best practice
28 W W W . I S M - J O U R N A L . C O M
S U M M E R 2 0 0 6
succinctly. We see this as an opportunity for fu-
ture research in this domain.
CONCLUSION
As Highsmith (1999) succinctly points out,
without a clear understanding of underlying
theoretical principles behind software devel-
opment approaches, organizations are at high
risk of being nonadaptive. This article contrib-
utes to the literature on complexity science
and IT development by providing a clear un-
derstanding and appreciation of the sources,
nature, and types of interdependencies be-
tween individuals, organizations, and IS solu-
tions within the context of fast-paced agile
software development. Based on discussion
presented in this article, we argue that organi-
zations that use heavyweight methodologies
need to reconsider these agile practices, rather
than discounting them as “hacking,” and inte-
grate them as suitable.
Opportunities for future research include
exploring the finer differences in how various
agile software development methodologies
support the proposed best practices; the devel-
opment of a customizable set of metrics for ag-
ile software development methodologies; and
the identification of mechanisms for embed-
ding these metrics into automated develop-
ment tools and integrated development
environments commonly employed in agile
software development projects.
Other areas that need to be addressed in-
clude the development of design principles
that are also rooted in CAS theory, the empiri-
cal evaluation of these principles to establish
their effectiveness and rigor, and the identifica-
tion of various metrics to assess product quali-
ty and process efficiency based on CAS theory.
This understanding can also be used to inform
us about why certain agile practices are more
amenable than others. Availability of this
knowledge can make the tailoring of agile prac-
tices more informed, rather than based simply
on intuition. ▲
References
Abrahamsson, P., Warsta, J., Siponen, M. T., &
Ronkainen, J. (2003). New Directions on Agile
Methods: A Comparative Analysis. Paper
presented at the 25th International Conference
on Software Engineering, Portland, Oregon.
Alshayeb, M., & Li, W. (2005). An empirical study of
system design instability metric and design
evolution in an agile software process. Journal
of Systems and Software, 74(3), 269–274.
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT
Anderson, P. (1999). Complexity theory and
Organization Science. Organization Science,
10(3), 216–232.
Arthur, M., Defillipp, R., & Lindsay, V. (2001).
Careers, Communities, and Industry Evolution:
Links to Complexity Theory. International
Journal of Innovation Management;, 5(2),
239–256.
Bansler, J., & Havn, E. (2003). Improvisation in
Action: Making Sense of IS Development in
Organizations. Paper presented at the
International Workshop on Action in Language,
Organisations and Information Systems (ALOIS
2003), Linköping, Sweden.
Baskerville, R., Ramesh, B., Levine, L., Pries-Heje, J.,
& Slaughter, S. (2003). Is “Internet-speed”
software development different? IEEE Software,
20(6), 70–77.
Beck, K. (1999). Embracing Change with Extreme
Programming. IEEE Computer, 32(10), 70–77.
Beedle, M., Bennekum, A. V., Cockburn, A.,
Cunningham, W., Fowler, M., Highsmith, J., et al.
(2001). Principles behind the Agile Manifesto.
Retrieved Feb 15th, 2004, from http://
agilemanifesto.org/principles.html
Blotner, J. (2003). It’s More than Just Toys and Food:
Leading Agile Development in an Enterprise-
Class Start-Up. Paper presented at the Agile
Development Conference (ADC 2003).
Blum, B. (1996). Beyond Programming: To a New
Era of Design: Oxford University Press.
Boehm, B. (2002). Get Ready for Agile Methods, with
Care. IEEE Computer, 35(1), 64–69.
Cao, L., Mohan, K., Xu, P., & Ramesh, B. (2004).
How Extreme Does Extreme Programming
Have to Be? Adapting XP Practices to Large-
Scale Projects. Paper presented at the 37th
Annual Hawaii International Conference on
System Sciences (HICSS’04), Big Island, Hawaii.
Chiva-Gomez, R. (2004). Repercussions of complex
adaptive systems on product design
management. Technovation, 24(9), 707–711.
Cilliers, P. (1998). Complexity and Postmodernism:
Understanding Complex Systems. London;
New York: Routledge.
Cilliers, P. (2000).What Can We Learn From a Theory
of Complexity? Emergence, 2(1), 23–33.
Coad, P., LeFebvre, E., & Luca, J. D. (2000). Java
Modeling in Color with UML: Enterprise
Components and Process: Prentice Hall.
Cockburn, A., & Highsmith, J. (2001). Agile Software
Development: The People Factor. IEEE
Computer, 34(11), 131–133.
Conboy, K., Fitzgerald, B., & Golden, W. (2005).
Agility in Information Systems Development: A
Three-Tiered Framework. In R. Baskerville (Ed.),
Business Agility and Information Technology
Diffusion. IFIP TC8 WG 8.6 International
Working Conference. Atlanta, Georgia, USA.:
Springer.
I N F O R M A T I O N S Y S T E M S
S U M M E R 2 0 0 6
M A N A G E M E N T
Cusumano, M., & Yoffie, D. (1999). Software
Development on Internet Time. IEEE Computer,
32(10), 60–69.
Eoyang, G. (1996). Complex? Yes! Adaptive? Well,
maybe … . Interactions, 3(1), 31–36.
Fowler, M. (2002, March). Agile Development: What,
Who, How, and Whether, from http://www.
fawcette.com/resources/managingdev/
interviews/fowler/
Gerber, M. (2002). Keynote Speech: Lightweight
Methods and Their Foundations in Chaos
Theory. Paper presented at the 6th IEEE
International Enterprise Distributed Object
Computing Conference (EDOC 2002), Ecole
Polytechnique Fédérale de Lausanne (EPFL),
Switzerland.
Germain, E., & Robillard, P. N. (2005). Engineering-
based processes and agile methodologies for
software development: a comparative case
study. Journal of Systems and Software,
75(1–2), 17–27.
Glass, R. (2003). Questioning the Software
Engineering Unquestionables. IEEE Software,
20(3), 119–120.
Grenning, J. (2001). Launching Extreme
Programming at a Process-Intensive Company.
IEEE Software, 18(6), 27–33.
Highsmith, J. (1997). Messy, Exciting, and Anxiety-
Ridden: Adaptive Software Development.
American Programmer, X(1).
Highsmith, J. (1999). Adaptive Software
Development: A Collaborative Approach to
Managing Complex Systems. New York, NY:
Dorset House Publishing.
Kauffman, S. (1991). Antichaos and Adaptation.
Scientific American, 256(2), 78–84.
Kauffman, S. (1995). At home in the Universe:
Oxford University Press.
Krutchen, P. (2001). Agility with the RUP. Cutter IT
Journal, 14(12), 27–33.
Kwak, Y. H., & Stoddard, J. (2004). Project risk
management: lessons learned from software
development environment. Technovation,
24(11), 915–920.
Larman, C., & Basili, V. R. (2003). Iterative and
Incremental Development: A Brief History. IEEE
Computer, 36(6), 47–56.
MacCormack, A., Verganti, R., & Iansiti, M. (2001).
Developing Products on “Internet Time”: The
Anatomy of a Flexible Development Process.
Management Science, 47(1), 133–150.
Martin, R. (2000). eXtreme Programming
Development through Dialog. IEEE Software,
17(4), 12–13.
McKelvey, B. (1999). Avoiding Complexity
Catastrophe in Coevolutionary Pockets:
Strategies for Rugged Landscapes. Organization
Science, 10(3), 294–321.
McKelvey, B. (2001). Energising Order-Creating
Networks of Distributed Intelligence: Improving
the Corporate Brain. International Journal of
Innovation Management;, 5(2), 181–212.
29
 CONTEMPORARY PRACTICES IN SYSTEMS DEVELOPMENT

Palmer, S., & Felsing, J. (2002). A Practical Guide
to Feature-Driven Development. Upper Saddle
River, NJ: Prentice Hall PTR.
Paulk, M. (2001). Extreme Programming from a
CMM Perspective. IEEE Software, 18(6), 19–26.
Rhodes, M. L., & MacKechnie, G. (2003).
Understanding Public Service Systems: Is There
a Role for Complex Adaptive Systems Theory?
Emergence, 5(4), 57–85.
Rihania, S., & Geyer, R. (2001). Complexity: an
appropriate framework for development?
Progress in Development Studies, 1(3),
237–245.
Rising, L., & Janoff, N. (2000). The Scrum Software
Development Process for Small Teams. IEEE
Software, 17(4), 26–32.
Simon, H. (1996). The Sciences of the Artificial
(Third ed.). Cambridge, MA: MIT Press.
Sutherland, J., & van den Heuvel, W.-J. (2002).
Enterprise Application Integration and Complex
Adaptive Systems. Communications of the
ACM, 45(10), 59–64.
Tan, J., Wen, H. J., & Awad, N. (2005). Health care
and services delivery systems as complex
adaptive systems. Communications of the ACM,
48(5), 36–44.
Truex, D., Baskerville, R., & Klein, H. (1999).
Growing systems in emergent organizations.
Communications of the ACM, 42(8), 117–123.
Zipf, G. (1949). Human Behavior and the Principle
of Least Effort. New York: Hafner Publishing
Company.

30 W W W . I S M - J O U R N A L . C O M
S U M M E R 2 0 0 6