You are on page 1of 6

Agile Software Development

What Is Agile Software Development?1


Jim Highsmith
Cutter Consortium
In the past two years, the ideas of “agile software development,” which encompasses individual methodologies such as Crystal
methods, eXtreme Programming, feature-driven development, and adaptive software development, are being increasingly
applied and are causing considerable debate. This article attempts to answer the fundamental question on many people’s minds:
What is agile software development?

“N ever do anything that is a waste of


time – and be prepared to wage
long, tedious wars over this principle,”
golly, we were successful because we fol-
lowed our plan to the letter.” Battlefields
are messy, turbulent, uncertain, and full of
measures success for the agile project
manager. Conformance to plan has little
meaning in either case. If we want to be
said Michael O’Connor, project manager change. No battlefield commander would agile, we have to reward agility.
at Trimble Navigation in Christchurch, say, “If we just plan this battle long and There is, however, a critical difference
New Zealand. This product group at hard enough, and put repeatable process- between managing a battle and managing
Trimble is typical of the homegrown es in place, we can eliminate change early warehouse logistics. Battlefields are man-
approach to agile software development in the battle and not have to deal with it aged by constant monitoring of condi-
methodologies. later on.” tions and rapid course alterations – by
While interest in agile methodologies A growing number of software proj- empirical processes. Adapting to changing
has blossomed in the past two years, its ects operate in the equivalent of a battle conditions is vital. Conversely, managing
roots go back more than a decade. Teams zone – they are extreme projects. This is warehouse logistics is a process that can
using early versions of Scrum, Dynamic where agile approaches shine. Project be described by calculations involving
Systems Development Methodology teams operating in this zone attempt to materials on hand, deliveries, and ship-
(DSDM), and adaptive software develop- utilize leading or bleeding-edge technolo- ments; managing can be described as a
ment (ASD) were delivering successful defined process, one that involves a relatively
projects in the early- to mid-1990s.
This article attempts to answer the “Projects may have a high degree of predictability and algorith-
mic precision. Many manufacturing plants
question, “What constitutes agile software relatively clear mission, operate as defined processes.
The concepts and assumptions behind
development?” Because of the breadth of
agile approaches and the people who prac- but the specific empirical and defined processes are funda-
tice them, this is not as easy a question to mentally and irreconcilably different. The
answer as one might expect. I will try to requirements can be practices of agile software development –
answer this question by first focusing on short iterations, continuous testing, self-
the sweet-spot problem domain for agile volatile and evolving organizing teams, constant collaboration
approaches. Then I will delve into the (daily integration meetings and pair pro-
three dimensions that I refer to as agile as customers and gramming for example), and frequent re-
ecosystems: barely sufficient methodology, planning based on current reality (rather
collaborative values, and chaordic per- development teams alike than six-month- old plans) – are all geared
spective. Finally, I will examine several of to the understanding of software develop-
these agile ecosystems. explore the unknown.” ment as an empirical process.
On the other hand, the fundamental
The Agile Problem gies, respond to erratic requirements basis of the Capability Maturity Model®
Domain: Fitting the changes, and deliver products quickly. (CMM®) and CMM IntegrationSM
Projects may have a relatively clear mis- (CMMISM) is a belief in software develop-
Process to the Project sion, but the specific requirements can be ment as a defined process. As such, tasks
All problems are different and require dif- volatile and evolving as customers and can be defined in detail, algorithms can be
ferent strategies. While battlefield com- development teams alike explore the defined, results can be accurately meas-
manders plan extensively, they realize that unknown. These projects, which I call ured, and measured variations can be used
plans are just a beginning; probing enemy high-exploration factor projects, do not to refine the processes until they are
defenses (creating change) and responding succumb to rigorous, plan-driven meth- repeatable within very close tolerances.
to enemy actions (responding to change) ods. For projects with any degree of explo-
are more important. Battlefield command- The critical issues with high-explo- ration at all, agile developers just do not
ers succeed by defeating the enemy (the ration factor projects are as follows: first, believe these assumptions are valid. This is
mission), not conforming to a plan. identifying them; second, managing them a deep, fundamental divide – and not one
I cannot imagine a battlefield com- in a different way; and third, measuring that can be reconciled to some comfort-
mander saying, “We lost the battle, but by their success differently. Just as winning is able middle ground. It is part of having a
® Capability Maturity Model and CMM are registered in the the primary measure of success for a bat- chaordic (meaning a combination of
U.S. Patent and Trademark Office. tlefield commander, delivering customer chaos and order as coined by Dee Hock,
SM
CMM Integration and CMMI are service marks of
Carnegie Mellon University. value (however the customer defines it) founder and former CEO of Visa

4 CROSSTALK The Journal of Defense Software Engineering October 2002


What Is Agile Software Development?

International) perspective on the world as ware development methodologies over the foundation leads. These are not always
described in the next section. years has been the attempted mismatch of easy questions to answer, and organiza-
While agile practices – refactoring, culture and methodology. Rather than rec- tions will have different answers for dif-
iterative feature-driven cycles, customer ognizing the inherent differences between ferent stages in their evolution and for dif-
focus groups – are applicable to nearly any people, project teams, and organizations, ferent projects in their portfolio.
project, I believe the agile sweet spot is this we denigrate those who have different cul-
exploratory projects problem category. The tures by labeling them unprofessional, An Agile Case Story
more volatile the requirements and the immature, or undisciplined. Or conversely, Jeff De Luca, project director of
more experimental the technology, the we label them bureaucratic, rigid, and Nebulon, an information technology con-
more agile approaches improve the odds closed-minded. For example, you can call sulting firm in Melbourne, Australia,
of success. a well-oiled extreme programming team a offers an example of an agile methodolo-
lot of things, but after watching them gy’s success using feature-driven develop-
The Agile Ecosystem: practice test-first development, pair pro- ment (FDD). De Luca’s project was a
Chaordic, Collaborative, gramming, constant refactoring, and sim- complex commercial lending application
ple design, the last thing you can call them for a large Singapore bank utilizing 50
and Streamlined is undisciplined, immature, or unprofes- people for 15 months (after a short initial-
The agile movement covers a broader set sional. ization period). I tracked De Luca down
of issues than the word methodology con- The second characteristic of agile looking for an FDD case story for my
notes, so I use the word ecosystem to include development is collaborative values and book, and subsequently spent several
the three characteristics that define agile principles. Agile and rigorous organiza- hours on the phone and exchanged many
development: a chaordic perspective, col- tions view people, and how to improve e-mails with him.
laborative values and principles, and bare- their performance, differently. Rigorous Previously, the Singapore lending proj-
ly sufficient methodology. A chaordic per- methodologies are designed to standardize ect had been a colossal failure. Prior to De
spective arises from recognition and people to the process, while agile process- Luca’s involvement in the project, a large,
acceptance of increasing levels of unpre- es are designed to capitalize on each indi- well-known systems integration firm had
dictability in our turbulent economy. vidual’s and each team’s unique strengths: spent two years working on the project
Two concrete ramifications of trying they adapt the process to the people3. and finally declared it undoable. Its deliv-
to manage in an unpredictable environ- Agile organizations focus on building erables included the following: 3,500
ment are that while goals are achievable, individual skills and on fostering a high pages of use cases, an object model with
project details are often unpredictable, and degree of interaction among team mem- hundreds of classes, thousands of attrib-
that the foundation of many process-driv- bers and the project’s customers. Agilists utes (but no methods), and, of course, no
en approaches (the goal of repeatable believe that with today’s complex projects, code. The project – an extensive commer-
processes) is unattainable. In company understanding comes more from face-to- cial, corporate, and consumer lending sys-
after company, I have found successful face interaction than from documentation. tem – incorporated a broad range of lend-
projects that met the customer’s vision, Agilists do not believe that a reliance on ing instruments (from credit cards to large
but in the end, looked nothing like the heavy processes makes up for lack of skill, multi-bank corporate loans) and a breadth
original plan. talent, and knowledge. of lending functions (from prospecting to
Furthermore, truly repeatable process- The third aspect of agile ecosystems is implementation to back-office monitor-
es would be almost mechanical in nature, the concept of a barely sufficient methodol- ing). “The scope was really too big,” said
and no mechanical process could possibly ogy that attempts to answer the question De Luca.
react to the infinite variety of variations of how much structure is enough. To be FDD arose, in name at least, in 1997-
that software projects encounter. The rea- agile, one must balance flexibility and 98 when Nebulon took over the Singapore
son many projects attain their goals has lit- structure, and barely sufficient does not project. De Luca had been using a stream-
tle to do with repeatable processes and mean insufficient. Bare sufficiency lined, light-process framework for many
much to do with the skill and adaptability reduces costs through streamlining but years. Peter Coad, who was brought in to
of the people who are working on the even more importantly, it incorporates the develop the object model for the project,
project. chaordic perspective that creativity and had been advocating very granular, fea-
Hock’s chaordic style is similar to what innovation occur in a slightly messy envi- ture-oriented development but had not
I call leadership-collaboration or adaptive ronment, not a primarily structured one. embedded it in any particular process
management, which is about creating an Too many organizations operate on the model. These two threads came together
environment with the requisite variety to unspoken assumption that “if a little on this project to fashion what was
meet the challenge of extreme projects, process is good, then lots of process will dubbed FDD.
particularly the challenge of high change. be better.” Less than two months into the new
Agile managers understand that Concepts drive action and behavior. project, De Luca’s team was producing
demanding certainty in the face of uncer- Software inspections, or any other soft- demonstrable features for the client. The
tainty is dysfunctional. They set goals and ware engineering technique, will be imple- team spent about a month working on the
constraints that provide boundaries within mented differently depending upon one’s overall object model (the original model
which creativity and innovation can flour- underlying conceptual framework. The and what De Luca refers to as the previ-
ish. They are macromanagers rather than underlying conceptual frameworks behind ous team’s useless cases were trashed).
micromanagers2. agile development and the CMM are dif- They spent another couple of weeks
While an entrepreneurial Silicon Valley ferent and will therefore drive organiza- working on the feature decomposition and
company has one culture, a space shuttle tions to different behaviors. The really short iteration planning. Finally, to
avionics team has another. One of the important questions are about to what demonstrate the project’s viability to a
biggest problems in implementing soft- kind of core capabilities one’s conceptual once-burned and skeptical client, De Luca

October 2002 www.stsc.hill.af.mil 5


Agile Software Development

and his team built a portion of the rela- risks, etc. should be briefly document- equilibrium.
tionship management application as a ed (for example, ASD’s one-page proj- LD is the operational piece in a three-
proof of concept. From that point on, ect data sheet). tiered approach4 that leads to change-tol-
with about four months elapsed, they • Short, iterative, feature-driven, time- erant businesses. It provides a delivery
staffed to 50 people and delivered approx- boxed development cycles. Explora- mechanism for implementing risk entre-
imately 2,000 features in 15 months. The tion should be done in definitive, cus- preneurship. The key in business, accord-
project was completed significantly under tomer-relevant chunks (for example, ing to Charette, is that the opportunity for
budget, and the client, the CEO of the FDD’s feature planning). competitive advantage comes from being
bank, wrote a glowing letter about the • Constant feedback. Exploratory more agile than the competitors in one’s
success of the project. processes require constant feedback to market.
While talking with De Luca, a couple stay on track (for example, Scrum’s LD’s risk entrepreneurship enables
of things struck me about this project. short daily meetings and XP’s pair pro- companies to turn risk into opportunity.
Certainly the FDD process contributed to gramming). Charette defines change tolerance as “the
the project’s success, but when I asked De • Customer involvement. Focusing on ability of an organization to continue to
Luca what made the FDD successful, his business value requires constant inter- operate effectively in the face of high mar-
first response was that the overriding action between customers and devel- ket turbulence.” A change-tolerant busi-
assumption behind the FDD is that it opers (for example, DSDM’s facilitat- ness not only responds to changes in the
embraces and accepts software develop- ed workshops and ASD’s customer marketplace, but also causes changes that
ment as a decidedly human activity. The focus groups). keep competitors off balance. “Most soft-
key, he said, is having good people – good • Technical excellence. Creating and ware systems are not agile, but fragile,”
domain experts, good developers, good maintaining a technically excellent said Charette. “Furthermore, they act as
chief programmers. No process makes up product makes a major contribution to brakes on competitiveness.” Every busi-
for a lack of talent and skill. creating business value today and in ness must deal with change by building a
My guess is that even if the first ven- the future (for example, XP’s refactor- change-tolerant organization that can
dor’s staff had used FDD as a process ing). impose change on competitors.
model, they would not have been success- Some agile approaches focus more Charettes’s work sends three key mes-
ful because they just did not have the heavily on project management and col- sages to agile developers and business
appropriate level of technical and project laboration practices (ASD, Scrum, and stakeholders in information technology.
management talent. However, had they DSDM), while others such as XP focus on First, the wide adoption of ASDEs will
been using a FDD-like agile process, their software development practices, although require strategic selling at senior levels
inability to complete the project might all the approaches touch the six key prac- within organizations. Second, the strategic
have surfaced in less than two years. This tice areas. The rest of this section delves message that will sell ASDEs is the ability
is a clear example of why working code is into four of these approaches, illustrating to pluck opportunity from fast-moving,
the ultimate arbiter of real progress. In the different aspects of each. high-risk exploration situations. And third,
end, thousands of use cases and hundreds proponents of ASDEs must understand
of object model elements did not prove Lean Development and communicate to their customers the
real progress. The most strategy-oriented ASDE is also risks associated with agile approaches and,
the least known: ITABHI, Inc. President therefore, the situations in which they are
A Sampler of Agile Bob Charette’s LD was derived from the and are not appropriate.
principles of lean production used during LD is as much a management chal-
Approaches the restructuring of the Japanese automo- lenge as a set of practices. Charette said,
There are a growing number of agile bile manufacturing industry in the 1980s. “You have to set the bar high enough to
methodologies, or agile software develop- In LD, Charette extends traditional force rethinking traditional practices. LD
ment ecosystems (ASDEs), as I prefer to methodology’s view of change from a risk initiatives focus on accelerating the speed
label them, and a number of agile prac- of loss to be controlled with restrictive of delivering software applications, but
tices such as Scott Ambler’s agile modeling management practices to a view of change not at the expense of higher cost or defect
[1]. The core set of these includes lean as producing opportunities to be pursued rates. These three goals need to be
development (LD), ASD, Scrum, eXtreme using risk entrepreneurship. LD has been achieved concurrently, or it isn’t LD.”
Programming (XP), Crystal methods, used successfully on a number of large
FDD, and DSDM. Authors of all of these telecommunications projects in Europe. Adaptive Software Development
approaches (except LD) participated in The goals of LD are completion in In 1992, I started working on a short
writing the Agile Software Development one-third the time, within one-third the interval, iterative, rapid application devel-
Manifesto [2] and so its principles form a budget, and with one-third the defect rate. opment process that evolved into ASD.
common bond among practitioners of While most other ASDEs are tactical in The original process, developed in con-
these approaches. While individual prac- nature, Charette thinks that the major junction with colleague Sam Bayer, was
tices are varied, they fall into six general changes required to become agile must be used on projects in companies from Wall
categories: initiated from the top of the organization. Street brokerage houses to airlines to
• Visioning. A good visioning practice Organizational strategy becomes the con- telecommunications firms. During the
helps assure that agile projects remain text within which agile processes can next several years, Sam and I (together and
focused on key business values (for operate effectively. Without this strategic separately) successfully delivered more
example, ASD’s product visioning ses- piece, agile development – as all those than 100 projects using these practices.
sion). who have tried to implement ASDEs in During the early to mid-1990s, I also
• Project initiation. A project’s overall organizations can testify – is shunted aside worked with software companies that
scope, objectives, constraints, clients, by the organizational forces that seek were using similar techniques on very

6 CROSSTALK The Journal of Defense Software Engineering October 2002


What Is Agile Software Development?

large projects. not know everything. The ASD life cycle focuses on results,
In the mid-1990s, my interest in com- The second conceptual component of not tasks, and the results are identified as
plex adaptive systems began to add a con- ASD is collaboration. Complex applica- application features. Features are the cus-
ceptual background to the team aspects of tions are not built; they evolve. Complex tomer functionality that is to be developed
the practices and was the catalyst for the applications require that a large volume of during iteration.
name change to ASD. Complexity theory information is collected, analyzed, and The practice of time boxing, or setting
helps us understand unpredictability and applied to the problem – a much larger fixed delivery times for iterations and
that our inability to predict does not imply volume than any individual can handle by projects, has been abused by many who
an inability to make progress. ASD works himself or herself. Although there is use time deadlines incorrectly. Time dead-
with change rather than fighting against it. always room for improvement, most soft- lines used to bludgeon staff into long
In order to thrive in turbulent environ- ware developers are reasonably proficient hours or to cut corners on quality are a
ments, we must have practices that in analysis, programming, testing, and sim- form of tyranny; they undermine a collab-
embrace and respond to change – prac- ilar skills. But turbulent environments are orative environment. It took several years
tices that are adaptable. Even more impor- defined in part by high rates of informa- of managing ASD projects before I real-
tantly, we need people, teams, and organi- tion flow and diverse knowledge require- ized that time boxing was minimally about
zations that are adaptable and agile. ments. Building an e-commerce site time – it was really about focusing and
The practices of ASD are driven by a requires greater diversity of both technol- forcing hard trade-off decisions. In an
belief in continuous adaptation – a differ- ogy and business knowledge than the typ- uncertain environment in which change
ent philosophy and a different life cycle – ical project of five to 10 years ago. In this rates are high, there needs to be a period-
geared to accepting continuous change as high-information-flow environment, in ic forcing function to get work finished.
the norm. In ASD, the static plan-design- which one person or small group cannot As in Barry Boehm’s spiral develop-
build life cycle is replaced by a dynamic ment model [3], analyzing the critical risks
speculate-collaborate-learn life cycle. It is
a life cycle dedicated to continuous learn- “A change-tolerant drives the plans for adaptive iterations.
ASD is also change-tolerant, not viewing
ing and oriented to change, re-evaluation,
peering into an uncertain future, and
business not only change as a problem but seeing the ability
to incorporate change as a competitive
intense collaboration among developers, responds to changes advantage.
management, and customers.
in the marketplace, eXtreme Programming
A Change-Oriented Life Cycle XP, to most aficionados, was developed by
A waterfall development life cycle, based but also causes Kent Beck, Ward Cunningham, and Ron
on an assumption of a relatively stable Jeffries and has, to date, clearly garnered
business environment, becomes over- changes that keep the most interest of any of the agile
whelmed by high change. Planning is one approaches. XP preaches the values of
of the most difficult concepts for engi- competitors off balance.” community, simplicity, feedback, and
neers and managers to re-examine. For courage and is defined, at least in part, by
those raised on the science of reduction- possibly know it all, collaboration skills (the its 12 practices: the planning game, small
ism (reducing everything to its component ability to work jointly to produce results, releases, metaphor, simple design, refac-
parts) and the near-religious belief that share knowledge, or make decisions) are toring, test-first development, pair pro-
careful planning followed by rigorous paramount. gramming, collective ownership, continu-
engineering execution produces the Once we admit to ourselves that we ous integration, 40-hour week, on-site
desired results (we are in control), the idea are fallible, then learning practices – the customer, and coding standards.
that there is no way to “do it right the first learn part of the life cycle – becomes vital There has been so much written about
time” remains foreign. The word plan, for success. Learning is the third compo- XP’s practices that another rehash seems
when used in most organizations, indi- nent in the speculate-collaborate-learn life less important than discussing XP’s
cates a reasonably high degree of certain- cycle. We have to test our knowledge con- impact on software development. The
ty about the desired result. The implicit stantly, using practices like project retro- interest in XP generally comes from the
and explicit goal of conformance to plan spectives and customer focus groups. bottom up, from developers and testers
restricts a manager’s ability to steer the Furthermore, reviews should be done tired of burdensome processes, documen-
project in innovative directions. after each iteration rather than waiting tation, metrics, and formality. These indi-
Speculation, the first conceptual con- until the end of the project. viduals are not abandoning discipline, but
cept, gives us room to explore, to make An ASD life cycle has six basic charac- excessive formality that is often mistaken
clear the realization that we are unsure and teristics: mission-focused, feature-based, for discipline. They are finding new ways
to deviate from plans without fear. It does iterative, time-boxed, risk-driven, and to deliver high-quality software faster and
not mean that planning is obsolete, just change-tolerant. For many projects, the more flexibly.
that planning is acknowledgeably tenuous. requirements may be fuzzy in the begin- XP and other agile approaches are
It means we have to keep delivery itera- ning, but the overall mission that guides forcing organizations to re-examine
tions short and encourage iteration. A the team is well articulated. A mission whether their processes are adding any
team that speculates does not abandon provides boundaries rather than a fixed value to their organizations. Well over 400
planning; it acknowledges the reality of destination. Without a good mission and a individuals have signed the Agile Software
uncertainty. Speculation recognizes the constant mission refinement practice, iter- Development Manifesto Web page, avail-
uncertain nature of complex problems ative life cycles become oscillating life able at: <www.agilealliance.com>. These
and encourages exploration and experi- cycles – swinging back and forth with no individuals reaffirm their desire to deliver
mentation. We can finally admit that we do progress. high-quality software without the burdens

October 2002 www.stsc.hill.af.mil 7


Agile Software Development

of bureaucracy. The DSDM reverses this viewpoint, The Future of Agile


Other important contributions of XP allowing the functionality to vary over the Development
proponents are their views on reducing life of the project as new things are There are fundamental shifts driving
the cost of change during a software’s life learned. However, while functionality is economies, the structure of products that
and their emphasis on technical excel- allowed to vary, control is maintained by we build, and the nature of the processes
lence through refactoring and test-first using time boxes. we use to build products. “These changes
development. XP provides a system of The DSDM also addresses the issues in products, technologies, firms, and mar-
dynamic practices, whose integrity as a of documentation – or lack thereof – a kets are not a passing phenomenon,”
holistic unit has been proven. constant criticism of ASDEs. Because according to Carliss Baldwin, Harvard
Some people think extreme is too one of the principles of the DSDM Business School professor and Kim Clark,
extreme, that XP would be more appeal- relates to the importance of collabora- dean of the Harvard Business School fac-
ing with a more moderate name. I don’t tion, it uses prototypes rather than ulty.
think many people would get excited lengthy documents to capture informa-
about a book on moderate programming. tion. The DSDM recommends only 15
These fundamental changes driven
New markets, new technologies, new work products from its five major devel-
by powerful forces deep in the eco-
ideas aren’t forged from moderation, but opment phases, and several of these are
nomic system, forces which more-
from radically different ideas and the prototypes. There is an interesting com-
over have been at work for many
courage to challenge the status quo. XP ment in the DSDM white paper on con-
years ... we must be prepared to dig
has led the way. tracting:
deep, for the forces that matter are
rooted in the very nature of things,
Dynamic Systems The mere presence of a detailed
and in the processes used to create
Development Method specification may act to the detri-
them. [5]
The DSDM was developed in the United ment of cooperation between the
Kingdom in the mid-1990s. It is an out- parties, encouraging both parties
In the foreword to “Planning eXtreme
growth of, and extension to, rapid appli- to hide behind the specification
Programming,” Tom DeMarco makes the
cation development practices. The rather than seeking mutual benefi-
DSDM boasts the best-supported train- cial solutions. [4] analogy between military history and soft-
ing and documentation of any ASDE, at ware development as each swing from the
least in Europe. With respect to work products, the relative advantages of armor to those of
Each of the major phases of the DSDM, unlike rigorous methodologies, mobility. DeMarco says:
DSDM development process – functional does not offer detailed documentation
model iteration, design-and-build itera- formats for its 15 defined work products. In the field of IT, we are just emerg-
tion, and implementation – are them- Instead, the DSDM work product guide- ing from a time in which armor
selves iterative processes. The DSDM’s lines offer a brief description, a listing of (process) has been king. And now
use of three interactive iterative models the purposes, and a half-dozen or so qual- we are moving into a time when
and time boxes can be used to construct ity criteria questions for each work prod- only mobility matters. [6]
very flexible project plans. uct.
The functional model iteration is a Another area that the DSDM focuses Agile development is not defined by a
process of gathering and prototyping on is establishing and managing the prop- small set of practices and techniques.
functional requirements based on an ini- er culture for a project. The manual Agile development defines a strategic
tial list of prioritized requirements. describes, for example, the different capability, a capability to create and
Nonfunctional requirements are also emphasis of project managers and points respond to change, a capability to balance
specified during this phase. The design- out how difficult the transition can be for flexibility and structure, a capability to
and-build iteration refines the prototypes project managers steeped in traditional draw creativity and innovation out of a
to meet all requirements (functional and approaches. A passage from the DSDM development team, and a capability to lead
nonfunctional) and engineers the soft- manual illustrates this point: organizations through turbulence and
ware to meet those requirements. One set uncertainty.
of business functions (features) may go A traditional project manager will Agile development does not abandon
through both functional model and normally focus on agreeing a structure, but attempts to balance flexibil-
design-and-build iterations during a time detailed contract with customers ity and structure – trying to figure out that
box, and then another set of features goes about the totality of the system to delicate balance between chaos and rigidi-
through the same processes in a second be delivered along with the costs ty. The greater the uncertainty, the faster
time box. Implementation deploys the and time scales. In a DSDM proj- the pace of change, and the lower the
system into a user’s environment. ect, the project manager is focused probability that success will be found in
The DSDM also addresses other on setting up a collaborative rela- structure. Plan-driven methodologies have
issues common to ASDEs. First, it explic- tionship with the customers. [4] a definite place for some problem
itly states the difference between the domains just as individual practices (con-
DSDM and traditional methodologies The focal point for a DSDM project figuration management for example) have
with respect to flexible requirements. The manager shifts from the traditional a definite place in the most agile of soft-
traditional view, according to the DSDM emphasis on tasks and schedules to sus- ware development projects. In a less
manual, is that functionality stays relative- taining progress, getting agreement on volatile era, rigorous processes were appli-
ly fixed (after it is established in the origi- requirement priorities, managing cus- cable for a wide range of projects. In an
nal requirements specifications), while tomer relationships, and supporting the era in which traditional management styles
time and resources are allowed to vary. team culture and motivation. dominated, plan-driven software develop-

8 CROSSTALK The Journal of Defense Software Engineering October 2002


What Is Agile Software Development?

ment approaches fit well. Modularity. Cambridge: The MIT


But as Bob Dylan sang, “Times, they Press, 2000. COMING EVENTS
are a-changin’.” Volatility and uncertainty 6. Beck, Kent, and Martin Fowler. October 14-16
increasingly defines today’s business, and Planning eXtreme Programming. 20 th Annual Pacific Northwest
even today’s military environment. Boston: Addison-Wesley, 2001.
Talented technical people want to work in Software Quality Conference
an organization in which they have more Notes
control over how they work and how they 1. This article is adapted from Jim
interact with peers, customers, and man- Highsmith’s book “Agile Software Portland, OR
agement. Problems are changing, people Development Ecosystems.” Addison- www.pnsqc.org
are changing, and ideas are changing. Wesley, 2002. (Article quotes and
While there are still opportunities for examples taken from this book.) November 3-6
plan-driven style development and man- 2. For additional information, see James 3 Annual Amplifying Your Effectiveness
rd

agement, I believe growth lies in being A. Highsmith. Adaptive Software (AYE) Conference 2002
agile and flexible. Development: A Collaborative App- Phoenix, AZ
Throughout the last three years, I have roach to Managing Complex Systems. www.ayeconference.com
used agile methods with project teams in New York: Dorset House, 2000.
India, Canada, Norway, the United States, 3. For extensive research in this area, see
New Zealand, Poland, and Australia. Buckingham, Marcus, and Curt November 4-8
Companies in these countries are strug- Coffman. First, Break All the Rules: Software Testing Analysis
gling with exploratory projects that run What the World’s Greatest Managers and Review Conference
the gamut, including an e-commerce infra- Do Differently. New York: Simon & Anaheim, CA
structure product, a clinical drug-trial Schuster, 1999, and Buckingham, www.sqe.com/starwest
monitoring application, 300,000 lines of Marcus and Donald O. Clifton. Now,
embedded C code in a new cell-phone Discover Your Strengths. New York: November 11-14
chip, a worldwide financial system prod- Simon & Schuster, 2001. National Defense Industrial Association
uct, a myriad of internal IT applications, 4. The three tiers are Risk Leadership,
the complete business system for a dot- Denver, CO
Risk Entrepreneurship, and Lean www.ndia.org
com start-up (that is still in business), and Development.
an oil-field geophysical data gathering and
analysis system. About the Author November 18-21
These companies want to be more Jim Highsmith is International Conference on
agile: They want to create change for their director of the Cutter Software Process Improvement
competitors and respond quickly to mar- Consortium’s Agile Washington, DC
ket conditions. They plan, but they are not www.software-process-institute.com
Project Management
blinded by those plans. They focus on
Practice, author of
delivering customer value, not adding up
“Agile Software Deve- February 24-27, 2003
how many processes they have in place.
They document, but they do not get lost lopment Ecosystems Software Engineering Process
in piles of paper. They rough out blue- (2002)” and “Adaptive Software Group Conference
prints (models), but they concentrate on Development: A Collaborative App-
creating working software. They focus on roach to Managing Complex Systems
individuals and their skills and on the (2000),” and winner of the 2000 Jolt
intense interaction of development team Award. He has more than 30 years
members among themselves and with cus- experience as a consultant, software
tomers and management. They deliver developer, manager, and writer. In the Boston, MA
results in a turbulent, messy, ever-chang- last 10 years, he has worked with infor- www.sei.cmu.edu/sepg/
ing, ever-exciting marketplace.◆ mation technology organizations,
industrial product companies, and
References April 28-May 1, 2003
software companies in the United
1. Ambler, Scott. Agile Modeling. New States, Europe, Canada, South Africa, Software Technology Conference 2003
York: John Wiley, 2002. Australia, Japan, India, and New
2. AgileAlliance. “Agile Software Zealand to help them adapt to the
Development Manifesto.” 13 Feb. accelerated pace of development in
2001 <www.agilemanifesto.org>. Salt Lake City, UT
increasingly complex, uncertain envi-
3. Boehm, Barry. “A Spiral Model of www.stc-online.org
ronments.
Software Development Enhance-
ment.” IEEE Computer May 1988. Cutter Consortium May 3-10, 2003
4. DSDM Consortium. Dynamic Sys- 2288 North Coulter Drive International Conference on
tems Development Method. Version 3.
United Kingdom <www.dsdm.org>.
Flagstaff, AZ 86004 Software Engineering
Phone: (781) 648-8700 Portland, OR
5. Baldwin, Carliss Y., and Kim B. Clark.
Design Rules – Vol. 1: The Power of E-mail: jim@jimhighsmith.com www.icse-conferences.org/2003

October 2002 www.stsc.hill.af.mil 9

You might also like