“Never do anything that is a waste oftime – and be prepared to wage

long, tedious wars over this principle,”said Michael O’Connor, project managerat Trimble Navigation in Christchurch,New Zealand. This product group atTrimble is typical of the homegrownapproach to agile software developmentmethodologies.

While interest in agile methodologieshas blossomed in the past two years, itsroots go back more than a decade. Teamsusing early versions of Scrum, DynamicSystems Development Methodology(DSDM), and adaptive software develop-ment (ASD) were delivering successfulprojects in the early- to mid-1990s.

This article attempts to answer thequestion, “What constitutes agile softwaredevelopment?” Because of the breadth ofagile approaches and the people who prac-tice them, this is not as easy a question toanswer as one might expect. I will try toanswer this question by first focusing onthe sweet-spot problem domain for agileapproaches. Then I will delve into thethree dimensions that I refer to as agileecosystems: barely sufficient methodology,collaborative values, and chaordic per-spective. Finally, I will examine several ofthese agile ecosystems.

The Agile ProblemDomain: Fitting theProcess to the ProjectAll problems are different and require dif-ferent strategies. While battlefield com-manders plan extensively, they realize thatplans are just a beginning; probing enemydefenses (creating change) and respondingto enemy actions (responding to change)are more important. Battlefield command-ers succeed by defeating the enemy (themission), not conforming to a plan.

I cannot imagine a battlefield com-mander saying, “We lost the battle, but by

golly, we were successful because we fol-lowed our plan to the letter.” Battlefieldsare messy, turbulent, uncertain, and full ofchange. No battlefield commander wouldsay, “If we just plan this battle long andhard enough, and put repeatable process-es in place, we can eliminate change earlyin the battle and not have to deal with itlater on.”

A growing number of software proj-ects operate in the equivalent of a battlezone – they are extreme projects. This iswhere agile approaches shine. Projectteams operating in this zone attempt toutilize leading or bleeding-edge technolo-

gies, respond to erratic requirementschanges, and deliver products quickly.Projects may have a relatively clear mis-sion, but the specific requirements can bevolatile and evolving as customers anddevelopment teams alike explore theunknown. These projects, which I callhigh-exploration factor projects, do notsuccumb to rigorous, plan-driven meth-ods.

The critical issues with high-explo-ration factor projects are as follows: first,identifying them; second, managing themin a different way; and third, measuringtheir success differently. Just as winning isthe primary measure of success for a bat-tlefield commander, delivering customervalue (however the customer defines it)

measures success for the agile projectmanager. Conformance to plan has littlemeaning in either case. If we want to beagile, we have to reward agility.

There is, however, a critical differencebetween managing a battle and managingwarehouse logistics. Battlefields are man-aged by constant monitoring of condi-tions and rapid course alterations – byempirical processes. Adapting to changingconditions is vital. Conversely, managingwarehouse logistics is a process that canbe described by calculations involvingmaterials on hand, deliveries, and ship-ments; managing can be described as adefined process, one that involves a relativelyhigh degree of predictability and algorith-mic precision. Many manufacturing plantsoperate as defined processes.

The concepts and assumptions behindempirical and defined processes are funda-mentally and irreconcilably different. Thepractices of agile software development –short iterations, continuous testing, self-organizing teams, constant collaboration(daily integration meetings and pair pro-gramming for example), and frequent re-planning based on current reality (ratherthan six-month- old plans) – are all gearedto the understanding of software develop-ment as an empirical process.

On the other hand, the fundamentalbasis of the Capability Maturity Model®

(CMM®) and CMM IntegrationSM

(CMMISM) is a belief in software develop-ment as a defined process. As such, taskscan be defined in detail, algorithms can bedefined, results can be accurately meas-ured, and measured variations can be usedto refine the processes until they arerepeatable within very close tolerances.

For projects with any degree of explo-ration at all, agile developers just do notbelieve these assumptions are valid. This isa deep, fundamental divide – and not onethat can be reconciled to some comfort-able middle ground. It is part of having achaordic (meaning a combination ofchaos and order as coined by Dee Hock,founder and former CEO of Visa

Agile Software Development

4 CROSSTALK The Journal of Defense Software Engineering October 2002

What Is Agile Software Development?1

Jim HighsmithCutter Consortium

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

® Capability Maturity Model and CMM are registered in theU.S. Patent and Trademark Office.

SM CMM Integration and CMMI are service marks ofCarnegie Mellon University.

“Projects may have arelatively clear mission,

but the specificrequirements can bevolatile and evolvingas customers and

development teams alikeexplore the unknown.”

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

What Is Agile Software Development?

International) perspective on the world asdescribed in the next section.

While agile practices – refactoring,iterative feature-driven cycles, customerfocus groups – are applicable to nearly anyproject, I believe the agile sweet spot is thisexploratory projects problem category. Themore volatile the requirements and themore experimental the technology, themore agile approaches improve the oddsof success.

The Agile Ecosystem:Chaordic, Collaborative,and StreamlinedThe agile movement covers a broader setof issues than the word methodology con-notes, so I use the word ecosystem to includethe three characteristics that define agiledevelopment: a chaordic perspective, col-laborative values and principles, and bare-ly sufficient methodology. A chaordic per-spective arises from recognition andacceptance of increasing levels of unpre-dictability in our turbulent economy.

Two concrete ramifications of tryingto manage in an unpredictable environ-ment are that while goals are achievable,project details are often unpredictable, andthat the foundation of many process-driv-en approaches (the goal of repeatableprocesses) is unattainable. In companyafter company, I have found successfulprojects that met the customer’s vision,but in the end, looked nothing like theoriginal plan.

Furthermore, truly repeatable process-es would be almost mechanical in nature,and no mechanical process could possiblyreact to the infinite variety of variationsthat software projects encounter. The rea-son many projects attain their goals has lit-tle to do with repeatable processes andmuch to do with the skill and adaptabilityof the people who are working on theproject.

Hock’s chaordic style is similar to whatI call leadership-collaboration or adaptivemanagement, which is about creating anenvironment with the requisite variety tomeet the challenge of extreme projects,particularly the challenge of high change.

Agile managers understand thatdemanding certainty in the face of uncer-tainty is dysfunctional. They set goals andconstraints that provide boundaries withinwhich creativity and innovation can flour-ish. They are macromanagers rather thanmicromanagers2.

While an entrepreneurial Silicon Valleycompany has one culture, a space shuttleavionics team has another. One of thebiggest problems in implementing soft-

ware development methodologies over theyears has been the attempted mismatch ofculture and methodology. Rather than rec-ognizing the inherent differences betweenpeople, project teams, and organizations,we denigrate those who have different cul-tures by labeling them unprofessional,immature, or undisciplined. Or conversely,we label them bureaucratic, rigid, andclosed-minded. For example, you can calla well-oiled extreme programming team alot of things, but after watching thempractice test-first development, pair pro-gramming, constant refactoring, and sim-ple design, the last thing you can call themis undisciplined, immature, or unprofes-sional.

The second characteristic of agiledevelopment is collaborative values andprinciples. Agile and rigorous organiza-tions view people, and how to improvetheir performance, differently. Rigorousmethodologies are designed to standardizepeople to the process, while agile process-es are designed to capitalize on each indi-vidual’s and each team’s unique strengths:they adapt the process to the people3.

Agile organizations focus on buildingindividual skills and on fostering a highdegree of interaction among team mem-bers and the project’s customers. Agilistsbelieve that with today’s complex projects,understanding comes more from face-to-face interaction than from documentation.Agilists do not believe that a reliance onheavy processes makes up for lack of skill,talent, and knowledge.

The third aspect of agile ecosystems isthe concept of a barely sufficient methodol-ogy that attempts to answer the questionof how much structure is enough. To beagile, one must balance flexibility andstructure, and barely sufficient does notmean insufficient. Bare sufficiencyreduces costs through streamlining buteven more importantly, it incorporates thechaordic perspective that creativity andinnovation occur in a slightly messy envi-ronment, not a primarily structured one.Too many organizations operate on theunspoken assumption that “if a littleprocess is good, then lots of process willbe better.”

Concepts drive action and behavior.Software inspections, or any other soft-ware engineering technique, will be imple-mented differently depending upon one’sunderlying conceptual framework. Theunderlying conceptual frameworks behindagile development and the CMM are dif-ferent and will therefore drive organiza-tions to different behaviors. The reallyimportant questions are about to whatkind of core capabilities one’s conceptual

foundation leads. These are not alwayseasy questions to answer, and organiza-tions will have different answers for dif-ferent stages in their evolution and for dif-ferent projects in their portfolio.

An Agile Case StoryJeff De Luca, project director ofNebulon, an information technology con-sulting firm in Melbourne, Australia,offers an example of an agile methodolo-gy’s success using feature-driven develop-ment (FDD). De Luca’s project was acomplex commercial lending applicationfor a large Singapore bank utilizing 50people for 15 months (after a short initial-ization period). I tracked De Luca downlooking for an FDD case story for mybook, and subsequently spent severalhours on the phone and exchanged manye-mails with him.

Previously, the Singapore lending proj-ect had been a colossal failure. Prior to DeLuca’s involvement in the project, a large,well-known systems integration firm hadspent two years working on the projectand finally declared it undoable. Its deliv-erables included the following: 3,500pages of use cases, an object model withhundreds of classes, thousands of attrib-utes (but no methods), and, of course, nocode. The project – an extensive commer-cial, corporate, and consumer lending sys-tem – incorporated a broad range of lend-ing instruments (from credit cards to largemulti-bank corporate loans) and a breadthof lending functions (from prospecting toimplementation to back-office monitor-ing). “The scope was really too big,” saidDe Luca.

FDD arose, in name at least, in 1997-98 when Nebulon took over the Singaporeproject. De Luca had been using a stream-lined, light-process framework for manyyears. Peter Coad, who was brought in todevelop the object model for the project,had been advocating very granular, fea-ture-oriented development but had notembedded it in any particular processmodel. These two threads came togetheron this project to fashion what wasdubbed FDD.

Less than two months into the newproject, De Luca’s team was producingdemonstrable features for the client. Theteam spent about a month working on theoverall object model (the original modeland what De Luca refers to as the previ-ous team’s useless cases were trashed).They spent another couple of weeksworking on the feature decomposition andshort iteration planning. Finally, todemonstrate the project’s viability to aonce-burned and skeptical client, De Luca

Agile Software Development

6 CROSSTALK The Journal of Defense Software Engineering October 2002

and his team built a portion of the rela-tionship management application as aproof of concept. From that point on,with about four months elapsed, theystaffed to 50 people and delivered approx-imately 2,000 features in 15 months. Theproject was completed significantly underbudget, and the client, the CEO of thebank, wrote a glowing letter about thesuccess of the project.

While talking with De Luca, a coupleof things struck me about this project.Certainly the FDD process contributed tothe project’s success, but when I asked DeLuca what made the FDD successful, hisfirst response was that the overridingassumption behind the FDD is that itembraces and accepts software develop-ment as a decidedly human activity. Thekey, he said, is having good people – gooddomain experts, good developers, goodchief programmers. No process makes upfor a lack of talent and skill.

My guess is that even if the first ven-dor’s staff had used FDD as a processmodel, they would not have been success-ful because they just did not have theappropriate level of technical and projectmanagement talent. However, had theybeen using a FDD-like agile process, theirinability to complete the project mighthave surfaced in less than two years. Thisis a clear example of why working code isthe ultimate arbiter of real progress. In theend, thousands of use cases and hundredsof object model elements did not provereal progress.

A Sampler of AgileApproachesThere are a growing number of agilemethodologies, or agile software develop-ment ecosystems (ASDEs), as I prefer tolabel them, and a number of agile prac-tices such as Scott Ambler’s agile modeling[1]. The core set of these includes leandevelopment (LD), ASD, Scrum, eXtremeProgramming (XP), Crystal methods,FDD, and DSDM. Authors of all of theseapproaches (except LD) participated inwriting the Agile Software DevelopmentManifesto [2] and so its principles form acommon bond among practitioners ofthese approaches. While individual prac-tices are varied, they fall into six generalcategories:• Visioning. A good visioning practice

helps assure that agile projects remainfocused on key business values (forexample, ASD’s product visioning ses-sion).

• Project initiation. A project’s overallscope, objectives, constraints, clients,

risks, etc. should be briefly document-ed (for example, ASD’s one-page proj-ect data sheet).

• Short, iterative, feature-driven, time-boxed development cycles. Explora-tion should be done in definitive, cus-tomer-relevant chunks (for example,FDD’s feature planning).

• Constant feedback. Exploratoryprocesses require constant feedback tostay on track (for example, Scrum’sshort daily meetings and XP’s pair pro-gramming).

• Customer involvement. Focusing onbusiness value requires constant inter-action between customers and devel-opers (for example, DSDM’s facilitat-ed workshops and ASD’s customerfocus groups).

• Technical excellence. Creating andmaintaining a technically excellentproduct makes a major contribution tocreating business value today and inthe future (for example, XP’s refactor-ing).Some agile approaches focus more

heavily on project management and col-laboration practices (ASD, Scrum, andDSDM), while others such as XP focus onsoftware development practices, althoughall the approaches touch the six key prac-tice areas. The rest of this section delvesinto four of these approaches, illustratingdifferent aspects of each.

Lean DevelopmentThe most strategy-oriented ASDE is alsothe least known: ITABHI, Inc. PresidentBob Charette’s LD was derived from theprinciples of lean production used duringthe restructuring of the Japanese automo-bile manufacturing industry in the 1980s.In LD, Charette extends traditionalmethodology’s view of change from a riskof loss to be controlled with restrictivemanagement practices to a view of changeas producing opportunities to be pursuedusing risk entrepreneurship. LD has beenused successfully on a number of largetelecommunications projects in Europe.

The goals of LD are completion inone-third the time, within one-third thebudget, and with one-third the defect rate.While most other ASDEs are tactical innature, Charette thinks that the majorchanges required to become agile must beinitiated from the top of the organization.Organizational strategy becomes the con-text within which agile processes canoperate effectively. Without this strategicpiece, agile development – as all thosewho have tried to implement ASDEs inorganizations can testify – is shunted asideby the organizational forces that seek

equilibrium.LD is the operational piece in a three-

tiered approach4 that leads to change-tol-erant businesses. It provides a deliverymechanism for implementing risk entre-preneurship. The key in business, accord-ing to Charette, is that the opportunity forcompetitive advantage comes from beingmore agile than the competitors in one’smarket.

LD’s risk entrepreneurship enablescompanies to turn risk into opportunity.Charette defines change tolerance as “theability of an organization to continue tooperate effectively in the face of high mar-ket turbulence.” A change-tolerant busi-ness not only responds to changes in themarketplace, but also causes changes thatkeep competitors off balance. “Most soft-ware systems are not agile, but fragile,”said Charette. “Furthermore, they act asbrakes on competitiveness.” Every busi-ness must deal with change by building achange-tolerant organization that canimpose change on competitors.

Charettes’s work sends three key mes-sages to agile developers and businessstakeholders in information technology.First, the wide adoption of ASDEs willrequire strategic selling at senior levelswithin organizations. Second, the strategicmessage that will sell ASDEs is the abilityto pluck opportunity from fast-moving,high-risk exploration situations. And third,proponents of ASDEs must understandand communicate to their customers therisks associated with agile approaches and,therefore, the situations in which they areand are not appropriate.

LD is as much a management chal-lenge as a set of practices. Charette said,“You have to set the bar high enough toforce rethinking traditional practices. LDinitiatives focus on accelerating the speedof delivering software applications, butnot at the expense of higher cost or defectrates. These three goals need to beachieved concurrently, or it isn’t LD.”

Adaptive Software DevelopmentIn 1992, I started working on a shortinterval, iterative, rapid application devel-opment process that evolved into ASD.The original process, developed in con-junction with colleague Sam Bayer, wasused on projects in companies from WallStreet brokerage houses to airlines totelecommunications firms. During thenext several years, Sam and I (together andseparately) successfully delivered morethan 100 projects using these practices.During the early to mid-1990s, I alsoworked with software companies thatwere using similar techniques on very

What Is Agile Software Development?

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

large projects.In the mid-1990s, my interest in com-

plex adaptive systems began to add a con-ceptual background to the team aspects ofthe practices and was the catalyst for thename change to ASD. Complexity theoryhelps us understand unpredictability andthat our inability to predict does not implyan inability to make progress. ASD workswith change rather than fighting against it.In order to thrive in turbulent environ-ments, we must have practices thatembrace and respond to change – prac-tices that are adaptable. Even more impor-tantly, we need people, teams, and organi-zations that are adaptable and agile.

The practices of ASD are driven by abelief in continuous adaptation – a differ-ent philosophy and a different life cycle –geared to accepting continuous change asthe norm. In ASD, the static plan-design-build life cycle is replaced by a dynamicspeculate-collaborate-learn life cycle. It isa life cycle dedicated to continuous learn-ing and oriented to change, re-evaluation,peering into an uncertain future, andintense collaboration among developers,management, and customers.

A Change-Oriented Life CycleA waterfall development life cycle, basedon an assumption of a relatively stablebusiness environment, becomes over-whelmed by high change. Planning is oneof the most difficult concepts for engi-neers and managers to re-examine. Forthose raised on the science of reduction-ism (reducing everything to its componentparts) and the near-religious belief thatcareful planning followed by rigorousengineering execution produces thedesired results (we are in control), the ideathat there is no way to “do it right the firsttime” remains foreign. The word plan,when used in most organizations, indi-cates a reasonably high degree of certain-ty about the desired result. The implicitand explicit goal of conformance to planrestricts a manager’s ability to steer theproject in innovative directions.

Speculation, the first conceptual con-cept, gives us room to explore, to makeclear the realization that we are unsure andto deviate from plans without fear. It doesnot mean that planning is obsolete, justthat planning is acknowledgeably tenuous.It means we have to keep delivery itera-tions short and encourage iteration. Ateam that speculates does not abandonplanning; it acknowledges the reality ofuncertainty. Speculation recognizes theuncertain nature of complex problemsand encourages exploration and experi-mentation. We can finally admit that we do

not know everything.The second conceptual component of

ASD is collaboration. Complex applica-tions are not built; they evolve. Complexapplications require that a large volume ofinformation is collected, analyzed, andapplied to the problem – a much largervolume than any individual can handle byhimself or herself. Although there isalways room for improvement, most soft-ware developers are reasonably proficientin analysis, programming, testing, and sim-ilar skills. But turbulent environments aredefined in part by high rates of informa-tion flow and diverse knowledge require-ments. Building an e-commerce siterequires greater diversity of both technol-ogy and business knowledge than the typ-ical project of five to 10 years ago. In thishigh-information-flow environment, inwhich one person or small group cannot

possibly know it all, collaboration skills (theability to work jointly to produce results,share knowledge, or make decisions) areparamount.

Once we admit to ourselves that weare fallible, then learning practices – thelearn part of the life cycle – becomes vitalfor success. Learning is the third compo-nent in the speculate-collaborate-learn lifecycle. We have to test our knowledge con-stantly, using practices like project retro-spectives and customer focus groups.Furthermore, reviews should be doneafter each iteration rather than waitinguntil the end of the project.

An ASD life cycle has six basic charac-teristics: mission-focused, feature-based,iterative, time-boxed, risk-driven, andchange-tolerant. For many projects, therequirements may be fuzzy in the begin-ning, but the overall mission that guidesthe team is well articulated. A missionprovides boundaries rather than a fixeddestination. Without a good mission and aconstant mission refinement practice, iter-ative life cycles become oscillating lifecycles – swinging back and forth with noprogress.

The ASD life cycle focuses on results,not tasks, and the results are identified asapplication features. Features are the cus-tomer functionality that is to be developedduring iteration.

The practice of time boxing, or settingfixed delivery times for iterations andprojects, has been abused by many whouse time deadlines incorrectly. Time dead-lines used to bludgeon staff into longhours or to cut corners on quality are aform of tyranny; they undermine a collab-orative environment. It took several yearsof managing ASD projects before I real-ized that time boxing was minimally abouttime – it was really about focusing andforcing hard trade-off decisions. In anuncertain environment in which changerates are high, there needs to be a period-ic forcing function to get work finished.

As in Barry Boehm’s spiral develop-ment model [3], analyzing the critical risksdrives the plans for adaptive iterations.ASD is also change-tolerant, not viewingchange as a problem but seeing the abilityto incorporate change as a competitiveadvantage.

eXtreme ProgrammingXP, to most aficionados, was developed byKent Beck, Ward Cunningham, and RonJeffries and has, to date, clearly garneredthe most interest of any of the agileapproaches. XP preaches the values ofcommunity, simplicity, feedback, andcourage and is defined, at least in part, byits 12 practices: the planning game, smallreleases, metaphor, simple design, refac-toring, test-first development, pair pro-gramming, collective ownership, continu-ous integration, 40-hour week, on-sitecustomer, and coding standards.

There has been so much written aboutXP’s practices that another rehash seemsless important than discussing XP’simpact on software development. Theinterest in XP generally comes from thebottom up, from developers and testerstired of burdensome processes, documen-tation, metrics, and formality. These indi-viduals are not abandoning discipline, butexcessive formality that is often mistakenfor discipline. They are finding new waysto deliver high-quality software faster andmore flexibly.

XP and other agile approaches areforcing organizations to re-examinewhether their processes are adding anyvalue to their organizations. Well over 400individuals have signed the Agile SoftwareDevelopment Manifesto Web page, avail-able at: <www.agilealliance.com>. Theseindividuals reaffirm their desire to deliverhigh-quality software without the burdens

“A change-tolerantbusiness not only

responds to changesin the marketplace,

but also causeschanges that keep

competitors off balance.”

Agile Software Development

8 CROSSTALK The Journal of Defense Software Engineering October 2002

of bureaucracy.Other important contributions of XP

proponents are their views on reducingthe cost of change during a software’s lifeand their emphasis on technical excel-lence through refactoring and test-firstdevelopment. XP provides a system ofdynamic practices, whose integrity as aholistic unit has been proven.

Some people think extreme is tooextreme, that XP would be more appeal-ing with a more moderate name. I don’tthink many people would get excitedabout a book on moderate programming.New markets, new technologies, newideas aren’t forged from moderation, butfrom radically different ideas and thecourage to challenge the status quo. XPhas led the way.

Dynamic SystemsDevelopment MethodThe DSDM was developed in the UnitedKingdom in the mid-1990s. It is an out-growth of, and extension to, rapid appli-cation development practices. TheDSDM boasts the best-supported train-ing and documentation of any ASDE, atleast in Europe.

Each of the major phases of theDSDM development process – functionalmodel iteration, design-and-build itera-tion, and implementation – are them-selves iterative processes. The DSDM’suse of three interactive iterative modelsand time boxes can be used to constructvery flexible project plans.

The functional model iteration is aprocess of gathering and prototypingfunctional requirements based on an ini-tial list of prioritized requirements.Nonfunctional requirements are alsospecified during this phase. The design-and-build iteration refines the prototypesto meet all requirements (functional andnonfunctional) and engineers the soft-ware to meet those requirements. One setof business functions (features) may gothrough both functional model anddesign-and-build iterations during a timebox, and then another set of features goesthrough the same processes in a secondtime box. Implementation deploys thesystem into a user’s environment.

The DSDM also addresses otherissues common to ASDEs. First, it explic-itly states the difference between theDSDM and traditional methodologieswith respect to flexible requirements. Thetraditional view, according to the DSDMmanual, is that functionality stays relative-ly fixed (after it is established in the origi-nal requirements specifications), whiletime and resources are allowed to vary.

The DSDM reverses this viewpoint,allowing the functionality to vary over thelife of the project as new things arelearned. However, while functionality isallowed to vary, control is maintained byusing time boxes.

The DSDM also addresses the issuesof documentation – or lack thereof – aconstant criticism of ASDEs. Becauseone of the principles of the DSDMrelates to the importance of collabora-tion, it uses prototypes rather thanlengthy documents to capture informa-tion. The DSDM recommends only 15work products from its five major devel-opment phases, and several of these areprototypes. There is an interesting com-ment in the DSDM white paper on con-tracting:

The mere presence of a detailedspecification may act to the detri-ment of cooperation between theparties, encouraging both partiesto hide behind the specificationrather than seeking mutual benefi-cial solutions. [4]

With respect to work products, theDSDM, unlike rigorous methodologies,does not offer detailed documentationformats for its 15 defined work products.Instead, the DSDM work product guide-lines offer a brief description, a listing ofthe purposes, and a half-dozen or so qual-ity criteria questions for each work prod-uct.

Another area that the DSDM focuseson is establishing and managing the prop-er culture for a project. The manualdescribes, for example, the differentemphasis of project managers and pointsout how difficult the transition can be forproject managers steeped in traditionalapproaches. A passage from the DSDMmanual illustrates this point:

A traditional project manager willnormally focus on agreeing adetailed contract with customersabout the totality of the system tobe delivered along with the costsand time scales. In a DSDM proj-ect, the project manager is focusedon setting up a collaborative rela-tionship with the customers. [4]

The focal point for a DSDM projectmanager shifts from the traditionalemphasis on tasks and schedules to sus-taining progress, getting agreement onrequirement priorities, managing cus-tomer relationships, and supporting theteam culture and motivation.

The Future of AgileDevelopmentThere are fundamental shifts drivingeconomies, the structure of products thatwe build, and the nature of the processeswe use to build products. “These changesin products, technologies, firms, and mar-kets are not a passing phenomenon,”according to Carliss Baldwin, HarvardBusiness School professor and Kim Clark,dean of the Harvard Business School fac-ulty.

These fundamental changes drivenby powerful forces deep in the eco-nomic system, forces which more-over have been at work for manyyears ... we must be prepared to digdeep, for the forces that matter arerooted in the very nature of things,and in the processes used to createthem. [5]

In the foreword to “Planning eXtremeProgramming,” Tom DeMarco makes theanalogy between military history and soft-ware development as each swing from therelative advantages of armor to those ofmobility. DeMarco says:

In the field of IT, we are just emerg-ing from a time in which armor(process) has been king. And nowwe are moving into a time whenonly mobility matters. [6]

Agile development is not defined by asmall set of practices and techniques.Agile development defines a strategiccapability, a capability to create andrespond to change, a capability to balanceflexibility and structure, a capability todraw creativity and innovation out of adevelopment team, and a capability to leadorganizations through turbulence anduncertainty.

Agile development does not abandonstructure, but attempts to balance flexibil-ity and structure – trying to figure out thatdelicate balance between chaos and rigidi-ty. The greater the uncertainty, the fasterthe pace of change, and the lower theprobability that success will be found instructure. Plan-driven methodologies havea definite place for some problemdomains just as individual practices (con-figuration management for example) havea definite place in the most agile of soft-ware development projects. In a lessvolatile era, rigorous processes were appli-cable for a wide range of projects. In anera in which traditional management stylesdominated, plan-driven software develop-

What Is Agile Software Development?

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

ment approaches fit well.But as Bob Dylan sang, “Times, they

are a-changin’.” Volatility and uncertaintyincreasingly defines today’s business, andeven today’s military environment.Talented technical people want to work inan organization in which they have morecontrol over how they work and how theyinteract with peers, customers, and man-agement. Problems are changing, peopleare changing, and ideas are changing.While there are still opportunities forplan-driven style development and man-agement, I believe growth lies in beingagile and flexible.

Throughout the last three years, I haveused agile methods with project teams inIndia, Canada, Norway, the United States,New Zealand, Poland, and Australia.Companies in these countries are strug-gling with exploratory projects that runthe gamut, including an e-commerce infra-structure product, a clinical drug-trialmonitoring application, 300,000 lines ofembedded C code in a new cell-phonechip, a worldwide financial system prod-uct, a myriad of internal IT applications,the complete business system for a dot-com start-up (that is still in business), andan oil-field geophysical data gathering andanalysis system.

These companies want to be moreagile: They want to create change for theircompetitors and respond quickly to mar-ket conditions. They plan, but they are notblinded by those plans. They focus ondelivering customer value, not adding uphow many processes they have in place.They document, but they do not get lostin piles of paper. They rough out blue-prints (models), but they concentrate oncreating working software. They focus onindividuals and their skills and on theintense interaction of development teammembers among themselves and with cus-tomers and management. They deliverresults in a turbulent, messy, ever-chang-ing, ever-exciting marketplace.◆

References1. Ambler, Scott. Agile Modeling. New

York: John Wiley, 2002.2. AgileAlliance. “Agile Software

Development Manifesto.” 13 Feb.2001 <www.agilemanifesto.org>.

3. Boehm, Barry. “A Spiral Model ofSoftware Development Enhance-ment.” IEEE Computer May 1988.

4. DSDM Consortium. Dynamic Sys-tems Development Method. Version 3.United Kingdom <www.dsdm.org>.

5. Baldwin, Carliss Y., and Kim B. Clark.Design Rules – Vol. 1: The Power of

Modularity. Cambridge: The MITPress, 2000.

6. Beck, Kent, and Martin Fowler.Planning eXtreme Programming.Boston: Addison-Wesley, 2001.

Notes1. This article is adapted from Jim

Highsmith’s book “Agile SoftwareDevelopment Ecosystems.” Addison-Wesley, 2002. (Article quotes andexamples taken from this book.)

2. For additional information, see JamesA. Highsmith. Adaptive SoftwareDevelopment: A Collaborative App-roach to Managing Complex Systems.New York: Dorset House, 2000.

3. For extensive research in this area, seeBuckingham, Marcus, and CurtCoffman. First, Break All the Rules:What the World’s Greatest ManagersDo Differently. New York: Simon &Schuster, 1999, and Buckingham,Marcus and Donald O. Clifton. Now,Discover Your Strengths. New York:Simon & Schuster, 2001.

4. The three tiers are Risk Leadership,Risk Entrepreneurship, and LeanDevelopment.

About the AuthorJim Highsmith isdirector of the CutterConsortium’s AgileProject ManagementPractice, author of“Agile Software Deve-lopment Ecosystems

(2002)” and “Adaptive SoftwareDevelopment: A Collaborative App-roach to Managing Complex Systems(2000),” and winner of the 2000 JoltAward. He has more than 30 yearsexperience as a consultant, softwaredeveloper, manager, and writer. In thelast 10 years, he has worked with infor-mation technology organizations,industrial product companies, andsoftware companies in the UnitedStates, Europe, Canada, South Africa,Australia, Japan, India, and NewZealand to help them adapt to theaccelerated pace of development inincreasingly complex, uncertain envi-ronments.

Cutter Consortium2288 North Coulter DriveFlagstaff, AZ 86004Phone: (781) 648-8700E-mail: jim@jimhighsmith.com

COMING EVENTS

October 14-1620th Annual Pacific NorthwestSoftware Quality Conference

Portland, ORwww.pnsqc.org

November 3-63rd Annual Amplifying Your Effectiveness

(AYE) Conference 2002Phoenix, AZ

www.ayeconference.com

November 4-8Software Testing Analysisand Review Conference

Anaheim, CAwww.sqe.com/starwest

November 11-14National Defense Industrial Association

Denver, COwww.ndia.org

November 18-21International Conference on

Software Process ImprovementWashington, DC

www.software-process-institute.com

February 24-27, 2003Software Engineering Process

Group Conference

Boston, MAwww.sei.cmu.edu/sepg/

April 28-May 1, 2003Software Technology Conference 2003

Salt Lake City, UTwww.stc-online.org

May 3-10, 2003International Conference on

Software EngineeringPortland, OR

www.icse-conferences.org/2003