Oct2002cover.qxd 9/4/02 11:10 AM Page 1 - Agile Sweden · approach to agile software development methodologies. While interest in agile methodologies has blossomed in the past two

Oct2002cover.qxd 9/4/02 11:10 AM Page 1

What Is Agile Software Development?In answering this fundamental question, this article looks at a sampler of agilemethodologies, an agile case story, and a look at the future.by Jim Highsmith

Learning From Agile Software Development – Part OnePart one of this two-part series describes how cost- and plan-driven projects can borrowfrom agile software development to improve their strategies and hedge against surprises.by Alistair Cockburn

Agile Methodologies and Process DisciplineThis article summarizes and critiques the compatibility of agile methodologies withplan-driven methodologies as described by the Capability Maturity Model for Software.by Mark C. Paulk

Odyssey and Other Code Science Success StoriesThis article includes real-world insights from developers applying a tailored version ofeXtreme Programming and a quantitative measure of its effectiveness since its inception.by John Manzo

Integrating Systems and Software Engineering:What Can Large OrganizationsLearn From Small Start-Ups? Learn how adaptive techniques and small informal teams inside large organizations cancomplement a formal organizational process focus.by Paul E. McMahon

Highpoints From the Agile Software Development ForumThis report summarizes what speakers said agile software development is and is not.by Pamela Bowers

Agile Before Agile Was CoolThis author was developing software solutions using agile methods before he realizedthere was such a methodology.by Gordon Sleve

Cover Design byKent Bingham.

3

9

14

18

31

DeparDepar tmentstments

Agile Agile SoftwarSoftwaree DeDevvelopmentelopment

ON THE COVER

2 CROSSTALK The Journal of Defense Software Engineering October 2002

4

10

15

19

22

26

28

SoftwarSoftware e EngineeringEngineering TTechnoloechnologgyy

From the Publisher

Coming Events

Web Sites

Top 5 Contest Information

BackTalk

CrossTalkArticle Submissions:We welcome articles of interest to thedefense software community.Articles must be approved by theCROSSTALK editorial board prior to publication. Please fol-low Author Guidelines, available at <www.stsc.hill.af.mil/crosstalk/xtlkguid.pdf>. CROSSTALK does not pay for sub-missions.Articles published in CROSSTALK remain the prop-erty of the authors and may be submitted to other publica-tions.Reprints and Permissions: Requests for reprints must berequested from the author or the copyright holder. Pleasecoordinate your request with CROSSTALK.Trademarks and Endorsements: This DoD journal is anauthorized publication for members of the Department ofDefense. Contents of CROSSTALK are not necessarily theofficial views of, or endorsed by, the government, theDepartment of Defense, or the Software Technology SupportCenter. All product names referenced in this issue are trade-marks of their companies.Coming Events:We often list conferences, seminars, sympo-siums, etc. that are of interest to our readers.There is no feefor this service, but we must receive the information at least90 days before registration. Send an announcement to theCROSSTALK Editorial Department.STSC Online Services: www.stsc.hill.af.milCall (801) 777-7026, e-mail: [email protected] Issues Available:The STSC sometimes has extra copiesof back issues of CROSSTALK available free of charge.The Software Technology Support Center was establishedat Ogden Air Logistics Center (AFMC) by Headquarters U.S.Air Force to help Air Force software organizations identify,evaluate, and adopt technologies to improve the quality oftheir software products, efficiency in producing them, andtheir ability to accurately predict the cost and schedule oftheir delivery.

SPONSOR

PUBLISHER

ASSOCIATEPUBLISHER

MANAGING EDITOR

ASSOCIATE EDITOR

ARTICLECOORDINATOR

CREATIVE SERVICESCOORDINATOR

PHONE

FAX

E-MAIL

CROSSTALK ONLINE

CRSIP ONLINE

Lt. Col. Glenn A. Palmer

Tracy Stauder

Elizabeth Starrett

Pamela Bowers

Chelene Fortier

Nicole Kentta

Janna Kay Jensen

(801) 586-0095(801) [email protected]/crosstalk

www.crsip.hill.af.mil

Subscriptions: Send correspondence concerningsubscriptions and changes of address to the followingaddress.You may e-mail or use the form on p. 27.

Ogden ALC/MASE7278 Fourth St.Hill AFB, UT 84056-5205

Open Open FForumorum

Online Online ArArticlesticles

30 Should You Be More Agile?by Rich McCabe and Michael Polen

Agile Development: Weedor Wildflower?by David Kane and Steve Ornburn

From the Publisher

This month’s CrossTalk focuses on one of the potentially hot topics of debate inthe software industry today – agile software development vs. disciplined, process-

focused software development. There seems to be much confusion about what agilesoftware development is and is not, and what agile implies. We hope that our selectionof articles will provide some insight into agile software development methodologies andhow they compare in application and use to the process improvement strategies embod-ied in capability maturity models that we have championed for many years. Perhaps these

articles may even widen your understanding and perceptions of where agile development fitswithin today’s software development challenges.

Our lead article by Jim Highsmith, What Is Agile Software Development? sets the stage for under-standing agile software development. He discusses what he terms the sweet spot problem domain foragile approaches and then gives greater detail on the three dimensions he refers to as agile ecosys-tems: chaordic perspective, collaborative values, and barely sufficient methodology.

We next provide part one of a two-part article by Alistair Cockburn, Learning From AgileSoftware Development – Part One. Part one describes how agile and plan-driven teams make differenttrade-offs of money for information or for flexibility, and presents the first seven of 10 princi-ples for tuning a project to meet various priorities, including cost, correctness, predictability,speed, and agility. Part two will be featured in the November issue of CrossTalk.

In Agile Methodologies and Process Discipline, Mark C. Paulk addresses issues surrounding agiledevelopment as compared to rigorous software process improvement models such as theCapability Maturity Model® for Software (SW-CMM®). He summarizes and critiques the compat-ibility of agile methodologies with plan-driven methodologies as described by the SW-CMM, andconcludes by making the point, “Perhaps the biggest challenge in dealing effectively with bothagile and plan-driven methodologies is dealing with extremists in both camps who refuse to keepan open mind.”

In his article, Odyssey and Other Code Science Success Stories, John Manzo tells of the successfuldelivery of an actual complex industrial automation application using an agile developmentmethodology based on eXtreme Programming (XP). He includes some real-world insights froma developer’s experience applying the development method, including a quantitative measure ofXP’s effectiveness since its inception.

Our supporting articles this month begin with Integrating Systems and Software Engineering: WhatCan Large Organizations Learn From Small Start-Ups? Author Paul E. McMahon explores variationsin large and small engineering organizations and presents an alternative view of large projects thathe claims may aid companies in their quest for more effective systems and software integration.He believes that using adaptive techniques and small informal teams inside large organizations cancomplement a formal organizational process focus that may already exist within a company.

Next, in Highpoints From the Agile Software Development Forum, Pamela Bowers summarizes thekeynote talks from “Creating Competitive Advantage Through Agile Development Practices,” atechnology forum held at Westminster College in Salt Lake City in March. In Agile Before Agile WasCool, Gordon Sleve describes a specific example of choice of an agile methodology for the devel-opment of a needed application, with quick turnaround to meet a customer’s need. He notes thatthis was done long before agile methods were well known or popular and concludes by saying, “Isee both methodologies coexisting and filling an important purpose: to make our customers successful.”

We conclude this issue with two online articles: Should You Be More Agile? by Rich McCabe andMichael Polen, and Agile Development: Weed or Wildflower? by David Kane and Steve Ornburn.These authors believe that software projects, even in the defense community, can benefit from thetechniques of agile development.

As noted in the lengthy references at the end of many of these articles, much is being writtenabout agile software development at this time. We hope that this selection of thought-provokingarticles will enable you to become more enlightened about the many perspectives of these newsoftware development alternatives and will have a positive influence on opening your minds tonew possibilities.

Agile Software Development DeservesAn Open-Minded Approach

H. Bruce AllgoodDeputy Director, Computer Resources Support Improvement Program

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

“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


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.”


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



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



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.”



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-



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: [email protected]

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


Being agile is a declaration of prioritiz-ing for project maneuverability with

respect to shifting requirements, shiftingtechnology, and a shifting understandingof the situation. Other priorities thatmight override agility include predictabili-ty, cost, schedule, process-accreditation, oruse of specific tools.

Most managers run a portfolio ofprojects having a mix of those priorities.They need to prioritize agility, predictabil-ity, and cost sensitivity in varying amountsand therefore need to mix strategies. Thisarticle focuses on borrowing ideas fromthe agile suite to fit the needs of plan-driv-en and cost-sensitive programs.

Our industry now has enough infor-mation to sensibly discuss such blending.The agile voices have been heard [1, 2, 3,4, 5, 6, 7], the engineering voices havebeen heard [8, 9, 10], two articles in thisissue [11, 12] illustrate the differences inworld view, and some authors have dis-cussed the question of their coexistenceand principles underlying successful devel-opment strategies [3, 8, 13].

Buy Information or FlexibilityMany project strategies revolve aroundspending money for either information orflexibility [3, 14].

In a money-for-information (MFI) propo-sition, the team can choose to expendresources now to gain information earlier.If the information is not considered valu-able enough, the resources are applied toother work. The question is how much theteam is willing to expend in exchange forthat information.

In a money-for-flexibility (MFF) proposi-tion, the team may opt to expend re-sources to preserve later flexibility. If thefuture is quite certain, the resources arebetter spent pursuing the most probableoutcome, or on MFI issues.

Different project strategies are madeby deciding which issues are predictable,unpredictable but resolvable, or unresolv-able, deciding which of those are MFI or

MFF propositions, and how best to allo-cate resources for each.

Predictable issues can be investigatedusing breakdown techniques. Such anissue might be creating a schedule forwork similar to that successfully per-formed in the past.

Unpredictable but resolvable issues can beinvestigated through study techniquessuch as prototypes and simulators. Suchissues include system performance limits.These are also MFI propositions. Agileand plan-driven teams are likely to usesimilar strategies for these issues as part ofbasic project risk management.

Unresolvable issues tend to be sociolog-ical, such as which upcoming standard willgain market acceptance, or how long keyemployees will stay around. These issuescannot be resolved in advance, and so arenot MFI propositions, but are MFFpropositions. Agile and plan-driven teamsare intrinsically likely to use differentstrategies for these issues. Agile teams willset up to absorb these changes, while plan-driven project teams must, by definition,create plans for them.

Teams will differ on which issues areresolvable, and how much money shouldbe spent in advance on predictable issues.A plan-driven team is more likely todecide that creating the project plan isbasically a predictable issue, and that agood MFI strategy is to spend resources

early to make those predictions.In contrast, an agile team might decide

that the project plan is fundamentally un-resolvable past a very simple approxima-tion. There being no effective MFI strat-egy, it adopts an MFF approach, makingan approximate plan early and allocatingresources for regular re-planning over thecourse of the project.

Both agile and plan-driven developersmight agree that the question of systemperformance under load is an importantMFI issue, and so both might agree tospend money early to build a simple sys-tem simulator and load generator tostress-test the design.

They are likely to spend money differ-ently on design issues. The plan-driventeam, viewing it as a sensible MFI propo-sition, will spend money early to reduceuncertainty about the future of the design.Agile teams are more likely to view designas either being inexpensive to change (apoor MFI candidate) or unresolvable(making it an MFF proposition). They aretherefore more likely to choose a designearly and allocate money to adjust it overtime. This difference on design issues isfundamental, since the two groups viewthe matter from different decision arenas.

Ten PrinciplesThe following 10 principles have shownthemselves useful in setting up and run-ning projects. Most of these are known inthe literature [3, 4, 8, 21]. My phrasing ofthem may be slightly different.1. Different projects need different

methodology trade-offs.2. A little methodology does a lot of

good; after that, weight is costly.3. Larger teams need more communica-

tion elements.4. Projects dealing with greater potential

damage need more validation ele-ments.

5. Formality, process, and documentationare not substitutes for discipline, skill,and understanding.

Learning From Agile Software Development – Part OneAlistair Cockburn

Humans and Technology

This two-part article compares agile, plan-driven, and cost-sensitive software development approaches based on a set of proj-ect organization principles, extracting from them ideas for pulling agile techniques into cost- and plan-driven projects. Partone describes how agile and plan-driven teams make different trade-offs of money for information or for flexibility, and pres-ents the first seven of 10 principles for tuning a project to meet various priorities, including cost, correctness, predictability,speed, and agility. Part two, which will run in the November issue of CrossTalk, will present the last three principles,then pull the material together for actions that plan-driven and cost-sensitive project teams can use to improve their strategiesand hedge against surprises.

“This is a MFI [money-for-information]

situation: It is worthspending a lot of money

now to discover ...where those next defects

are located.”

Learning From Agile Software Development – Part One


6. Interactive, face-to-face communica-tion is the cheapest and fastest channelfor exchanging information.

7. Increased communication and feed-back reduces the need for intermediatework products.

8. Concurrent and serial developmentexchange development cost for speedand flexibility.

9. Efficiency is expendable in non-bottle-neck activities.

10. Sweet spots speed development.The first seven principles are discussed

in this article, the last three will beaddressed in part two.

1. Different Projects Need DifferentMethodology Trade-offsThis should be obvious, but it seems toneed re-stating at frequent intervals [15,16, 17, 18].

Figure 1, adapted from Boehm andPort [8], shows one particular aspect ofthese differences. In this figure, the twodiminishing curves show the potentialdamage to a project from not investingenough time and effort in planning. Thetwo rising curves show the potential dam-age to the project from spending toomuch time and effort in planning.

The lines crossing on the left indicate aproject for which potential damage is rela-tively low with under-planning, and rela-tively high with over-planning. Muchcommercial software, including Web serv-ices fall into this category. The lines cross-ing on the right indicate a project forwhich potential damage is relatively highwith under-planning, and for which muchmore planning would have to be donebefore damage would accrue from delaysdue to planning. Safety-critical softwareprojects fall into this category.

The curves should make it clear thatwhen there is risk associated with taking aslow, deliberate approach to planning,then agile techniques are more appropri-ate. When there is risk associated withskipping planning or making mistakeswith the plan, then a plan-drivenapproach is more appropriate. The curvesillustrate clearly the home territory ofeach.

Figure 2 shows a different characteri-zation of project differences [3]. Thehori-zontal axis captures the number ofpeople needing to be coordinated, risingfrom one on the left to 1,000 on the right.The idea is that projects need more coor-dina-tion elements to their methodologyas the number of people increases.

The vertical axis captures the potentialdamage caused by undetected defects inthe system, from loss of comfort to loss

of life. The idea is that projects needmore validation elements as the potentialdamage increases.

Each box in the grid identifies a set ofprojects that might plausibly use the samecombination of coordination and valida-tion policies. The label in the box indi-cates the maximum damage and coordi-nation load common to those projects(thus, D40 refers to projects with 20-40people and potential loss of discretionarymonies). Projects landing in differentboxes should use different policies.

The different planes capture the ideathat projects run to different priorities,some prioritizing for productivity, somefor legal liability, and others for cost, pre-dictability, agility, and so on.

Any one methodology is likely to beappropriate for only one of the boxes onone of the planes. Thus, at least 150 or somethodologies are needed (Capers Jonesidentifies 37,000 project categories [17]).That number is increased by the fact thattechnology shifts change the methodolo-gies at the same time.

2.A Little Methodology Does a Lotof Good;After That,Weight is CostlyFigure 3 (see page 12) relates three quan-tities: the weight of the methodologybeing used, the size of the problem beingattacked, and the size of the team.(Problem size is a relative term only. Theproblem size can drop as soon as some-one has an insight about the problem.Even though problem size is highly sub-jective, some problems are clearly harderfor a team to handle than others.) Thisfigure illustrates that adding elements to ateam's methodology first helps then hin-ders their progress [3].

The dashed line shows that a small

team, using a minimal methodology, cansuccessfully attack a certain size of prob-lem. Adding a few carefully chosen ele-ments to the methodology allows them towork more effectively and attack a largerproblem. As they continue to add to themethodology, they increase the bureau-cratic load they put on themselves and,being only a small team, start expendingmore energy in feeding the methodologythan solving the problem. The size of theproblem they can successfully attackdiminishes.

The curve is similar for a large team(the solid line), but not as abrupt. Thelarge team needs more coordination ele-ments to work optimally, and has morepeople to feed the methodology as itexpands. Eventually, even the larger teamstarts being less productive as themethodology size grows and solves thelarger problems less successfully.

3. Larger Teams Need MoreCommunication ElementsSix people in a room can simply talkamongst themselves and write on whiteboards. If 200 people were to try that,they would get in each other’s way, misstasks, and repeat each other’s work. Thelarger team benefits from coordination.This is the slower rise in the large-teamcurve in Figure 3. The smaller team needs

Time and Effort Invested in Plans

Dam

age

fro

mO

ver-

or

Un

der

-Pla

nn

ing

Plan-DrivenSweet Spot

AgileSweet Spot

Figure 1: Balancing Discipline and Flexibilitywith the Spiral Model and MBASE

Number of People Involved

Crit

ical

ity(d

efec

ts c

ause

loss

of..

.)

Comfort(C)

EssentialMoney

(E)

Life(L)

+20%

. . . Prioritized for Legal Liability

1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000

C6 C20 C40 C100 C200 C500 C1000

D6 D20 D40 D100 D200 D500 D1000

E6 E20 E40 E100 E200 E500 E1000

L6 L20 L40 L100 L200 L500 L1000

Prioritized for Productivity & Tolerance

DiscretionaryMoney

(D)

Figure 2: Projects by Communication, Criticality, and Priorities [3]



fewer coordination mechanisms and cantreat them with less ceremony than canthe larger team.

Although this principle should beobvious, many process designers try tofind a single set of coordination elementsto fit all projects.

4. Projects Dealing with GreaterPotential Damage Need MoreValidation ElementsA team of developers charged with creat-ing a proof-of-concept system does nothave to worry about the damage causedby a system malfunction in the same waythat a team charged with developing afinal production system to be produced invast quantities does. Atomic power plants,automated weapons systems, even cellphones or automobiles produced in themillions have such economic conse-quences that it is well worthwhile spend-ing a great deal more time locating andeliminating each additional remainingdefect. This is an MFI situation: It isworth spending a lot of money now todiscover information about where thosenext defects are located.

For a system in which remainingdefects have lower economic conse-quences (such as ordering food onlinefrom the company cafeteria), it is notworth spending as much money to dis-cover that information. The team willconsequently find it appropriate to usefewer and lighter validation techniques onthe project

5. Formality, Process, andDocumentation Are NotSubstitutes for Discipline,Skill, and UnderstandingHighsmith [4] points to the differencebetween discipline and formality, skill andprocess, understanding and documenta-tion.

Discipline is an internal quality ofbehavior; formality is an externally visibleresult. Many of the best developers arevery disciplined in their actions withoutusing formal methods or documents.

Skill is an internal quality of action,typically of a single person, while processis an externally declared agreement, usual-ly between several people. Individuals op-erating at high levels of skill often cannotsay what process they follow. Processes aremost useful in coordinating the flow ofwork between people.

Understanding is an internal realiza-tion; documentation is external. Only asmall part of what people know can be putinto external documentation, and thatsmall part takes a lot of time.

Process designers often forget thesedifferences, thinking that enough formalitywill impart discipline, enough process willimpart skill, and enough documentationwill impart understanding. An agile projectmanager relies on discipline, skill, andunderstanding, while requiring less formal-ity, process, and documentation (Figure 4).This allows the team to move and changedirections faster.

6. Interactive, Face-to-FaceCommunication Is theCheapest and Fastest Channelfor Exchanging InformationUnderstanding passes from person to per-son more rapidly when two people arestanding next to each other, as when theyare discussing at a white board. At thatwhite board, they can use gestures, facialexpressions, proximity cues, vocal inflec-tion and timing, cross-modality (aural-

visual) timing, and real-time feedbackalong modalities to discover what eachknows, needs to know, and how to conveyit [3, 19]. They use the white board as anexternal-marking device not just to draw,but also to hold some of their discussionpoints in place so they can refer back tothem later.

As characteristics of that situation areremoved, the communication effectivenessbetween the two people drops (Figure 5).On the phone, they lose the entire visualchannel and cross-modality timing. With e-mail or instant messaging, they lose vocalinflection, vocal timing, and real-timequestion and answer. On videotape, theyhave visuals, but lose the ability to getquestions answered. On audiotape, theyagain lose visuals and cross-modality tim-ing. Finally, communi-cating through doc-uments, they attempt to communicatewithout the benefit of gestures, vocalinflection and timing, cross-modality tim-ing, proximity cues, or question-and-answer.

This principle suggests that for costand efficiency improvements, a projectteam employ personal, face-to-face com-munication wherever possible. A decade-long study at MIT's Sloan School ofManagement in the 1970s and a recentresearch compilation both concluded thatphysical distance matters a great deal [20,21].

The cost of imposing distancesbetween people can be seen with a simplecalculation. Suppose that a developer earns$2 per minute, and two people workingside-by-side on the same problemexchange questions and answers at the rateof 100 questions each per week. Thus, foreach minute on average that gets inter-posed between thinking the question andhearing the answer adds $200 of salarycost to the project per person per week, orabout $10,000 per year. For a 10-personproject, that one-minute average delaycosts the organization $100,000 per year.Two offices being a few meters apart cre-ates a one-minute delay. For offices aroundthe corner or up a flight of stairs, the aver-age delay is more on the order of five min-utes ($500,000 per year).

The salary cost is actually the smallercost. The larger cost is that when two peo-ple are more than about half a minute'stravel apart, they simply do not ask eachother many of those questions. Instead,they guess at the answers. Some percent-age of those guesses are wrong, and thosemistakes end up as defects in the systemthat must be found through debugging,external test, integration test, or eventhrough system use.

Methodology Weight

Large Team

Pro

blem

Siz

e

Small Team

Figure 3: A Little Methodology Goes a LongWay

Formality, Process, Documentation

Dis

cipl

ine,

Ski

ll, U

nder

stan

ding

X Typical Heavy Methodology

Light Heavy

Ada

ptin

g

Low

High

Optimizing

X Typical Light Methodology

Figure 4: Differences Between Adapting andOptimizing Approaches

“An agile projectmanager relies ondiscipline, skill, and

understanding, whilerequiring less formality,

process, anddocumentation.”

Learning From Agile Software Development – Part One


7. Increased Communication andFeedback Reduces the Need forIntermediate Work Products Intermediate work products – those notrequired by the final users of the systemor the next team of developers -– tend tohave two forms: a) promises as to whatwill eventually be constructed, and b)intermediate snapshots of the develop-ers' knowledge (design descriptions).

This understanding, as we havealready seen, moves faster through inter-active than paper-based communication.Increasing the use of interactive commu-nications will never entirely eliminate theneed for archivable design documenta-tion, but it can reduce it, particularly dur-ing the design and development stages ofthe project. Eventually, external docu-mentation will be needed when none ofthe original designers are around, butthat does not count as intermediate docu-mentation.

Users who regularly get to see thedeveloping system stop needing elabo-rate promises of what they will be given.This is an MFI issue. If the users are notgoing to get to see the result for a year ortwo, then it is worth a lot to create themost accurate promise possible. If onthe other hand, the users get to seeresults every few days or weeks, then abetter use of the project's money is tosimply build the system and show it tothe users.

There is, however, a MFF issue at playhere as well since there are diminishingreturns on the MFI issue of creating thatpromise. No amount of care in crafting adetailed promise can capture the unpre-dictable reaction of the users on seeingthe final product in their own environ-ment as they perform their work assign-ments. The time and money spent onguessing at the users' response to thedelivered system would be better allocat-ed to deal with their response on seeingthe real system.

Mock-ups, prototypes, and simula-tions deal with the MFI aspects of thesituation. They are an expenditure ofresources to discover information soon-er. The MFF aspects of the situation arehandled through incremental deliverywith iterative re-work, allocating resour-ces for the inevitable surprises resultingfrom real delivery.

Interim SummaryThe natural tension between agility-focused, plan-driven, and cost-sensitiveproject teams is explained in part by theirinterpretations of what counts as a money-

for-information proposition, what counts asa money-for-flexibility proposition, and howmuch money to spend on each. We haveseen how people with various prioritiesuse those economic strategies differently.

It is particularly important, in work-ing with the first seven principles, thateach be used to tune a project's runningrules, of particular importance is thateach project team declares its priorities aswell as its communication and validationrequirements. With those in place, theteam can orient itself to the amount offace-to-face communication it can man-age, and the extra methodology weight itshould appropriately set in place.

The principles are intended to beused as slider scales. Too much towardeach end of the sliding scale brings itsown sort of damage.

The second part of this article willpresent the final three principles, thenpull from the collected information tosuggest specific actions that leaders ofplan-driven and cost-sensitive projectscan take to either improve their strate-gies, or at least hedge their bets againstfuture surprises.◆

References1. Beck, Kent. eXtreme Programming

Explained: Embrace Change. Boston:Addison-Wesley, 1999.

2. Coad, P., E. Lefebvre, and J. De Luca.Java Modeling In Color With UML:Enterprise Components and Process.Upper Saddle River: Prentice Hall,1999.

3. Cockburn, Alistair. Agile SoftwareDevelopment. Boston: Addison-Wesley, 2001.

4. Highsmith, Jim. Agile Software Deve-lopment Ecosystems. Boston: Add-ison-Wesley, 2002.

5. Schwaber, K., and M. Beedle. AgileSoftware Development with Scrum.Upper Saddle River: Prentice Hall,2001.

6. Highsmith, Jim, and AlistairCockburn. “Agile SoftwareDevelopment: The Business ofInnovation.” IEEE Software 34.9(2001): 120-122.

7. Cockburn, Alistair, and JimHighsmith. “Agile SoftwareDevelopment: The People Factor.”IEEE Software 34:11 (2001): 131-133.

8. Boehm, Barry, and D. Port. “BalancingDiscipline and Flexibility with theSpiral Model and MBASE.”CrossTalk Dec. 2001: 23-30.Available at: <www.stsc.hill.af.mil/crosstalk/2001/dec/boehm.pdf>.

9. Software Engineering Institute.Capability Maturity Model® Integra-tionSM V1.1 (CMMISM). Pittsburgh:SEI, 2002. Available at: <www.sei.cmu.edu/cmmi>.

10. Humphrey, Watts. A Discipline forSoftware Engineering. Boston:Addison-Wesley, 1997.

11. Paulk, Mark C. “Agile Methodologiesand Process Discipline.” CrossTalk

Oct. 2002: 15-18.12. Highsmith, Jim. “What Is Agile

Software Development?” Cross-

Talk Oct. 2002: 4-9.13. Cockburn, Alistair. “Agile Software

Development Joins the Would-BeCrowd.” Cutter IT Journal Jan. 2002:6-12.

14. Sullivan, K., P. Chalasani, S. Jha, and V.

Richness (Temperature) of Communication Channel

Com

mun

icat

ion

Effe

ctiv

enes

s 2 People atWhite Board

2 People on Phone

2 Peopleon E-mail

Videotape

PaperAudiotape

(hot)(cold)

(No Question-Answer)

(Question-and-Answer)

Figure 5: Increasing Communication Effectiveness from Richer Communication Channels

Sazawal. “Software Design as anInvestment Activity: A Real OptionsPerspective,” in Real Options andBusiness Strategy: Applications toDecision Making. L. Trigeorgis, ed.London: Risk Books. Dec. 1999.

15. Mathiassen, L. “Reflective SystemsDevelopment.” Scandinavian Journalof Information Systems. Vol. 10, No.1, 2. Gothenburg, Sweden: The IRISAssociation, 1998: 67-117.

16. Hohmann, L. Journey of the SoftwareProfessional. Upper Saddle River:Prentice-Hall, 1997.

17. Jones, Capers. Software Assessments,Benchmarks, and Best Practices.Boston: Addison-Wesley, 2000.

18. Cockburn, Alistair. “Selecting aProject's Methodology.” IEEESoftware 17.4 (2000): 64-71.

19. McCarthy, J., and A. Monk. “Channels,Conversation, Cooperation and

Relevance: All You Wanted to KnowAbout Communication But WereAfraid to Ask.” CollaborativeComputing 1.1 (Mar. 1994): 35-61.

20. Allen, T.J. Managing the Flow of Tech-

nology. Cambridge, MIT Press, 1977.21. Olson, G. M., and J. S. Olson.

“Distance Matters.” Human-Computer Interaction 15 (2001): 139-179.

About the Author



AgileAlliancewww.agilealliance.org/homeThe AgileAlliance is a nonprofit organization dedicated topromoting the concepts of agile software development, andhelping organizations adopt those concepts, which are out-lined by the Agile Software Development Manifesto and canbe found on this Web site. The AgileAlliance was designed tobe lightweight, initially consisting of a board of directors, oneadministrator, and a set of bylaws. Just like agile processes, allwork and operations within the AgileAlliance is intended toemerge from subsets of members that self-organize into pro-grams.

Agile Development Conferencehttp://agiledevelopmentconference.comThe Agile Development Conference is a conference on deliv-ering fit-for-purpose software under shifting conditions,using people as the magic ingredient. A number of tech-niques, practices, and processes have been identified to dothis, and more will be found in the future. This conferencewill discuss people working together to create software, andthe tools, techniques, practices, and issues involved. Comehere to learn, or, even better, to name them. This conferencehas recently been funded and is still being organized. Readthe conference vision and structure and the request for par-ticipation.

Crystal Methodologieswww.alistair.cockburn.us/crystalCrystal collects together a self-adapting family of “shrink-to-fit,” human-powered software development methodologiesbased on these understandings:

• Every project needs a slightly different set of policies andconventions, or methodology.

• The workings of the project are sensitive to people issues,and improve as the people issues improve, individuals getbetter, and their teamwork gets better.

• Better communications and frequent deliveries communi-cation reduce the need for intermediate work products.This site is a resource for people wanting to understand

those ideas, to find more about improving skills and team-ing, and to identify some project policies to use as a start-ing point. This site is set up as a museum of information,with exhibit halls, exhibit rooms, exhibits with notes, and adiscussion area.

North Carolina State Universitywww.csc.ncsu.eduThe North Carolina State University's (NCSU’s) ComputerScience Department cites strengths in the areas of softwaresystems, communications and performance analysis, theoryand algorithms, and computer architecture. Founded in1967, NCSU’s is one of the oldest computer science depart-ments in the country and the only one at a state-assistedResearch I University. The university hosts a small workshop,“Agile Software Development Methodologies: Raising theFloor or Lowering the Ceiling” at <http://collaboration.csc.ncsu. edu/agile>.

XBreedwww.xbreed.net/index.htmlXBreed is the product of mixing SCRUM, eXtremeProgramming (XP) and Alexanderian ideas. Informationtechnology is the result of developing multiple applicationsand shared components as fast as humanly possible.Combining Scrum and XP was very natural: Scrum providesa solid management framework, while XP provides a basicbut complete set of engineering practices. The result is a leanbut very effective way to run software projects. In addition,Scrum practiced at the application team level – provided ashared resources team is involved – can lead to re-usability.XBreed is a free method. This Web site includes everythingyou need to know to run XBreed projects.

WEB SITES

Alistair Cockburn, aninternationally recog-nized expert in objecttechnology, methodolo-gy, and project manage-ment, is a consulting fel-

low at Cockburn and Associates. He isauthor of “Surviving Object-OrientedProjects,” “Writing Effective Use Cases,”and “Agile Software Development,”which have won Jolt Productivity BookAwards. He is one of the original authorsof the Agile Software Development

Manifesto and founders of theAgileAlliance, and is program directorfor the Agile Development Conferenceheld in Salt Lake City. Cockburn hasmore than 20 years experience leadingprojects in hardware and software devel-opment.

1814 Fort Douglas CircleSalt Lake City, UT 84103Phone: (801) 582-3162Fax: (775) 416-6457E-mail: [email protected]


Agile Methodologies and Process Discipline

Mark C. PaulkSoftware Engineering Institute

Agile methodologies have been touted as the programming methodologies of choice for the high-speed, volatile world of Internetand Web software development. They have also been criticized as just another disguise for undisciplined hacking. The realitydepends on the fidelity to the agile philosophy with which these methodologies are implemented, and the appropriateness of theimplementation for the application environment. This article addresses these issues and summarizes and critiques the com-patibility of agile methodologies with plan-driven methodologies as described by the Capability Maturity Model® for Software.

Agile methodologies, such as eXtremeProgramming (XP), have been touted

as the programming methodologies ofchoice for the high-speed, volatile world ofInternet and Web software development.They have also been criticized as justanother disguise for undisciplined hacking.Although creators of agile methodologiesusually espouse them as disciplinedprocesses, some have used them to argueagainst rigorous software processimprovement models such as theCapability Maturity Model® (CMM®) forSoftware (SW-CMM®) [1].

Many organizations moving into e-commerce (and e-government) have exist-ing CMM-based initiatives (and possiblycustomers demanding mature processes)and desire an understanding of whetheragile methodologies can address CMMpractices adequately. Usually, the realitydepends on 1) the fidelity to the agile phi-losophy with which these methodologiesare implemented, and 2) the appropriate-ness of the implementation for the appli-cation environment.

This article recaps the Agile SoftwareDevelopment Manifesto and its underlyingprinciples. The compatibility of agilemethodologies with plan-driven method-ologies as described by the CMM is sum-marized and critiqued. Although agilemethodologies can be characterized aslightweight methodologies that do not empha-size process definition or measurement tothe degree that models such as the CMMdo, a broad range of processes can be con-sidered valid under the CMM. The conclu-sion is that agile methodologies advocatemany good engineering practices, althoughsome practices may have an extremeimplementation that is controversial andcounterproductive outside a narrowdomain.

For those interested in processimprovement, the ideas in the agile move-ment should be thoughtfully considered.When rationally implemented in an appro-priate environment, agile methodologiesaddress many CMM Level 2 and 3 prac-

tices. The ideas in the agile movementshould be carefully considered for adop-tion where appropriate in an organization'sbusiness environment; likewise, organiza-tions considering agile methodologiesshould carefully consider the managementand infrastructure issues of the CMM.

Agile MethodologiesMany names have been used for the agilemethods, including Internet-speed, light-weight, and lean methodologies. Similarly,plan-driven methodologies have been

described as rigorous, disciplined, bureau-cratic, heavyweight, and industrial-strength. Some of these descriptors can beconsidered derogatory, e.g., lightweight orbureaucratic. Agile is the term preferred bythe AgileAlliance, a group of softwareprofessionals dedicated to promoting theconcepts of agile software development.Plan-driven was coined by Barry Boehm [2]to characterize the opposite end of theplanning spectrum from agile methodolo-gies.

Any discussion of agile methodologiesshould begin with the fundamentals of

agile as expressed by its proponents. TheManifesto of the AgileAlliance found at<www.agilemanifesto.org> states:

We are uncovering better ways ofdeveloping software by doing it,and helping others do it. Throughthis work we have come to value:• Individuals and interactions

over processes and tools.• Working software over compre-

hensive documentation.• Customer collaboration over

contract negotiation.• Responding to change over fol-

lowing a plan.That is, while there is value on

the items on the right, we value theitems on the left more.

The principles behind the agile mani-festo are as follows:1. Our highest priority is to satisfy the

customer through early and continuousdelivery of valuable software.

2. Welcome changing requirements, evenlate in development. Agile processesharness change for the customer'scompetitive advantage.

3. Deliver working software frequently,from a couple of weeks to a couple ofmonths, with a preference to the short-er timescale.

4. Business people and developers mustwork together daily throughout theproject.

5. Build projects around motivated indi-viduals. Give them the environmentand support they need, and trust themto get the job done.

6. The most efficient and effectivemethod of conveying information toand within a development team is face-to-face conversation.

7. Working software is the primary meas-ure of progress.

8. Agile processes promote sustainabledevelopment. The sponsors, develop-ers, and users should be able to main-tain a constant pace indefinitely.

“The conclusion isthat agile methodologies

advocate many goodengineering practices,

although some practicesmay have an extremeimplementation thatis controversial andcounterproductiveoutside a narrow

domain.”



9. Continuous attention to technicalexcellence and good design enhancesagility.

10. Simplicity – the art of maximizing theamount of work not done – is essen-tial.

11. The best architectures, requirements,and designs emerge from self-organiz-ing teams.

12. At regular intervals, the team reflectson how to become more effective, thentunes and adjusts its behavior accord-ingly.Agile methodologies are usually target-

ed toward small- to medium-sized teamsbuilding software in the face of vagueand/or rapidly changing requirements.Agile teams are expected to be co-located,typically with less than 10 members.

Process Discipline inthe Agile MethodsWhy would we challenge the principles ofagile methodologies? Do not most profes-sionals share the objectives espoused inthe agile movement? In one sense, the val-ues expressed in the agile manifesto shouldbe captured in any modern software proj-ect, even if the implementation may differradically in other environments. Customersatisfaction, communication, working soft-ware, simplicity, and self-reflection may bestated in other terms, but without them,non-trivial projects face almost insur-mountable odds against success.

In effective CMM-based improvement,when defining processes, organizationsshould capture the minimum essentialinformation needed, use good softwaredesign principles (such as information hid-ing and abstraction) in structuring the def-initions, and emphasize usefulness andusability [3]. One of the consequences ofthe Level 1 to Level 2 culture shift isdemonstrating the courage of convictionsby becoming realistic in estimates, plans,and commitments.

Much of the formalism that character-izes most CMM-based process improve-ment is an artifact of large projects and/orsevere reliability requirements, especiallyfor life-critical systems. The hierarchicalstructure of the SW-CMM, however, isintended to support a broad range ofimplementations within the context of the18 key process areas and 52 goals thatcompose the requirements for a fullymature software process. It is true, howev-er, that the CMM emphasizes explicitlycapturing knowledge via documentationand measurement – a process emphasis.The challenge for many in adopting agilemethodologies lies in the (perceived) prob-

lems in de-emphasizing processes, docu-mentation, contracts, and planning.

Individuals Over ProcessAgile methodologies assume the pro-grammers are generalists rather than spe-cialists. Competent generalists are hard tocome by, but this is an endemic problemin any technically demanding discipline.Specialist knowledge in a domain can beneeded, however, which may lessen theeffectiveness of practices such as pairprogramming.

The foundation of software engineer-ing in the SW-CMM at Level 1 is compe-tent people, sometimes doing heroics, alltoo frequently working to overcome thesystem to do professional work. In spite ofheroics, the foundation that is assumed inthe CMM is competent professionals.

Without competent professionals, thebest software process is ineffective –because the work we do in software proj-ects is human-centric and design-inten-sive, and the process is what we do.

Software professionals want to takepride in their work, but how can theywhen managers say, “I’d rather have itwrong than have it late. We can always fixit later.” When program managersacknowledge that making the schedule isthe primary consideration in raises andpromotions, what is the impact on moti-vation, quality, and professionalism?These are fundamental managementissues, which is why the focus at Level 2of the SW-CMM is on project manage-ment, which empowers competent pro-fessionals to do quality work.

It is interesting to note that, althoughagile methodologies emphasize individu-als over process, the set of practices in anagile methodology addresses the samekind of planning and commitment issuesas the focus on basic project managementat CMM Level 2. An agile methodology thatignored customer collaboration and incre-mental development would almost cer-

tainly fail. Agile practices are synergistic,and the success of agile methodologiesdepends on the emergent properties ofthe set of practices as a whole.

Working SoftwareOver DocumentationThe agile emphasis on tacit rather thanexplicit knowledge, as externally capturedin documentation, can be a high-riskchoice in many environments such asgovernment contracting, but it can be aneffective choice if rationally made. Whenagile advocates denigrate the value ofdocumentation, they lessen their credibil-ity in the eyes of many experienced pro-fessionals. The tone in arguing againstnon-essential documentation differs fromarguing that documentation is an ineffi-cient waste.

eXtreme Programming expert BobMartin said at the 2001 XP Universe con-ference that he ran into someone whosaid his organization was using XP.Martin asked him how pair programmingwas viewed, and the reply was, “We don’tdo that.” Martin asked how refactoringwas working out, and the reply was, “Wedon’t do that.” Martin asked how well theplanning game was working, and the replywas, “We don’t do that.” “Well,” Martinasked, “then what are you doing?” “Wedon’t document anything!” was theanswer.

Success carries the seeds of failure,and the agile methodologists are con-cerned that some adopting these newideas do not really understand what anagile methodology is – and it is not adhoc, chaotic programming.

When considering process documen-tation, the element that is missing fromagile methodologies, which is crucial forthe SW-CMM, is the concept of institu-tionalization, i.e., establishing the culturethat “this is the way we do things aroundhere.”

Although implicit in some agile prac-tices such as the peer pressure formed bypair programming, infrastructure isimportant for institutionalizing goodengineering and management practices.The key process areas in the CMM arestructured by common features that dealwith implementing and institutionalizingprocesses. The institutionalization prac-tices for each key process area map to allthe goals within the area, so a naïve agileimplementation that ignored these cultur-al issues would fail to satisfy any CMMkey process area.

As implementation models that focuson the development process, these issues

“Software professionalswant to take pride in

their work, but how canthey when managers say,‘I’d rather have it wrongthan have it late.We can

always fix it later.’ ”

Agile Methodologies and Process Discipline


are largely outside the focus of the agilemethodologies, but they are arguably cru-cial for their successful adoption.

Over-documentation is a perniciousproblem in the software industry, espe-cially in Department of Defense (DoD)projects. Software maintainers have longknown that the only documentation youcan really trust is the code (and those ofus with experience debugging compilerand run-time defects doubt even that).Having said that, an architectural descrip-tion of the system that provides a tour ofthe top-level design can be invaluable tomaintainers.

From a technical perspective, as proj-ects become larger, emphasizing a goodarchitectural philosophy becomes increas-ingly critical to project success. Majorinvestment in the design of the product’sarchitecture is one of the practices thatcharacterizes successful Internet compa-nies [4]. Architecture-based design, desig-ning for change, refactoring, and similardesign philosophies emphasize the needfor dealing with change in a systematicfashion.

One of the compromises that agilemethodologists are likely to be required tomake as they move into larger projectsand applications that are life- or mission-critical is a stronger emphasis on docu-menting the architecture and the designof the system. In turn, plan-drivenmethodologists must acknowledge thatkeeping documentation to a minimum,useful set is also necessary. What benefitdo we really get from detailed designswhere the programming design languageis nearly as large as the code?

Much of the controversy with respectto the technical issues centers on whathappens as projects scale up. Practicesthat rely on tacit knowledge and highlycompetent professionals may break downin larger teams with their rapidly expand-ing communication channels and coordi-nation challenges. However, replacingthose practices with ones appropriate forlarge teams may result in losing the emer-gent properties of the agile methodology.

Customer CollaborationOver ContractsThe degree of trust implicit in relying oncustomer collaboration rather than a con-tract is not justified in many customer-supplier relationships. Even when the rela-tionship begins with the best of intentionsand the highest of expectations on bothsides, one of the main difficulties in learn-ing from experience is “the use of unaid-ed memory for coding, storing, and

retrieving outcome information” [5], withthe consequence that “change can makeliars of us, liars to ourselves” [6]. As timegoes by, as things change, our unaidedmemories become unreliable.

The reliance of agile methodologieson tacit knowledge is therefore vulnerableto perception shifts over time, yet tacitknowledge may be much more effectivethan external, explicit knowledge in set-ting expectations and driving behavior. Ina government-contracting context, federalacquisition regulations establish a contextfor ensuring fair play – even if it is notnecessarily an effective and efficient envi-ronment. This can be considered a prob-lem in expectations management. Theagile methodologies manage customerexpectations by insisting on an ongoingcustomer interaction and rapid iteration.

Ignoring possible regulatory issues, thestories in XP, in conjunction with an evolu-tionary life cycle and ongoing customer-supplier communication [7], documentrequirements and commitments in a man-ner that could satisfy the goals of require-ments management and software projectplanning in the SW-CMM. Will such a setof stories satisfy a DoD customer that therequirements are adequately stated andthat commitments as driven by the customerare being met? Or will the natural desirefor a more comprehensive requirementsstatement drive the customer towards arequirements specification that lacks thedynamic capability desired for an agilemethodology?

Perhaps an honest answer to this typeof question reveals more about the com-fort levels of both customer and supplierin an agile relationship. One of the most sig-nificant barriers to implementing an agilemethodology is likely to be an inability toestablish and maintain close and effectivecustomer collaboration – and this barrieris likely to be erected on the customer’sside of the relationship.

Responding to ChangeOver PlanningDwight Eisenhower is quoted as saying thatplanning is more important than the plan.And one of the great military axioms is thatno battle plan survives contact with theenemy. That said, planning – and prepara-tion – are prerequisites to success. Planningfor change is quite different from not plan-ning at all.

Agile methodologies, with their rapiditerations, require continual planning.Customer collaboration and responsivenessto change are tightly linked, if perhapsinconsistent with typical government-con-tractor relationships. One of the shifts inacquisition strategy in recent years has beentoward prototyping, evolutionary develop-ment, and risk-driven life cycles. With theiremphasis on addressing requirementsvolatility, agile methodologies could be apowerful synthesis of practices that DoDcontractors could leverage to make planningmore responsive to change.

Stepping Up to the PlateThe greatest challenge in taking advantageof the virtues of agile methodologies maylie in convincing acquisition agencies to stepup to the plate and use agile methods whereappropriate. Hardly lesser is the challenge inconvincing agile advocates to consider mod-ifying the agile methodologies to suit newarenas. We have to decide where to place thebalance point in documentation and planningto alleviate the concerns of the stakeholders(and regulatory requirements) while achiev-ing the flexibility and benefits promised inthe agile philosophy.

Agile methodologies may wind up beingthe preferred process in many environ-ments, yet be inappropriate in contexts suchas life-critical systems or high-reliability sys-tems. Modifications to the agile methodolo-gies needed for those environments may begreat enough that the synergistic effects ofthe set of practices in an agile methodologyare lost. Emergent properties in a system aresensitive to interdependencies. Arguing thatagile methodologies are not suitable for allenvironments is not the same as saying theyare suitable for none.

Contractual commitments explicitlybased on evolutionary or incremental lifecycles are desirable. Plans with miniature mile-stones that are detailed in the short term andconceptual in the long term are possible.Processes that capture the minimum essen-tial information needed to reliably and con-sistently perform the work and documenta-tion that captures useful information arefeasible. Just because these objectives aredesirable, possible, and feasible does not,

“One of the mostsignificant barriers toimplementing an agilemethodology is likelyto be an inability to

establish and maintainclose and effective

customer collaboration.”



however, mean they are easily realized.Selecting an appropriate balance pointrequires an open mind from both agile andplan-driven methodologists on both thesupplier and customer sides of the equation.

ConclusionsAgile methodologies imply disciplinedprocesses, even if the implementations dif-fer in extreme ways from traditional soft-ware engineering and management prac-tices; the extremism is intended to maxi-mize the benefits of good practice [8]. TheSW-CMM tells what to do in general terms,but does not say how to do it; agile method-ologies provide a set of best practices thatcontain fairly specific how-to information– an implementation model – for a partic-ular kind of environment.

Even though agile methodologies maybe compatible in principle with the disci-pline of models such as the CMM, theimplementation of those methodologiesmust be aligned with the spirit of the agilephilosophy and with the needs and inter-ests of the customer and other stakehold-ers. Aligning the two in a government-con-tracting environment may be an insur-mountable challenge.

As we learn empirically what works wellin the agile methodologies and how farthey can be extended into different envi-ronments, we should expect software engi-neering to adapt and adopt the useful ideasof the visionaries in the agile movement.This will include using data to separate thewheat from the chaff as we identify what is

useful, and what is limited in its applica-tion. Laurie Ann Williams, for example, hasintegrated pair programming into an exten-sion of the Personal Software ProcessSM

called the Collaborative Software Process,and demonstrated that performanceimproves [9].

Many of the practices in the agilemethodologies are good practices thatshould be thoughtfully considered for anyenvironment. While the merits of any ofthese practices can be debated in compari-son with other ways of dealing with thesame issues, none of them should be arbi-trarily rejected. Perhaps the biggest chal-lenge in dealing effectively with both agileand plan-driven methodologies is dealingwith extremists in both camps who refuse tokeep an open mind.◆

References1. Paulk, Mark C., Charles V. Weber, Bill

Curtis, and Mary Beth Chrissis. TheCapability Maturity Model ®: Guidelinesfor Improving the Software Process.Boston: Addison-Wesley, 1995.

2. Boehm, Barry. “Get Ready for AgileMethods, With Care.” IEEE ComputerJan. 2002.

3. Paulk, Mark C. “Using the SoftwareCMM with Good Judgment.” ASQSoftware Quality Professional June1999.

4. MacCormack, Alan. “Product Devel-opment Practices That Work: HowInternet Companies Build Software.”MIT Sloan Management Review Winter2001.

5. Einhorn, Hillel J., and Robin M.Hogarth. “Confidence in Judgment:

Persistence of the Illusion of Validity.”Psychological Review 85.3 (1978).

6. Dawes, Robyn M. Rational Choice in anUncertain World. Orlando: HarcourtBrace Jovanovich, 1988.

7. Beck, Kent. eXtreme ProgrammingExplained: Embrace Change. Boston:Addison-Wesley, 1999.

8. Paulk, Mark C. “Extreme ProgrammingFrom a CMM Perspective.” IEEESoftware 34.11 (2001).

9. Williams, Laurie Ann. “The Collabora-tive Software Process.” Diss. Univer-sity of Utah, Aug. 2000.

About the AuthorMark C. Paulk is asenior member of theTechnical Staff at theSoftware EngineeringInstitute. He has beenwith the SEI since

1987. Paulk was the “book boss” forVersion 1.0 of the Capability MaturityModel® for Software and the projectleader during the development ofSoftware CMM® Version 1.1. His cur-rent interests center on high maturitypractices and statistical control forsoftware processes.

Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213 Phone: (412) 268-5794Fax: (412) 268-5758E-mail: [email protected]

2002 U.S. Government's Top 5 Quality Software ProjectsThe Department of Defense and CrossTalk are currently accepting nominations for the 2002 U.S. Government's Top 5 Quality Software Projects. Outstanding performance of software teams will be recognized and best practices promoted.

These prestigious awards are sponsored by the Office of the Under Secretary of Defense for Acquisition Resources and Analysis, and are aimed at honoring the best of our government software capabilities and recognizing excellence in software development.

The deadline for the 2002 nominations is December 13, 2002. You can review the nomination and selection process, scoring criteria, and nomination criteria by visiting our Web site. Then, using the nomination form, submit your project for consideration for this prominent award.

Winners will be presented with their award at the 15th annual Software Technology Conference in Salt Lake City and will be featured in the July 2003 issue of CrossTalk and recognized at the AmplifyingYour Effectiveness 2003 conference.

SM Personal Software Process is a service mark of CarnegieMellon University.


Using Code Science®, an agile softwaredevelopment methodology based on

eXtreme Programming (XP), we1 recentlydelivered an application (code-namedOdyssey) consisting of 400,000-plus exe-cutable source lines of code (ESLOC) toone of the world’s premier industrialautomation companies. The application waswritten in C++ by as many as 17 developers(including some of our customer’s staff) inapproximately 15 months. We are geograph-ically remote from this customer.

Odyssey was delivered a month and a halfahead of schedule with a productivity rate of43 ESLOC per coding hour. During theproject duration, approximately 2,400defects were found and fixed, yielding a cap-tured defect density of six defects per thou-sand lines of code (KLOC). During a thor-ough, more than six-week customer-con-ducted acceptance test, only about 200defects were found (none severe), yielding adelivered defect density of 0.5/KLOC. Thecustomer is delighted with the product and isconfident of the competitive edge achieved.

The ApplicationThe Odyssey program consists of two dis-tinct but related scalable vector graphicsapplications. The first is a run-time applica-tion that issues real-time commands from atouch screen panel to devices known as pro-grammable logic controllers, which are usedin manufacturing assembly processes. Thesecond is a panel design application thatenables human-machine interface engineersto develop the graphical equivalent of ahardware panel made up of buttons, gauges,and other control and monitoring devices.

Why Agile MethodsWe began experimenting with XP severalyears ago, and actually began our first XPproject a few months before Kent Beck pub-lished his first book on the subject [1].Before that time, we used several traditionalwaterfall and rapid application design-basedmethods. We were impressed at how quicklyour first XP project was completed.

In a side-by-side comparison of XP andwaterfall on the very same project, the XPteam delivered their final product when theother team was less than 50 percent com-plete. Since then, we refined our initial XPapproach to encompass successive refine-ments that became known as Code Science.

Code Science is largely based on thetwelve tenets of XP. These are as follows:1. Customer at the Center of the Project.

The customer is treated as a full-fledgedmember of the development team withaccess to all the information that the restof the team is privy to (e.g., defect logs,issue lists, etc.).

2. Small Releases. Simple releases are putinto production early and updated fre-quently on a very short cycle (two tothree days). New versions are released atthe end of each iteration (three to fiveweeks).

3. Simple Design. A program built with XPshould be the simplest program thatmeets the current requirements.

4. Relentless Testing. XP teams focus onvalidation of the software at all times.Programmers develop software by writ-ing tests first followed by software thatfulfills the requirements reflected in thetests. Customers provide acceptancetests that enable them to be certain that

the features they need are provided.5. Refactoring. The system design is

improved throughout the entire develop-ment process. This is done by keepingthe software clean, without duplication,as simple as possible, and yet complete –ready for any change that comes along.(Martin Fowler defines refactoring as“the process of changing a software sys-tem in such a way that it does not alterthe external behavior of the code yetimproves its internal structure” [2]).

6. Pair Programming. XP programmerswrite all production code in pairs: Twoprogrammers work together at onemachine.

7. Collective Ownership. All the codebelongs to the all the programmers. Thisenables the team to work at full speed.When something needs changing, it canbe changed without delay. It is importantto note that an effective configurationmanagement discipline is an importantenabler of this practice.

8. Continuous Integration. The softwaresystem is integrated and built multipletimes per day (ideally, every time a task isfinished). Continual regression testingprevents functional regressions whenrequirements change. This also keeps theprogrammers on the same page andenables very rapid progress.

9. 40-Hour Workweek. Tired programmersmake more mistakes. XP teams do notwork excessive overtime, which keepsthem fresh, healthy, and effective.

10. On-Site Customer. An XP project issteered by a dedicated individual who isempowered to determine requirements,set priorities, and answer questions.

11. Coding Standards. For a team to workeffectively in pairs and to share owner-ship of all the code, programmers needto write the code in the same way withrules that ensure the code communicatesclearly.

12. Metaphor. Development is guided with a

Odyssey and Other Code Science Success Stories

John ManzoAgileTek L.L.C.

Code Science® is an agile software development method based on eXtreme Programming (XP). This article describes the suc-cess achieved using code science to develop a complex industrial automation application. With a brief review of XP as back-ground, code science is described in terms of refinements made to XP in applying it to a wide variety of application domainsand industries over a period of almost four years. Included are real-world insights from the developers’ experience in applyingthis agile development method, concluding with a quantitative measure of the effectiveness of XP since its inception almostfour years ago.

“In a side-by-sidecomparison of XP andwaterfall on the verysame project, the XP

team delivered their finalproduct when the otherteam was less than 50

percent complete.”

® Code Science is registered in the U.S. Patent and TrademarkOffice.



simple shared story of how the overallsystem works. XP was originally used todevelop a payroll program at ChryslerCorporation [3]. The team used themetaphor of an assembly line to describethe process of building a payroll check.The key tenet in XP is iterative develop-

ment and the unforgiving honesty of work-ing code. The concept of iterative develop-ment has been around for a long time.However, XP does have some limitationssuch as scaling – the ability to add largenumbers of developers to a project thatrequires them. (Most XP practitioners con-sider six to 12 developers to be the practicallimit.) It was necessary to modify XP todevelop a methodology that would work onlarge projects, across multiple applicationdomains, and for clients with diverse andsometimes very specialized needs, for exam-ple, regulatory environments such as theFood and Drug Administration (FDA),where there is a strong need for extensivedocumentation.

The Code Science DifferenceA way to quickly understand Code Science isto think of it as XP with a delta (a set of dif-ferences). Some of the differences are addi-tive (+), some are subtractive (-) and someare simply modifications or refinements (�).Following are a set of differences defined.

+ Business Process AnalysisIn employing XP there is an implicitassumption that the client basically knowswhat it wants and, therefore, the require-ments gathering process can begin with userstories. Although this is often the case, manyof our clients need to focus and solidify theirideas and, most importantly, determine withclarity what they need rather than what theywant. To accomplish this, we developed aprocess that helps bring focus and under-standing to the client’s business needs, prior-itizing features and functions in terms of thebusiness value they represent. This first step,which is formally absent from XP, is a stepwe can take when necessary to ensure that thestory-gathering effort produces stories basedon a real vs. perceived need.

+ Delphi EstimationThe Delphi method of estimating involvesthree or more participants who discuss thework and provide anonymous estimates ofthe time for completion (usually in units ofperfect programmer hours – i.e., an ideal, nointerruption, period of time). These esti-mates are tallied and a mean and standarddeviation is made known to the participants.Discussion ensues among the participants asto the differences in the estimates (whichremain anonymous). This continues for suc-

cessive rounds (usually three) until the stan-dard deviation (a measure of uncertainty) ismade sufficiently narrow. Once the numberof perfect programmer hours is known, aloading factor is applied to convert this esti-mate to real programmer hours.

+ Componentized ArchitectureFor complex systems, it is especially impor-tant to assure conceptual integrity in the finalproduct. Also, because complex systems canbe large, it is also important to enable thesystem to be developed in an environmentof distributed ownership. Among the leastunderstood areas of XP is the notion ofdesign-as-you-go through refactoring. To some,especially those who equate design andarchitecture, this means no up-front archi-tecture, and, by implication, any architecturethat the delivered system may have is a de-facto one at best.

Architecture of a system simply meansidentifying the constituent components ofthe system and defining the interrelation-ship(s) between them. The best architecturesare isomorphic (one-to-one) mappingsbetween problem and program space. Thisensures that a system’s underlying structureand components mirror the problem beingsolved. This means that for the program tochange requires that the problem changes and,therefore, you are change-proofing your pro-gram. While there may be more efficientways to solve a problem (e.g., creating onemodule to perform similar functions byinvoking it in a context sensitive way), thisefficiency will almost always come at theexpense of time spent debugging and latermodifying the program if one or more ofthe functions change.

However, it also means something more.By defining the relationships between thevarious components, one has gone most ofthe way toward establishing agreements forthe interfaces. The power of interface agree-ments is that they serve as restrictive libera-tors. In other words, the individuals workingon various system components are free todesign the internals of those componentswithout regard for potential untowardeffects on the rest of the system – so long asthe interface agreements are honored.

By spending a relatively small amount oftime up front, one can ensure both a prod-uct with conceptual integrity and a projectthat can scale.

+ Automated Contract andRegression TestingGiven that XP is premised upon the need toembrace change, making it easy to performregression testing is an important part ofany XP project. We have taken this to thenext level by implementing the capability toperform contract testing, which checks forthe existence of predefined pre-conditions,post-conditions and class invariants. (As anexample, an overdrawn flag in your checkingaccount is invalid if there is a positive bal-ance remaining after the last transaction.)

+ Story ActorsWe have added to the notion of stories theconcept of story actors. Actors are personifi-cations of the various categories of users thesystem will encounter. Thinking of therequirements in terms of actors brings therequirements to life as well as unmasksnuances that would otherwise remain invisi-ble to both the developers and the customer.

+ Wall GanttsFrequently used in project management, aGantt chart provides a graphical illustrationof a schedule that helps to plan, coordinate,and track specific tasks in a project. We havetaken the concept one step further andadapted it to agile methods by creating aphysical construct using twine, pushpins,and index cards. The twine is used to createa line on a wall. Tasks, written on cards, arefolded in half and hung on the line (one linefor each project participant). Index cardswith dates (one for each day of an iteration,which usually lasts three to five weeks) arepinned across the top of the chart.

Physically constructing the Gantt chartmakes it very easy to move tasks around,drive out dependencies, and load balance.Because the chart is wall size, it is easy forthe team to stand around the chart to discussthe state of the project in near real-time(each day starts with a stand-up meeting).The wall Gantt also provides clear owner-ship for development efforts, encouragesaccountability, and serves as the team’s warroom and center of the project universe.

+ Automatic Document GenerationThrough a tool we have built called Doc-It(similar to JavaDoc), we are able to reducethe burden and streamline the process ofgenerating documentation that describes theinner workings of the code. Experienceshows that it is a poor practice to separate

“The best architecturesare isomorphic

(one-on-one) mappingsbetween problem and

program space.”

Odyssey and Other Code Science Success Stories


documentation from the code that itdescribes. Updating source code documenta-tion is difficult enough, but once the docu-mentation is separated from the code, it is“out of sight, out of mind.” To deal withthis, a programmer simply needs to tag acomment in the source code and Doc-It cre-ates automatic HTML Application ProgramInterface documentation with every build.

Doc-It traverses source code directories,creating a navigable hierarchy (directory,class, method) and creates a Web page foreach source file. This makes the documenta-tion easily accessible to new and existingteam members. It also makes the documen-tation easily accessible to clients during co-development or during knowledge transferphases.

� Pair ProgrammingAlthough our experience proves pair pro-gramming to be extremely effective, formany routine programming tasks, pair pro-gramming has not shown itself to be costeffective. On the other hand, for anythingeither algorithmically or logically complex,pair programming is a must. The default is toprogram in pairs, but the team gets to decidewhich modules will be coded solo.

- 40-Hour WorkweekWhile we strive to provide the highest quali-ty of life for all our staff members, it is unre-alistic to expect that our client’s time-criticalrequirements will not sometimes necessitatesustained periods of activity. Treating a 40-hour workweek as a hard requirement isoften impractical.

- MetaphorMetaphor is not included in Code Science.While we concede that it has benefits, so farwe have not found a need to incorporate theuse of metaphor in our methodology.

+ Flexibility to MeetClient’s Special NeedsSome of our clients have special needs thatare not accounted for by pure XP (e.g., inhighly regulated environments such as bio-medicine, the FDA requires specialized doc-umentation and traceability for certain typesof software). Code Science eliminates thisXP limitation by incorporating a special needsprovision in our methodology.

Application to OdysseyCode Science is used on all Geneer softwaredevelopment projects. The Odyssey projectwas no exception. However, no two projectsare the same. Each emphasizes certain ofthe specific tenets described above to differ-ing degrees. In the interest of brevity, we

describe some of our developers’ moresalient experiences and insights in applyingthese tenets.

The Customer Isat the CenterXP talks about having the customer on-site.While this is ideal, our experience in usingXP/Code Science over the last four years isthat it is seldom practical unless your cus-tomer is internal. In the case of Odyssey, thecustomer was located hundreds of milesaway.

More important than physical location,however, is putting the customer at the cen-ter of your project as described earlier. In anXP/Code Science project, there is noattempt to hide information from the cus-tomer. While we did not insist the customerbe physically in our facility, we did requestthat they be present during iteration plan-ning, periods of critical knowledge transfer,or to approve test plans and validate theirresults – usually at the beginning/end ofiteration. When this was impractical, or forroutine communications, we used e-mail,conference calls, WebEx sessions, or video-conference. With active customer participa-tion, the resulting product can be everythingthat the customer expects it to be.

RefactoringRefactoring does not mean re-working. Donot partially write a feature with the intent ofrefactoring to get it complete later. Keep thechanges simple, but keep them atomicallycomplete.

Pair ProgrammingPair programming was especially useful inramping up a new staff member. It was alsoquite useful for chasing down complexdefects. For simple modules, the team foundit more expedient to use the white board inpairs for 15 minutes, then program solo.

Continuous IntegrationThe team performed builds at least daily,more often, two or three times a day. With agood automated build program, you cannotbuild too often. Our builds are generatedwith a custom, home-grown application thatcreates builds at 4 a.m. and again at 3 p.m.This gives the team a fresh build everymorning and also one to work on in theafternoon. Besides performing the physicalbuild, we are also informed if the build isbroken (e.g., cannot compile because of asyntax problem, or a configuration manage-ment issue – checked in one file and notanother, etc.).

40-Hour WeekDuring a long period of peak activity, the

team found it helpful to make their workenvironment homier. By making their work-place a more dorm-like environment, theysignificantly eased the stress of the long,often intense, workdays and nights.

Componetized ArchitectureA high-level architecture was defined at thebeginning of the first iteration, and as moreinformation became available, more detailwas added to successive iterations. Teamleads would spend perhaps two days withtheir teams using white boards for a four tosix-week iteration. We found that the biggestmistake one can make here is to attempt toget too detailed about something for whichthere is insufficient information.

Story ActorsBecause most of the team never worked onan industrial automation application, actorshelped the team get familiar with the client’sdomain. When the team took a field trip,they could identify the user types by theiractor names (representative of their role-play, more than their job title). It helped theteam understand the business and how theproduct would be used in stories. Therequirements were written in terms of howthe system would be used, vs. desired func-tions. By associating who is doing what, ithelps conceptualize and compartmentalizethe functions.

Wall GanttsWall Gantts make load balancing easy andkept the project on track. The whole teamsees the actual size of the function based onthe task cards and there is great satisfactionin putting completion stickers on each card.An extremely useful management tool, WallGantts also helped to reveal issues andexpose risks.

Large Team ExperienceAlthough the overall team was divided intosubteams, stand-up meetings were typicallywith the entire team. Team leads summarizeand add detail with other team members asneeded. As tasks are completed, people canmove from one team to another.

ConclusionDuring a period of almost four years,XP/Code Science has been employed on 14projects across a wide variety of applicationdomains and industries such as aerospace,telecommunications, banking and finance,pharmaceuticals, consumer goods, and evenpari-mutuels. These projects ranged in sizefrom 10 KLOCs for a Personal DataAssistant client, to more than 400 KLOCs

CONTINUED ON PAGE 30

Software Engineering Technology

Today, many companies are examiningtheir internal processes in an effort to

integrate more effective systems and soft-ware engineering. Many of the challengesfaced in integrating systems and softwareengineering exhibit similarities to chal-lenges observed on large distributedefforts.

In this article, engineering organiza-tional variations are first explored, not tojudge but to recognize the existence ofvariation and to note a common charac-teristic observed in all successful organi-zations regardless of size or structure.The article then discusses how the identi-fied characteristic is achieved in differentorganizations.

This preliminary investigation sets thestage for a closer examination of whatsystems and software integration meansin practice. An alternative view of a suc-cessful large project is presented that maychallenge current published literature.The information presented in this articleis the result of research initially conduct-ed on large distributed projects [1].

Organizational VariationIf you were to ask a manager or seniorengineer working today in a largeadvanced technology software-intensiveorganization to examine the chart inFigure 1, it is likely he (or she) would nodhis (or her) head up and down, reflectingfamiliarity with the functional organiza-tional structure and terminologyemployed on the chart.

Each rectangle on Figure 1 under-neath the engineering manager is imple-mented through a department each withits own manager and pool of skilled engi-neers. At this level, similarity acrossdiverse organizations is evident.Nevertheless, while many organizationshave a similar top level structure, we haveseen that inside these organizationsimplementation can vary greatly.

For example, in some organizations

the Systems Engineering department istotally responsible for producing the soft-ware requirements specification (SRS). Inother organizations, the Systems andSoftware Engineering departments col-laborate on the production of the SRSwith each producing specific piece-parts ofthe final SRS. We have also witnessed athird organizational variation where theSoftware Engineering department pro-duces the complete SRS, while the sys-tems group provides a review andapproval role.

Note that in all three cases described,the organizational chart referenced inFigure 1 could be used to describe theorganizational structure. At the sametime, it is important to note that what weare asking engineers to do in departments

by the same name, but in different organ-izations, can differ greatly.

Common Successful KeyCharacteristicsIt is not the intent here to judge the mer-its of particular organizational approach-es, but rather to acknowledge their exis-tence and to point out a key characteristicwe have observed common to all success-ful organizations. In each case, when anorganization functions successfully toproduce an end product, individuals with-in that organization understand and accepttheir specific role. That is, they understandthe organization’s expectations of them.

This mutual understanding of roles,responsibilities, and expectations leads tooperational efficiency with minimal dupli-cation of effort. The successful organiza-tion appears from the outside to functionas a single unit. Its piece-parts may varyon the inside, but in each case they cometogether without major surprises into afinal integrated product.

It is worth noting here that in ourexperience we have found in many suc-cessful organizations that the definition ofand responsibility for each piece-part isoftentimes not written down or describedformally. It has been our experienceworking with large software intensiveorganizations with long histories ofdevelopment and evolution that thisknowledge may have been written downat some point in time but due to organi-zational evolution, its current state ismost often passed on through less formalmeans.

Integrating Systems and Software Engineering:What CanLarge Organizations Learn From Small Start-Ups?

Paul E. McMahonPEM Systems

In an effort to integrate more effective systems and software engineering, many companies today are examining their internalprocesses. Recent research conducted on distributed development efforts may provide insight that could aid today’s systems andsoftware integration initiatives. Drawing material from his book, “Virtual Project Management: Software Solutions forToday and the Future [1],” the author explores variations in large and small engineering organizations and presents an alter-native view of large projects that may aid companies in their quest for more effective systems and software integration.


EngineeringManager

SystemsEngineering

SupportEngineering

Integration & TestEngineering

SoftwareEngineering

Figure 1: Traditional Functional Engineering Organization

“... it is importantto note that what

we are askingengineers to do in

departments by thesame name, but

in differentorganizations, can

differ greatly.”


Integrating Systems and Software Engineering: What Can Large Organizations Learn From Small Start-Ups?

Communicating Expectationsin Large OrganizationsIn large organizations we tend to seeexpectations communicated throughstructure and what we refer to as aprocess focus. While many large firmshave over the past few years undergoneorganizational streamlining, our experi-ence indicates that sizable written com-mand media with phase-related exit andentry criteria continues to be relied upon.

The process employed inside many ofthese large organizations can be referredto as predictive, or repeatable. Whilewritten command media aids repeatabili-ty and communication, we have foundthat new engineers in many large organi-zations cannot rely totally on this writtenword to fully comprehend organizationalexpectations. Frequently, local culturesare also relied upon to aid communica-tion of expectations.

Communicating Expectationsin Small OrganizationsUnlike many large organizations, smallorganizations most often see little struc-ture, little process, and little establishedculture. The focus of most small organi-zations is on surviving. We find manysmall organizations to be heavily relianton specific individuals. Given this situa-tion, on the surface it would appear thereis little a large organization could learnfrom a small one. However, let us take acloser look at the small organization.

The Small OrganizationSuper Programmer ModelThe communication of expectations inmany small organizations is simple todescribe. We refer to it as the super pro-grammer model that implies a do-it-allexpectation. The problem with thismodel is that, while expectations areclear, those expectations often lead toover-reliance on, and burnout of, individ-uals. We frequently find organizationsthat live by the super programmer modelalso live by the code-and-fix methodology.

During the past few years, we haveknown colleagues who have given up therelative security of the large, establishedorganization in favor of the increasedopportunity afforded by small start-ups.Unfortunately, many have also foundthat the demands of the small start-uprequire great personal sacrifice. Whilesome have returned to the more pre-dictable large corporate environment, oth-ers have found increased job satisfactionthrough an alternative small-companymodel that is rapidly gaining in populari-

ty: the small team model.

The Small Team ModelToday, many small organizations are mov-ing away from the super programmermodel of operation in favor of a small teamdevelopment approach. This change alsooften reflects a move away from a code-and-fix methodology, or no process, towhat is referred to as an adaptive or light-weight process or method [2]. When weuse the term adaptive method in this articlewe mean a method that supports rapidchange initiated through small teams.

Lightweight processes can be thoughtof as just enough process, or process with-out a process-focus. Examples includeeXtreme Programming (XP), which havebeen described by Kent Beck [3] and JimHighsmith [4].

Characteristics of many lightweightprocesses include the following:• Code and test focus.• Continual iterative design.• Pair programming.• Continual planning and integration.

Upon first learning about the charac-teristics of XP, our reaction was, “This isfluff camouflaging a traditional code-and -fix methodology.” However, after observ-ing and interacting with a number of smallteams embracing this approach, we havereached a different conclusion.

XP Fundamentals in PracticeWhile it is true that XP focuses on today,we have found that organizations that takethis methodology seriously do not do so atthe expense of planning. In fact, teamsthat follow this process often find them-selves planning continuously. Planning inan XP environment is different from tra-ditional planning conducted on manylarge projects. Plans are short in length,contain specific attainable goals, and oftenfocus on periods of only a few weeks induration.

This notion might not even sound likeplanning to those familiar with the processas currently implemented in many largeorganizations. It also might sound short-sighted and non-optimizing (not lookingto the future for improvement), but theimmediate feedback provided throughshort repeated cycles of planning and exe-cution is proving to be effective from theperspective of the engineer in the trench.

This is the first fundamental differ-ence we noticed when dealing with a smallcompany employing an adaptive method-ology. The second came when talking tosoftware engineers working on an XPteam: We found a surprising level ofawareness and ownership of schedule and

budget. The software engineers wereaware of the schedule and budget and feltownership of it because they had partici-pated in its development. On the otherhand, in many large organizations, wehave found that it is not uncommon forengineers to have little insight into theproject schedule and budget.

Upon first learning about XP, wefound its code-focus to be difficult toaccept. However, after observing an XPteam in action, it left us with a differentimpression.

The notion that programmers usingXP do not design is a misunderstanding.One member of a small XP teamexplained it to us this way: “Just becausewe focus on the code doesn’t mean wedon’t give each task considerable fore-thought. We just don’t write down theresult formally, and we don’t use a formaldesign tool.” Then after he hesitated, headded, “But we might draw a sequencediagram or two, if we think it might help.”Another member of the same team said,“We keep our designs as simple as possi-ble, and we try not to spend any unneces-sary time in design.”

We had an opportunity to witness thedesign process in action with a small team,and it reminded us of an informal brain-storming session you might see in anyorganization. The meeting had not beenscheduled ahead of time. It just happenedbecause one member of the team wantedsome help. Within a few minutes, threeteam members had gathered around awhite board, and 25 minutes later therewas a design solution sketched out on theboard. We suggested that someone cap-ture the diagram more formally.

Another interesting aspect of XP ispair programming. When we first heardabout pair programming, we expressedagreement with the concept to a youngclient. Our thinking was that this tech-nique would provide a backup in case oneteam member was pulled off the projector got sick. But the client was quick toexplain that pair programming had noth-ing to do with having a backup.

We have since learned that some pairprogramming team members are adamantabout having both team members presentside by side during 100 percent of theprogramming activity. That is right! Notonly does it take two people to completeone program, but also if one of the two ismissing, in some cases, the other does notwant to move on. Doesn’t that soundincredibly inefficient?

But then the client went on to explain:“It’s the dialogue that I don’t want to miss.By having my teammate right next to me,

Software Engineering Technology

it forces me to verbalize my thoughtprocess at the moment I type the code in.Often through this process, errors aredetected at the same moment when theyare about to be created.”

As I listened to this process beingdescribed, a light bulb was flicking on inmy head – this process is what peerreviews and early error detection wasalways meant to be!

Tailoring XPWhen reading about a new methodology,you often envision something differentfrom the way organizations actually applyit. XP, according to the book, includes 12key practices. However, not all companiesthat claim to employ XP follow all thepractices exactly as outlined by Beck [3].For example, while many small organiza-tions have recognized the value of pairprogramming, others have also recognizedthat what their engineers actually doextends beyond programming itself.

Often we find in practice that the pairrecognizes that one of the members hasmore of a systems inclination (i.e., customerinterface, requirements management),while the other prefers the traditional pro-grammer role. These recognitions are usu-ally based on individual strengths anddesires. As a result, we tend to see a systemsfocus and a software focus being supportedwithin the small team and small companyenvironment, but without the formal sys-tem and software department boundariesthat are prevalent in large organizations.

Effective Systems andSoftware Integrationin PracticeWe have witnessed large organizationscommunicating expectations throughdefined organizational structures, support-ed by heavyweight command media (policies,practices, and procedures). We have alsoseen the key role of culture in communi-cating expectations in large organizations.

In small organizations applying light-weight methodologies, on the other hand,communication occurs through short-range planning that leverages individualteammate strengths. Given what we havewitnessed inside both large and smallorganizations, we are led to a question:“What does effective systems and softwareintegration mean in practice?”

We believe that the answer to thisquestion should be independent of thesize and structure of the organization. Wepropose the following definition: Effectivesystems and software integration meansthat the right interactions are occurring at

the right time, the right questions arebeing asked at the right time, and the rightfactors are being considered and actedupon at the right time.

Systems Engineering InsideLarge OrganizationsWe have, on a number of occasions, takenthe opportunity to ask an engineer in alarge organization, “What is systems engi-neering?” Often the answer received hasequated to, “whatever the systems engi-neering group does,” in that particularorganization.

Unfortunately, this answer can beproblematic for two reasons. First, froman educational viewpoint, how are we toprepare systems engineers in our universi-ties when the expectations of a systemsengineer can vary dramatically from oneorganization to another?

Second, when task expectations aretoo tightly coupled to an organizationalstructure or department charter, theincreased likelihood for tasks to fallthrough cracks exists. This is because noorganization is perfect. We have alsofound that a tight coupling of task respon-sibilities to organizational partitioningtends to give rise to the “it’s not my job”syndrome in large organizations.

Systems Engineering InsideSmall OrganizationsOn the other hand, when we have asked,“What is systems engineering?” to an engi-neer who has experienced only the smallorganization environment, the most com-mon response has been a puzzled look onhis/her face. This is because in most smallorganizations, engineers do not think interms of distinct systems and softwaretasks; rather, they think in terms of gettingthe job done.

One reason small organizations do nottend to exhibit the task-related difficultieswe have observed in large organizations isbecause they have not artificially parti-tioned detailed tasking responsibility basedon organizational boundaries. Stated dif-ferently, in small organizations that useadaptive methods, the team works out thetask responsibilities knowing that togetherthe team is responsible for everything.

Applying a LightweightApproach to a Large ProjectPublished literature available today onlightweight methodologies [3, 4] indicatesthese approaches may not be scalable tolarge projects. While we do not recom-mend XP practices be applied in full onlarge projects, a number of the most suc-

cessful large projects we have witnessedtend to already embrace many of thesesame practices. Although it is unwritten,i.e., not found in any formal corporatecommand media, a number of the mostsuccessful large projects we have observedalso tend to exhibit an unspoken adaptivesubculture.

Characteristics of these projectsinclude incremental development, plansthat focus on today, and a code focus. Acode focus may seem unusual to a largeproject especially in large disciplinedorganizations, but in practice it has provento be particularly effective when heavyreuse is involved. Testing candidate reusecode early, peer reviewing proposedchanges early and often, integrating early,and staying integrated through a series ofincremental builds have proven to be effec-tive techniques on projects of all sizes.

A Key to SuccessThis article recommends managing a largeproject as a collection of small adaptiveprojects. This recommendation is notmeant to imply that the adoption of suchmethods alone is sufficient to ensure largeproject success. On the contrary, if smallteams within a large team were allowed tocontinually adapt their plan independently,then chaos would certainly result.

On one large project that we worked asa team member, the software work waspartitioned across the country at three dis-tinct sites. But before the work partitioningtook place, a small group of senior projectpersonnel established overall system archi-tecture with very specific constraints,including computer platforms, compilers,tools, and interfacing requirements.

As the project evolved, there alsoevolved a number of small teams each withapproximately seven to 10 engineers. Eachsmall team had its own unique develop-ment issues. The project leader empoweredthese lower level informal small teams tomake key decisions constrained only by theproject requirements and the defined proj-ect architecture.

Many of the characteristics we haveseen in successful small companiesemploying adaptive methods are also evi-dent within small informal teams insidelarge projects. You will not necessarily findthe small teams we are referring to on a for-mal organizational chart.

In-the-large XP practices can work, butonly if implemented within the context ofa higher level framework.

In short, we want our small teamsinside large teams to take on increasedresponsibility, but the key to success onlarge projects is ensuring small team adap-



Integrating Systems and Software Engineering: What Can Large Organizations Learn From Small Start-Ups?

tations are consistent with well-defined,well-communicated system architecture.

An Alternative Viewof a Large ProjectThrough the use of a small architecturegroup and other related techniques tocommunicate architectural decisions andresponsibilities [1], large projects caneffectively be managed as a collection ofsmall adaptive projects (Figure 2). Whilemany large companies may not formallydescribe their operating structure in theseterms, many successful large projects oper-ate in this manner today.

It is also worth noting that we do notrecommend that the notions of smallteams and pair programming be overlyformalized in large organizations. Thiswould, in fact, undo the value we seek.Informality is an essential ingredient to thesuccess of the small team in any organiza-tion.

Pair programming can be effective inan organization of any size, but it is alsoimportant to realize that some people justdo not team well, and we do not believethat forcing small teams or pair program-ming makes sense in any organization.

Different companies have differentcultures and differing past experiences andbeliefs surrounding their workspace. Somebelieve in open workspaces, while otherspride themselves in the private offices theyprovide their professional personnel.Nevertheless, we are witnessing a definitemovement within the software communitytoward more group activities in support ofincreased productivity.

One new engineer in a large companytold us that he sat in his cubicle for the firstthree months of his new job continuallywanting to ask questions, but not wantingto be perceived as a nuisance. Other newengineers in the same company, we foundout later, felt the same way.

Soon thereafter, an engineering labenvironment was set up. It was not longbefore all the new software engineers werespending more and more time together inthe lab. One engineer said the lab environ-ment made it much easier to ask questionsand to listen to answers to questions askedby others. Progress on the projectincreased at lightning speed shortly there-after.

Conclusions A few months after providing assistance toa small company utilizing XP, we askedone of their engineers a simple question:“Had anything changed over the past fewmonths?” The engineer responded: “If Ihad to point to one thing, I’ve noticed thatI’m spending less time dealing with urgentand unimportant matters, and more timeon the things that count.”

Adaptive methods not only can workin large organizations, we have found theyare often key to large project success. Werecommend large organizations that arenot operating as effectively as desired con-sider the selective adoption of adaptivetechniques.

What really first caught our attentionwith adaptive methods was the focus onthe engineer in the trench. Too often, well-intentioned process improvement initia-tives never seem to reach the real workers.

In reality, the short cycles of planningare not shortsighted, rather they are basedon the length of time into the future wherewe have control over where we are going.

It is also important to note that it is notthat the process we see today in large com-panies is not working, but it works at itsown pace. Adaptive techniques and smallinformal teams inside large organizationscan complement a formal organizationalprocess focus, and can also be an effectivemethod to facilitate change in an organiza-tion that is not evolving at the pace need-

ed to remain competitive in today’s world.Write plans that work today, and do not

discourage your team from continuallyupdating their plans to reflect increasedknowledge tomorrow. Encourage smallteams to leverage your organization’sstrengths regardless of where thosestrengths lie inside your organization.

Small teams and adaptive methods cannot only help your systems and softwareintegration efforts, but they can also pre-pare your organization to be more effec-tive in tomorrow’s collaborative world.◆

References1. McMahon, Paul E. Virtual Project

Management: Software Solutions forToday and the Future. Boca Raton: St.Lucie Press, An Imprint of CRC PressLLC, 2001.

2. Fowler, Martin. “Put Your Process on aDiet.” Software Development Mag-azine Dec. 2000: 32-36.

3. Beck, Kent. eXtreme ProgrammingExplained: Embrace Change. Boston:Addison-Wesley, 1999.

4. Highsmith, James A. AdaptiveSoftware Development: A Collabora-tive Approach to Managing ComplexSystems. New York: Dorset HousePublishing, 1999.

About the AuthorPaul E. McMahon isan independent con-tractor providing tech-nical and managementleadership services tolarge and small engi-neering organizations.

Before initiating independent work asPEM Systems in 1997, McMahon heldsenior technical and management posi-tions at Hughes and Lockheed Martin.Today he employs his 28 years ofexperience to help organizationsdeploy high quality software processesintegrated with systems engineeringand project management. He hastaught software engineering atBinghamton University in New York,conducted software process and man-agement workshops, and has pub-lished more than 20 articles and a bookon virtual project management.

118 Matthews St.Binghamton, NY 13905Phone: (607) 798-7740E-mail: [email protected]

Large Project

SmallTeam

SmallTeam

SmallTeam

Figure 2: An Alternative View of a Successful Large Project

Agile software development is not new.It has been around since the beginning

of software development, but did notshow a competitive advantage in the 1970sand 1980s, said Alistair Cockburn, a con-sulting fellow at Cockburn and Associates.However, it did win the development racesin the turbulent 1990s, he said, andmethodologies that began appearing in1993-95 were Rapid ApplicationDevelopment, eXtreme Programming(XP), Scrum, Dynamic SystemsDevelopment Method, Crystal, and adap-tive.

Cockburn was one of the speakers atthe “Creating Competitive AdvantageThrough Agile Development Practices”technology forum held recently atWestminster College in Salt Lake City.More than 150 attendees learned aboutagile software development and networkedwith peers during breakout sessions. TheWestminster College Gore School ofBusiness and Wasatch Digital IQ co-spon-sored the forum.

In his talk, Cockburn explained thatagile software development is about put-ting value on “maneuverability.” He said,“Its [agile development] being able torespond quickly became its advantage,however, agility is a value statement.”Cockburn stressed that agile is not appro-priate for every project. Some projectswant predictability and repeatability, andcost and agility go against each other, hesaid. “With agile, it costs more to deliverproducts faster. There are trade-offs, andeach project will make its own appropriatevalue decisions.”

Jim Highsmith, director of CutterConsortium’s Agile Project ManagementAdvisory Service, cited two main reasonsfor the popularity of agile software devel-opment today. “Agile addresses a problemdomain where speed and flexibility areparamount,” he said. “And it addresses aculture and workplace we would like –that Dilbert would like to work in – acommunity.”

Cockburn noted that agile methods

make greater use of the following: individ-uals and interactions, working software,customer collaboration, and responding tochange. Plus, agile means different tech-niques in different situations, he said.“Within agility, different tactics fit differentsituations. Agile is not just a re-titling ofeXtreme Programming.”

Highsmith noted that agile works bestin “exploration” environments. He com-pared it to drilling for oil: Drilling toknown oil reserves requires very differenttechniques to be cost effective than does

exploration drilling to find oil. In each case,projects are managed differently and suc-cess is measured differently, he said. “Agilesoftware development finds a way aroundproblems to get successful projects.”

Highsmith defined an exploratoryproject in the software world as “one tocomplete large projects that are both fron-tier (research-like) and mission critical in aturbulent business and technology environ-ment. The characteristics include earlyproduct release, high customer involve-ment, and frequent testing.”

What led Symantec to move to XP was

not delivering the product that its customerneeded, said Russell Stay, vice president ofProduct Delivery. The company was usinga modified Waterfall technique consistingof up-front design then execution. Tightproject management resulted in deliveringthe product on time and in budget, saidStay, but it was the wrong product. “Weneeded to adopt a new process.”

Agile software development is aresource-limited cooperative game ofinvention and communication, saidCockburn. The key is adapting to realitywith players – people – who are non-linear,unpredictable, spontaneous, and bringweaknesses and strengths to the game,which never repeats itself, he said.“Software succeeds when people noticeerrors and have enough pride in their workto step out of their job description to seethat it gets fixed.”

An important consideration, saidCockburn, is that people communicatemost effectively interactively, i.e., face toface. “The richest form of communicationis two people at a white board. The leasteffective form is on paper.” Much is said inthe communication that occurs with bodylanguage, voice inflection, facial expression,etc., he said.

Added to this is the fact that the projectmethodology gets restructured around theecosystem details, which are always chang-ing. The key is to pair workers who com-plement each other to achieve the desiredresults. For example, said Cockburn, if“Bill” only has the patience to take a proj-ect through the requirements stage, then heshould be teamed with “Mary” who excelsin implementing the process through toproject completion, he explained. “Thisway, information gets from the marketplaceto the programmers.”

“Gone are the days of the saviors andcowboys,” said Stay. Pair programming wasstressed up front when Symantec began itsagile implementation. Stay said that he waswilling to accept a 15 percent attrition ratedue to this change. However, after giving ita try, he said that fewer than 8 percent of

Highpoints From the Agile Software Development Forum

Pamela BowersCrossTalk

There is much confusion in the software industry about what agile software development is and is not, and what it implies.This article reports on the keynote talks at the “Creating Competitive Advantage Through Agile Development Practices”technology forum held at Westminster College in Salt Lake City in March. Nearly 110 attendees at this initial annual forumparticipated in work sessions and networking breaks, and heard speakers and panel discussions about increasing return oninvestment, decreasing time to market, increasing innovation, and more.


“Agile softwaredevelopers are not

hackers. Agilists planregularly, test according

to project priorities,and re-check results

with users often.They talk to each

other and customersas a matterof practice.”


employees left the company.Stay stressed that it is important for the

team to buy into the agile method and thatcoaching should be brought in house. Co-residence is also critical so that leaders anddevelopers can work side by side, he said.“Individual office cubes get used less andless. Our average use is about one hour perday. The rest of the time, the developmentarea is the hub of activity.”

Unfortunately, the agile message isoften misconstrued, said Cockburn. “Agilesoftware developers are not hackers.”Unlike hackers, agilists do plan regularly, hesaid. Agilists test according to project prior-ities, and re-check results with users often.They talk to each other and customers as amatter of practice. They expect manage-ment to provide priorities and to participatejointly in making project adjustments.

Stay concurred. The process atSymantec is “highly managed but flexible,”he said. They use the “queing” theory ofbreaking down the process into small parts;

iterations are done biweekly. Also, exit cri-teria and test procedures are defined first,before writing code, he said, and testautomation is a priority.

It is also not true that agile only workswith the best developers, Cockburn said.The critical success factor is to have at leastone experienced and competent lead per-son, who can then carry four or five “aver-age or learning” people. With that skill mix,agile techniques have been shown to workmany times when the deck is “stacked” asfollows:• Hire good people.• Seat them close together to help each

other out, close to customers and users.• Arrange for rapid feedback on deci-

sions.• Let them find fast ways to document

their work.• Cut out the bureaucracy.

“Agile software development has a lotto do with how much trust and communi-cation is set up,” said Cockburn.◆

Successful Methodology Ensures Reuse

In the real world, organizations can mandate that Personal Software ProcessSM (PSPSM)be used on a project and install the trainers to make sure it is used. However, soft-

ware developers can either refuse to use PSP, or find many ways to subvert it, warnedAlistair Cockburn, a recognized expert on software project management in an interviewwith CrossTalk.

“Since 1991, my views on methodology have been that programmers can at anytimeopt not to use this [process] either overtly or covertly,” said Cockburn, a consulting fel-low at Cockburn and Associates. “Therefore, the definition of the successful method-ology for me includes that the people agree to use it the next time.”

Cockburn said that he is looking for the way [methodology] that “puts the leastrequirements for consistency and discipline on software teams, yet beats the odds.” Hepointed to Crystal as a solution. There are three core principles in Crystal that make itsuccessful. First, it works in increments, which allow you to recover from almost anycatastrophe. Second, Crystal calls for reflection after every increment to discuss what tokeep and what to change, which develops a process that adapts to change. Third, theteam must tailor itself to create its own process. He added that Crystal also has a strongemphasis on personal communications, tacit knowledge, close worker proximity, andfrequent delivery of running deliverables. It is all these elements, Cockburn said, thatallow you to “beat the odds.”

When asked, “What are the three things that most ensures agile success?” Cockburnsaid that experienced management is the No. 1 factor. “You need to have a project man-ager who is alert, sensing whether something is right or wrong, and with enough expe-rience to steer the group. Second is having access to real users; developers need reliableinformation for requirements, to have someone handy to show results, and to get feed-back on a reliable basis. Third most important is physical proximity. It is important tohave people close enough together that they can talk to each other, he said.

Cockburn also advises management to pay attention to their fears. “They could bewell founded.” The key is to find out which fears are unfounded, he said. For example,he pointed to the fear of “hacking.” In XP, the process check is that there are alwaystwo people working together, so it’s a lot harder for one of them to hack, he said.Programmers also write their acceptance check before they write actual code, and thistakes a lot of thinking, he added. A final rule is that any two people sitting together canchange anybody else’s work, as long as they agree, he said. “Call it common ownership.”

With agile development, said Cockburn, “Programmers cannot just say, ‘Go awayand leave us alone’. Agile takes collaboration among project managers, users, program-mers and testers. There is no privacy in the code.”

Get Your Free Subscription

Fill out and send us this form.

OO-ALC/MASE

7278 Fourth Street

Hill AFB, UT 84056-5205

Fax: (801) 777-8069 DSN: 777-8069

Phone: (801) 775-5555 DSN: 775-5555

Or request online at www.stsc.hill.af.mil

NAME:________________________________________________________________________

RANK/GRADE:_____________________________________________________

POSITION/TITLE:__________________________________________________

ORGANIZATION:_____________________________________________________

ADDRESS:________________________________________________________________

________________________________________________________________

BASE/CITY:____________________________________________________________

STATE:___________________________ZIP:___________________________________

PHONE:(_____)_______________________________________________________

FAX:(_____)_____________________________________________________________

E-MAIL:__________________________________________________________________

CHECK BOX(ES) TO REQUEST BACK ISSUES:

JUL2001 � TESTING & CM

AUG2001 � SW AROUND THE WORLD

SEP2001 � AVIONICS MODERNIZATION

JAN2002 � TOP 5 PROJECTS

MAR2002 � SOFTWARE BY NUMBERS

MAY2002 � FORGING THE FUTURE OF DEF

JUN2002 � SOFTWARE ESTIMATION

JULY2002 � Information Assurance

AUG2001 � SOFTWARE ACQUISITION

SEP2002 � TEAM SOFTWARE PROCESS

To Request Back Issues on Topics Not

Listed Above, Please Contact Karen

Rasmussen at <karen.rasmussen@

hill.af.mil>.

Highpoints From the Agile Software Development Forum


Open Forum

People go years, possibly their entirelives, exhibiting certain behaviors,

sometimes knowingly but often unawareof any notable pattern. Sometimes anevent will occur where a name is given totheir particular behavior. A man who takeshis work problems out on his family maybe in an anger management class and beinformed that he exhibits misplaced aggres-sion. For a woman whose husband is analcoholic, yet buys liquor for him, might belabeled an enabler.

This identification can lead to anepiphany for the subject. This sudden real-ization is exactly what happened to mewhen a colleague of mine inquired as tomy willingness to write this article on agileprogramming.

I had never before heard the term agileprogramming, but my associate was famil-iar with the concept and also with mywork, so I was willing to trust in his judg-ment. During research into the concept ofagile programming, it quickly became evi-dent that this was an acceptable label forthe coding practices I have used routinelyfor more than 13 years.

Unwitting Agile ProgrammerIn my work as an analyst for a programmanagement firm, I use a fourth genera-tion language (4GL), control and analysistool to build reports and graphs. My cus-tomers and I use these documents to per-form analysis on schedule related data. Theinformation derived from this data is usedto point out past mistakes and potentialproblems, thus saving both time andmoney. This is my goal as a program man-agement analyst, and the goal of my firm,to make our customers successful.

Occasionally I am called upon to devel-op related applications or modules using4GL. Some applications are written to ana-lyze existing data and some to capture newdata. The latest major development effortinvolved a resource-forecasting tool usedto project future work requirements, andprovide what-if scenario modeling. Becausethe customer wanted to keep the existinganalysts at the site working on their currentassignments, a separate contract was writ-ten and programmers were hired to per-

form the work. This project followed a tra-ditional software development methodolo-gy because this methodology worked forthis project. The project finished on timeand under budget.

In 1994, the Air Force was awarded theNavy FA-18 programmed depot mainte-nance (PDM) contract. This was historic inthat it was the first time that one branch ofthe armed forces was contracted to repaira weapon system used by a differentbranch. The accepted proposal called forthe work to be performed at Hill Air ForceBase (AFB) in Ogden, Utah.

Since the fall of 1993, I had been work-ing as a program analyst on the Program-med Depot Maintenance Support Systemcontract in the Aircraft Directorate at HillAFB. When the new workload arrived, theprogram management team providedprecedence network schedules and trackedthe work against the plan, as had beendone for the other aircraft work at HillAFB.

Not long thereafter, the AircraftDirectorate was audited by an independentaudit agency. Their findings required HillAFB to provide an auditable unplanned workapproval tracking system. The F-18s werebrought to Hill AFB for a PDM, which isbasically an overhaul of the entire aircraft,according to a specific set of operations tobe performed, called planned operations.There are also provisions for problemsencountered either during aircraft inspec-tion or while the mechanics are perform-ing planned work. These problems aredefined as unplanned work and requireextra time not accounted for in theplanned operation package.

Given that the FA-18 is a Navy weaponsystem and each aircraft has spent a gooddeal of time on aircraft carriers or atcoastal Naval Air Stations, much of theunplanned work is corrosion removal. Thisunplanned work accounted for more thanhalf of the total hours on a FA-18 PDM.The independent audit agency required away to show that hours billed to this con-tract workload were not being used towork on F-16s or C-130s, which werelocated in the same hangars as the FA-18.Without such an auditable system, the

workload would be pulled from Hill AFBand given back to the Navy.

The Aircraft Directorate quickly estab-lished a manual process that may have sat-isfied the requirements set forth by theindependent audit agency. The only worrywas, with hand carrying of thousands ofdocuments to and from the hangars, somewere bound to get lost and therefore thesystem might fail the audit.

An Air Force major working in theAircraft Directorate approached our firmabout automating this process. It was easyto show a good potential return on invest-ment (ROI) based on the amount of man-hours involved in processing work cards inthe manual system. This also fell into thescope of our firm’s program managementcharter. Automating this system wouldprovide the ability to add the hours gener-ated by this unplanned work into theschedule as soon as the requests wereapproved, thereby extending the schedulein a real time fashion. Since all parties werein agreement that this was a win-win situa-tion, the next decision was how would weproceed with development?

To bring in more analysts wouldrequire writing a new contract or makingan amendment to the existing one. Sincethe customer wanted the system in placeby the time the audit agency returned, thisoption would take too long. They decidedinstead to reallocate the existing resourcesof the program management team andplace all three analysts on full-time devel-opment of the new application. Due to thetime constraint, there was no developmentof a formal plan or extensive require-ments, which led to the use of methodsnow described as agile.

A Perfect Agile FitTraditional programming methodologieswere put in place mainly to prevent require-ments creep. In agile programming, potentialfor these problems is diminished by gettingthe application to the users quickly. Surelyif it takes two years to develop an applica-tion, changes will arise in the organizationor process that will drive new requirementsand cause delays. Agile methodologiesexist that are specifically tailored to long-

Agile Before Agile Was CoolGordon Sleve

Robbins Gioia LLC

Success can be achieved by many means. Sometimes it is obvious which road to take, other times it does not really matter.Look at individual circumstances before choosing one path over the other.Success can be achieved by many means. Sometimes it is obvious which road to take, other times it does not really matter.Look at individual circumstances before choosing one path over the other.


Agile Before Agile Was Cool

term projects, but my experience has beenwith short-term projects. The unplannedwork module was not extensive and wewere confident that we could provide aquick turnaround. Even though we did nothave agile methodology guidelines to goby, this project was a perfect candidate forjust such a philosophy. The Agile SoftwareDevelopment Manifesto states:

We are uncovering better ways ofdeveloping software by doing it andhelping others do it. Through this workwe have come to value:• Individuals and interactions

over processes and tools.• Working software over compre-

hensive documentation.• Customer collaboration over

contract negotiation.• Responding to change over fol-

lowing a plan.That is, while there is value in

the items on the right, we value theitems on the left more. [1]

Although we did not know of agilemethodologies, in retrospect we practicallyfollowed them to the letter. We focusedalmost entirely on those items on the left andfor all intents and purposes, ignored theitems on the right. In this case, circumstancerather than conscious thought led us toperform in this manner. We were under thegun to get a working product in place in ashort amount of time. There was little timefor planning, contract negotiation, or doc-umentation.

The lack of planning shows a slightdeparture from agile, but remember, wedid not have the agile methodology withwhich to work. The available resources andtheir expertise locked in our tools. Due tothe fact that very little of the traditionalmethodologies were available to us, wewere forced to draw heavily from what isnow an agile approach. I like to look atthese two approaches as the Scarecrow andthe Tin Man, agile being the Scarecrow(flexible) and traditional being the Tin Man(rigid.) They both want to get Dorothy toOz, but they each have unique abilities andweaknesses. In our case, we had to rely ona Scarecrow named “agile.”

The initial requirements were to auto-mate the manual process and add reports.The bulk of the detailed requirementswere obtained during development byworking closely with civilian counterpartsinvolved in the unplanned work process.These individuals were planners, sched-ulers, and the approval authority, each withknowledge of how their piece of theprocess worked.

We met daily, but on an informal basis,usually with the point of contact (POC)most familiar with the section beingworked in a one-on-one setting. Thiswould almost always take place at thedeveloper’s desk. We showed progressfrom the previous day and verified with thePOC that their requirements were beingmet. Then we would identify any changesthat needed to be made and start workingto that end. As we moved through thedevelopment phase, we would identifythose nice to have features and record thoserequirements for follow-on work. Throughthis process the programmer learned muchmore about his customer’s needs than hecould by reading thousands of pages ofrequirements documents. It also showed acommitment to individuals and interac-tions over processes and tools.

As changes were made to the applica-tion, corroboration was sought from theuser before continuing further. Some-times the user would sit through severaliterations of code changes right at the pro-grammer’s desk, commenting and cri-tiquing. By working closely with the usercommunity, there was very little need fordocumentation and training. By the timedevelopment was completed, the users hadbeen trained through their constantinvolvement. There was no need for a for-mal training class after implementation.Since we knew there would be a good dealof follow-on changes, we decided to waiton documentation.

The main application was completedwith great success in plenty of time for thenext audit. The only cost associated withthe program was the temporary loss ofproductivity toward the original programmanagement objectives. Our team wasawarded a certificate of appreciation fromthe Aircraft Directorate citing a savings of250 direct/indirect man-hours per aircraft.There was a dollar figure placed on boththe cost (approximately $28,800) and thesavings (approximately $1 million) result-ing in an actual ROI of more than 30 to 1.

Given the limited planning work, therewas no way to predict such a fantasticwindfall. However, had more time beenspent in planning, documentation, con-tracting, and processes the ROI ratiowould have been less impressive. Follow-on changes included expansion for both F-16 and C-130 workloads, and a master write-up module that provided the users with apick list of frequently used write-ups.

Specified SuccessfulUse ContinuesAlthough the F-18 contract only lasted one

year before the workload was returned tothe Navy, the use of this application on theF-16 and C-130 programs continues to thisday. This program is still in a textual inter-face format but will soon be converted toan Oracle/Web-based format to providebetter accessibility and ease of use. Theuser community has taken ownership ofthis application and they like it because ofthat very fact; it is their own creation.From time to time, minor bugs appear,which will be the case when omitting con-figuration management and strict codingpractices, but the users are happy with thattrade-off for flexibility.

One might argue that agile softwaredevelopment flies in the face of programmanagement. While the irony of a pro-gram management professional touting“responding to change over following aplan” is not lost on me, I see both method-ologies coexisting and filling an importantpurpose: to make our customers successful.

Yes, I am a proponent of agile pro-gramming but only in those cases where itis the best solution. Unless given a specif-ic set of circumstances, I cannot say whichis best. I have experienced success withboth agile and traditional software devel-opment methodologies, and success is theultimate goal.◆

References1. AgileAlliance. “Agile Software Devel-

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

About the AuthorGordon Sleve is a sen-ior program analyst forRobbins Gioia LLCworking in the ICBMprogram office at HillAir Force Base (AFB)

in Ogden, Utah. He was previously asite manager at Letterkenny ArmyDepot in Chambersberg, Penn. Slevewas selected as Robbins Gioia’s SeniorProgram Analyst of the Year forDayton-based operations in 1995 forhis support of the implementation ofProgrammed Depot MaintenanceSupport System at Hill AFB.

Robbins Gioia LLCOO-ALC/LMSO6014 Dogwood Ave.Bldg. 1258 Rm. 14Hill AFB, UT 84056-5816Phone: (801) 775-5943Fax: (801) 586-4835E-mail: [email protected]

for the industrial automation projectdescribed herein. The languages were most-ly C++ but also included C, HTML, VB, andSQL. Productivity ranged from a low of 21to a high of 48 lines of code per codinghour, averaging 35 lines of code per codinghour.

Compared to projects conducted beforeadopting this intensely practical and agilesoftware development discipline, our costper line of code and defect rates were dras-tically reduced while our development veloc-ity was significantly increased. Our mostrecent audit revealed an overall average pro-ductivity index of 22 [4]. This index is amanagement scale corresponding to theoverall process productivity achieved by anorganization during the main software build.An index of 25 is considered among thehighest ever recorded.◆

References1. Beck, Kent. eXtreme Programming

Explained: Embrace Change. Boston:Addison-Wesley, 1999.

2. Fowler, Martin, et. al. Refactoring:Improving the Design Of Existing

Code. Boston: Addison-Wesley, 1999.3. C3 Team. “Chrysler Goes to Extremes.”

Distributed Computing. Oct. 1998<www.xprogramming.com/publications/distributed-computing .html>.

4. Putnam, Lawrence H., and Ware Myers.Measures of Excellence: Reliable

Software on Time, Within Budget.Upper Saddle River: Prentice Hall/Your-don Press, 1992.

Note1. “We” as mentioned throughout this arti-

cle refers to the Geneer company.


About the AuthorJohn Manzo has spentmore than three decadesof his career in softwareengineering, and hascontributed to and madesignificant accomplish-

ments in the development of software,computer, and telecommunicationssolutions. Manzo comes to AgileTekfrom Geneer where he was chief tech-nology officer, and brings with him alegacy of broad and deep experience inagile development methods. Earlier inhis career, Manzo was recognized forhis development of the Fire Controlsoftware for the Navy's highly success-

ful AEGIS system – one of the largestand most complex software develop-ments ever delivered to the Departmentof Defense. He has served as a repre-sentative to the President's NationalScience Advisory Board, and served asan adjunct faculty member of HarvardUniversity where he developed, and forseveral years taught, “The Managementof Software Engineering.”

AgileTek934 South Golf Cul de SacDes Plaines, IL 60016Phone: (847) 840-3765Fax: (847) 376-8308E-mail: [email protected]

CONTINUED FROM PAGE 21

Agile software development techniques are an effective response to many problems still plaguing development projects. Althoughthere are a number of issues to consider, almost any project can become more agile to its benefit. What exactly does it meanto be more agile? Words like predictable, cost-effective, and mature are more often used to characterize desirable software devel-opment processes. Agile development has come into focus recently due to the popularity of its most widely known interpreta-tion, eXtreme Programming, but some of its foundations go back as far as 20 years. This article addresses some of the ques-tions about agile: What is agile? Who needs to be agile? How can any project not creating small business applications seri-ously consider agile development? Is agile development an “all or nothing” proposition?

Online Articles

Should You Be More Agile?Rich McCabe and Michael Polen

Software Productivity Consortium

Agile Development: Weed or Wildflower?1

David Kane SRA International

Steve Ornburn GBC Group, Inc.

Editor’s Note: Due to space constraints, CrossTalk was not able to publish these articles in their entirety. However, they can beviewed in this month’s issue on our Web site at <www.stsc.hill.af.mil/crosstalk> along with back issues of CrossTalk.

The Software Engineering Institute’s Capability Maturity Model® (CMM®) has been a major force for software process andacquisition improvement in the federal government’s civil and defense communities for the past decade. Major investments havebeen made by the government, their contractors, and many other organizations to make software development more consistentand reliable. The CMM provided an alternative to the cowboy programmer archetype. Amid this backdrop of progress, a newtrend in software development has emerged – agile development, which aims to build software faster and more flexibly than tra-ditional approaches. Agile values “individuals and interactions over processes and tools” [1]. For organizations that haveinvested in a CMM, do agile methods represent the rebirth of the cowboy – a weed to be stamped out? Or, are agile methodsa reasonable way to build software in a world in which needs are changing at an ever-increasing pace – a wildflower to be nur-tured? This article looks at whether there is a home for agile methods in communities that have have embraced the CMM.

BACKTALK


In the February issue of CrossTalk, I sensed an intellectualmelee in the air. Six months later, software publications and con-

ferences were abuzz. In an industry where plans are inadequate andplanning is essential, we are starting to question the strong hold ofpredictive, process oriented, model-based software development.

Grassroots intrigue with lightweight methods like eXtremeProgramming (XP) and Scrum has triggered software developers toquestion their approach, methods, and focus. Although questionscurrently outweigh answers, this debate has broken the assiduousfixation on such heavyweight methods like the Capability MaturityModel® IntegrationSM (CMMISM) and Software ProcessImprovement and Capability dEtermination.

I am, however, concerned for individuals, teams, and organiza-tions that are ensnared and laden by incompatible methods orapproaches. For some these processes and methods have becomeaddicting and will be hard to break.

For those who are troubled, I offer the time-tested 12-Step pro-gram used by millions of people to successfully transform their livesand recover from obsessive-compulsive behaviors. With modifica-tion, I hope these steps successfully amend software developmenthabits and aid in the recovery from career threatening behaviors.

If you are clinging to the sanctuary of models, processes, andtheoretical control, and find these heavy methods too restrictive foryour small-to-medium projects, unstable requirements, competentteam, and short deadlines then repeat after me: “I, (state your name)am a heavyweight zealot. I promise to follow the 12 Steps forHeavyweights.”

12 Steps for Heavyweights1. I admit I was powerless over predictability, and my life had

become unimaginative.2. I believe that a power greater than a process, model, or best

practice could restore my sanity.3. I made a decision to turn my will and my career over to the care

of vigilance, acumen, proficiency, and ingenuity.4. I searched and made a fearless inventory of my respect for col-

leagues and customers.5. I admit to customers, myself, and to colleagues the exact nature

of my wrongs.6. I am entirely ready to have pair programming, coding standards,

and iterative deliveries remove my defects.7. I humbly ask my customer, collaborative colleague, and test pro-

grams to reveal my shortcomings.8. I made a list of customers I harmed, and I am willing to make

amends to them all.9. I will make amends to customers wherever possible, except

when to do so would injure them or others.10. I will continue to take personal inventory, and when I am wrong

will promptly admit it and refactor.11. I will seek through collective ownership to improve my con-

scious contact with customers asking only for knowledge oftheir will for me and the power to carry that out.

12. Having had a creative awakening, I will carry this message toheavyweight zealots and practice these principles in all myaffairs.If your proclivity for collaboration, rapid development, and

empirical control has led you to the fast paced world of XP, Scrum,Crystal, adaptive software development, feature-driven develop-ment, or dynamic systems development method, and you find these

light methods are inadequate for your largeproject, dependable requirements, andmotley team then repeat after me: “I,(state your name) am a lightweight infidel.I promise to follow the 12 Steps forLightweights.”

12 Steps for Lightweights1. I admit I was powerless over change, and

my life had become unmanageable.2. I believe that a power greater than ingenu-

ity could restore me to sanity.3. I made a decision to turn my will and my

career over to the care of prescriptiveprocesses and best practice models.

4. I searched and made a fearless inventory ofmy process areas and maturity.

5. I admit to my manager, SEPG, and qualityassurance department the exact nature ofmy wrongs.

6. I am entirely ready to have quantitativemanagement and optimization remove mydefects.

7. I humbly ask assessments, inspections, andquality assurance to reveal my shortcom-ings.

8. I made a list of all process areas I neglected,and I am willing to make amends to them all.

9. I will make amends to my process areas wherev-er possible, except when to do so would injure the budget, inwhich case I will request a waiver.

10. I will continue to assess my maturity and when I deviate, I willpromptly conform.

11. I will seek through documentation and meetings to improve myconscious contact with “The Model” asking only for knowledgeof its will for me and the power to carry that out.

12. Having had a disciplined awakening, I will carry this message tolightweight infidels and to practice these principles in all myaffairs.Since the majority of the industry has considerable investment

in heavyweight methods and will likely dismiss the agile movementas a return to callow software programming, I offer you the follow-ing athletic afflatus.

In planning for one of the most grueling events, the Tour deFrance, Lance Armstrong starts preparations a year in advance. Hedoes not prepare for a specific race but instead prepares for sever-al race scenarios and his ability to adapt to them. That is importantbecause as soon as the race starts, the event will take its own courseand any planning will be history. He knows the course, conditions,and competitors are unpredictable and his success depends onknowing what is going on and responding quickly.

Software development, although not the Tour de France, is farfrom predictable and would benefit from the insight of one of thegreatest athletes in the world. Although not a panacea, these pellu-cid ideas, if allowed to imbue the mind, will ameliorate your soft-ware organization. Go ahead. Break from the peloton.

–– Gary PetersenShim Enterprise, Inc.

The 12-Step Program for Software Weight Watchers

CrossTalk / MASE7278 4th StreetBldg. 100Hill AFB, UT 84056-5205

PRSRT STDU.S. POSTAGE PAID

Albuquerque, NMPermit 737

Sponsored by theComputer ResourcesSupport Improvement

Program (CRSIP)

Published by theSoftware Technology

Support Center (STSC)

Oct2002cover.qxd 9/4/02 11:09 AM Page 2

Documents

Oct2002cover.qxd 9/4/02 11:10 AM Page 1 - Agile Sweden · approach to agile software development methodologies. While interest in agile methodologies has blossomed in the past two