AgileSoftwareDevelopment2nd ed(additions) page 1

AgileSoftware
Development

SoftwareDevelopmentasaCo
operativeGame

nd
2 edition

AlistairCockburn

1
 AgileSoftwareDevelopment2nd ed(additions) page 2

0'UNKNOWABLEANDINCOMMUNICABLE:EVOLUTION ..............................................................................4
COMMUNICATIONAND SHARED E XPERIENCE 5
SHUHARI 6
1'ACOOPERATIVEGAMEOFINVENTIONANDCOMMUNICATION:EVOLUTION..................................7
THE SWAMP GAME 8
COMPETITIONWITHIN COOPERATION 8
OTHER FIELDSASA COOPERATIVE GAMES 10
SOFTWAREENGINEERINGRECONSTRUCTED 10
2'INDIVIDUALS:EVOLUTION ..............................................................................................................................17
STRATEGYBALANCING 19
3'TEAMS:EVOLUTION ..........................................................................................................................................21
ASAMPLE OFFICELAYOUTREVISITED 23
4'METHODOLOGIES:EVOLUTION.....................................................................................................................24
METHODOLOGIESVERSUS STRATEGIES 26
METHODOLOGIESACROSSTHE ORGANIZATION 26
PROCESSESAS CYCLES 27
DESCRIBING METHODOLOGIES MORE SIMPLY 29
5'AGILEANDSELFADAPTING:EVOLUTION ..................................................................................................31
MISCONSTRUINGTHE MESSAGE 34
EVOLUTIONOFTHE AGILE METHODOLOGIES 45
NEW METHODOLOGY TOPICS 51
PERSISTENTQUESTIONS 61
ANOTHER VIEWOF AGILEANDCMMI,BY PAUL MCMAHON,PRINCIPAL,PEMSYSTEMS 65
INTRODUCINGAGILEFROMTHE TOP 10LESSONS,BY ERIC OLAFSSON,CEO,TOMAX 74
AGILE OUTSIDE SOFTWAREDEVELOPMENT 76
REVISITINGTHE CUSTOMCONTRACT,BY ERIC OLAFSSON,CEO,TOMAX 79
CREATING CHANGEWITH STICKERS,BY KAYJOHANSSEN,TESTMANAGER 81
LEAN MANUFACTURINGATO.C.TANNER,BY MIKE COLLINS,VICE PRESIDENTLEANENTERPRISE DEVELOPMENT,
O.C.TANNER 84
6'THECRYSTALMETHODOLOGIES:EVOLUTION.........................................................................................92
THE CRYSTAL GENETIC CODE 94
CRYSTALCLEAR 97
INTRODUCINGCRYSTAL CLEAR,BY JONATHANHOUSE,MANAGEROF SOFTWAREDEVELOPMENT,AMIRSYS 98
STRETCHING CRYSTAL CLEARTO YELLOW 100
TAILORING CRYSTALYELLOW,BY GRY DERBIER, PROJECTMANAGER,SOLYSTIC 102
APPENDIXA'THEAGILESOFTWAREDEVELOPMENTMANIFESTOANDTHEDECLARATIONOF
INTERDEPENDENCE.................................................................................................................................................105
THE AGILEMANIFESTOREVISITED 107
THE DECLARATIONOF INTERDEPENDENCE 108
APPENDIXB'NAUR,EHN,MUSASHI:EVOLUTION........................................................................................113
NAUR 115
EHN 115
MUSASHI 115
7(newchapter)AFTERWORD .................................................................................................................................116
BUSINESSASA COOPERATIVE GAME 118
LEADERSHIPANDPROJECTMANAGEMENT 119
AGILE SOFTWARE DEVELOPMENT 118

2
AgileSoftwareDevelopment2nd ed(additions) page 3
EVERYONE 120
REFERENCES .........................................................................................................................................................121

REFERENCES .........................................................................................................................................................121

3
AgileSoftwareDevelopment2nd ed(additions) page 4

0'
Unknowableand
Incommunicable:Evolution
TheIntroductionsetouttwoideas:
Communicatingistouchingintosharedexperience.
People listen and act at three skill levels: Shu, Ha, and Ri (following,
leaving,andfluent).
Thoseideascouldstandafewmoreparagraphseach.

4
 AgileSoftwareDevelopment2nd ed(additions)
CommunicationandSharedExperience
Atthetimeofwritingthefirstedition,Ididn'tfullyappre
ciatetheharmonybetweentheideaof"communicationas
touching into shared experience" and the articles in Ap
pendixBbyPelleEhnandPeterNaur.
(New readers may want to skip this section until they
finish reading Appendix B. I am writing this section as
thoughyouhavedonesoandcomebacktothispoint.)
Withinthelastfiveyears,peoplefirstappliedthe idea
of"communicationastouchingintosharedexperience"to
project documentation. Teams are being more creative in
usingalternateforms of documentationto serve as mark
ers and reminders for other team members1. They are
separating what is needed as "reminders for the people
who had been in the room at the time" from what is
neededas"catchupinformationforpeople who were not
intheroomatthetime."
Thisis,ofcourse,verymuchinlinewithPeterNaur's
article"ProgrammingasTheoryBuilding"inAppendixB.
Naur describes designing a program as creating a theory
oftheworld(wemightsay modelinsteadoftheory,today)
and another theory of how the program operates in that
world.
Toremindsomeoneabout aconversationthey partici
pated,wepoint intotheirtheory(ormodel),andpoint as
directly as possible into their shared experience. For this
purpose,it is desirableto keeptheoriginal, messy, hand
writtenflipcharts.Rewritingthemintocleancomputertext
losestheexactreferencingmechanismwewanttoutilize.
Italsoworkout,handilyenough,thatkeepingtheoriginal
flipchartsisfastandcheap,whereasrewritingthemonline
is relatively time consuming and expensive. So using the
original flipcharts as reminders is both cheap and effec
tive.
However, it is quite different when the purpose is to
bringsomeoneelseuptotheteam'scurrentstateofunder
standing (their theory, in Naur's terms). The same messy
flipchart that is so effective as a reminder is unlikely to
containthecuesnecessaryforthenewperson2.Mostofthe
time, the team will choose to use a completely different
approach to documenting their current state of under
standingtohelpthenewpersoncatchupwiththem.How
1
See, in particular, the many examples of project documentation in Crystal
Clear (CockburnCC2005).
2
Unless,ofcourse,theflipchartisrecreatedredrawn,inthesamesequence
for the new person as it was for the original audience. Then the new person
buildsaninternalmemoryofthesessionrathersimilartothosewhowereinthe
room forthe original meeting. I have used this technique on occasion to good
effect.
page 5
evertheyapproachit,agreatdealofinformationisinevi
tablylost,justasNaurdescribesinhisarticle.
In the second article in the appendix, Pelle Ehn de
scribed the difficulty he and his programmers had com
municating with their computernave users in the 1970s.
Surprising most people (including me), he wrote that
completecommunicationisnotnecessary:
"...paradoxicalasitsounds,usersand designers do
nothavetounderstandeachotherfullyinplayinglan
guagegames of designbydoing together. Participa
tioninalanguagegame of designand the use of de
sign artifacts can make constructive but different
sensetousersanddesigners."(seepagexxx???).
Hisinsightisrelevantagaintoday,whenethnographers
and user experience designers still try to understand the
work habits of users, and from that understanding con
struct a good user interface. At a time when we work so
hardtounderstandourusers,itisgoodtoberemindedthat
completecommunicationisnotpossible...butit is also
not required. What is required is to play the language
game, acting, and reviewing the feedback, over and over
inneverendingcyclesofimprovingutility.
Youcanapplythelessonsof"touchingintosharedex
perience"inyourownenvironment:
Watch as people point to an old artifact to remind
themselvesofsomethingthathappened.
Watchastheyconstructsomethingtocreatea"ladder
ofsharedexperience"foranewperson.
Watch how communication gets missed, understand
ing is incomplete, but action gets taken anyway. No
tice how many times the people repeat the cycle of
explainactdiscuss before they get to an acceptable
levelofnonunderstanding.
Noticehowpeoplehavedifferenttolerancesforlevels
of nonunderstanding and for the number of times
theyhavetorepeat thecycle.Use what younoticeto
dotwothings:Raiseyourowntoleranceforrepeating
thecycleand(surprise!)raiseyourtoleranceforpeo
plewhohavelowtolerances.
5
 Sw DevasaCooperativeGame
TheShuHaRidistinctiondatesback,asIlearned,not to
theoriginsofAikidotheearly1900s,buttoJapaneseNoh
theater,almostfourcenturiesago.
Understanding the three levels of listening has turned
outtobeofgreatervaluethanIexpected.Itwasoriginally
placed as a small section in an appendix, but so many
people wrote to me during the early drafts of the book,
describinghowtheywereusingtheShuHaRidistinction
to smooth meetings, that I moved it forward into the In
troduction.
You can apply ShuHaRi to designing courses and
writing technique materials. Recognize that some people
cometothe courseintheShustate,looking for thetech
nique that solves their problems. Other people come al
readyknowingmanytechniques,afraidthatyouwilltryto
convince them that your technique is the technique that
solvestheirproblems.
Organizeyourmaterialtoreassuretheadvancedpeople
inyourcoursethat it is not beingpresentedasa cureall,
butsimplyanothertechniqueinthetoolboxoftheprofes
sional. Then teach the technique at theShu level, so that
the beginners will have a starter technique to take home
withthem.Butbeforeyoufinish,putthetechniqueintoa
largercontext,sothebeginnerscanstarttoseewherethey
willexpandto,andtheadvancedpeoplecanseehowthis
onetechniquebridges to others they might knoworwant
tolearn.
I got caught in a ShuHaRi mismatch, shortly after
publishing the first edition, and was saved by someone
whoknewthetrio.
page 6
ShuHaRi
In2002,JimHighsmithandIwereorganizingthefirst
Agile Development Conference (alert readers will notice
herethatconferenceorganizationisacooperativegameof
invention and communication, but one in which the in
cremental / iterative and collocation development strate
giesaredifficulttouse,ifnotimpossible).Itwasmyfirst
ever conferenceorganizing experience, and I was very
muchintheShustage,butwithoutanyonetofollow.Ac
cordingly, I was incredibly detailed in listing everything
that needed to be taken care of for the conference. I had
sheetsandsheetsofpapercontainingallmannerofminu
tiae.
We signed an experienced conference organizer, who
was baffled by my excruciatingly long lists. A colleague
watchingourtenseconversationspointedoutthatmylong
lists were immaterial to her, as she operated in Ri mode
andcouldmakethenecessaryplansinherheadratherthan
onslipsofpaper.
Thatobservation gave methe peace of mind I needed
torelaxandlethertakeover.Istillkeptlistsofdetailsto
watchfor,butonlythe ones Iwas specifically concerned
about.
You can apply the lessons of ShuHaRi in your own
environment:
Lookforlevelmismatchesatwork.IntroducetheShu
HaRiconceptandseeifthatmighthelptosmooththe
discussion.
Update your training materials to highlight what sec
tionsareforShulevellearning,andwheretheHaand
Rilevelsfit.
6
Sw DevasaCooperativeGame page 7

1'
ACooperativeGameof
InventionandCommunication:
Evolution
Ioncethoughtthatsoftwaredevelopmentwasuniqueinitsbeingacooperativegameof
invention and communication. As I gave talks on the subject, however, business execu
tivesstartedtelling methattheirownprofessionallivesfitthatdescription.Business,it
turnsout,isverymuchacooperative(andcompetitive!)gameofinventionandcommuni
cation.Soarelaw,journalism,conferenceorganization,entertainment,andrunninggov
ernments.Moresurprisingto me, personally, was discovering that engineering is also
largelyacooperativegameofinventionandcommunication.
Researchingthetopicofengineering,Ifoundthat,possiblyduetothesuccessofap
pliedphysicsinWorldWar II,itlostits original association with craft and experiment
onlyquiterecently.Reconsideringengineeringinitsmorehistoricalinterpretation,asa
combination of applied science, craft, experiment, and case lore, gives it a new and
richermeaning.Thisviewofengineeringshowsthewayforus toreconstruct"software
engineering"inawaythatisbothprovidesagoodeducationalbase,andalsoispracti
calonliveprojects.

7
 Sw DevasaCooperativeGame
TheSwampGame
Rockclimbinghasonelimitationasacomparisonpartner
to software development: When people finish a rock
climb, they walk back down to their cars and drive off.
Whentheyfinishasoftwareproject,theystayaroundand
enhancethesystemorbuildtheneighboringsystem.They
have to live with the results of what they did, and they
havetointegrateotherpeopleintotheworldtheycreated.
Thereis anactivitythat is closertosoftware develop
ment than rock climbing. It is an imaginary activity, for
now,butwhoknows,peoplemayreallystart playingthis
game, or simulating it on a SimCity type of computer
gametotrainprojectleaders.
Imagineacompetitionin which each team must build
something somewhere in a swamp. They don't know ex
actlywhattheyhavetobuild,theydon'tknowwherethey
havetobuildit,theydon'thaveamapoftheswamp,but
they are in a race to build it. They will create subteams.
Somewillscavengeforbuildingmaterials,otherswillex
ploretheswamp,andsoon.Notethatthiscorrespondsto
people finding different specialties in software develop
ment.
Iftheyhavetoplay only oneround ofthe game, they
willfinditoptimaltobuildtheweakest,sloppiestbridges
and the most careless maps possible to get to the end of
the game. However, if they know there will be another
teamcominginafterthem,theymaychoosetomakebet
ter maps, better bridges, better paths. This difference be
tweenstrategiesis whatcorrespondstoasoftwareproject
team updating their system documentation and training
theirjuniorpeople.
Itisthisdifferenceinstrategiesthatmakestheswamp
game a better comparison partner than rock climbing.
Every software project contains a carryover to the next
project, and so the strategies to use in software develop
ment shouldpayattentiontoboththis game andthe next
game.
CompetitionwithinCooperation
IamsuchabigfanofcooperationandcollaborationthatI
sometimes forget that there are other things even more
powerfulcompetition,tonameone.Thequestionishow
to harness it so that the competition does not destroy the
collaboration.
page 8
Observethatpeoplearepartofthecarryoverfromone
roundofthegametothenext.Inanidealworld,theteam
wouldarrangethatnoneoftheoriginalteamwouldleave.
Thesepeoplecarryalotoftacitknowledgeintheirheads,
informationthatcan'tbeputintothepaperdocumentation
(this is the exact point made by Peter Naur in Appendix
B).However,inarealworldsetting,peopleflowintoand
outoftheteam.Theteam'sstrategyneedstoincludeways
totransferasmuchknowledgeas possibletothe arriving
people.
Theswampgameletsusexploreinourheadsdifferent
strategies the teams might use, and map those strategies
maptosoftwaredevelopment.
Wecanimaginekeepingtheoriginalteamintactforas
longaspossible.
We can imagine junior players on one round becom
ingteamleadsonthenextround.
We can imagine using an apprenticeship model to
trainnewpeoplejoiningtheteam.
We can imagine making the paths and bridges weak
onthefirstround,buttakingthetimetoimprovethem
on subsequent rounds (think here of refactoring code
insubsequentreleases).
The good news is that delivering the result in the current
roundisafinitetask.Thebadnewsis that settingupad
vantageouslyforthefollowingroundis essentially an in
finitetask:thereisneverenoughtime,money,staff,men
talandcommunicationcapacitytodoitperfectly.
This informs us as to why the documentation and
training never seems to be satisfactory at the end of a
project.Project managersalwaysfeelliketheyareunder
resourced, and they are. They are trying to balance finite
resources across a finite task plus an infinite task. They
willalwayscomeupshort.
Thetrickis not toaimfor perfection, but to construct
strategiesthatserveausefulpurposeingettingtothenext
moveorroundofthegame.
DarinCummins3 foundaway,as faras Icantell,and
althoughheonlyused it twice,it pointstoaset ofpossi
bilitiesotherteamsmightliketoexperimentwith.Heused
thefollowing"game"twice,whichisagoodsign,andde
cidedthatparticularthemehadrunitscourse.
3
OfADPLightspeed,Inc.See"TheDevelopmentGame"(Cummins2003).
8
 Sw DevasaCooperativeGame
Darincautionsthatthecompetitionshouldnotbeabout
thecodebeing written,becausethenthecollusion,cheat
ing,anddestructivesideofcompetitioncanruinthecode
baseortheteam.Instead,heandthe othermanagers cre
atedacompetitiveframeworkthatreinforceddevelopment
practices that they hadselected.Interestingly, as the peo
pleontheteamcolludedtooptimizetheirpositionsinthe
game,theyactuallycarried out thepractices and collabo
ratedmorethantheyotherwisewouldhave.So"cheating"
strengthenedboththeteamandthepractices.
Darin had read a Harvard Business Review article,
EverythingIKnowAboutBusinessILearnedfromMo
nopoly(Orbanes2002).Orbaneslistssixprinciples that
make a great game and describes how those they can be
appliedtobusiness.
1) Maketherulessimpleandunambiguous.
2) Dontfrustratethecasualplayer.
3) Establisharhythm.
4) FocusonwhatshappeningOFFtheboard.
5) Givethemchancestocomefrombehind.
6) Provideoutletsforlatenttalents.
Darin applied those principles to improving their
team'ssoftwaredevelopmentpractices.
He got his company executives to put real money
intothepot.
Theyboughtgadgetsthatmightinterestthepeople
ontheteam.
Theymadefakemoney(withtheVP'sfaceonit!)
torewardpeopleforspecificactions.SeeFigure8
1forapartiallistoftherewards.
AsDarinwrites:
"The developers get paid for having their code re
viewed, reviewing someone elses code, completing
tasks on schedule, reusing code, creating unit tests,
etc.Wealsominimizedtheprocessasmuchaspossi
blebygettingridofthehugechecklistthatwasquite
difficulttogettheteamtouseandreplacingitwitha
simple,8itemchecklistthatisturnedinattheendof
each cycle. This checklist and a simple code review
worksheetareusedtohelpdeterminehowmucheach
playergetspaid....
The management team also has the ability to reward
itemsnotincludedonthelist.Forexample,whenwe
startedhavingpeoplecomeinlatetoourdailystandup
meeting, one of the managers chose to pay everyone
$5forbeing on time. The message was received and
the problem became minimal. Players also have the
abilitytopayeachotheriftheychoose....
One important principle that the game article dis
cussedis giving the playersthe chancetocome from
behind in the endgame. This prevents a player from
fallingbehindtothepoint where playingthegame is
page 9
hopelessandtheyloseinterest.Asweapproachedthe
endofthegame,wedevisedsomeextraactivitiesthat
couldearnadevelopermoremoney."
What I found interesting was that the (inevitable) collu
sionimprovedtheoutcomefortheteamasawhole.Peo
plefiguredoutthattheywouldgetpointsfasterbytrading
codetoreview,andmorecodegotreviewed!
At the end of the threemonth game period, they held
an auction in which the fake money was used to bid for
the real items purchased. To make it more fun, they
broughtinafasttalkingsalesmanasauctioneer.
"The results from implementing the game have been
far better than expected. The one result that we had
hopedforincreatingthegamewastoincreasemorale.
Whileitwasntintolerable,thereweresomebadatti
tudes and bickering beginning to surface. Left un
checked, I feared that these attitudes would escalate
untiltheprojectand/ortheteam suffered. The game
helpedattitudesrisebackto wherethey neededto be
forustobeabletocompletethe projectby givingan
outletandprovidingfocus.
The first unexpected thing we noticed was that the
process now had a purpose. Everyone who has ever
writtencodeknowsthatsoftwaredevelopersjustwant
tobeleftalonetocode.Logically,theyknowthatthe
process is necessary, but emotionally the attitude is
simply If you want it done, go away and leave me
alone. The game had the effect of not only giving
themanemotionalreasontoaccepttheprocess,butto
giveitsomeexcitementtoo."
The game worked for them, and they ran it a second
timebeforedecidingitwouldgetoldaftertoomanyuses.
Afterreadingthearticle,I'mkeepingmyeyesopenfor
other ways to use competition to improve (not damage)
teamqualityandteamoutput.
Description Reward
CreatingUnitTests/TestPlans $20
Reviewcodeforsomeoneelse $30
Receive an Excellent average rating $50
incodereview
Receive a Acceptable average rating $20
incodereview
Receive a Unacceptable average rat $20
ingincodereview
Donthavecodereviewed $50
Implementing suggestions from Code $30
Review
Warningsinbuild $20
Errorscausingbuildfailure $50
Errorsintestafterbuild $30
9
 Sw DevasaCooperativeGame
Figure81.Someoftherewards fortheDevelopment
OtherFieldsasaCooperativeGames
When I wrote the first edition of this book, I promise I
wasthinkingonlyaboutsoftwaredevelopment.However,
as I gave talks on the subject afterwards, I kept hearing
business executives, actors, lawyers, journalists, and oth
ershearingtheirprofessionsinthetalk.Itseemsthatquite
a lot of fields involve people inventing and cooperating,
andtheoutcomesintheirfieldsarehighlysensitivetothe
quality of their invention, communication and collabora
tion.
Most recently I was introduce to a company in Salt
LakeCity,O.C.Tanner,usingtheleanmanufacturingap
proach in their manufacturing line for corporate rewards
(plaques, pins, medals and the like). I had thought that
SoftwareEngineeringReconstructed
Ihavetwicereportedonthemismatchbetweenouruseof
the term software engineering and the practice of engi
neering4. As part of, and following those reports, I have
beenresearchingthe question of what "engineering" con
sists ofinpractice,where wewent wrong with our inter
pretationofthephrasesoftwareengineering,andhowwe
canputsoftwareengineeringbackonsolidfootings.This
sectioncontainswhatIhavesofar.
Wherethetermcamefrom
The term "software engineering" was coined in 1968, in
theNATOConferenceonSoftwareEngineering.Itisfas
cinating to read the verbatim reports of that conference,
andcomparewhatthoseattendees weresayingwithwhat
wehavecreatedsincethen.
Thefirstthingtonoteisthattheconferenceorganizers
did not deduce that software development was like engi
neering.Rather,theyweredeliberatelybeingprovocative
in coining the term "software engineering." We read, in
the introductory note, "BACKGROUND OF CONFER
ENCE"(p.8):
IntheAutumnof1967the ScienceCommitteeestab
lished a Study Group on Computer Science. The
StudyGroupwasgiventhetaskofassessingtheentire
field ofcomputerscience,andin particular, elaborat
ingthesuggestionsoftheScienceCommittee.
The Study Group concentrated on possible actions
whichwould merit an international, rather than a na
tionaleffort.Inparticularitfocusseditsattentions on
4
The firstedition ofthis bookand "The End of Software Engineering and the
StartofCooperativeGaming"(Cockburn2003).
page 10
Game(Cummins2003).
surely linebased manufacturing was quite far from the
agileandcooperativegameideas,butitturnsoutthateven
(wellrun)manufacturinglines aresensitivetothe quality
ofongoinginvention,communicationandcollaborationof
theirworkers.
In the upcoming chapter on agile techniques (Chapter
5), I will revisit the story of O.C. Tanner and Tomax,
amongothercompaniesplayingthecooperative gamede
liberately. Those of us using this vocabulary share the
feelingisthatdespiteallthebookswritteninthebusiness
world,thereisstillmuchtobelearnedfromthecoopera
tivegameapproach.
the problems of software. In late 1967 the Study
Grouprecommendedtheholdingofaworkingconfer
ence on Software Engineering. The phrase software
engineering was deliberately chosen as being pro
vocative,inimplyingthe needforsoftware manufac
turetobebasedonthetypesoftheoreticalfoundations
andpracticaldisciplines,thataretraditionalinthees
tablishedbranchesofengineering.
Wherewewentwrong
Thesecondinterestingthingtonote in those proceedings
is the mismatch between what they claimed engineering
consists of, and how they described their own methods
and recommendations for developing software. We read
from their motivational comments, such as this one (p.
12):
We build systems like the Wright brothers built air
planes build the whole thing, push it off the cliff,
letitcrash,andstartoveragain.
Actually,theWright brothers practiced engineering in its
best possible sense: They used theory, experiment,
guessesandfeedback.TheWrightsaccount(Wright1953,
pp.1518)readsasfollows:
Inordertosatisfyourmindsastowhetherthefailure
of the 1900 machine to lift according to our calcula
tionswasduetotheshapeofthewingsortoanerror
intheLilienthaltables,weundertookanumberofex
periments to determine the comparative lifting quali
ties of planes as compared with curved surfaces and
the relative value of curved surfaces having different
depths of curvature. . . . In September we set up a
small wind tunnel in which we made a number of
measurements...butstilltheywerenotentirelysatis
10
 Sw DevasaCooperativeGame
factory.Weimmediatelysetaboutdesigningandcon
structing another apparatus from which we hoped to
secure much more accurate measurements. . . . we
made thousands of measurements of the lift, and the
ratioofthelifttothedriftwiththesetwoinstruments.
But engineering is more than just calculating tables. It
consists of interacting with a material (air, in the Wright
brothers' case). The activity, "doing engineering" is
learning the qualities of the material and devising (in
venting) ways to accomplish what one wants with the
material.Therearealmostalwaysconflicts,sothat aper
fectsolutionisnotavailable.Findingasolutionthatworks
adequately in the particular situation requires reframing
the problem over and over as more is learned about the
material,theproblem,andthesetofpossiblesolutions.
DonaldSchnand Chris Argyris, professors at M.I.T.
refer to this constant reframing as having a "reflective
conversationwiththesituation."InTheReflectivePracti
tioner(Schn1983),theycatalog,amongothers,chemical
engineers tackling a new problem. These chemical engi
neeringgraduatestudentsaskedtocreateamanufacturing
processtoreplicateaparticularpatinaonchinathat came
from the use of cow bone, which was soon going to be
come unavailable. The students progressed through three
stagesintheirwork:
They tried using chemical theory to work out the re
actions that were happening with the bone, so they
could replicate those. They got completely bogged
downusingthisapproach.
Abandoning theory as too difficult, they next experi
ment with processes in whatever form they could
thinkup.Thisalsogotthemnowhere.
Finally, their professor coached them not to replicate
theboneprocess,buttodeviseaprocessthatresulted
inasimilareffect.Theycombinedbitsoftheorywith
experimentstomakeincrementalprogress,gettingone
category of improvement at a time and reducing the
searchspaceforfuturework.
Theirthird stage shows their reflective conversation with
thesituation.Astheylearnedmoreabouttheproblemand
thesolution,theywereabletomakebettermovesintheir
game.
Schn and Argyris's account meshes perfectly with
Pelle Ehn's description of software design as a language
game(seepage[Ehn,p.230]ofthisbook):
"In the conversation with the materials of the situa
tion, the designer can never make a move that has
only intended implications. The design material is
continually talking back to him. This causes him to
apprehend unanticipated problems and potentials,
whichbecomethebasisforfurthermoves."
page 11
Engineering, then proceeds as a cooperative game of in
vention and communication, in which the moves come
from theory or inspiration, and are checked with experi
mentsthatrevealmoreaboutthesituation.
How, then, did engineering get so misunderstood?
SchnandArgyrisrelate:
Harvey Brooks, the dean of the Harvard engineering
programwasamongthefirsttopointouttheweakness
ofanimageofengineeringbasedexclusivelyonengi
neeringscience.Inhis1967article,"DilemmasofEn
gineeringEducation,"hedescribedthepredicamentof
the practicing engineerwhois expected to bridge the
gap between a rapidly changing body of knowledge
andtherapidly changingexpectations ofsociety. The
resultingdemandforadaptability,Brooksthought,re
quired an art of engineering. The scientizing of the
engineeringschoolshadbeenintendedto moveengi
neeringfromarttoscience.
Aided by the enormous public support for science in
the period 19531967, the engineering schools had
placedtheirbetsonanengineeringscienceorientedto
"thepossibilityofthenew"ratherthantothe"design
capability"ofmakingsomethinguseful...Practicing
engineers are no longer powerful role models when
theprofessorsofhigheststatusareengineeringscien
tists....by1967engineeringdesignhadvirtuallydis
appearedfromthecurriculum,andthequestionofthe
relationship between science and art was no longer
alive....(Schn1983,pp.171172)
People exaggerate the reliability of mathematical predic
tioninexpectingengineeringprojectstocompleteoncost,
time and quality. Civil engineers fail in the same way as
the average software developer when put in a similar
situation. As just one example, the project to build a
highwayunderthecityofBostonwasestimatedin1983to
cost $2.2 Billion and be completed in 1995. It was still
incomplete in2003,withacostestimate of $14.6 Billion
(Cerasoli2001,ChaseURL).The600%costoverrunwas
attributedtotheprojectbeinglargerthanpreviousprojects
ofthissort,anditsusingnewanduntriedtechnologies.
Afterstudyingthisandothercivilengineeringprojects,
Martin Fowler quipped in a public talk, "Compared to
civil engineers, software developers are rank amateurs at
costoverruns".
Popular expectations about engineering are faulty be
causepopularunderstanding of engineeringasanactivity
is faulty. Once we understand engineering as an eco
nomiccooperative game, the difficulty in accurately pre
dicting the trajectory of an engineering project is one of
thethingsthatbecomesunderstandable.
11
 Sw DevasaCooperativeGame
ReconstructingSoftwareEngineering
Ifwereconsiderengineeringasacooperativegameofin
ventionandcommunicationandasreflectiveconversation
with a situation, can we create a better understanding of
thetermsoftwareengineering?Ibelievewecan,andthat
wecanfitsoftwaredevelopmentintheproperengineering
traditionbybuildingbothonthefoundations ofcraft,the
cooperative game of invention and communication, and
thelessonswehavelearnedfromleanmanufacturing.
Thecraft modelcaptures individualbehavior.The co
operative game model captures team behavior. Lean
manufacturingtheorycapturestheeconomicsofstructures
andstrategies.
The keyintransferringlessons from manufacturing to
engineeringistorecognizethatthe"unvalidateddecision"
is the unit of inventory in engineering (or cooperative
gamesofinventionandcommunication,ingeneral).
Herearethecomponentsoftherestructuring.
Craft
In The Reflective Practioner, Argyris and Schn follow
the working habits of architects and engineers. In their
case , we see people making predictions as to what their
situationwillsupport,thentheydosomoftheirworkand
watchwhatthesituationactuallyproduces,andfromthat,
they alter their understanding. They update their under
standing of the problem and the proposed solution, both,
accordingtothechangedsituationandtheirnewlearning.
This "reflective conversation with the situation," is just
whattheWrightbrothersdidindesigningtheirairfoil.
Craftimplies skillinworkinginamedium, mental or
physical.Therearemanymaterialsinanengineeringproj
ect,andthereforemanyskillsorcraftstobecomeadeptat.
Some people need skills around managing people others
needmathematicalskillsothersneedvisualdesignskills,
andsoon.
Each skill and material brings its own specialized vo
cabulary: Ceramicists "wedge" clay and study the shrink
rateofdifferentglazescomparedtoclays.Civilengineers
work with the tensile strength, fatigue rates and thermal
expansion of their materials. Writers look for flow and
developmentintheirtexts.Programmerslookat cohesion
and coupling, testability, clarity of expression, and com
putational complexity in their algorithms. Testers work
with test coverage and probabilities of occurrences. User
interface (UI) designers work with cognitivemotor task
switching times, recognition times, color scales, and user
workpatterns.Projectmanagersworkwithpeople,andare
concerned with what builds or tears down trust, commu
nityandinitiative.
In each case, craft practice requires practitioners to
haveareflectiveconversationwiththematerial,usingthe
page 12
specialized vocabulary. They work with the constraints
offeredbythematerials,thevocabulary,andtheproject.
On a software project, the UI designer is constrained
by the twodimensional screen, the operating system's
rules,andtheUIcomponentsetthathasbeenselectedfor
useontheproject.TheUIdesignerwilllearnwhatispos
sibleandnotpossibleintheframework(andpossiblyalso
whatisnotsupposedtobepossible,butcanbedoneany
way).As workprogresses,using the evolved understand
ingofwhatcanandcannotbedone,theUIdesigner may
counterpropose a different workflow to the users from
whattheyoriginallyrequested.
The materials for a system architect are architectural
standards,applicationprograminterfaces (APIs), andsig
nal propagation technologies. The architect balances per
formance degradation with ease of change as they add
APIs and separate the system across different boxes or
locations.Thisworkis partlyamathematicalactivityand
partlyheuristic.
The materials for a programmer are the programming
language, the operating system, and the components or
APIs the programmer is obliged to use. Some program
minglanguagesareverymalleable,LISP,APL,Smalltalk,
Python, Ruby, being examples. Other languages are less
malleable, Ada, C++, and the other strongly typed lan
guagesbeingexamples.Programmerssometimescompare
workingintheformerlanguagestoworkingwithclay,and
working in the latter languages to working with marble.
Wonderful sculptures can be made from either clay or
marble,buttheskillsandtheapproachdiffersignificantly.
So,too,forthedifferentprogramminglanguages.
Insoftwareengineering,thecraftsincludeatleast
projectmanagement,
"requirements" elicitation (in quotes because the de
velopment team can usually counterpropose alterna
tives,whichmeanttheyweren'treallyrequirementsin
thefirstplace),
userinterfacedesign,
systemarchitecture,
programdesignandprogramming,
databasedesign,
algorithmdesign,
testing,and
communicatingwhattheyarethinking.
Developing professionals in our field means recognizing
themultiplecraftsneededtocarryout aproject.It means
training newcomers in the basics of those crafts. It re
quires professionals in the field to continue developing
craft skills development as a natural part of being in a
craftprofession.Itmeanshonoringthedifferent craftsre
quiredtocompleteaproject.
12
 Sw DevasaCooperativeGame
The crafts define the specific moves that the people
makeinthecooperativegame.
CooperativeGames
Engineering is seldom done alone. Engineers exchange
their thoughts and proposals as they proceed along their
intertwined paths. They communicate with sponsors and
theusers:Thesponsorsmustfindwaystofundthe work.
Theusers mustrespondtotheunexpectedways in which
thesystemwillchangetheirlives.
Below is a description of engineering work at Lock
heed'sSkunkworksfacility.Inthisextract,itiseasytosee
the principles of the cooperative game in action and the
crosscouplingofthecrafts.This is anoutstandingexam
ple of a group holding a reflective conversation with the
situationasateam:
SKUNK W ORKSROOMS
"Kelly kept those of us working on his airplane
jammed together in one corner of our [building]...
My threeman thermodynamics and propulsion
groupnowsharedspace withtheperformance and
stabilitycontrol people. Through a connecting door
wastheeightmanstructuresgroup....HenryandI
could have reached through the doorway and
shakenhands.
"... I was separated by a connecting doorway from
the office of four structures guys, who configured
thestrength,loads,andweightoftheairplanefrom
preliminary design sketches. ... [t]he aerodynamics
group in my office began talking through the open
door to the structures bunch about calculations on
thecenterofpressuresonthefuselage,whensud
denly I gotthe idea of unhinging the door between
us, laying the door between a couple of desks,
tackingontoitalongsheetofpaper,andhavingall
ofusjoinindesigningtheoptimumfinaldesign....It
tookusadayandahalf...."
"All that mattered to him was our proximity to the
productionfloor:A stone's throw was too far away
hewantedusonlystepsawayfromtheshopwork
ers, to make quick structural or parts changes or
answeranyoftheirquestions.(Rich1994)
LeanManufacturing
Lean manufacturing may seem a peculiar foundation for
software engineering. Surely, if there is one difference
between manufacturing and engineering, it is surely that
manufacturingisaboutmakingthesameitemmanytimes,
and engineering is about approaching situations that are
uniqueeachtime5.
5
However, see MikeCollins' descriptionoflean manufacturing ina mass cus
tomizationenvironment,onpage???.
page 13
Replace manufacturing's flow of materials with engi
neering's flow of decisions, however, and the rules gov
erningthetwoareremarkablysimilar
Oneremainingdifferenceisthattheflowofdecisions
inanengineeringprojecthasloops(requestsforvalidation
and correction), which designers of manufacturing lines
try hard to avoid. These loops complicate the optimal
strategies fortheteam but do not change the rules of the
situation.
Figures 82 and 83 show the flow of decisions in a
softwaredevelopment project. In Figure 82, I erased the
variousfeedbackloopsinordertohighlightthebasicidea
ofdecisionflowFigure83includesthemshowtheactual
situation.Theloopsarecriticalwithoutthem,theteamis
missing badly needed feedback about their work. So
whatever you do, please don't copy Figure 82 as a ren
deringofhowgoodsoftwareengineeringis done! Ifany
thing,showit as arendering of howpoor software engi
neeringisdone.
AlthoughFigure82iswronginasguidetohowtoset
up your development shop, it is still useful as a starting
point for this discussion, because it is simple enough to
inspectataglance.Letuslookatit:
The users and sponsors make decisions about what
theywant.Theyfeed those decisions to UI designers
andbusinessanalysts(BAs).
The UI designers and BAs, collaboratively with the
users,orontheirown, make detaileddecisions about
theappearances,behaviorsanddatatobeputintothe
system. They feed those decisions to the program
mers.
The programmers make a decisions about the pro
gram. Those decisions probably change some of the
users' requests and the decisions made by the UI de
signers and BAs, but let's skip that topic for the mo
ment.Howevertheymaketheirdecisions,those deci
sionsgotothetesters.
Thetestersmakedecisionsaboutwheretheforegoing
people have made mistakes. (The dashed arrow in
Figure 82 represents another oversimplification pic
ture,thatIdonotsaywhencethetestersgettheiridea
ofwhatis"correct".Forthisfigure,itjustcomesfrom
somewhere ahead of them in the chain of decision
making.)
The testers can't tell whether the program is correct until
theyget runningcode the programmers can't know what
tocodeuntiltheUIdesignersandBAsmaketheirdetailed
choicesandthe UI designers and BAs can't decide what
to request until the sponsors and users make up their
minds.
As with manufacturing, there is "inventory," there are
"workinprogress" queues between work stations, and
13
 Sw DevasaCooperativeGame page 14
there is the problem of selecting batch sizes for those
handoffs.
The engineering team's inventory is made up of un
validated decisions. The more decisions saved up and
passedfrom onepersontoanotherat onetime,thelarger
thebatchsizeinvolvedinthathandoff.
Texts on lean manufacturing (for example, Reinertsen
1997)stressthatincreasingthebatchsizegeneratesalmost
uniformly negative consequences on the system's overall
behavior.Small,naturalvariationsinworkspeedproduce
unpredictabledelaysatthehandoffs.Intheend,itishard
to predict the flow through the system, even for a well
designed system. The cure is to reduce batch size at the
handoff points, then choose from a collection of tech
niques discussed in the lean manufacturing literature to
deal withthe inevitable bubbles of inventory that pop up
fromplacetoplacewithinthesystem6.

6
Thesimplestistocrosstrainpeopletobeabletodotheworkofthoseadjacent
to them in the flow. When inventory starts to build up at a handoff point, the
upstreamworkerjoinsthedownstreamworkerinclearingit.

14
 Sw DevasaCooperativeGame page 15

Detailed
decisionsabout
external
appearance
Decisions
Decisions
aboutfunction Decisions aboutprogram
andstyle aboutprogram correctness
UI structure
Designers

Detaileddecisions
Users& aboutfunction T
esters
anddata Programmers
Sponsers

Business
Analysts

UI
Designers

Users& T
esters
Programmers
Sponsers

Business
Analysts
Figure82/3.(newfigure)replacingboth82and83.Decisionflowwithfeedback
In software development, reducing batch sizes corre
sponds to designing, coding, testing and integrating
smalleramountsoffunctionalityat onetime.It is hardto
imaginewhatjust"one"pieceoffunctionalityis,but it is
easytoseethatonmostsoftwareprojects,alargenumber
of unvalidated decisions are batched up in the require
mentsdocument,alargenumberofunvalidated decisions
are batched up in the UI design, and a large number of
unvalidated decisions are batched up in the assembled
codebasebeforethetestersaregivenanythingtotest.Re
ducing the functionality requested in one delivery incre
mentisthefirststepinreducingbatchsizes.
As with manufacturing,thereis acostassociatedwith
reducing batch sizes. In manufacturing it is the cost in
switching from one job to another. Lean manufacturing
companies spend a lot of money reducing job switching
times so that they can gain the benefits of smaller batch
sizes. (Important note: they don't make excuses that they
can't have small batch sizes because they have high job
switching costs they redesign their job switching proce
durestolowerthatcostinorderthattheycanusesmaller
batchsizes.Thisdifferenceissignificant.)

15
 Sw DevasaCooperativeGame
Engineering groups have not only the taskswitching
costs,butalsothecostofinjectingnewworkintothesys
tem through the feedback loops and the cost of revising
thedesignsastherequestschange.Unresolvedarguments
still rage in the software development community about
howsmallthebatchsizescanbemadeinUIanddatabase
design.
Figure82shows oneotherimportant characteristicof
adevelopmentteam:Thereareadifferentnumberofspe
cialists at each point in the flow, so they have different
capacities for clearing their decisions. Alert managers do
twothingswhenstudyingthesedecisionflowcapacities:
They work to balance the relative capacities at the
respective stations. It does little good to have lots of
BAs and not enough programmers, or lots of pro
grammersandnotenoughtesters.
They decide what to do with the specialty groups
where there is excess capacity. If they can't simply
sendthe extrapeoplehome,they haveto decide how
to use those people. This is where Principle #7 from
Chapter4comesin("Efficiencyisexpendableatnon
bottleneck stations"). That principle points to a wide
set of management strategies that can be used in dif
ferentcircumstances(Cockburn2005ICAM).
Now to deal with Figure 82's oversimplifications. First,
the dashedline flow of information into the testers. The
testers willget theirinformationeitherfrom the users, or
the BAs, depending on the organization. To repair this
aspectofFigure82,simplyconnectthedashedlinetothe
appropriatesource.
Next,considertheloops.Whenthetesters finda mis
take,theysendareportbacktotheprogrammerortheUI
team.Thesedefectreportsconstituteadditionalinventory
for the programmer or UI team to handle. A loop exists
from the UI designers to the sponsors and users. The UI
designersmakeamockupoftheuserinterface,showitto
the users, and come away with a stack of rework deci
sions.Athirdloopmayexistfromtheprogrammerstothe
usersandsponsors,creatingamoredecisionsbeingfedto
theUIdesigners,BAs,andprogrammers.
page 16
Figure83showsthis morerealistic,pictureofthede
cision flow in software development. Note that although
the flow is more complicated than Figure 82, the same
theoryapplies.Thesameresultsapplyaboutbatchsizesat
the handoff points and also about the use of creative
strategiesatnonbottleneckstations.
Alltheabovedependenciesexistevenwhenthepeople
aresittingnexttoeachotherinthesameroom.
SoftwareEngineeringReconstructed
Isuggestthatthosethreefoundationsprovideamodelthat
is bothsoundandpractical.Itapplies ingeneraltocoop
erative games, and in particular to both engineering and
software development (or software engineering, as it is
nowsafetowrite).
The model helps us gain insight into both education
and project management. On the education side, people
shouldbetrained
inthevocabularies of their respective crafts, whether
that be civil engineering, user interface design, re
quirementsnegotiation,programming,ortesting
in the principles and techniques of invention and
communication
inthemathematicsandlessonsoflean manufacturing
systems,and
in strategies for dealing with dependency flows and
loops.
Onthemanagementside,managersshould
learn how to work from queue size and flow to im
provetheirprojectplanningstrategies,
pay close attention to the quality of the communica
tion,moraleandcommunitypresentintheirteams,
helptheirteams to become better skilled at all facets
oftheirrespectivecrafts,and
seethatpeoplegetcrosstrainedinotherspecialtiesso
theycanhelpeachotherout,tosmooththeinevitable
bubblesthataccruerandomlyatthehandoffpoints.
16
Sw DevasaCooperativeGame page 17

2'
Individuals:Evolution
Thecharacteristicsofindividualshave,ofcourse,notchangedinthelastfiveyears.The
item that I want to highlight here is the little section, "Supporting Concentration and
Communication."Thethemetodiscussisstrategybalancing.

17
Sw DevasaCooperativeGame page 18

2INDIVIDUALSANDTEAMS(II) .......................................................................................................................... 17
STRATEGYBALANCING 19

18
 Sw DevasaCooperativeGame
StrategyBalancing
ManypeoplethinkIwantpeoplealwaystositcloselyto
gether, just because communication is most effective
whentheyareclose.TheideaIwishtodevelophereis:
Just because a strategy is good much of the time,
doesn'tmeanitisgoodallofthetime.
ThepointisencodedintheprojectleadershipDeclaration
ofInterDependence(seehttp://pmdoi.org): "We improve
effectiveness and reliability through situationally specific
strategies,processesandpractices."Thecooperativegame
modelservestoremindusthatdifferentsituationscallfor
different strategies,andthat different strategies arecalled
foratdifferentmomentsinthesamegame(anexampleis
chess, with it's different opening, midgame, and end
game strategies consider that the same applies to proj
ects).
Agoodsetofprinciplescallsforabalancingofforces
(thisis,tomymind,abasictestofsoundness).Theprin
ciples should show when something is too much or too
littleforagivensituation.Itisthebalancingoftheforces
thatgeneratesoptimalstrategies.
Let'slookagainatthe matter of collocation and com
munication:Communicationismosteffectivewhenpeople
are face to face, but it is not always the case that "most
effectivecommunication"isthetoppriority.
Sometimes we want peace and quiet (see the discus
sion ofdrafts in Convection Currents of Information,
in Chapter 3). Sound barriers help create peace and
quiet.
Sometimeswewanttimetothink,ortorunaconver
sation when we are not all present at the same time.
Asynchronous mechanisms,suchas voicemail, email,
andtextmessagingservewellhere.
Sometimeswewanttobeabletostudyanideaatour
leisure,andsowantawrittenform,perhapsonpaper,
sowecanstudy it,thinkabout it overnight,rereadit,
markitup.
Sometimes we want to dilute a particular person's
overlystrongpersonality.Inthissituationwewillpre
feralessrichcommunicationtechnologysuchasthe
telephone(Ihavebeentoldstories ofpeople whode
liberatelyusethephonewiththeirbosses,forjustthis
reason).
Theprinciples plus yourpriorities helpyoucreate an op
timalbalanceforthesituation.Forexample,whensetting
up your office, balance osmotic communication against
"drafts"togetaspacethatworksforyou.
page 19
Asalargerexample,herearetwo,opposingstrategies
createdfromthesameprinciple.Watchhowthestrategies
canbecombinedininterestingways.
The strategy of Osmotic Communication (Chapter 3)
suggests that people who need to communicate a lot
shouldsitsotheyoverheareachotherintheirbackground
hearing.Theylearnwhoknowswhatandwhichissuesare
current.Theycanrespondveryquicklytotheinformation
flowaroundthem.TheExpertin Earshotstrategy(Cock
burn 2002z) applies Osmotic Communication to profes
sionaleducation.
The opposite strategy is the Cone of Silence7 (Cock
burn 2005cos). In that strategy, one or more people are
sequesteredawayfromeveryoneelse,forthesolepurpose
ofavoidingcommunication.
HowcantheCone ofSilence possibly be useful? The
situation that clarified the matter for me was a project in
whichthetechnicalleadwassupposedtodothemostdif
ficult programming, and also educate all the people
aroundhimandalsositinmeetingstoplanfutureexten
sionstothesystem.Heneverhadquiettimetodohisown
work. The project was falling farther and farther behind
schedule.
Aftertryingseveralotherstrategiesunsuccessfully(in
cludingaskinghis managerandcolleaguestostoppester
inghim),weusedtheBusLengthCommunicationPrinci
pletotryonelastditchstrategy.
BusLengthCommunicationPrinciple: Communica
tion between people drops off radically as soon as
their (walking) distance from each other exceeds the
lengthofaschoolbus.
(What is interestingas asidetopicis that we wereso at
tachedtothestrategyofOsmoticCommunicationthatthis
wasourlastthoughtforfixingtheproblem!)
Th BusLength Communication principle is nothing
more than a mnemonic restatement of what researchers
havefoundandevengraphed(Allen1998,Olson1999?).
However, until facing that particular situation, I had al
ways interpreted the research and that principle to mean,
"Put people closer together." I had always wanted more
communication. In the project at hand, however, we
wantedtheoppositeeffectwewantedpeopletostopdis
turbingthetechnicallead.Sowefoundhiman officeup
stairs, at the far end of the rather large building, around
7
The name of this serious strategy playfully parodies the gadget of the same
namefromthe1960s spy sitcom "GetSmart."There is noconnection between
thetwoexceptasenseofhumor.
19
 Sw DevasaCooperativeGame
manycorners,certainlyfarther away than the length of a
schoolbus.
The result was nothing short of remarkable. Exactly
accordingtotheprinciple,people stopped bothering him.
He found the time and peace of mind to program at full
speed, and within a couple of months the project went
frombeingimpossiblybehindscheduletoaheadofsched
ule.
(An additional topic to consider is another strategy in
playhere:givethebestprogrammertime,peaceandquiet,
and that person can sometimes get astonishing amounts
programmedinaremarkablyshorttime.Butthatisadif
ferentstrategywithdifferentboundaryconditions.)
Having seen the Cone of Silence succeed, I suddenly
started noticing its application in many places (Cockburn
2002cos). One example was when IBM wanted to enter
thePCbusiness theylocatedthe PC development team
awayfromanyIBM development laboratory,sotheteam
would not be disturbed. Another example is the fairly
commonstrategytosendagrouptoanoffsitelocationfor
aweekend(orweek)toget alot accomplished ina short
time.
TheConeofSilenceandOsmoticCommunicationare
two,diametricallyopposedapplicationsoftheBusLength
Communication principle. They can be used together, in
alternation,oroneinsidetheother.
Puttingateamoffsite inawarroomsetting is apply
ingConeofSilencetotheteamwithrespecttoitsexternal
connections,OsmoticCommunicationwithintheteam.In
the project described just above, we used Osmotic Com
municationwithintheprojectteam,andonlythetechnical
leadoccupiedtheConeofSilence.
Strategybalancingshouldbeused when arranging of
ficefurniture.As morepeople gather, their conversations
page 20
become less relevant to each other. At some point, it be
comesbettertoseparatethemthantoclusterthem.Many
wouldbe agile developers forget this. They fill a space
with more and more people. Those people become de
pressed, because the noise gives them headaches and be
causetheygetlessworkdone.
Balancethestrategies.Decidewhenthegroupsizebe
comes toolarge,andthen decide where osmotic commu
nicationisuseful,whereitisnot.
Every strategy has builtin limitations. For Osmotic
Communication,thefirstlimitationisthatoptimalseating
will change over time. At some point, you must decide
whether to leave the nowsuboptimal seating in place, or
todisturbpeoplebyrearrangingtheseating.
Itssecondlimitationis that osmoticcommunication is
difficult to arrange when people are working on several
projects at one time. The immediate strategy to apply in
thissituation,ofcourse,istorearrangetheprojectstaffing
andtime allocations so that they aren't working on many
projectsatonce(thisstrategyhasbeenheavilystudied,see
Goldratt199x?andAnderson2003?,forexample).When
you do this, you are likely to run into the next problem,
whichisthatpeoplehavebecometoospecialized.
Theprinciples,problems,andstrategieslinkonetoan
other.Useofastrategyintroduces anewproblem,which
requires a new strategy. Sooner or later, you choose one
principleorstrategyasdominatingthesituationand driv
ingtherest.
Asastartersuggestion,dowhateverittakestoletpeo
ple work on one or at most two projects, but not more.
Serialize the projects, and apply osmotic communication
as practical. Balance the strategies and principles from
thatstartingpoint.Inallcases,balanceyourstrategiesac
cordingtotheirboundaryconditions.
20
Sw DevasaCooperativeGame page 21

3'
Teams:Evolution
Aswithindividuals,notmuchaschangedaboutthewayteamswork.Whathaschanged
inthelastfiveyearsistheattentiongiventoteambuildingandteamqualitywithinsoft
waredevelopment.Theproject leadershipDeclarationofInterDependenceraises team
behavior to a toplevel concern: "We boost performance through group accountability
forresultsandsharedresponsibilityfor teameffectiveness."Thereis, however, one ex
tension I need to make to the discussion of the office layout described in the previous
chapter.

21
Sw DevasaCooperativeGame page 22

3TEAMS(II).............................................................................................................................................................. 17
ASAMPLE OFFICELAYOUTREVISITED 23

22
 Sw DevasaCooperativeGame page 23

ASampleOfficeLayoutRevisited
I decided to save some page space on Figure 313 by full floor plan in your book? Why would you show just
showing only the programming room in Ken Auer's theprogrammingarea?"Argh,thatImissedsomuch!
building.Kencorrectlytook metotaskfor showing only
thatoneroom.
My mistake showed up as I gave talks on the idea of Meeting
convection currents of information. Having more space Programming
availableinthetalkslides,Ishowedtheentireofficeplan
(Figure5'1).During those talks, I found myself discuss
ing the uses of the private work area, the kitchen, the li Kitchen
brary,and the meeting room, and noticed they each con
tributedaseparatevalue:
Peoplegototheprivateworkareawhentheywantto
dopersonalcomputerwork.
They go to the kitchen to decompress and get some
refreshment. There, they discuss both outofwork Library
topics and some work topics. Both help the team. Privatework
People relax, talk and increase the amicability and
personal safety with each other. Increasing these re
duces their inhibitions about speaking to each other,
which in turn speeds the flow of information within
theteam(Cockburn2004).
They go to the library to get some peace and quiet,
anddoresearch.
They take noisy and directed conversations to the
meetingroom.
Figure5'1.Completedofficelayout(CourtesyofKen
WhatIfindinterestingis howpeopledeclaretheirmental
Auer,RoleModelSoftware)
stateastheymovebetweenzones.Whentheywalkoutof
theprogrammingzone,theyaredeclaring,"Ineedabreak
(forsomereason)."Whentheywalkintothekitchen,they
indicate their availability for social chitchat. When they
walk into the library, they indicate their need for quiet.
And when they walk back into the programming zone,
they indicate that they are once again back in full force
andreadytomakeheadway.
Delightedwithmyfindings,ItoldalltheabovetoKen.
He replied, "Of course. You mean you didn't include the

23
Sw DevasaCooperativeGame page 24

4'
Methodologies:Evolution
FiveyearsagoIdidnotmakeaconsciousseparationbetweenmethodologyandproject
management.It'snotthatImixedthetwomyself,butIdidn'twarnothersagainstit.This
isthetimeforthatwarning.
Thefirstsectioninthischapterarguesforseparatingprojectmanagementstrategies
fromprocessormethodologypolicies.
Thesecondsectionaddressesthetrickyquestion:oncethesetwoareseparated,and
supposingtheorganizationhasawiderangingportfolioofprojectstorun,whatcanbe
saidaboutmethodologiesacrosstheorganization?
The third section contains my best current description of how to talk about incre
mental,iterativeandcyclicalprocess.
Thefourth sectionaddresseshowto write down your team's methodology in just an
afternoonortwo.

24
Sw DevasaCooperativeGame page 25

METHODOLOGIES(II) 24
METHODOLOGIESVERSUS STRATEGIES 26
METHODOLOGIESACROSSTHE ORGANIZATION 26
PROCESSESAS CYCLES 27
DESCRIBING METHODOLOGIES MORE SIMPLY 29

25
 Sw DevasaCooperativeGame
MethodologiesversusStrategies
Afterrunningaseriesofsuccessfulprojects,itistempting
toextract the success factors from those projects and de
clarethempoliciesforfutureprojects.Thisisadangerous
thingtodo,forthreereasons:
We may have extracted the wrong "success" factor,
and are now setting as policy something that was ei
ther incidental or even detrimental to the success of
the project (which is what I suspect happened with
waterfalldevelopment).
Even if we extract the correct success factor for that
one set of projects, there is nothing to promise that
thatfactorwillbethesuccessfactoronthe next proj
ect(seethediscussionofbalancingstrategies onpage
???).
Theprojectmanager,ortheteamonthegroundinthe
situation,is probably best suited to judge what is the
beststrategytoapplyatanygivenmoment.
Strategiesthatgeneratedsuccessonasmallsetofprojects
shouldnotbecastasglobalprocess ormethodologypoli
cies. Yet this is exactly what most people think method
ologiesarefor.
Amethodologyisjustthesetofconventionsagroupof
peopleagreeto follow (less optimistically: therules they
are told to follow). These conventions can touch on any
topic at all, from clothing to seating to programming to
documentationtoworkflow.
The group's conventions are likely to shift over time.
This is proper. And, as simply a set of conventions, it is
quitepossiblethatthegroupwillneverwritedownthefull
listofconventions.
At some point, someone may decide to write down a
selectedsubset of the conventions to apply to other proj
ects.Atthispointthe methodologybecomes aformula,a
theoreticalconstructionthatabstractsprojectsandpeople.
Necessarily,thepeopleandthesituationsonthenextproj
ectwillbedifferent.
MethodologiesacrosstheOrganization
Notwithstanding the appropriateness of extracting the
project management strategies from the corporate meth
odology,andtherecognitionthatsometailoringisneeded
withineachproject,executivesquitereasonablywanttheir
projectstohavesomeconventionsincommon.Theywant
people to be able to understand what is happening when
they transfer onto another project. This requires having
someconventionsacrosstheorganization:
page 26
Knowing all the above, the highly experienced leader
maystilldecidetocastaspolicyselectedconventionsthat
usually work well, that are likely to work well for most
projects,asawayoftrainingandguidinglessexperienced
project teams. This is sensible, as long as experienced
leadersarearoundtotellwhentheconventionsareamis
fittothesituationathand.
However,theexperienced leaderis likelyto move on,
leavingtheorganizationwithanoutdatedsetofstrategies
hardeningintocorporatepolicies.Atthis point,thesocial
conventions become ritualized procedures. The organiza
tionhasaShutypeofdescriptionforaRiclass ofactivi
tiesandasRussRuferquipped,"Wecan'tmakeoneShu
fitall."
Ifprojectmanagementpolicies,practicesandstrategies
donotbelonginthemethodology,wheredotheybelong?
Theybelonginastrategymanual,acollectionofproj
ectstoriesandstrategies(seeforexample AppendixAof
SurvivingObjectOrientedProjects(Cockburn1998)fora
sampling of such strategies). The organization can use
suchacollectiontotrainjuniorproject managers and de
velopment teams. This training will highlight the
strengths, weaknesses and limitations of each strategy.
Thestrategies,takenawayfrom the process policy hand
book,areplaced wheretheybelong, as part of the project
managementcraft.
Project managersshouldbeevaluated,inpart,on how
welltheyadjusttheirstrategiestothesituation.
Itmayseemtocertainskepticalreaders that thesitua
tionIamdescribingisuniquetosoftwaredevelopment.It
is not. In Simultaneous Management (Laufer 1999?),
whichdealsprimarilywithcivilengineeringprojects,Lau
fer describes how project managers have to move from
costprioritized to flexibilityprioritized strategies from
one day to the next (and indeed, between any priorities
that may arise). That book is good reading for project
managersinanyfield.
Definitionsofcommonvocabulary.Peopleneedtobe
able to understand each other. They need to under
stand just what is meant and what variations are al
lowedbyparticularphrases.Forexample:
Doesiterationonlymean"planningwindow,"oris
it required, when saying "iteration" that code is
writtenandunittested ornot only integrated, but
tested,documentedandreadyfordeployment?
26
 Sw DevasaCooperativeGame
What is really supposed to happen in an iteration
planning meeting? Is the demo to the customer to
happeninsidethatmeetingorbeforeitaretheuser
stories supposed to written before it or during it
doesitcontaindesigndiscussionorisdesigndone
later?
What does delivery mean? Does it mean real de
ploymenttothefulluserbase,testdeploymenttoa
friendly user, or deployment to a machine in the
testdepartment?
Iwascalledinoncebecauseeveryteamusedthoseterms
differently, and they could neither understand what other
peoplemeantnorwhattheyweredoingontheirprojects.
Definitions of common formats. Although two teams
may not have to create the same work products, it is
usefuliftheyusecommonformatsforwhateverwork
productstheydohaveincommon.
Every project should probably have a vision and
scopedocument.
Every project needs a way to report its status.
Finding ways to represent status for all possible
projects is very difficult (see "A Governance
Model For Agile and HybridAgile Projects"
(Cockburn 2005) for a progressreporting format
thatcoversalotofprojects).
The Unified Modeling Language (UML) helps
people use a common language when drawing a
domainmodelorsequencechart.Theorganization
mayaddadditionalrules to how those models are
presented (naming conventions, complexity in a
single drawing, use of vertical and horizontal
placement,andsoon).
Communication requirements. The testing and mar
ketingdepartments need advance notice of upcoming
productreleases.Theorganizationmaysetpoliciesin
place about how much advanced warning they get
ProcessesasCycles
Mostpeopledescribethedevelopmentprocessasalinear
processovertime,asIalsodiduntil2001.Thesedescrip
tion werenevercorrect,or were too complicated to read.
Somepeoplesimply draw abig circle, or perhaps circles
connectedtoeachothereitherinabiggercircle.Theseare
either look wishywashy or are again too complicated to
use. The generic circle doesn't map to a calendar in any
way that helps a project manager. Around 2001, Don
Wellssolvedtheproblem,inpart,byillustratingXPusing
nested cycles at different time spans for different prac
tices.
Figure 101 shows an incremental development proc
ess using nested cycles. This nestedcycle idea fits most
page 27
("two months"), or how reliable the schedule should
be("whenthescheduleis estimatedtobewithin10%
accuracy"),andwhatsortofinformationtheyaretobe
given.
Baseline project management strategies. The organi
zationmayrequireeveryprojecttorunanExploratory
360 (see Cockburn 2004cc) before receiving com
mittedfunding.It mayrequireeachproject todeliver
systemincrementstorealuserseverythreemonthsor
less. It may require automated testing, and perhaps
test coverage policies. These policies may be chal
lengedonaprojectbyprojectbasis.
Amongthestrategiesmostoftenmistakenlyputwithinthe
methodology are the sequence and timing of gathering
information.Itiscommontorequirethatallrequirements
begatheredbeforeanydesignis done,orthatalluserin
terfacedesignbedonebeforeanysoftwarearchitectureis
done.By now it should be clear that any strategy calling
for"allofonebeforeanother"hasseverelylimitedappli
cability.
Even sophisticated developers and managers fall into
this trap. In teaching how to write use cases, I describe
how to select what to write, and the format in which to
write. People even experienced people immediately
jumptothe conclusionthat Iwant all of the use cases to
bewrittenbeforeanydesignisdone,orthateachusecase
should be written to completion at one time. Neither is
true.
Thechoiceofhowmuchofoneusecaseorhowmany
usecases to writeat onetimeshouldbereevaluatedcon
tinuallyduringaproject.Thealertteamwillcomeupwith
different answers at different moments on a project, and
certainlydifferentanswersondifferentprojects.Thisisin
keepingwiththecooperativegamemodel.
projects, agile projects particularly well. The version in
Figure101isintendedtoshowboththelinearaspectsof
theproject(readtheactivitiesclockwisearoundeachring)
andthecyclicalaspects(goaroundthe inner rings multi
pletimesforeachouterring).Alinear,ortimebasedun
foldingofFigure101isshowninFigure102.
Neitherthecircularnorthelinearversioniscompletely
correct, because there are interactions between the inner
andoutcycles.Forexample,bothiterationsanddeliveries
contain planning, reflection and celebration. Of course,
one typically does not hold two planning sessions at the
startofthefirstiterationinadeliverycycle,ortworeflec
tionsandtwocelebrationsattheendofthelastiterationin
27
 Sw DevasaCooperativeGame page 28
a delivery cycle. One merges and adjusts them accord Project
Wrapup Charter
ingly.Tryingtoshowtheseinteractionson eitherformof
Delivery
diagram is too complicated. In practice, people have no Deliver,Reflect,Celebrate(delivery) Plan(delivery)
trouble understanding that the planning at the start of a Reflect&Celebrate(iteration)
Iteration
Plan(iteration)
deliverycyclewillincludebothdeliveryanditerationtime Day
horizons,andsimilarlyfortheendofcycleactivities.This Dailysmoketest Dailystandupmeeting
Integration
iswherepracticeisforoncesimplerthantheory. Integrate&test
Design
Episode
Checkin&Test Design&Code

Figure101.Nestedcyclemodelofanagileprocess
Project Project
charter Delivery Delivery wrapup

Delivery
Iteration Iteration deliver reflect

Iteration
plan Day Day Day reflect&celebrate

Day
dailystandup Integration Integration Integration

Integration
Episode Episode Episode build&test

Figure102. Thecyclesunrolled(needsfixingtoshowdeliveryplanning!!!???)
ReadFigure101asfollows:
Aprojectstartswithacharteringactivity,whichcould
takefromanhourtoseveralweeks.Withintheproject
aresomenumberofdeliveries,afterwhichtheproject
endswithawrapupactivityofsomesort.
Thedeliverycyclestartswithanupdatetotheproject
plan,andcontains some number of iterations. It ends
withthedeliveryofthesystemtosomenumberofus
ers.Agileteamstendtoreflect aftereach delivery,to
improvetheirprocessandtheproduct.
Each iteration starts with a planning session. The it
eration ends with a reflection workshop and, in the
best shops, a celebration event of some sort. For the
lastiterationinadeliverycycle,itisprobablythecase
that the iteration reflection session is held after the
delivery,aspartofthedeliveryreflectionworkshop.
Within an iteration, there are two cycles that operate
at their own, independent rates. There are regular
weekly activities, such as the Monday morning staff
meeting, the daily standup meeting, and the daily
smoketestofthesystem.Therearealsoregulardaily
activities, such as the daily standup meeting and the
dailyfullintegrationwithtesting.
Within and overlapping the daily and weekly cycles
are integration cycles and design episodes8. Each de
signepisodeconsistsofdoingsomedesign,program
mingthe design(andtheunit and acceptance tests to
match),checkinginthe new code and tests, and run
ningthetests.Theprogrammers maygothroughsev
eral design episodes before checking in and integrat
ingtheircode.Thereareusually multiple design epi
sodes within a day, which is why I show the design
episodeastheinnercycle.Someteamsintegratemul
8
Thanks to Ward Cunningham for this term. See
http://c2.com/ppr/episodes.html

28
 Sw DevasaCooperativeGame
tiple times a day, other teams integrate every few
days.
WhatIfindparticularlyusefulaboutFigure101isthatit
allows us to capture periodic "operations" activities such
as the weekly status meeting and the daily integration in
thesameformatas"progress"activitiessuchaschartering
theprojectanddesigningnewfeatures.Eachcycleisquite
simpleinitself,whichhelpsinthepresentationofanoth
erwisecomplexprocess.
People,astheygoaboutduringtheday,havenotrou
bleinknowingwhatcycleeachactivitybelongsto.While
attendingthe weeklystatusmeetingor the daily standup
meeting, they know they are in an operations activity.
Whentheywalkout,theyknowtheyareenteringadesign
episode, and vice versa. It is not confusing to them that
theyswitchbetweenmultiplecyclesinthesameday.
Presenting the process as nested cycles has one more
benefit most people misinterpret a linear drawing of a
process as being "waterfall," even when it is specifically
not. This misinterpretation is because the linear process
drawings really describe a dependency graph between
work products! The dependency graph should be read
righttoleft, for its dependencies, not lefttoright for a
process.
The"process"diagramshowninsomanypresentations
shows Gather requirements pointing to Do design (and
Writecode),whichpointstoRuntests,andsoon,leading
toDeliver system.Althoughtothe unwary it looks like a
processdiagram,whatitreallyissayingisthatthepeople
DescribingMethodologiesMoreSimply
In Chapter 6, I describe Crystal Orange, Crystal Orange
WebandCrystalClearusingthree different formats.The
CrystalOrangeWebformatwasthenewest,andIexperi
mentally recommended it as a faster and simpler way to
capturemethodologyrules.
Iamhappytoreportthatseveralpeoplehaveusedthat
format,and have reported back to me that it works well,
andfast.
BillBarnettatWachoviaBankwassettingupfivecon
currentagileteamsforthefirsttime.Hisfirstgroupwere
using an experimental set of conventions, so of course
theydidn'twritethose down.A month later, when he set
up the second group, the first team conveyed the current
setofconventionstothesecondteam verbally,andagain
they didn't write them down. But by the time the next
threeteamsweregettingstarted,bothmanagementandthe
teams themselves were asking to have the conventions
writtendown.
Normally, writing down a methodology is something
thattakesseveralmonths,resultsinalong document that
page 29
can'tdeliverthesystemuntilthetests are run.They can't
runthetestsuntilthecodeiswritten.Theycan'twritethe
codeuntiltheylearnwhattherequirementsare,andsoon.
Althoughthesearealltruestatements,theyarenot really
informative, and they particularly don't say the really in
terestingthingsthatneedtobesaid:
Howmanyrequirements,at what level of completion,
are needed before design can usefully get started?
(The answers are usually "relatively few" and "rela
tivelylow",bytheway.)
How does feedback from the design team affect the
amountofdetailputintothewrittenrequirements?
How much of the system must be designed and pro
grammedbeforeusefulintegrationandtesting can be
done?("Relativelylittle")
Howmuchofthesystem,atwhatlevelofcorrectness,
is needed before being useful to the users or suitable
for user review? ("Relatively little" and "relatively
low").
There are two important points to take from this discus
sion:
Consider processes as nested cycles. This simplifies
their description, allowing capture of both progress
and operations activities, and allows incremental / it
erativedevelopmenttobedescribedmuchmoreaccu
rately.
Don't confuse dependency diagrams for process dia
grams.
almost no one reads. Bill feared his task accordingly. I
suggestedthathesimplywritetheconventionsasalistof
sentences, and then cluster them into topics.This he did,
and wrote to me a few days later, saying that he had
draftedtheentire,approximately12pagedocumentinone
afternoon!Anotherafternoonofreviewwiththeteam(and
touchingupthetext),andhewasdone.
Greg Luck, then at Thoughtworks (working out of
Australia), also picked up that documentation style, and
becameproficient atit.Hewas abletojoina project and
withinafewdayshavecapturedafirstdraftoftheirmeth
odology.
Whyis this important?ForBillBarnett,ashort,read
able document was needed so each new team could go
throughitandseewhattheyhadtosetintoplace.
InGreg'scase,itwasmorefortheThoughtworksclient
thanforthe development team. The people on the devel
opmentteamknewwhattheyweredoing.Theclientdidn't
know what conventions the development team was oper
atingunder.Byproducingadocument quickly,and mak
29
 Sw DevasaCooperativeGame
ingitshortandreadable,theteamwasabletoreassurethe
clientaboutwhatwashappening,theclientdidnothaveto
pay months of consultant salary for it, and other depart
mentscouldseehowtheywouldinterfacewiththedevel
opmentteam.
Hereisasummaryofhowtodothiswriting:
Planoneafternoonforthefirstdraft,thenrevieweach
sentencewiththeteamandupdateit.Youmayneedto
updateitquarterlyastheteamconventionschange.
Ifyouareamembertheteamandhavebeenworking
in a consistent way for several iterations, you may
know enough to just sit down and do the writing. If
youarecomingfromoutsidetheteam,gathertheteam
fortheafternoonandcreatethesentencestogether.
Have a (fast typer) scribe use a word processor
projected onto a screen so everyone can see and
comment on what is being written. You will
probablywantafacilitatorinadditiontothescribe.
Capturethesentencesinalist.
The person doing the typing asks questions for
clarification, the people in the room comment on
thecontent.
Don't get locked up in wordsmithing details, just
gettheideasdown.Therewillbeareviewsession
forcorrectingsmallerrors.
Write downonesentenceforeach convention in use.
Thesecancoveranytopicat all.Herearesomesam
plepossiblesentences:
"Everyonesitsinoneroom."
"Each multispecialist function team sits together
thedifferent functionteams sit as closely together
astheycanmanage."
"The marketing and sales representative visits the
teameachmorningtoseetheprogress,answerany
questions, and report on changes in direction of
newobservationsaboutthemarketandthecompe
tition."
"Programmerscheckincodeseveraltimesaday."
"2:00to4:00p.m.is reserved for focus time each
day people who agree can work on a topic to
gether, but no meetings are called, and outside
callsareblocked."
page 30
"The traffic light (or other information radiator
linkedtotheautomatedbuildmachine)turnsgreen
afterasuccessfulbuildandredwhenabuildfails.
Soundbroadcasts(e.g.cheerorbabycrying)areup
tothediscretionofeachteam."
"Teams located across time zones have a daily
standup meetingonceaday by telephone to pass
alongwhateachhasdoneorisplanningtodo."
Clusterthesentencesbytopic(thiscanbedonelater).
Some will describe basic workflow, who hands
whatsortofdecisionordocumenttowhom.
Some will describeformats,such as the format of
thestorytrackingboardortheusecaseortheuser
story.
Somewill describecommunicationpatterns,times
ofmeetings,quiettime,andsoon.
Some will describe morale raising conventions,
suchas whenDoom getsplayed, or group volley
ball games, or the Friday afternoon wine and
cheesegathering.
Reviewthedocumentwiththeteam.
Collect the team for about two hours. Go through
thedocumentclusterbyclusterandcollectcorrec
tions.
Ifyouthinkyouwillhavetroublecompletingthis re
viewintwohours,getsomeonewhoisgoodatfacili
tationtoleadthesessionand makesureit doesn'tget
boggeddown.
Ifthereisrealdisagreement onsomepoint,appoint a
separateworkingsessionbetweenjustwiththepeople
whoareconcernedwiththatpoint,andmoveon.After
that workingsession,seeifyoucanget agreement to
the changed session in the daily standup meeting or
byemail.
Reviewandupdatethe document afterthenext itera
tionorafterthreemonthsatmost.
That'sit,that'sthewholething.Nowtryit.
30
Sw DevasaCooperativeGame page 31

5'
AgileandSelfAdapting:Evolution
Thischapterisquitelong,becauseourunderstandingofagiledevelopmenthasevolveda
greatdealsincethewritingoftheagilemanifesto.
Atfirst,peopleasked,"Whatdoesagiledevelopmentreallymean?"Thatwasaccom
panied by manyinteresting ways of misconstruing the message (which continue to this
day).Thenthequestionsbecame:"Whereisthesweetspotofagile,andwhatdoyoudo
outsideofthesweetspot?"and"Whatistheroleofaprojectmanagerinahyperagile
project?"
Weshalltakealookhereatthesequestions,alongwithhowagilemethodologieshave
evolved.
Alsosuitablefordiscussionisthewayinwhichtheagileapproachgetsappliedout
sidesoftwaredevelopment.Thecooperativegamemodelappliestobusiness,journalism,
law, and entertainment, as well as software development. Agile development applies to
thoseareas,butalsotocivilengineeringandconstructionprojects,suchashouseorair
portconstruction.

31
Sw DevasaCooperativeGame page 32

AGILEANDSELFADAPTING:EVOLUTION 31
MISCONSTRUINGTHE MESSAGE 34
"Iterationsmustbeshort" 34
"Agileteamsmustbecollocated" 35
"Agileteamsdon'tneedplans" 36
"Architectureisdead,refactoringisallyouneed" 37
"Wedon'tneedno*%@!managers!" 39
"Agiledevelopmentislowindiscipline" 40
AgilityandDiscipline 40
ToleranceforUncertainty 41
"Agileonlyworkswiththebestdevelopers" 42
"Agileisnew,old,failedanduntried" 43
EVOLUTIONOFTHE AGILE METHODOLOGIES 45
XPSecondedition 45
Scrum 46
PragmaticandAnonymous 46
Predictable,PlandrivenandOtherCenterings 47
TheoryofConstraints 48
Theimportanceofthebottleneckstation 48
Thetheoryofconstraints(TOC) 49
Criticalchainprojectmanagement. 49
LeanDevelopment 50
NEW METHODOLOGY TOPICS 51
Agileprojectmanagement 52
Testing 52
UserExperienceDesign 53
ProgramGovernance,BurnCharts,andSystemsEngineering 54
AGovernanceView 55
UseCasesandUserStories 58
UserStoriesOverloaded 58
UseCasesRevisited 60
MappingUseCasestoUserStories 60
PERSISTENTQUESTIONS 61
SweetSpotsandtheDropOff 61
FixedPrice,FixedScopeContracts 62
Agile,CMMI,ISO9001 62
AnotherViewofAgileandCMMI,byPaulMcMahon,Principal,PEMSystems 65
WhenToStopModeling(reprise) 68
TheHighTech/HighTouchToolbox 69
TheCenterofAgile 70
HowAgileareYou? 70
IntroducingAgile 73
IntroducingAgilefromtheTop10Lessons,byEricOlafsson,CEO,Tomax 74
AGILE OUTSIDE SOFTWAREDEVELOPMENT 76
Projectportfoliomanagement. 76
CustomerRelations 76
Contracts 77
RevisitingtheCustomContract,byEricOlafsson,CEO,Tomax 79
IntroducingChangeIntoAnOrganization 81
TheProcessMiniature 81
AnchoringNewBehaviors 81
CreatingChangewithStickers,byKayJohanssen,TestManager 81
ALargeChangesisManySmallOnes 82
LeanManufacturingatO.C.Tanner,byMikeCollins,VicePresidentLeanEnterpriseDevelopment,O.C.Tanner84
ProgrammersReadtheHarvardBusinessReview 86
Houseconstruction 87
Airportconstruction 88

32
Sw DevasaCooperativeGame page 33
Bookpublication 89
ConferenceOrganizationandLimitsoftheAgileModel 90

33
 Sw DevasaCooperativeGame
Over the last five years, people have been quoting agile
rhetoricwithoutadoptingtheelementsthatmaketheagile
approachwork.Thissectionismylittleattempttocorrect
someofthemisquotesoftheagilemodelthatoverzealous
wouldbeagiledevelopersinflictupontheirmanagers.
Before getting into ways to misconstrue the message,
let'sfirstreviewwhatthemessageissupposedtobe(orat
leasthowIthinkaboutit).
First, create a safety net for the project, one that in
creases the chances of a successful outcome. This
safetynetconsistsofthefollowing:
Everyone ontheteam sits within a small physical
distanceofeachother(osmoticcommunication).
They team uses an automated tool suite that inte
grates the code base every short while (continu
ously, each half hour or each hour), runs the test
suite,andpoststheresultonaninformationradia
tor.
The team, working in small increments so they
checkincodeandtestsseveraltimesaday,creates
unitandsystemtestsfortheautomatedintegration
systemtorun.
The sponsor and key users visit the project team
often(dailyoronceaweek)toofferinsights,feed
back,anddirection.
The team delivers running, tested features (RTF)9
torealuserseveryweek,month,orquarter.
Following each delivery, the sponsors, key users
and development team get together and review
theirmission,thequalityoftheirproduct,andtheir
workingconventions.
After the safety net is set in place, see what can be
removed from the development process. Typically,
requirements documents can be lightened, planning
documentsput intoa simpler form, and design docu
mentation done in a different way. Also typically,
moretraining needs tobe brought in, more test auto
mation done, designs simplified, and community dis
cussionsincreased.
ThepointIwishtomakeisthatsimplifyingtheprocessis
arewardtheteamgetsforputtingthesafetynetintoplace.
Manywouldbeagile developers take the reward without
everputtingthesafetynetinplace.
Here are some of the harmful misquotes of the agile
manifestoIhaveheard.
9
AneattermcoinedbyRonJeffries(JeffriesURL).
page 34
MisconstruingtheMessage
"Iterationsmustbeshort"10
A macho culture has developed around making iterations
shorter and shorter. Teams that fall into this trap end up
with iterations that are too short to complete features
within.Theiterationdevolvestoamereplanningperiod.
Atelltalesignofthattheiterationsaretooshortisthat
theteamgetspreoccupiedwiththeworditeration.Wesee
teams charting oneiteration'sworthof work without see
inghowthevarious specialists'workfitstogetherorhow
theoutputoftheiterationsgrowtowardausefuldelivery.
The mistake is assuming that short iterations are uni
formly good. An iteration should, in theory, permit the
following:
The business experts work out the details of the fea
turestobebuiltinthisiteration.
Theprogrammersprogramthem.
Theusers,businessexpertsandtesterscheckthatwhat
got built is adequatelycorrect,andcomment on what
needstobechanged.
The programmers change the software to take those
commentsintoaccount.
They repeat the last two steps until the business ex
perts,usersandsponsorsfeelthefeaturesaresuitable
fordeployment.
Now imagine a fairly normal team of business experts,
programmersandtesters(UIdesignexpertswillnoticethe
usualabsenceofUIdesigners!)whohavechosenanitera
tionlength oftwo weeks.Theteamfinds it cannot do all
five steps in just two weeks. So, they decide to pipeline
theirwork:
Inthefirsttwoweekcycle,thebusiness expertswork
outthedetailsoffeatureset1.
Inthenexttwoweekcycle,thebusinessexpertswork
outfeatureset2andtheprogrammersprogramfeature
set1.
Inthenexttwoweekcycle,thebusinessexpertswork
outfeatureset3,theprogrammersprogramfeatureset
2,andthetesterstestfeatureset1.
Theyrunintoaproblem immediately:The groups are all
workingondifferentfeaturesets.Discussionthat felt like
collaborationwhentheywereworkingonthesamefeature
set now feels like interruption. When the testers in the
third iteration ask the business experts a question about
10
This issue is discussed at length in the article, "Are Iterations Hazardous to
YourProject?"(Cockburn2005z)
34
 Sw DevasaCooperativeGame
featureset1,theyforcethebusinessexpertstoremember
issuesexaminedtwocyclesago,amonthintheirpast.
Toprotectthemselves,sotheydon'tgetbotheredwhile
they work out their new decisions, the business experts
write documents to give to the programmers and testers.
Similarly, the programmers create documents to hand to
thetesters.
Inpipeliningtheirwork,theyhavecreatedatimebar
rier, which can be crossed only using archival forms of
documentation,whichaswesawinChapter2,areexpen
sive, tedious, and relatively ineffective forms of commu
nication.
Some agile experts are really opposed to lengthening
the iteration, and this for good reason. As the iteration
lengthens, people have a tendency to delay their work,
pushing it all toward the end of the iteration. As Dan
Gackle once wrote, describing their team's use of one
monthiterations:
""Meander, meander, meander, realize there isn't
muchtimeleft,freakout,getintense,OKwe'redone.
Repeatmonthly."
Good agile coaches steer carefully to avoid these two
traps, shortening the iteration to get results quickly,
lengtheningittogetpropercommunicationandfeedback,
keepingpeoplefocusedonmakingprogressatalltimes.
"Sowhatshouldwedo?"
Becomepreoccupiedwiththeword"delivery."
Understand that each iteration builds toward the next
delivery,andknowexactlywhateachiterationcontributes
toeachthenextdelivery.Withthisinmind,determinethe
length of the iteration from factors having to do with
knowledge of the domain, the technology, the user base,
and the communication patterns. Consider at what pace
theteamcandeliverrunning,testedfeaturestorealusers,
while also collecting and incorporating feedback from
those users. Balance brevity of iteration with the quality
andcompletenessofteaminteractions.
Retain in all cases is the idea that a feature is not
"done"untilthekeyusershavehadachancetoseeitand
change it at least twice. Although this is not in the agile
manifesto,itisacriticalpolicyforthesoftwaretobecon
sideredsuccessfulinuse.
"Agileteamsmustbecollocated"
Distributed teams lose the high levels of communication,
trust, and project safety afforded by collocation. Project
managerswhoonceledcollocatedteams but thengot as
signeddistributedteamsrepeatedlycommentto meabout
thelossoftrustandthe difficulty inrebuildingit.This is
independentofwhethertheywereusinganagileapproach
ornot.
page 35
While it is clear that working with a distributed team
makesagiledevelopmentharder,itdoesn'tmeanyoucan't
use the agile model. The wouldbeagile distributed team
must put more energy into its communication and team
buildingstrategies,andfindtimestogettheteamtogether
facetoface.
Automationtoolsandhighspeedcommunicationtech
nologies help.Webcamerasand microphones attachedto
workstationsletpeopletoseeandtalktoeachotherinreal
time.Instant messagingletsthemtradecodeinreal time.
Net meeting software lets them pair program together.
Automatedbuildandtesttoolsletpeopleindifferenttime
zonesworkfromthesamecodebase.
Distributedteams mustbecarefultoworkinsmallin
crements, integrating and testing multiple times a day.
Because communication is not as fast, synchronizing the
codebasebecomesmoreimportantastheteamgetssepa
rated.
A distributed team must put more energy into simpli
fyingthesystem'sarchitecture(CockburnCutterref).The
reason has to do with Naur's "Programming as Theory
Building." Since the communication channels between
people are constrained, it is more difficult for them to
build a shared theory of what they are developing. The
more complicated the architecture is, the more compli
cated the theory is, and the less likely they will work to
the same decision principles. Conversely, with a simpler
architecture,theyhaveagreaterchancetokeepthetheory
intactacrossdistanceandintermittentcommunication.
Even with all that, there is still no substitute for per
sonal,facetofaceencounterstobuildpersonalsafetyand
trust.Gooddistributedteamsgettogetherinitiallyandpe
riodically for both technical work and social interaction.
Through these gettogethers, they build shared mental
modelsoftechnicaltopicsandpersonaltrust.
Partofthetroublewithdistributeddevelopmentisthat
executives and managers have never learned how to de
velopsoftwarehere.Theycometothinkthatperhapsthey
knowhowtodevelopsoftware there,orifthereisgoingto
beamess,itisbetteroutofsight,andifthereis goingto
beafailure,thefailurewillbelessexpensiveifithappens
there. What I am interested in is learning and teaching
howtodevelopsoftware here,foranyhere.Oncewelearn
this,thenwecandevelopsoftwareboth hereand there.
Idon'texpecttoreversethetrendofdistributeddevel
opment. I do wish executives to consider more of the is
sues involved, particularly the higher communication
costs.
Asuccessinthisregardwaswhenoneexecutive,who
was running projects split between Pennsylvania and
North Carolina, turned to her colleague, and said
(roughly):"Ithinkthatwecouldhaverunthatlastproject
35
 Sw DevasaCooperativeGame
just in Philadelphia. Even though Jim (the best program
mer)isinNorthCarolina,wecouldhaveusedMartin(in
Philadelphia)insteadandsavedalotoftrouble."Shewas
balancingtheincreasedexpertiseshecouldgetinmultiple
sitesagainstlowercommunicationscostsandhigherteam
productivityshecouldgetwithacollocatedteam.
"Sowhatshouldwedo?"
Pay even closer attention to the agile values than collo
catedteams do.Simplify the architecture. Add new face
toface communication opportunities. Use an automated
buildmachineandcheckyourcodeineveryfewhours.
Keepyoureartothegrapevineandpickupnewideas
beingtriedinotherteams.
"Agileteamsdon'tneedplans"
Earlycritics oftheagile movement worriedthat we were
dropping project planning, which would be dangerous to
theproject.Sadly,Ihaveseenexactlythis(droppingplan
ning)happenalltoooften,and withthe expected damag
ingconsequences.
Itseemsthatquiteanumberofoverzealous wouldbe
agilistssaytotheirmanagers,"Ifwearesufficientlyagile,
we don't need plans we can always react quickly
enough.Ifweneedplans,wearejustnotagileenough."I
have lost count of the number of executives who tell me
that this is howtheirprogrammers present agile develop
menttothem.
The final value comparison in the agile manifesto
states: "Responding to change over following a plan."11
That is followed by the tempering statement, "While we
valuetheitemsontheright,wevaluetheitemsontheleft
more."Planningisusefulinbothcases.
The value comparison in the agile manifesto is in
tendedtocompare
makingaplanandperiodicallyreconsideringwhether
therealitycurrentlyfacingtheteamisbetterservedby
keepingtothatplanorbycreatinganewoneagainst
makingaplanandcontinuallytryingtogetbackonto
it.
Whensomeaspect ofthe project doesn't work out as ex
pected,asuddenstaffchangehitstheteam,orsomeexter
nal event changes the sponsors' priorities, the team must
decide whether to get back to the written plan, or to
changeboththegoalandtheplan.Itisnotpartoftheagile
manifestotoassert whichis betterto get back onto the
planortocreateanewone.Itisapartoftheagile mani
festo to assert that one should make that choice deliber
ately.
11
http://agilemanifesto.org
page 36
Except oncertainexploratoryprojects, there is almost
alwaysenoughinformationtomakeacoarsegrainedplan
that is aligned with the project and the organization's
overall vision. This coarsegrained plan serves to make
coarsegrained cost and time estimates. Those estimates
are badly needed by the sponsors to weigh the project
againstotherpossibleinitiatives.
We worked to repair the situation as we could in the
Declaration of InterDependence. The third principle in
theDOIstates:
"Weexpectuncertaintyand manage foritthrough it
erations,anticipation,andadaptation."12
Thisphrasehighlightsthatuncertaintyisafactorthatcan
not be completely eliminated, but can be mitigated with
the feedback mechanisms in standard use by agile teams
(iterations, reflection, adaptation), plus making use of in
formationthatisalreadyavailableanticipation.
It remains to be seen whether upper management will
accept that uncertainly cannot be eliminated. It also re
mains to be seen whether agile zealots will accept that
anticipationhasvalue.
In practice, agile teams tend to produce plans at two
levels: longterm, coarsegrained plans, and shortterm,
finegrainedplans13.
On one 18month, $15m fixedprice project, we
workedfrom240casualusecases14,alistofexternalsys
tems that would have to be touched, an estimate of the
numberofdomainclassandscreensthatwouldhavetobe
built,andareleaseplanthatconsistedofadozenbubbles
with dependency arrows between them, with lines mark
ing the five deliveries that would be made. Such coarse
grained longterm plans are typically used for projects
greaterthanthreemonths.
The shortterm, finegrained plan is used for time
frames between one week and three months. Inside the
onemonth time frame, work items are typically broken
downintopiecesbetweenhalfadayandthreedayslong.
Thesetwolevelplanshaveseveraladvantages:
They paint an overall picture of the project and still
allowroomformovement.
The longterm, coarsegrained plan show the overall
direction, the timing, the approximate cost, and how
theiterationsfittogethertodeliverthebestvalueover
thelongterm.
Theshortterm,finegrainedplanisusedtocoordinate
teamsindetail.
Eachlevelcanbeupdatedquickly.
12
http://pmdoi.org
13
ExamplesofeachareshowninCockburnCC2004,pp??????.
14
"Casual"usecasesarewritteninonlytwo paragraphs.Theyaredescribedin
(Cockburn weuc).
36
 Sw DevasaCooperativeGame
Theteamcanbalancethe needs of setting overall di
rectionwithtrackingdetailedwork.
Any change in a longterm plan invalidates a large
amountof workinadetailedplan,andwecanbecertain
that there will be changes in the longterm plan. By ex
panding the detail of the plan just prior to starting an it
erationoradeliverycycle,wereducereworkinplanning.
"Sowhatshouldwedo?"
Createacoarsegrainedlongtermplantoknowwherethe
target is, and a finegrained shortterm plan for the next
week,monthorquarter.
Sidebar: HelmuthvonMoltke
Agilistsoftenmotivatetheiraversiontodetailedlongterm
plans by quoting the German military strategist Helmuth
vonMoltke:"Nobattleplansurvivescontactwiththe en
emy."
I found this a compelling quote, until I learned that
therewere twoHelmuthvonMoltkeswhomighthavesaid
it.
Moltke the Younger (Helmuth Johann Ludwig von
Moltke, 1848 to 1916) has been (controversially) blamed
for Germany's loss in the Marne campaign and conse
quentlytheFirstWorldWar.
"AsChiefoftheGeneralStaffMoltkewasresponsible for
thedevelopmentandexecutionofthestrategicplansofthe
GermanArmy.Thereisconsiderabledebateoverthenature
ofhisplans.Criticsfromthesocalled"SchlieffenSchool"
arguethatMoltketookhispredecessor'splan...modifiedit
without understanding it, and failed to execute it properly
during the First World War, thus dooming German ef
forts."15
If Moltke the Younger said that no battle plan survives
contact with the enemy, then those opposed to the agile
viewpointwouldrespondthatthiswasspokenbysomeone
whoclearlyhadn'tplannedwellenough.
On the other hand, Moltke the Younger's uncle, Hel
muthKarlBernhardvonMoltke(1800to1891,knownas
MoltketheElder),didn'tloseanywarsforGermany,was
very successful in battle and was eventually promoted to
Field Marshall. If it was Moltke the Elder who said the
quote,thentheaboveretortcan'tbegiven,and"Nobattle
plansurvives contact with the enemy" meaningfully sup
portstheviewthat even the best plans need frequent up
dating.
Fortunately,itwasMoltketheElderwhosaidit.
15
http://en.wikipedia.orfg/wiki/Helmuth_von_Moltke_the_
http://en.wikipedia.org/wiki/Helmuth_Karl_
Bernhard_von_Moltke
page 37
"Architectureisdead,refactoringisallyouneed"
Similartonot needing plans is the overzealous view that
architecture is not needed: "If you are sufficiently agile,
youdon'tneedanarchitectureyoucanalwaysrefactorit
onthefly,"saythesepeople.
Let'slookat bothsides oftheargument,withtheidea
that the extreme of either probably is not good for most
projects (but possibly is good for some project some
where).
Good agile developers start with simple architectures
and then evolve them. I have seen good developers start
withsimplisticintercomputermessagingmechanismsand
latersubstitutecommerciallyprovidedmessagingsystems
without difficulty. This pattern of development is called
WalkingSkeletonwithIncrementalRearchitecture(Cock
burnCutterref,CockburnCC).
The advantage gained is that the team, sponsors and
users have a system up and running early. From there,
they can steer the feature set, the architecture, the staff
composition,the use of technology, and the development
process. The cost to the strategy is that the team must
makechangestothesystemwhiledevelopmentcontinues.
Thecounteringargumentisthatamorecomplexorigi
nal architecture would probably also be wrong in unex
pectedwaysandwouldalsoneedtobechanged.
I have seen and heard of projects saved by deploying
an early, simple architecture and changing it later after
they saw where its shortcomings were and I have seen
and heard of projects that failed due to an overly ambi
tious initial architecture that could never be fully devel
opedand deployed at all. I therefore consider the cost of
upgrading a simple initial architecture as nothing more
than the insurance premium for increased project safety
andforreducedriskaffordedbyhavinganearly,running
system16.
Changing the architecture is possibly a good thing in
itself. I ran across the following argument somewhere
along the way, and have examined it closely with some
friends.Wethinkitissound.Seeifitmakessensetoyou.
Younger and
16
Alongerdiscussionofpayingextraforflexibilityispartofthearticlesseries
"LearningfromAgileSoftwareDevelopment"(CockburnCrosstalkagileref)
37
 Sw DevasaCooperativeGame
Changestooexpensivetomake(deadproduct)
Changesslowthebusinessdown
Cost
to
update without
constant with
the
software
refactoring constant
refactoring
Numberofchanges
Figure5'1. Thegraphicalargumentthatbusinessesget
heldupbynotrefactoringsystemsconstantlyearlierthan
whentheyrefactorconstantly(seetext).
Figure5'1showsthecostofrefactoringversusnotre
factoringcodeovertime.Thecoreideais that whenpeo
plemakechangestothecode,theyaddsmall,extrabitsof
complexity, perhaps an extra branch condition or code
duplication. These little bits of complexity are not inde
pendent,butstarttointertwine.Anewbranchconditionis
based on a previous branch condition, code duplication
gets copied, modified and gets its own new branches.
Oncetheselittlebitsofcomplexitystarttointertwine,the
totalsystemcomplexitygoesup,notlinearlyasitwouldif
theywerecompletelyindependent,butexponentially.
The cost for updating the software looks like interest
growthonafinancialloan:(1+c+u)n..Here,cistheneces Ron to estimate the cost of communicating the new re
sarycomplexityaddedtothe code through the new busi
nessrules,uisthecostforunderstandingtheunnecessary
intertwining across the changes, and n is the number of
changes put into the code. Even if u is a small number,
over thousands of changes across a period of years the
cost to understand and modify the code grows to a point
where the system simply can't be updated in the time
frameneededbythebusiness.
The graph shows how it comes about that modifica
tions to a software system start out easy, but become
harderandharderovertimeuntilfinallytheprogrammers
tell the business owners, "We can't make any more up
gradestothissystem.Wehavetostartover."
Refactoringconstantlytocleanupthe code, the curve
becomes exponential with a slower exponential. It does
cost time to clean up each new piece of complexity, but
thesecleanupactivitiesdon'tintermixwitheachother,so
the cleanup activity costs. The cost is (1+c)n.+ (r*n),
whereristhecostofdoingtherefactoring.Thecodestill
growsmorecomplex,butthegrowthisslower,andsothe
system lasts longer before slowing down the business
(ratherlikepayinga5%loaninsteadofan11%loan).
Noticethatinitially,therefactoringcostisgreaterthan
the cost of understanding a few extra bits of complexity,
page 38
butovertime,thetwotradeplaces,asshowninFigure5'
1.
Inotethattheincreasedcostofunderstandingthesys
temas it grows in complexity is part of what Peter Naur
talks about as "theory building" in Appendix B. It is an
intrinsiccost,meaningthatitcan'tberemoved.
Sofarintheargument,wehaveseenthatstartingwith
a simple architecture is good and refactoring is good.
Where'stheproblem?
The problem is that sometimes the development team
has information available that can reduce the refactoring
cost. Ron Crocker's example illustrates(Cockburn cutter
archarticleref):
RonCrockerwas lead architect at Motorola on a new
mobilephoneplatformthatcoveredfromthetransmission
towers to handheld and PCbased devices. They were
facedwithmeonecorearchitecturalquestion,whetherto
designthemobilephonestohandlebothcircuitswitching
and packetswitching traffic right from the start, or just
circuitswitching. They suspected they would need both.
The refactoring approach would have them design the
system to handle circuit switching, to add the capability
forpacketswitchingonlywhenthatbecamestrictlyneces
sary,andtorefactortheirarchitectureatthattime.
Ron'sdevelopmentteamconsistedof250peopleinsix
countries,andIknewthatthiswasafactorinhisdecision
to design for both right from the beginning. So I asked
designunderthesimplestcircumstances,thattheirproject
consistedonlyof30people,alllocatedinthesamebuild
ingonthesamefloor.Aftersomepause,heestimatedthat
they might have been able to migrate the developers to
understanding the new architecture in "merely" a few
weeks.
"ButwhywouldIwanttodothat?"heasked,meaning,
whywouldtheywanttocosttheentireteamtwoweeksof
theirtime,whentherequirement wasknownfromthebe
ginning?
In fact, with 250 people in six countries, the cost of
communicating the revised architecture would have been
enormous. Since the requirements were known from the
start, it made sense for his team to design for both right
fromthestart.Itis relevant to mention that his team had
designedthesetypesofsystems before,sothey were em
barkingonafamiliar,ratherthanunfamiliar,path.
On another project, the lead architect, who was con
tracting out the work to an XP team, watched in frustra
tionasthesubcontractorsignoredtheknownrequirements
to support a variety of peripheral devices, and imple
mentedaseriesofdesignsoneaftertheother,addingeach
peripheraldeviceasasurpriseadditioneachtime.Hewas
frustrated because he knew they could have cut quite a
38
 Sw DevasaCooperativeGame
few revisions if only they considered the future require
mentsfortheperipheralsmuchearlier.
This is where some balancing of the issues is called
for.
We have learned in the last ten years that simple de
signs with clean interfaces really can be altered and ex
tended with quite low cost. The cost is low enough that
very often, a simple, clean design followed by a targeted
change comes out at a better overall cost than an overly
complicated initial design that takes longer to implement
andisdifficulttobothlearnandmodify.
What we need to take into account is that good agile
developers are quite experienced and have good design
reflexes.Theirdesignsaresimple,clean,andrefactoreas
ily. The refactored design is again tidy and clean and al
lowsitselftoberefactoredagain.
Inexperienced designers are likely not to have such
gooddesignreflexes.Theycanbenefit frombeingforced
tothinkthroughtheissuesofscalability,performanceun
dergrowingloads,andprobablechangesinrequirements.
Thethinkingtimeiswellspent,eveniftheydecidetoim
plementasimplerdesign.
Thishasbeenalongsection.Architectureis not dead,
andrefactoringisnotacureall.Thinkingabout designis
still important, as is developing good reflexes about sim
ple,tidydesigns.
"Sowhatshouldwedo?"
This quesiton one has no simple recommendation, as far
asIcantell.Differentpeoplethinkaheadtodifferenttime
horizons.
I like Ron Crocker's advice17: Create a simple archi
tecture that handles all the known "big rocks" (require
mentsparticularlyhardtoincorporatelateintheproject).
Handle the "small rocks" as they appear during the proj
ect.
Agoodarchitectureissimpleandunderstoodbyallon
theteam.Thistakesthinking.Atthesametime,goodag
ileteamshavedemonstratedthatwithcleandesigns,even
significantchangescanbemakeremarkablyquickly.
"Wedon'tneedno*%@!managers!"
Along with plans and architecture, overzealous agilists
dismiss therole ofproject manager.Here again, we need
tolookattheissuesinvolved.
From interviewing project teams and managing proj
ectsmyself,I have made the following list of ten factors
criticaltoprojectsuccess,infiveareas(seeFigure5'2):
17
(Cockburncutterarchref)
page 39
NourishmentfromExecutiveSponsors
(decisions,money)
Community
(communication,amicability)
Focus
(knownpriorities,focustime) Incremental
development
& Reflection
People
(abilities,motivation)
Figure5'2. Tencriticalfactorsinprojectsuccess
Sponsorship:Without adequatesponsorship,the proj
ectwillstarveforresources.Sponsorshipconsistsof
Moneyforstaff,trainingandequipment
Decisionsaboutdirectionandpriorities
The people: The people have to be both capable and
willingtodothework.Thisincludes
Ability meaningtalent,the latent part of ability,
and skills, thetrainablepart
Motivation the willingness of the people to par
ticipate in both social and technical sides of the
endeavor
Incremental development with reflection: Without
incremental development, the team doesn't have a
chanceto detect andcorrect problems in its direction
and process without reflection, the team won't actu
allyredirectitself.Theseare
Incrementalgrowthandintegrationoftheproduct,
preferablywithdeliveries
Reflection after each increment about their direc
tion(includingtargetmarketandfeaturesets),their
rateofmovement,andtheirprocess.
Community:Thequalityofthecommunityaffectsthe
speedofmovementofideasitisoneplacewheredy
namicshiftsinteamproductivitycanoccur.Commu
nityincludes
Communicationpathsthespeed oftheproject is
limited by the speed at which information moves
betweenpeople(ergseconds/meme,seep.???).
Trustissues (personal safety and amicability) if
peoplewon'tspeakorwon'tlisten,theinformation
won'tgetfromwhereitistowhereitneedstobe
Focus,meaningbothdirectionandtime.
Prioritiesknowingthetwoorthreekeyitems to
workonatanytime
Focus time having quiet time to get the work
done
Figure5'3showsroleoftheprojectmanager.
39
 Sw DevasaCooperativeGame
Sponsor(s)
Interruptions
Decisions
$ Visibility
X and "XP and Discipline," p. ???), many people have
PM
Communication
Amicability developers
Priorities
Focus time
Skills development
Motivation
Reflection
Figure5'3.Roleoftheprojectmanagerinmodern,agile
projects
If the team does not make its results visible to the
sponsors, the sponsors will cut the supporting flow of
moneyanddecisions.Indeed,whenIlookthroughstories
of failed agile projects, this is a dominant pattern that
emerges:Theprojectteamdismissedtheprojectmanager,
did not create an adequate line of visibility to the spon
sors, and the support got cut off a short time later. This
visibilityproviding role need not be in the hands of the
projectmanageritjustusuallyis,becausethatispartof
thenormaljobdescriptionforaproject manager(PM). If
anagileteamwishestoworkwithoutaPM,theteammust
find another way to get the visibility and support they
need.
The PM also serves the team is by acting as a wall
againstinterruptions.Indeed,fromthetimeIwasajunior
hardware designer in the 1970s through today, I have
heard developers say, "The only thing a project manager
providesmeiskeepinginterruptionsaway!"
The largest part of a PM's job is "getting people to
worktogetherwhowouldotherwisebesittinginthecafe
teria arguing.18" This means working on communication,
amicability,personalsafety,andmotivation.
Finally, it is the project manager who helps people
identify and get the skills development they need who
helps them clear time for focusing on work who makes
sureeveryoneknowstheirpriorities,thattheprioritiesare
aligned within the team and with the organization's who
organizesandmayleadthereflectionsessions.
EvenafterwedropthebureaucraticloadofthePM to
nil,thereisstillplentyforagoodprojectmanagertodo.If
18
ThankstoCarlEllison,whospokethesemysteriouswordstomebackaround
1978. They have been rattling around my head for decades waiting for me to
makesenseofthem!
page 40
you choose to eliminate the role of "project manager,"
makesurethatallthesecriticalfactorsaretakencareof.
"Agiledevelopmentislowindiscipline"
Notwithstanding the discussion in the 1st edition of this
book("CounteringwithDisciplineandTolerance,"p.52?
formed the impression that agile development is low on
discipline.
Thebestagileteamsareextremelydisciplined,writing
test cases before they write new code, checking in and
integrating runningtested code every few hours, refac
toring their code to simplify it, showing their results to
users every week, and reflecting on their work habits
everyweekoreverymonth.Ifindthesepracticesdifficult
tointroducein mostorganizations.Iamalways surprised
at how many agile groups manage to do them all, enjoy
doingthem,andinsistondoingthem.
Agilityand Discipline
The idea that agility is not disciplined comes from
people working with a onedimensional comparison line
(see Figure 5'(2)). This view causes trouble because
people are forced to place agile development somewhere
betweencowboycodingandplandrivendevelopment.
Cowboycoding Plandriven
Discipline
Figure5'(2).Theoldviewofaonedimensionalspec
trumofdisciplinebetweencowboycodingandplan
driven.
But it doesn't sit between those two choices at all.
There is another dimension in play, namely how much
fluxorchangeishappeningwiththerequirementsandthe
code(seeFigure5'(1)).
Cowboy coding (what I sometimes call "lost in the
woods"development)involveschangingdirectionalot,as
well as missing discipline. The changes in direction may
or may not be useful to the company. Plandriven devel
opment intends to slow down the changes by adding a
certainlevelofdiscipline.
Agile development permits greater changes in re
quirementsanddesign,byaddingacertainlevel of disci
pline. There are numerous agile methodologies, some of
which call for more discipline than others. XP probably
calls for the greatest amount of discipline among the
named agile methodologies (see "XP and Discipline, p,
???).CrystalandScrumarefairlydeliberateabout lower
ingtherequirementsfordisciplineaslowaspossiblebut
bothstillrequiremoredisciplinethancowboycoding.Ju
dicioususeofagileprinciplesandtechniqueslettheteam
40
 Sw DevasaCooperativeGame
respond faster to changing requirements and design than
cowboycodingdoes.
agile
development
cowboy
flux
coding
plandriven
development
discipline
Figure5'(1).Amoreaccurateviewshowsdiscipline
andfluxasseparatedimensions.Agiledevelopmentoccu
pies the highflux zone and permits a varying amount of
discipline.
Thus,agility does not go against discipline, but is an
independentselection.Onemanagementbookcapturesthe
importance of having both: In Big Winners, Big Losers,
Alfred Marcus (2006) reports on his study of companies
thatstayedsuccessfulacrossleadershipchanges.Hefound
theyhadallthreecharacteristics:
Agility
Discipline
Focus
Focus, which provides knowledge of direction and the
abilityto not workonthings not relatedtothat direction,
simplifies people's choices. Agility, which provides the
abilitytochange directions quickly,drives effectiveteam
workhabits.Discipline,whichprovidesthecapacitytodo
theunpleasant,keepstheteamdoingwhatworks.
Agility, discipline and focus are as essential to an ef
fectivesoftwareteamastothecompanyasawhole.
ToleranceforUncertainty
This is the appropriate time to offer a graph that Jim
HighsmithandIdrewupinoneofourearlymeetings,but
which we haven't published up to now (Figure 5'5). It
relatestotheorganizationaltolerancetowardflux.
The most productive strategies operate with a high
level of flux, ambiguity and uncertainty. Incremental de
velopment, iterative development, and concurrent devel
opment are three strategies in this line. Anyone who has
lived through a concurrentengineering project under
standsthehigherlevelsofflux,ambiguityanduncertainty
itgenerates.
page 41
The horizontal axis shows the level of ambiguity and
uncertaintythepeopleintheorganizationcantolerate.As
theycantoleratemore,theycanapplythemoreproductive
concurrent strategies. As they can tolerate less, they are
restrictedto simpler, less productive strategies (waterfall,
forexample).
Eachproject requires acertainlevel ofproductivityto
complete in time. If the project requires a lower level of
productivity, then a team with lower tolerance for ambi
guity and uncertainty can still complete the project with
their simpler strategies. However, if the project requires
thehighestlevels ofproductivity,thesameteamwillfail,
becausethepeopleareunableorunwillingtousethemore
productivestrategies(thatcallfortheextraambiguityand
uncertainty).
Projectrequiresatleastthismuch
(usingflux&uncertainty)
productivitytosucceed
eprojects
Productivity
oldschool
projects
Toleranceforambiguity/uncertainty
Figure5'5. Somegroupscannotusehighlyproductive
strategiesbecausethosestrategiesrequiremoretolerance
forambiguityanduncertaintythanthegroupscanman
age.
ThisiswhattheBoehmTurnerdiagrampointsatwith
theCultureaxisseeFigure5'4,inthenextsection).Some
organizations need order, or the fiction of it. Those or
ganizations are less suited to trying out agile strategies,
sincethe agile strategies will bring ambiguity and uncer
taintywiththem.Organizationswithhighertolerancewill
haveaneasiertimewiththeagileapproach.
Figure 5'5 makes one more, very important, point.
Some projects require the more advanced, more produc
tive,uncertaintygeneratingstrategiesinordertosucceed.
Others don't. If your organization's projects don't require
that extra level of productivity, then your organization
doesn'tneedtheaddedstresscausedbyagilemethods.If,
ontheotherhand,yourprojectneedsthatlevelofproduc
tivity,butyourorganizationcan'ttoleratetheneededlevel
ofambiguityanduncertainty,thenyou'reintrouble.
Ithinkthatthisgraphhintsatthelimitsofadoptionof
theagileapproach
41
 Sw DevasaCooperativeGame
"Sowhatshouldwedo?"
Donotchoosebetweenagilityanddiscipline.Youcan
haveeither,orneither,orboth.
"Agileonlyworkswiththebestdevelopers"
Manywritershaveofferedapeculiarobjectiontotheagile
approach.Theyobservethat very bright designers articu
latedtheprinciples,andjumpfromthatobservationtothe
assertionthatonlyanallexpertteamcansucceedwiththe
agileapproach.
This objection is peculiar because the argument is so
riddledwithflaws that Iamsurprisedtofindit being of
feredatall,letalonebypeopleIrespect.Iinclude herea
discussionofthispeculiarobjectiononlybecausesomany
peopleciteit.
Themanifesto'sauthorsweremostlyconsultantsatthe
time of the writing. As consultants, we and here I cer
tainlyspeakformyselfwerenevergiventheopportunity
to work will "all expert" teams. Those are not the teams
thatcallusforhelp.Itisthenonexpertteamswhocallin
the consultants. Therefore, we were writing from experi
enceinworking withteams havingafairlynormal distri
bution of expertise: maybe a good person or two, some
youngnovices,somemediocrepeople.TheprojectteamsI
interviewed in the early 1990s, from whom I learned the
agile ideas, had those standard skill distributions. That
skill mix did not change when I started consulting. The
agile approaches were learned from, debugged on, and
practicedwithteamshavingtheusualteamskillmix.
Besidestheabovepracticalobjection,thereisaninter
esting logical flaw in the argument. It uses a rhetorical,
cognitive illusion19, to fool an audience into believing a
false result. The cognitive illusion is that we are quickly
drawn to believe theinverse of a proposition, when only
the contrapositivelogicallyfollows.
Hereis aquickrefresher.Suppose that when Jim eats
fishhegetssick.
Toformthe inverse(whichwon'tbetrue),negateboth
partsandleavetheminthesameorder:"IfJim didn't
eatfishlastweek,thenJimdidn'tgetsicklastweek."
Onthesurface,thislooksreasonable,butwithabitof
thinking, we realize that Jim could have gotten sick
fromsomeothercause.
To form the contrapositive (which will be true), ne
gate both pieces andreverse their order: "If Jim was
notsicklastweek,thenJimdidn'teatfishlastweek."
Thisistrue,asthefollowingtablesummarizes.
Proposition A B "IfA,then B"
19
See InevitableIllusions (???),whichtalksaboutothercognitive(asopposedto
optical)illusions.
page 42
Inverse ~A~B Doesn'tfollow
Contrapositive ~B ~A Follows
The cognitive illusion is that we find ourselves drawn to
theunsound,simplerinverseratherthantothemorecom
plicated, sound contrapositive (the length of the word
contrapositivedoesn'thelp).
Withthatrefresher,let'stakealookatanassertionthat
I have seen at the top of more than one speaker's slides:
"Aproblemwithagileprocesses isthattheyrequirecom
petentandexperiencedpeople."
Proposition: "If I'm using an agile process, I need
somecompetentandexperiencedpeople."
Thesimple,unsound inverseis:
Inverse: "If I am not using an agile process, I dont
need any competent and experienced people on my
project."
Theimplicationbeing given is that if we use a nonagile
process, we can avoid using any competent and experi
encedpeople.
Thiswouldbeanamazingresultifit weretrue!How
ever, if we look at project histories, one of the simplest
observationsisthatprojectsofallshapesandsizesrelyon
at leastafew competent and experienced people to set it
upandpullitthrough.
Inreality,nomatterwhatprocessweuse,wearegoing
toneedat leastafewcompetent and experienced people.
So,theinversepropositiondoesn'tmakesense.
Nowlet'slookatthecontrapositive:
Contrapositive: "If I don't have a few competent and
experiencedpeople,Icantuseagileprocesses."
Oranythingelse,forthatmatter!Havingacertainnumber
ofcompetent and experiencedpeople onaproject is sim
ply a critical success factor, no matter what the process
type. This contrapositive is true but almost meaningless!
Andthereforesoisthesentence,"Touseanagileprocess,
Ineedsomecompetentandexperiencedpeople."True,but
basicallywithoutmeaning.
Ihadaprojectconsistingonlyofnovices,Iwouldput
mymoneyonthemdoingbetterwithanagilethanaplan
drivenprocess.Ican'timagine novices comingup with a
meaningful plan from the beginning, or delivering a suc
cessful project by sticking to that plan, or updating the
planeverytimetheyfoundamistakeinit.Anagileproc
ess will call for them to work together, integrate fre
quently,testtheircode,showtheirresultstotheirsponsors
and users, and update their plans and working practices
accordingly.Withthisapproachtheyhaveabetterchance
tolearnandimprovewithintheproject.
BarryBoehmandRichTurnercameupwithan inter
estingvariationoftheobjection.Theywrote,"Youneeda
42
 Sw DevasaCooperativeGame page 43
Personnel
higher ratio of competent and experienced people on an (%Level1B)(%Level2&3)
agile project than on a plandriven or papercentric proj 40 15

ects." 30 20

This statement is true, as far as I can tell, through an

20 25
interesting and sort of backhanded line of reasoning that Dynamism
Criticality
alsoappearstobetrue.Itgoeslikethis: (Lossdueto 10 30
(%Requirements
impactofdefects) change/month)
Onanagileproject,thereisverylittleextrapaperwork Many 0 35
1
to produce. Most of the time is spent writing code or Lives Single
Life
Essential
Funds Discretionary
10
5

writing tests. Poor performers stand out in this climate20. Comfort 30

Funds 50

moresuitedforagile
Theprojectcangetawaywithfewerpeople,becausethere 3
90
issolittleextrapaperworktoproduce. 10
70

Onthe otherhand,there is a lot of paperwork to pro 30

50
duce in the average plandriven process. It is a waste to 100

have top programming talent doing paperwork, and so it 30

300 moresuitedforplandriven
makessensetohirelowerqualifiedpeopletodoit. Size
10
Culture
Referringtothemaslevel1(forbeginners)andlevel3 (#ofpersonnel) (%thrivingonchaosvs.order)

(for competent and experienced) people, we see the fol
lowing.
On an agile project, it is sensible to have a fewer
level1 to level3 people, 3:1 to 5:1 are ratios I have
seenworkwell.
On a plandriven project, it is advantageous to have
more level1 people, so perhaps between 5:1 to 8:1
couldmakesense.
BarryBoehmandRichTurnercapturethislineofthinking
intheirbook,BalancingAgilitywithDiscipline21 (Boehm
2003).RecapturedinFigure5'4.theyshowastarfishdia
gram withfive different characteristics ofa project situa
tion:
thenumberofpeoplebeingcoordinated
thecriticalityoftheproject
theratiooflevel1tolevel3peopletherate of re
quirementschange
the tolerance of the organization to change (see
alsoFigure5'5).
Thisstarfishdiagramlookscorrecttome,andIcommend
ittootherstostudy.
20
One of the objectionstotheagileapproachin some organizations is exactly
that the low performers get revealed so quickly. If those people have political
clout,thiscanbeenoughfortheorganizationtorejectanagileprocess.Sadly,as
humoristDaveBarrywrites,"Iamnotmakingthisup."
21
Itisanoddtitle.Agilityanddisciplinearenotoppositesto betradedagainst
each other see "Agile development is low in discipline " on page 34???.
Withinthebook,theyshifttothetermplandriven,which is better but still not
my preference see "Predictable, Plandriven and Other Centerings" on page
55???.Thosetermsaside, they give an outstanding presentation of the tension
betweenplanningandmoving,andtheneedforuseofthelargemiddleground.
Figure5'4. Starfishdiagramshowingtheshiftinghome
territoriesofagileandplandrivendevelopment,from
(Boehm2003).
Withrespect tothe question oflevel1 to level3 peo
ple,we might note an implicit assumption in that axis of
the diagram, that the organization is obliged to use all
thoselevel1people.That is,someone obliges theproject
managers to find ways to keep all those people busy. If
thatwerenotthecase,thenIwouldsuggesteitheroftwo
strategies:
Get rid of the extra level1 people and use an agile
processwiththereducedteamsize.
Useanagileprocesswiththesmallestnumberofpeo
plepossibletogetthejobdonelettherestofthepeo
ple do anything they want just so long as they don't
interferewiththeprogressofthedevelopmentteam.
Odd though this latter strategy sounds, I have met with
two project teams that did just that, and both recom
mended the strategy highly. They said that payroll costs
were fixed with respect to the number of people being
paid,buttheirspeedwashigherwithoutthelevel1people
slowingthemdown.Thisunusualstrategyillustratesgood
sense in playing the cooperative game, though perhaps a
perverse attitude toward the organization's personnel de
partment.
"Sowhatshouldwedo?"
Get some competent, experienced people. Work with
agilityandfocusinallcases.Improvetheteam'sspeedby
adding disciplined agile practices as the team can or is
willing.
"Agileisnew,old,failedanduntried"
Itiscommontoobjecttoanideabysayingthat it is "not
new"meaningthatithadbeentriedandfailedandsi

43
 Sw DevasaCooperativeGame page 44
multaneouslythatitisnewmeaningthatwedon'tknow
ifitworks.WhenIheartheseobjections,IthinkthatTom
Waitshastheonlycorrectanswer:

"It'snew,it'simproved,it'soldfashioned"
TomWaits,"StepRightUp"

Everyideaintheagilecanon has beentracedas farback

as the 1960s and even the 1950s22. We find incremental
development, collocation, pair programming, frequent
integration, testfirst development, customer interaction
andsoon.
As far as I can tell, good developers have long been
using these ideas, but weren't articulate about what they
were doing. I ran across one personal account (reference
lost,sorry)inwhichthe writersaidthat hewas sostruck
bythesillinessofthewaterfallstylemethodologiesbeing
published in the 1970s that he didn't see the need to re
spond. He assumed they would fall into oblivion from
their own weight, and was shocked when people contin
uedtoreferencethemseriously.
My theory is that agile approaches have always been
used,butdidnotshowamarketadvantageuntilthe1990s,
whenbusiness andtechnologywerechangingsofastthat
only the agile practitioners were delivering systems in
timetothemarket.Certainly,thatwasthecaseintheearly
1990s,whenIwasjuststartingtodebriefprojectsforthe
IBM Consulting Group in order to construct a methodol
ogy for objecttechnology projects. In those initial inter
views,there was averycleardividinglinebetweenthose
projectteamswhoweredeliveringprojectsandthosewho
weren't. Those who were delivering were following the
values and principles expressed almost ten years later in
theagilemanifesto.
Abetterwaytothinkoftheagilemanifestoisthatthe
manifestoauthors"cherrypicked"averysmallset topay
close attention to out of hundreds of possibly important
things,. We were asserting, in essence, that these few
itemsoutweighedtherest.
It is natural that the items we chose had been around
for a long time. What was new was that we bothered to
nameaparticularandcriticalcombination,andtherewere
certainnewwrinklesontheoldpracticestooffer.
Agileisnew,it'simproved,it'soldfashioned.

22
See, for example, Craig Larman's Agile and Iterative Development (Larman
2003???),andFredBrooksdescriptionof"growingsoftware"inhis "NoSilver
Bullet"article(Brooks1999???)

44
 Sw DevasaCooperativeGame
EvolutionoftheAgileMethodologies
Thepeoplewhowrotetheagilemanifestothinkandwork
in different ways, all at the Ri end of the scale (see the
ShuHaRi scale of skills development, pages ???). Writ
ing the manifesto, they were looking to find what was
common in their approaches and still preserve their right
to differ. The agile manifesto successfully locates com
monality across widely varying, strongminded people,
and does so in such a way that other Rilevel people can
findtheirownhomeandbeeffective.
Thathasbeen,andcontinues tobe good.What itsen
tailsisthatthereisnoagreeduponShuformofagile de
velopmentforbeginnerstofollow.
Indeed,as the onlineconversationbetweenJohnRusk
and Ilja Preu23 below points out, not specifying manda
toryShulevelpracticesiscoretotheagileapproach.Any
specific set of Shu practices would be fragile over time
andsituations.
John Rusk: As Alistair mentioned, the Manifesto is
the nonbranded resource. But, personally, because it
emphasizesvaluesratherthanpractices,Ididnotfind
ittobeanidealstartingpointforunderstandingAgile.
(Beginners want details, even if they can't handle
them!)TheManifesto made much moresenseto me
afterI'dlearntaboutseveralofthebrandedprocesses.
IljaPreu:Ithinkthereisadilemmaheretome,not
followingsomecookbook*is*attheheartofAgility.
And there's the dilemma: People just starting out need a
Shulevelstarterkit.Theagileexpertswantfinallynotto
be trapped by simplistic formulae. It's Russ Rufer's quip
again:"Wecan'tmakeone Shufitall."
Looking at the evolution of the agile methodologies,
we find a growing aversion to simple formulae and in
creasing attention to situationally specific strategies (not
accidentallyoneofthesixprinciplesintheDeclarationof
InterDependence).Sincemostofthebrandedagilemeth
odologiesareformulaicbynature,wefindagrowinguse
of unnamed methodologies, or even nonmethodology
methodologies (a contradiction in terms, I know, but it
reflectspeople'sdesiretobreakoutoffixedformulae).
Let's take a look at the methodology evolution since
2001,changesintesting,the modernagiletoolbox,anda
longoverduerecognitionofthespecialtyformerlyknown
as userinterface design. The evolution of the Crystal
familyofmethodologiesgetsitsownchapter.
23
http://groups.yahoo.com/group/crystalclear/message/586.Thanksto John and
Iljaforlettingmereproduceithere.
page 45
XPSecondedition
The first edition of Kent Beck's "Extreme Programming:
EmbraceChange"(Beck1999?)changedtheindustry.His
secondedition,producedjustfiveyearslater(Beck2004),
rockedtheXPcommunityasecondtime,butforadiffer
ent reason he reversed the strong position of the first
edition, making the practices optional, independent and
variable.
Inthefirstedition,hewrote:
"XP is a lightweight methodology for smallto
mediumsized teams developing software in the face
ofvagueorrapidlychangingrequirements."
The book contains a Shulevel description of XP. Kent
wassaying,"Hereisausefulbundleofpractices.Dothese
things and good things will happen." Beginners need a
Shulevelstarter kit, and the first edition served this pur
pose.
Over time, it became clear that project teams needed
differentcombinationsofXPandthingssimilarto,butnot
exactly,XP.Also,itturnedoutthatmanyofthepractices
standnicelyontheirown(important note:somepractices
donotstandontheirown,but depend onotherpractices:
aggressiverefactoring,forexample,relies oncomprehen
siveandautomatedunittests.)
Notethedifferenceinwritinginthesecondedition:
"XP is my attempt to reconcile humanity in my own
practice of software development and to share that
reconciliation."
Thebookcontainstwobigshifts.First,herejectstheidea
thatXPissomethingthatyoucanbein compliancewith.
It doesn't make sense to check, "Are you in compliance
with Kent's attempt to reconcile humanity in his own
practice of software development and sharing that recon
ciliation?"Hecorrectlynotesinthebookthatpeoplewho
areplayingintheextremewaywillrecognize eachother.
It will be evident to the people in the club who is in the
club.
Secondlyand moresignificantly,thesecond editionis
writtenat theRi level. It contains a number of important
things to consider, with the advice that every situation is
different and the practitioner will have to decide how
muchof eachidea,in what order,to apply to each situa
tion. As predicted by the ShuHaRi model and the di
lemma captured by Ilja Preu, this causes discomfort in
peoplelookingforaShuleveldescription.
Beginnerscanstillbenefit fromthefirsteditionofthe
book by using it as their starter kit as they grow in so
45
 Sw DevasaCooperativeGame
phistication, they can buy the second book and look for
waystomake adhocadjustments.
Scrum
Scrum provides a Shulevel description for a very small
setofpractices anda Rilevelavoidanceofwhat todo in
specific situations. Scrum tells people to think for them
selves.
Scrum can be summarized (but not executed) very
simply24:
Theteamandtheprojectsponsorscreateaprioritized
listofallthethingstheteamneedstodo.Thiscanbe
alistoftasksoralistoffeatures.Thisisknownasthe
productbacklog.
Each month,theteampulls off the top section of the
list, what they estimate to be one month's worth of
work.Theyexpandittoadetailedtasklist,calledthe
sprintbacklog.Theteampromisestodemoordeliver
theresultstothesponsorsattheendofthemonth.
Each day, the team meets facetoface for five to ten
minutestoupdateeachotherontheirstatusand what
roadblocksareslowingthem down.This is calledthe
dailystandupmeeting.
Oneparticularpersonisdesignatedthescrummaster.
Itisthisperson'sassignment toremove, orget some
one to remove, whatever roadblocks the team men
tionsinthestandupmeeting.
Scrum avoids saying how the team should develop their
software, but is adamant that the people act as mature
adultsinowningtheirworkandtaking care of problems.
Inthissense,itisanessentialdistillationoftheagileprin
ciples.
The importance of the first three elements of Scrum
listed above should be clear from the theory of software
development described all through this book. The fourth
pointdeservessomefurtherattention.
Scrum calls for a staff role, the scrum master, whose
purpose in life is to remove obstacles. Scrum is the only
methodologyIknowthattrainsitspractitionersintheidea
that success comes from removing obstacles and giving
thepeoplewhattheyneedtogettheirworkdone.
Thisideawasillustratedinthesection ontheCone of
Silence strategy. There, I described how a project went
from hopelessly behind schedule to ahead of schedule
fromthesingleact of movingtheleaddeveloperupstairs
andaroundafewcornersfromtherestoftheteam.Itwas
illustrated again in another conversation about another
project. A manager came up to me once to tell me how
wellScrumwasworkingforthem.
24
SeeKen Schwaber'stwobooks(Schwaber2002,Schwaber2004).
page 46
"Ourprojectwentfromfourmonthsatinitialestima
tion to delivering in just six weeks," he glowed at
me.
Since I know that Scrum contains nothing specific
thatwouldcausethatsortofajumpinproductivity,I
challenged him to tell me what happened in more
detail, and what caused the amazing change in
fortunes.
Hesaidthatatthedailystandupmeetings,thekey
programmerkeptsayinghewasbeingpulled away
severaltimesadaytofixbugsinothersystems.
Themanagerwenttoanexecutivehighenoughup
the management chain to be able to control both
projects' resources. He challenged the executive,
saying that he had been told this particular project
hadhigh priority, andthe programmer shouldn't be
pulledoutlikethis.Theexecutiveagreed.
The interruptions stopped. The key programmer,
freed from interruptions, sat down and completed
theprograminsixweeks.
It seems the fourmonth estimation was based on his ex
pectationofacertainlevelofinterruptions.Withoutinter
ruptions,he got done muchfaster(seethe project critical
successfactor,"Focus",onp.42???).
Remember, success is not generated by methodology
magic nearly so much as by giving the people what they
needtogettheirworkdone.
PragmaticandAnonymous
Andy Hunt and Dave Thomas, coauthors of the agile
manifesto and authors of The Pragmatic Programmer
(Hunt2003???),havebeendefendingthatitisnotprocess
but professional and "pragmatic" thinking that are at the
heartofsuccess.Theyaredefendingsituationallyspecific,
anonymous methodologies, properly referred to as ad
hoc25.
In the five years since the writing of the manifesto,
situationally specific methodologies have become more
thenormthantheexception.Agrowingnumberofteams
lookattherulesofXP,Scrum,Crystal,FDDandDSDM
and decidethat eachone insomefashiondoesn'tfit their
situation.Theyblendthemintheirownway.
The two questions that those teams get asked are: is
their blend agile, and is their blend effective? A bit of
thought reveals that the first question is not really mean
ingful,that it is only the second question that matters. In
25
HereIamusing adhoc withitsproperLatinmeaning:"forthesituation."Ad
hoc isnotsupposedtomean"notthoughtout."Weseetheimportanceof adhoc
strategiesthroughoutthebook,andtheDeclarationofInterDependenceexplic
itlycallsforsituationallyspecificstrategies.
46
 Sw DevasaCooperativeGame
manycases,theansweris,"moreeffectivethanwhatthey
weredoingbefore."
The alert reader is likely to ask at this point, What is
the difference between an anonymous, ad hoc methodol
ogyandCrystal,sinceCrystalsays totunethe methodol
ogytotheprojectandtheteam?Thisquestionleadstothe
question:Whatisthepointoffollowinganamedmethod
ologyatall?
A named methodology is important because it is the
methodology author's publicly proclaimed, considered
effort to identify a set of practices or conventions that
workwelltogether,and whendonetogether,increasethe
likelihoodofsuccess.
Thus,inXPfirstedition,KentBeckdidnotsay,"Pair
programming is a good thing do pair programming and
your project will have a good outcome." He said, "Pair
programming is part of a useful package this package,
whentakentogether,willproducea good outcome." Part
ofthedistresspeopleexperiencedwiththesecondedition
was that he took away his stamp of approval from any
particular packaging of the practices, leaving the con
structionofaparticularmixuptotheteam(inthis sense,
XP second edition becomes an ad hoc methodology).
Whatgotlostwasanyassuranceabouttheeffectsofadd
inganddroppingindividualpractices.
Crystalis myconsidered effort toconstruct a package
ofconventionsthatraisestheoddsofsuccess,andat the
same time the odds of being practiced over time. Even
thoughCrystalcallsfortailoring,Iput bounds onthetai
loring,identifyingtheplaceswhereIfeelthelikelihoodof
successdropsoffsuddenly.
When I look at people working with conventions
similarto Crystal's, the first thing I usually notice is that
theydon'treflectontheirworkhabitsverymuch.Without
reflection, they lose the opportunity to improve. (They
usually don't deliver the system very often and they usu
allydon'thaveverygoodtests,butthosecanbothbead
dressediftheyreflectseriously.)
Inotherwords,thereisadifferencebetweenageneric
adhocmethodologyandatailoringofCrystal.Ifeelthere
is enoughsignificancetonamingthe key issues to attend
to, and the dropoffs, to make the Crystal package worth
retainingasa named package. I include details of what I
have learned about the Crystal methodologies in Chapter
9?.
Ifyouwanttoknowifyourtailoringislikelytobeef
fective, read the list of practices in "Sweet spots and the
dropoff"(p.???)andinthetableshownin"Howagileare
you?"(p.???),andcomparewhereyourpracticesarewith
respecttothesweetspotsandthedropoffs.
Theaboveline ofthinkingsuggests that other authors
shouldcomeupwiththeirownrecommendationsforspe
page 47
cific sets of conventions or practices that improve some
aspectofateam'swork.
One such set that I find interesting, but has not yet
been published, was described by Lowell Lindstrom of
Oobaya Consulting. Lowell runs an endofiteration re
flection workshop that is more thorough than mine, and
which I intend to start using. His contains three specific
parts,coveringproduct,progressandprocess.Hecreatesa
flipchart for each and asks the team to reflect on each in
turn:
ReflectontheProduct:What didtheusers andspon
sors think about the product? What should be im
proved,what added, what removed, and what are the
priority directions for product evolution? This reflec
tiontopicaddressestheteam'sdirectionandpriorities,
keyforeverythingthatfollows.
Reflect on the Team's Progress: What did the team
memberssaytheywouldaccomplishduringthe itera
tion, and what did they accomplish? What does that
difference mean? What do they want to promise for
the next iteration? This reflection topic is subject to
changesindirectionfromthefirstreflectionquestion.
Reflect on the Team's Process: What worked well in
theworkingconventionsfromthelastcycle,andwhat
does the team want to try differently? This is the
Crystalreflectiontechnique(seep.???)andinCrystal
Clear(Cockburn2005CC)).Notethat what theteam
chooses to change depends on the changes identified
inbothproductandprogress.
Lindstrom's reflection package is a good addition to any
methodology. Combined with Scrum, it makes a good
starterkitforteamslookingtogetoutoftheShustageand
intothe Hastage.
Predictable,PlandrivenandOtherCenterings
The term "plandriven" was coined by Barry Boehm to
contrasttotheterm"agile".Tounderstandthetermandits
implications,weneedtolookat howthesesortsofterms
centerateam'sattention.
"Agility"is onlya declaration of priorities for the de
velopment team. It may not be what the organization
needs. The organization may prefer predictability, ac
countability, defectreduction or an atmosphere of fun26.
Eachof those priorities drives a different behavior in the
developmentteam,andnoneofthemisawrongpriorityin
itself.
26
At one university working on the human genome project, the students were
paid so little that the department only hoped that they wouldn't just quit. The
studentscould proposeany problemthey wantedto work on, chooseany tech
nology they wanted to use, set any work hours and methods that suited them.
They felt that having a "laid back" methodology was crucial to being able to
retaintheprogrammerstheyneeded.
47
 Sw DevasaCooperativeGame
Further,nomethodologyisinitselfagile(oranyofthe
other priorities). The implementation is what is or is not
agile.Thus,agroupmaydeclarethat theywishtobeag
ile,orwishtobepredictable,ordefectfree,orlaidback.
Onlytimewilltelliftheyactuallyare.Thus,anymethod
ology is at best "wouldbe agile", "wouldbe predictable"
andsoon27.
There is, therefore, no opposite to agile development,
any more than there is an opposite to jumping animals
(imaginebeingabiologistdecidingtospecializein "non
jumpinganimals").Saying"nonagiledevelopment"only
means having a top priority other than agility. But what
wouldtheprioritybeforalltheprojectstylesthattheagile
manifestowaswrittentocounteract?Noonehasbeenable
to get all those people in a room to decide where their
centerofattentionhasbeen.
Actually, agile is almost the wrong word. It describes
thementalcenteringneededfortheseprojects,butitdoes
n'thaveanearoppositecomparisonterm.Adaptivedoes.I
don'twishtosuggestthatagileshouldberenamed,andI
am careful to give a different meaning to adaptive meth
odologiescomparedtoagilemethodologies:
Forme,andforsomeofthepeopleatthewritingofthe
agile manifesto,agile meant beingresponsivetoshifting
system requirements and technology, while adaptive
meantbeingresponsivetoshiftingculturalrules.Wewere
discussingprimarilytheformeratthemanifestogathering.
Thus,XPfirsteditionwasagileandnotveryadaptive,
RUPwasadaptiveandnotveryagile,andCrystalandXP
secondeditionarebothagileandadaptive.Inthelastfive
years, being adaptive has been seen as so valuable that
mostpeoplenowconsiderbeingadaptiveaspartofbeing
agile.
Using the word adaptive for a moment allows us to
lookatitsnearoppositecomparisonterm: predictable.
Inmyview,thepurposeofthatotherwayof working
wastoprovide predictabilityinsoftwaredevelopment28.
Wecan sensibly compare processes aimed at increas
ingpredictabilitywiththoseaimedatincreasingadaptive
ness to changing requirements, and we can see what we
might want from each. However, although some of us
mighthavepreferredtheword'predictable',BarryBoehm
chose'plandriven'forthoseprocesses.
Iearlier ("Agile only works with the best developers"
on p. 55???) described some the work that Barry Boehm
andRichTurnerhavebeen doing withpartiallyagileand
27
Formoreonthis,see"AgileJoinsthe'WouldBeCrowd,"Cockburnwouldbe
2003???
28
There is even dissention about how to provide predictability. Many agilists
claim that the agile approach confers greater predictability. The difference in
viewsisdiscussedindetailinthesectionon"BuyInformationorFlexibility"in
"LearningfromAgileDevelopment"(Cockburn2002.10 crosstalk).
page 48
partially plandriven projects (Boehm 2002???, Boehm
2003???).Figure5'6showsanother.
Figure5'6shows that foreachproject, there is a cer
tain type and amount of damage that accrues from not
doingenoughplanning(havingaspacestationexplodeis
agoodexample).Thereisalsoacertaintypeandamount
of damage that accrues from doing too much planning
(losingmarketshareduringthebrowserwarsofthe1990s
isagoodexample).
over/underplanning
Damagefrom
Plandriven
sweetspot
Agile
sweetspot
TimeandEffortInvestedinPlans
Figure5'6.Differentprojectscallfordifferentamounts
ofplanning(afterBoehm2002,2003)
Figure 5'6 shows that the agile approach has a sweet
spot insituations in which overplanning has a high dam
ageandunderplanning doesn't. The plandriven approach
hasasweetspotwhenthereverseistrue.Thefigurehints
that there are situations in the middle that call for a
blendingofpriorities.This matches therecommendations
inthisbookandtheDeclarationofInterDependence.
In the time since the writing of the agile manifesto,
people have been working to understand the blending of
the two. Watch over time as more plandriven organiza
tions find ways toblendtheagile ideas intotheirprocess
togetsomeofitsbenefits.
TheoryofConstraints
Goldratt's"theoryofconstraints"hasbeenbeingexamined
among agile developers. Three threads from Goldratt's
writingdeservementionhere.
Theimportanceofthebottleneckstation
Inthebook TheGoal (Goldratt1985),Goldrattdescribesa
manufacturing situation in which the performance of a
factoryislimitedbyonestation.Heshowsthatimproving
efficiencyat the otherstations is awasteof money while
thatoneisstillthebottleneck.Heendswiththepointthat
as the team improves that one station, sooner or later it
stopsbeingthebottleneck,andatthatmoment,improving
itanyfurtherisawasteofmoney.
48
 Sw DevasaCooperativeGame
Ihavefound a fruitful line of inquiry to consider that
one can "spend" efficiency at the other, nonbottleneck
stationstoimproveoverallsystemoutput.Thissurprising
corollaryisdescribedinmoredetailonpages???and???
ofthisbook,andin(CockburnICAM2005???).
Fewmanagersbothertounderstandwheretheirbottle
neckreallyis inthefirstplace,sotheyaretakingadvan
tageofneitherthemainresultnorthecorollary.
Thetheoryofconstraints(TOC)
TheTOC(goldratt19??)isverygeneral.Itsays:
Locatewhateveristheconstraintorbottleneck.
Target all efforts at improving the efficiency at the
constraintpoint.
Maximize the utilization of the available capacity
intheconstraint
Dont make it do work that wont produce
throughput29
Donthaveitidleforanyotherreason
Invest in and increase the capacity of the con
straint.
Improvethatareasothatitisnolongertheconstraint.
Atthatmoment,theconstraintissomewhereelse,and
thecycleofworkstartsover.
Itisnotsomuchthesimplestatement oftheTOC thatis
interesting, but all the special solutions being catalogued
fordifferent situations. A web search for "theory of con
straints"anditsconferences willturnupmoreusefulref
erences than I can provide here. David Anderson pre
sentedacasestudyofapplyingthetheoryofconstraintsto
software development in "From Worst to Best in 9
Months"(Anderson2005).
Criticalchainprojectmanagement.
Goldratt's"criticalchain"(Goldratt2001cchain)is more
controversial. "Controversial" in this case means that I
think it is hazardous, even though it has backing in the
TOCcommunity.HereiswhyIworryaboutit.
Thecriticalchainideasays to start by making a task
dependency network that includes also names of people
whowillbecomeconstraintsthemselves.
Forexample, in most software projects, the team lead
usually getsassignedthe mostdifficult jobs, but also has
tosit inthe most meetings,and also does the most train
ing.AnormalPERTchartdoesnotshowthisaddedload,
andsoitiseasytocreateascheduleinwhichthis person
needs to be in multiple places at once. Putting the team
lead's name on the tasks, and putting that person's tasks
29
Paul Oldfield notes the interesting contradiction between this point and the
needforworkersto"sharpenthesaw":upgradingtheirskills,recuperating,and
reflectingontheirworkpractices.I notethatpractitioners oftheleanapproach
take"sharpeningthesaw"veryseriously.
page 49
into a linear sequence produces a truer schedule (and an
unacceptablylongone,usually!).Onecanquicklyseethat
theschedule improves as theload gets removed from the
teamlead,evenwhenthetasksareassignedtopeopleless
qualified.Sofar,thisisasimpleapplicationofTOC.
Second (and here is the controversial part), ask the
people on the team to estimate the length of each task,
thencut each estimateintotwohalves.Leave one half in
place as the new estimate of the task duration, cut the
otherhalfinhalfandputthatquarterintoasingleslippage
buffer at the end of the project. Discard the remaining
quarter as "time saved" from the people's original esti
mate.
The thinking is that if people are given the shortened
lengthoftimetodotheirwork,theywillsometimes meet
thattargetandsometimesnot,inastatisticalfashion.The
buffer at the end serves to catch the times they are not.
Since not every task will need its full duration, the end
buffercanbehalfoftheoriginal.
The hope is that people tend to pad their estimates to
show when they can be "safely" done. Having once pad
ded the estimate, they have no incentive to get the work
doneearly,andsowilltakeupmoretimethantheystrictly
needtogetthetaskdone.Bycuttingthe estimateinhalf,
theyhaveincentivetogoasfastastheycan.Bykeepinga
quarter of the time estimate in the slippage buffer, the
project has protection against a normal number of things
goingwrong.
Where I find the above thinking hazardous is that it
touches upon a common human weakness, being very
easy to abuse from the management side. Indeed, in the
onlytwoprojectsthatIfoundtointerviewabouttheiruse
ofthistechnique,theybothfellintothetrap.
The trap is that managers are used to treating the
schedule as a promise not to be exceeded. But in critical
chainplanning,theteammembersarenot supposedtobe
penalized for exceeding the cutinhalf schedule after
all,itgotcutinhalffromwhattheyhadestimated,onthe
basis that about half the tasks will exceed the schedule.
Criticalchainrelies onhaving enlightened managers who
understand this and don't penalize the workers for ex
ceedingthehalvedtimeestimates.
Mysuspicionisthatifthepeopleknowthattheiresti
mates willget cut inhalf,andtheywillget penalizedfor
takinglongerthanthat half,thenthey will doublethe es
timate before turning it in, removing any benefit that the
buffer planning method might have offered. If they don't
double their estimates, there is a good chance that they
will,infact,get penalizedfortaking longer than the cut
inhalfestimate.
That is exactly what I found in the first critical chain
interview. The project manager on this fixedtime, fixed
49
 Sw DevasaCooperativeGame
pricecontracthaddonethePERTchart,cutthe estimates
in half and created the slippage buffers as required, and
managed the work on the critical path very closely. He
wasveryproudoftheirresulttheyhadnever hadto dip
intotheirslippagebufferatall!
Ihopeyoucanseetheproblemhere.Hehadgottenhis
developerstocuttheirestimatesinhalf,andthenhadrid
den them through weekends and overtime so that they
would meet all of their cutinhalf estimates without
touchingtheslippagebuffer.Hewasproudofnotdipping
intothebuffers,eventhoughcriticalchaintheorysaysthat
he should have dipped into those buffers about half the
time.Missingthepointofthemethod,heandhisdevelop
ershadallsuffered.
Thecompanyexecutivesweredelightedatdeliveringa
fixedpricecontractin3/4ofthetimeestimated.Afterall,
they turned an unexpected extra 25% profit on that con
tract.Thesadpartwas that they gave no bonuses for the
overtimeputinbytheprojectmanagerandtheteam.This
is what I mean by critical chain touching upon common
human weaknesses. I suspect the developers will double
theirestimatesforthenextprojects.
Ifyouaregoingtousethecriticalchaintechnique,be
sure to track work time in hours, not days or weeks.
Tracking indays andweeks hides overtime work. Track
inginhourskeepsthetimeaccountingcorrect.Iftheman
ager in the previous story had scheduled and tracked in
hours, he would have had to use those buffers as critical
chaintheorysaysheshould.
The above doesn't mean that critical chain doesn't
work,onlythat it easyto misuse. I suspect it only works
properly in a wellbehaved, hightrust environment, and
willceaseto workas soonas it startsto be misused, and
peoplegamethesystem.
LeanDevelopment
Agiledevelopershavebeenstudyingthelessonsfromlean
manufacturingtounderstandstrategies in sequencing and
stackingdecisions.Thiswasdiscussedin"Reconstructing
SoftwareEngineering"(p.???).
As a reminder, inventory in manufacturing matches
unvalidated decisions in product design. When the cus
tomerrequestsafeature,wedon'tactuallyknowthatitisa
useful feature. When the architect or senior designer cre
atesadesign decision,we don'tactually knowthat it is a
correct or useful design decision. When the programmer
writessomecode,wedon'tknowthatitiscorrectoreven
usefulcode.
The decisions stackupbetweentheuserandthe busi
ness analyst, the business analyst and designer
programmer,thedesignerprogrammerandthetester,and
thetesterandthedeploymentperson(seeFigures22and
page 50
23). In each case, the more decisions are stacked up the
greatertheuncertaintyindeliveryofthesystem.
Kent Beck drew a graph (Figure 5'7) that shows the
way that decisions stack up as the delivery interval gets
longer.Hedrewitonalogscaletocapturethetimescales
involved. To understand it, imagine a project in which a
request shows up in the morning, gets designed, pro
grammed, tested within 24 hours. Let this be the unit
measureofdecisiondelay.
Daysofwork
notyetinproduction
5yearwaterfall(e.g.military)project=1,200days
1000
3yearwaterfallproject =720days
100
Quarterlyincrementalreleases=65days
3weekiterations(XP) =15days
10
1 Dailyrelease(SwissXPproject)
0.1 (whatwouldthismean?)
Figure5'7.Decision"inventory"shownonsoftware
projectsofdifferenttypes(thankstoKentBeck).
Theproblem,ashisdrawingcaptures,isthatthespon
sors of a fiveyear waterfall project are paying for thou
sands of times more decisions and not getting validation
orrecoveringtheircostsonthosedecisions,forfiveyears.
Theappropriateness(whichistosay,thequality)ofthose
decisions decays over time, as business and technology
change. This means that the value of the investment de
cays.Thesponsorsareholdingtheinventorycosts,losing
returnoninvestment(ROI).
Asthedelayshrinks,fromrequesttodelivery,ROIin
creases because inventory costs drop, the decisions are
validated (or invalidated!) sooner, and the organization
can start getting business value from the decisions
sooner30. Kent's graph shows how quickly the queue size
increasesasthedeliverycyclelengthens.
Oneofthelessonsfromleanmanufacturingistoshrink
thequeuesizebetweenworkstations.Thetargetistohave
singlepiece,orcontinuousflow.It is noaccident that the
firstprincipleintheDeclarationofInterDependenceis
"We increase return on investment by making con
tinuousflowofvalueourfocus."
Figure5'7alsoshowstherelationshipbetweenthequeue
size and delay. In software development, we can't easily
see the size of the decision queue. However, the size of
30
This line of reasoning is spelled out in great detail and in ways accounting
managerscanunderstandin SoftwarebyNumbers (???ref???).
50
 Sw DevasaCooperativeGame
thequeueisproportionaltothedelay,andwecanmeasure
thedelay.
Figure 5'8 shows how queue size and its analog, de
lay, can be used in managing a software project. It plots
the work completed by each specialist. In this sort of a
graph, a cumulative flow graph, the queue size corre
spondstoverticalsizeinanyshadedarea,andthedelayto
the horizontal size in the same shaded area. If you don't
knowhowtomeasurethenumberofitemsinyourqueue,
measure the length of time that decisions stay in your
queues.
Figure5'8.Cumulativeflowgraphforasoftwareproject
usedtotrackpipelinedelayandqueuesize(Anderson
borcon).Theoriginalcaptionwas"CFDshowinglead
timefallasaresultofreducedWIP"[WIP=workinpro
gress]
DavidAndersondescribesthesegraphsinhisbookand
experience reports (Anderson 2003???, Anderson 2004).
He and others have built software development tracking
tools that show the number of features in requirements
analysis, in design, and in test, so that the team can see
whattheirqueuesizeanddelaysare.Davidwritesthatas
of2006,"managingwithcumulativeflowdiagramsis the
defaultmanagementtechniqueinMicrosoftMSFmethod
ology shipped with Visual Studio Team System and the
cumulativeflow diagram is a standard out of the box re
portwithVisualStudioTeamSystem."
Queue sizes are what most people associate with lean
manufacturing,but therearetwo morekey lessons to ex
tract. Actually, there are certainly more lessons to learn.
ReadThe Machine that Changed the World (sss yyy???)
andToyota ProductionSystem(xxxyyy???)to start your
owninvestigation.HerearethetwoIhaveselected:
NewMethodologyTopics
page 51
Crosstraining. Staff at lean manufacturing lines are
crosstrained at adjacent stations. That way, when inven
tory grows at a handoff point, both upstream and down
stream workers can pitch in to handle that local bump in
queue size. Agile development teams also try to cross
train their developers and testers, or at least sit them to
gether.
One of the stranger obstacles to using agile software
development techniques is the personnel department. In
morethan one organization that I have visited, personnel
regulations prevented a business analyst from doing any
coding or testing. That means that the business analysts
are not allowed to prototype their user interfaces using
Macromedia's Dreamweaver product, because Dream
weaver generates code from the prototyped UI, nor are
they allowed to specify their business rules using FIT
(Ward Cunningham's Framework for Integrated Tests),
becausethatcountedaswritingtestcases.
It is cleartothe employees inthese organizations that
therulesslowdownthecompany.However,evenwiththe
bestof will,theydon't havethe politcal power to change
therules(thusillustratingJimHighsmith'scorollarytothe
agile catchphrase, "People trump process." Jim follows
thatwith:"Politicstrumppeople").
"We'reallus,includingcustomersandsuppliers".The
agile manifesto points to "customer collaboration." Lean
organizationsextendthe"us"grouptoincludethesupplier
chainandtheendpurchaser.
One (unfortunately, only one) agile project team told
methattheywhentheyhiredanexternalcontractsupplier
to write subsystem software for them, they wrote the ac
ceptancetests aspartoftherequirementspackage (incre
mentally, of course). It saved the main project team en
ergy.They had extremely low defect rates, with an aver
age time to repair a field defect less than one day. They
suspected that the subcontractor's testing procedures
wouldn'tbeuptotheirstandards.Bytakingonthemselves
the burden of creating the tests they needed, the subcon
tractor wouldn't waste their time shipping them buggy
code,thedefectsinwhichthey wouldhavetofirstdetect
and then argue over with the subcontractors. This alone
madeit worththeirtimeto writethetests themselves.Of
course, it simplified the life of the subcontractors, since
theydidn'thavetowritetheacceptancetests.
Their story is a good start,but only hints at what can
happenwhentheentiresupplychainis"us".
51
 Sw DevasaCooperativeGame
This section is for discussing the evolution of project
management, testing, userinterface design, project gov
ernance,andrequirementsgathering.
Agileprojectmanagement
I earlier discussed the myth, "We don't need no *%@!
managers!"(p.50???).Evenwithaselfmoderatingteam,
there is still a role for someone to monitor and enhance
focus, community, amicability, personal safety and com
munications within the team to give the project good
visibility to the sponsors and to secure directional deci
sions and funding from them and to keep distractions
awayfromtheteam(seeFigure5'3???).
However,thereisstillakerneloftruthintheideathat
theprojectmanager'sroleisshifted,ifnotreduced,inag
ile development. Good agile teams develop their plans
jointly, present their status visibly and publicly, and in
general have a better understanding of themselves as a
mutuallydependentcommunity.
Since the writing of the manifesto, some excellent
books have appeared on project management in the agile
context.Theseareallexcellentbooks:
AgileProjectManagement(Highsmith2004),
ManagingAgileProjects(Augustine2005),and
eXtremeProjectManagement(DeCarlo2004)
allhighlightthehumanaspectsofmanaging.
AgileManagement for Software Engineering (Ander
son 2003) incorporates lessons from the theory of
constraints(seepage62???).
Agile Project Management with Scrum (Schwaber
2004)coverstheScrumview.
Agile and extreme project management have even
been entered as specific categories starting with the
2003 third edition of Wysocki's Effective Project
Management:Traditional,Adaptive,Extreme.
From outside the circle of agile and software project
managers,Laufer's(1997)SimultaneousManagement
is based onwork primarily on civil engineering proj
ects, but with the same thoughts, recommendations
andstrategiesasthosecomingfromtheagileworld.
Anumberofpeoplefeltthatthediscussionofhowtolead
agileprojectswas being missed inthefervorsurrounding
theagile manifesto.This includedJim Highsmithandme
asagilemanifestoauthors,plusoveradozenotherexperts
in product development, project management, and line
management. Over a sixmonth period, we worked on a
followontotheagile manifesto that would carry over to
nonsoftwareprojects,andalsotoproduct (as opposed to
project)management.
page 52
The result was published in January of 2005, and
calledthe"DeclarationofInterDependence31"orDOI.
TheDOIwaswrittentofitselfmanagedteamsaswell
as hierarchically managed teams. It is aimed at develop
mentteamsoutsideandinsidesoftwaredevelopment,and
for product development as well as project management.
Anyonereadingitwillimmediatelydetectthatitprovides
good guidelines for line management as well as project
management.Itcontainsthethingsweexpectfromanag
ilemindset:payingattentiontoworkersashumanbeings,
using short feedback loops and situationally specific
strategies.
The DOI is described in detail in Appendix C. Ex
tended support and discussion surrounding the DOI is
provided by a nonprofit group called the Agile Project
LeadershipNetwork32 (APLN).
Testing
The newesttopicinagile methodologies is the growth of
automated testing and testdriven development as core
practices.Hereagain,XPhasbeentheleader.
Five years ago I felt that automated testing was not a
criticalproject success factor.However, it becomes more
critical as project teams shorten their iterations, work in
crementallyandrefactormoreoften.
Here is an example: A person in one of my classes
asked me how to get started with agile development. I
suggestedthathepickanyprojecthewasworkingon,and
shift to a oneweek iteration and delivery cycle just for
one ortwo weeks.In each week,justforthetrialrun, he
shouldtakeanewrequirement,designandprogramit,test
andintegrateit,anddeployittosomeuserworkstation.
The person said he was immediately stuck. On his
project, the testing would take two days alone, so he
wouldhaveonlythreedaystodorequirements,designand
coding.Hecouldn'tdoaoneweekiteration.Itwasatthat
pointthatIrecognizedthatautomatedtestinghadbecome
criticaltoagilepractices.
Inproject visits,Ifindpeople havingtrouble with de
veloping in increments, with integrating with other peo
ple'scode, and with refactoring, issues that would not be
problemsiftheyhadautomatedtestsuites:.
Tomakethecreationoftestsmorepalatableandacces
sible to users, customers and business analysts, Ward
Cunningham created the Framework for Integrated Test
ing (FIT)33. It allows people to specify input and outputs
in a spreadsheet or HTML file, and to hook those quite
simply to the application under development. Using FIT
oritsrelative,FITnesse,businessanalystscanwritefewer
31
http://pmdoi.org
32
http://apln.org
33
Seehttp://fit.org,http://fitnesse.org
52
 Sw DevasaCooperativeGame
specification documents, replacing those with user
readable specification tests. This shift supports the agile
manifestovalue ofrunningsoftware overdocuments (see
"HexagonalArchitectureExplained"(Cockburn2004z/??)
foramoredetaileddescriptionofcreatingasystemarchi
tecturethataccommodatesFIT).
Testdriven development (TDD) started as a way just
to make sure that developers wrote unit tests at all. Its
practitionersfoundthatwhentheythoughtcarefullyabout
theteststheywerewritingoneatatime,andhowtomake
eachtestpassjustafteritwas written,theycameupwith
different designs than they expected. They were simpler,
cleaner,andeasiertochange.TDDhasbecomeoneofthe
toprecommendationsfordevelopingnewcode.
Inabitofirony,TDDcoaches findtheyhavetofight
against the "test" implications of the term they write
teststohelpthemdesign,butresistantdevelopersonlysee
thereferencetotesting.Anumberofalternativeacronyms
arebeingsuggestedtoreducetheassociationwithtesting.
My favorite is XXD (eXecutable eXample), pronounced
"DosEquisdrivendevelopment"34.
UserExperienceDesign
Topdesignersoftheexternallyvisiblesideofasoftware
systemnolongerconsiderthemselvesdesignersofmerely
the "user interface", but of the "user experience." In
keeping with their choice of words, I will refer here to
user experience (UX) design rather than user interface
(UI)design35.
UX designers have largely been resisting the fine
grainedincremental development policies oftheagilede
velopers.Manysaytheyneed to collect most of their in
formation before they can design a coherent user experi
ence or interface. They say that if they are forced to de
veloptheUXpiecemeal,theresultwillbeclumsy.
There is much to be said for this position. However,
many projects don't have a timeline that supports gather
ingsomuchinformationbeforestartingdevelopment.
A second group of UX designers argue that the low
precisionUXmodelcanbecreatedinamatterofdays,not
months, and so incremental development can be applied.
Jeff Patton argues for this view, and has published tech
34
Notaccidentally, "DosEquis," Spanish for "two X's," is the name of a top
Mexicanbeer.Thanksto KentMcDonald,JamesShoreandJeffry Fredrick for
helpingcomeupwiththisgreatterm!
35
Thislittle bit of title inflation is due to the watering down of the title "user
interfacedesigner"attheturnofthemillennium.Mostorganizations gave(still
give)thattitletopeoplewhohaveneithertalentnortraininginthespecialty.As
areaction,trueUXdesignersrefusetobeclassifiedas"mere"UIdesigners.This
is a shame in all directions. One the one hand, UI design should refer to all
aspects of appearance and use, not just the text or colors. At the same time,
companies find people with talent in this specialty and should develop their
skillsinit.
page 53
niques to support rapid UX design with incremental de
velopment (Patton 2004, Patton 2005a, Patton 2005b).
Holzblatt and XXX have created a "rapid" form of their
contextualdesigntechniquetosupport thesame develop
mentstyle(Holzblatt2003?).
The UXquestionis complicatedbecause the field has
notsortedouthowmuchneedstobedoneinadvanceand
whatcanbedoneincrementally,onthefly.Itisclearthat
changing the user interface with each deployment causes
users discomfort. That argues for at least some upfront
design. It some cases, people have shown that a broad,
lowprecisiondesignsufficesandsomescreen details can
becreatedincrementallyovertime.
We can use the cooperative game model and lean
manufacturingprinciplestohelpunderstandwhatisgoing
onhereandhowtocreateastrategy.Herearetheissuesat
play:
Users will get upset if the design changes too often.
That speaks for creating a broad user model early,
evenifthedetailsareworkedoutincrementally.
ThereisadependencybetweentheUXdesignersand
the programmers. The programmers can't program a
function until the UX designers understand what the
functionshouldbe.Plus,thereisatimelagfromwhen
theUXdesignersgettheirinformationandwhenthey
make their recommendations. If they have a broad
user base and show their designs to the users several
timestorefineit,thenthistimelagcanbequitelarge,
oftenontheorderofamonth.
Neitherofthetwoextremesislikelytobeagoodstrategy.
In some organizations the UX team drives the timeline,
and insist on getting their design "correct and complete"
beforeinterfacing withtheprogrammers.This hurtsthem
in two ways. First, the project is so delayed that quite
likelytheuserrequests willhavechangedbeforethesys
tem is developed (it was a correct UX design, but no
longer is a correct one). Second, the programmers are
likely to raise valid issues that cause changes to the UX
design.
In some organizations, wouldbe agile programmers
drivethe timeline, and insist that the UX design be done
incrementallyintwoweekiterations,simultaneouslywith
programming. The UX designers complain that there is
not time to research their users, create a design and pro
gramit withinthetwoweekwindow.Constantly encoun
tering new user situations, they have trouble creating a
consistentusermodel.
Balance the need for lead time with the timing of the
incremental development to get a consistent big picture.
Strategize about what those lead times are, how much
concurrencycanbe employedbetween UX designers and
programmers,andhowmuchneedstobelaiddowninone
53
 Sw DevasaCooperativeGame page 54
single,initialdesigntocreateaconsistentuserexperience. was scheduled for 1 workmonth on a 100 work
Wherepossible,usethehexagonalarchitecture(Cockburn monthproject,butreallytook2workmonthstocom
???) to decouple the system functions from the presenta plete, credit the team with 1% growth in "earned
tionofthosefunctions. value"onthegraph.
Alertreaderswillnoticethatatthispoint wehaveleft A similar pair of lines are created for the financial side,
the realm of methodologies and entering the realm of using expected and actual costs per task. They show the
project management strategies. What I hope is that the rateatwhichtheprojectisburningthroughthebudget.
teamwilldiscuss thetensionbetweenoverallconsistency The literature on earnedvalue charts is full of four
and incremental development, and pay attention to the letteracronymsstandingfortheworkestimated,thework
leadtimes required between the users, the UX designers, completed, the difference between the two, and so on.
and the programmers. Then experiment, reflect, and ad Whatisimportanthereisthattheearnedvaluegraphpro
just. vides one way of seeing at a glance the actual speed of
ProgramGovernance,BurnCharts,and movement.
Expectedcomplete...
SystemsEngineering Module10designed
...afterQ4 100%functionalitydesigned
Agile development is sometimes rejected out of cultural ...afterQ3
Module9designed
reasons.Onesuchculturalmismatchiswithsystemsengi Module8designed
Module7designed
neering, which deals with the design and construction of ...afterQ2
Module6designed
large systems, usually with mechanical, hardware and Module5designed
...now ExpectedCompletenow
softwarecomponents.Systems engineers typically accuse Module4designed
Completenow
agiledevelopersofbeingsloppyintheirthinking. ...afterQ1 Module3designed
Therearetworealdifficultiesinapplyingagileprinci Module2designed
Module1designed
plestotypicalsystemsengineeringprojects:
Since the systems contain mechanical and hardware Jan Feb Mar Apr May Jun Jul Aug Sep Oct

components,thefeedbacktimefrom designtoimple Figure5'9.Sampleearnedvaluechart(showingprogress

mentationtoevaluationislongerthanwithsoftware. lines,notfinanciallines).
The projects are typically large and contain multiple
layers of subcontractors, and so it is extremely diffi Figure5'9showsaseriesofdesigntasksforasystem
culttogetrealusersorcustomerstoviewthegrowing consistingoftenmodules.Themonthsare markedonthe
system. horizontal axis with small triangles. The fat dashed gray
lineshowstheexpecteddesignschedule,theshorter,solid
Itwasthereforearealtreattodiscoveronepoint ofnear
black line shows the actual progress made to date. The
commonality that helps bridge the culture and communi
verticalaxisshow%progressupto100%.
cations gapbetweenthetwo worlds.That is the "earned
value" chart in the systems engineering world and the I have added one thing to the normal earnedvalue
"burnup"chartintheagileworld. chart in order to set up the discussion on governance
comingupshortly.Theverticalaxis inFigure5'9shows
Hereis a simplified explanation of creating an earned
whatshouldbecompletedattheendofeachquarter,what
value chart, to show how it fits with the agile burnup
shouldbecompletedbytoday'sdate,andwhat is actually
charts(asimplewebsearchwillturnupmanytutorialson
completedattoday'sdate.Thisprojectiongivesanexecu
thesubject).
tivesummaryoftheproject status,without the details of
Writedownandsequenceallthetasksthatneedtobe theexactitemsbeingworkedon.It shows theanticipated
done. relativeprogress expectedbyquarter and where the team
Estimatehowlongeachwilltake.This numberis the is now compared to where it should be. We shall make
"value"ofthetask.Itisnot"value"inamarketvalue moreuseofthisprojectionshortly.
sense, but rather in the sense that completing that
piece of work brings the project that much closer to
completion.
Usingthesequenceandtime estimate,graphtheesti
matedtaskrateonagraphwithtimehorizontallyand
completiontoward100%vertically(seeFigure5'9).
As each task completes, no matter how long it actu
allytook,credittheprojectwiththescheduledamount
of valueforhavingcompletedthe work.That is, if it

54
 Sw DevasaCooperativeGame
Expectedcomplete...
...afterQ4 100%functionalityintegrated Module10designed
Module9integrated
...afterQ3
Module8integrated
Module7integrated
...afterQ2
Module6integrated
...now ExpectedCompletenow
Module5integrated
Completenow Module4integrated
...afterQ1 Module3integrated
Module2integrated
Module1integrated
Jan Feb Mar Apr May Jun Jul Aug Sep Oct
Figure5'10.Equivalentburnupchart.
Here is the matching simplified description of how to
createaburnupchart.
Write down and sequence all the system features or
functionthatneedtobedeveloped.
Estimatehowlongit willtaketo design,develop,in
tegrateandtesteachfeatureorfunction.This number
isthe"value"ofthetask.Itisnot"value"inamarket
value sense, but rather in the sense that completing
thatpieceofworkbringstheprojectthatmuchcloser
tocompletion.
Usingthesequenceandtime estimate,graphtheesti
matedcompletionrate on a graph with time horizon
tallyandcompletiontoward100%vertically(seeFig
ure5'10).
As each feature or function gets completed and inte
grated,nomatterhowlongitactuallytook,credit the
projectwiththescheduledamountofvalueforhaving
completedthework.Thatis,ifitwasscheduledfor1
workmonth on a 100 workmonth project, but really
took2workmonthstocomplete,credittheteamwith
1%growthin"earnedvalue"onthegraph.
Asimilarpairoflinescanbecreatedforthefinancialside,
usingexpectedandactualcostperintegratedfeatureset.
ItisnoaccidentthatIcopiedthetextfromthedescrip
tionoftheearnedvaluechart,northatthetwographslook
almost identical. The point I wish to make is that the
earnedvalue chart in systems engineering can be con
vertedtoaburnupchartintheagileworldassoonasone
(very significant) change is made: No credit is given to
completingrequirements, design or programming!Credit
accrues only when the function or feature is integrated
into the body of the system and passes testing. This is a
much morereliable markerofprogress than merely com
pleting a paper design. It also requires the use of incre
mentaldevelopment.
Several other people have written about burn charts
and earned value charts. See, for example, John Rusk's
"AgileCharts"(Ruskurl),GlenAlleman's"MakingAgile
Development Work in a Government Contracting Envi
page 55
ronment" (Alleman 2003), and Mike Cohn's Agile Esti
matingandPlanning (Cohn2005).
Few people notice that the value that gets granted is
notthemarketvalueofthefeatureorfunctionbutonlyits
estimated completion cost. In this sense, it is not "value"
at all, it is "cost". Some (rare) teams are working with
their users and sponsors to assign market values to each
featureorfeaturecluster.Doingthis makesveryclearthe
difference between something that takes a long time to
develop,andsomethingthatisvaluabletodevelop.Where
they can do this, those teams are able to create true
"earnedvalue"charts.
AGovernanceView
"Programgovernance"referstoasteeringgroupofevalu
ators who meet periodicallyto watch overanset of proj
ects, or "program" in systems engineering jargon. When
thesteeringcommitteegetstogethermonthlyorquarterly,
theyhavealotofdatatosortthrough.Whattheyneedisa
quickwaytoseethestatusofeachproject andspot what
needsattention.
Theverticalaxisprojectionontheburnupchartshows
the information in an efficient way, and has the remark
ablepropertythatitcanbeusedforbothincrementaland
waterfallprojects.
Figure5'11shows howtoget fromthe burnup chart
to a very compressed rendering of the project's predicted
schedule and current status. Figure 5'11(a) shows the
verticalaxistakenfromFigure5'10.
(Twonotesareinorderbeforecontinuingwiththede
scriptionofFigure5'11:First,Ichosea12monthperiod
because it is common period and it makes the quarterly
marks come out tidily. Second, I chose to show percent
complete. I could have chosen to show number of use
cases,numberoffunctionpoints,ornumberofuserstories
instead. Which to use depends on who you are showing
themtoandwhatyouwouldliketoshow.)
Expectedcomplete...
...afterQ4(100%) Q4
...afterQ3
Q3
...afterQ2 Q2
...now now?
Actuallycompletenow
now
...afterQ1 Q1
(a) (b)
55
 Sw DevasaCooperativeGame
Figure5'11.Theverticalaxisoftheburnupchartcon
vertstoacompressedviewofprojectstatus.
Just to the left of the "expected complete" arrows of
Figure5'11(a)isacompressedrenderingofthesame in
formation.Thetenlittletickmarksplacedverticallymark
out 10% complete steps up to the 100% complete mark.
The hollow triangle marks the amount of functionality
expectedtobecompletebytheendofthefourthandfinal
quarter (it is, of course, at 100%). The three other black
triangles marktheamountof functionality expected to be
completelyintegratedattheendofquartersone,two,and
three,respectively.Notethat the existence of the triangle
marks the time value (Q1, Q2, Q3, Q4), and the vertical
placementofthetrianglemarkstheamountoffunctional
itycompleted.
The amount of functionality expected to be complete
"now" is shown by the placement of a longer horizontal
line.Thislinemovesupwardcontinuallyas thetime flies
throughtheyear.
Theamount offunctionalityactuallycompleted"now"
is show by the shaded thermometer bar. The bar grows
upward only as new functionality gets integrated and
completed.
(Second note: For projects in which a significant
amount ofdocumentationis requiredas part ofthe deliv
erable,creditfor"done"isonlygivenwhenthecoderuns
andallthedocumentationiscompleteforthatfunctional
ity.)
Therearethree particularly nice things with the trian
gles,lineandbarinFigure5'11(b)besidesjustcompact
ness:
They can show a myriad of development strategies,
fromwaterfalltoagile,andanywhereinbetween.
Theycanbeoverlaidonasystemarchitecturediagram
toshowprogramstatus.
They can be slightly modified to show the relative
status of requirements, UI design, programming and
documentation, again, for very different project
strategies.
Let'slookatthoseoneatatime.
A B C D
page 56
Figure5'12.Fourprojectswithdifferentstrategiesand
status.[[AC:fix!separateABfromCD]]
Figure 5'12 shows the strategy and status of each of
fourprojects,shownninemonthsthroughaoneyearplan.
ProjectsAandBareusingthesamestrategy: develop
and integrate about 40% of the total functionality in the
first quarter, then about 63% in the second quarter, then
about 90%inthethird quarter,and finishing it off in the
fourthquarter.Presumablythis strategy is intended to al
lowplentyoftimeforfeedback,testingandrevisioninthe
finalquarter.
ThedifferencebetweenprojectsAandBisthatAison
schedule, and B is behind (it hasn't even finished the
functionsscheduledtohavebeencompletedat theendof
thesecondquarter).
ProjectsCandD,bothonschedule,haveverydifferent
strategies. Project C intends to develop very linearly, de
veloping and integrating about 25% of the functionality
eachquarter.ProjectDissetuptoruninahybrid(semi
waterfall, semiagile) fashion. The team expects to inte
gratelessthan10%ofthefunctionalityinthefirstquarter
(presumablythey will be gathering requirements and set
tingupthearchitecture at that time).They will still have
lessthan25%ofthefunctionalityintegratedbytheendof
thesecondquarter,then60attheendofthethirdquarter,
andtheyplantocompletethelast40%oftheworkinthe
fourthquarter.
JohnRuskwroteinwithanideatoshowbothfinancialand
progressmarkersatthesametime.Drawtwo renderings of the
triangle,lineandbar,oneforprogressandoneforcost(coloror
shadethemdifferently,ofcourse).Figure5'13illustrates(itisa
loteasierwhenincoloronascreen,insteadofblackandwhite
inthisbook).
Figure5'13.Fourprojectswithvaryingprogressandcost
status(courtesyofJohnRusk).
Thenicethingisthatyoucandiagnosewhatiswrongfrom
seeingthetwobarsatthesametime.InFigure5'13weseethat
Aisontrackforprogressandcost.Bisbehindscheduledueto
underresourcing (the cost is just as low as progress). C is on
track for progress but the team is working overtime or extra
teammembershave been added (cost is above prediction). Ds
costsareasplannedbutprogressisslow.
56
 Sw DevasaCooperativeGame page 57

ProjectZewa Status: 2006.05.15

timeperiod:2005.012005.12

App1 App2 App3

[Harmon] [Reese] [Marks]

Workstation

UIShell[Jones]

CommonUI[Smith]
Security[Sanchez]

AppSpecificBackEnd

DB1[Rich]

DB2[Carmac]

AppIndependent BackEnd

DBsvcs[Rich]

Security[Sanchez]

Legend
App Intendeddoneafter
eachinternalrelease
Application component
Component Actual vs.Expecteddone
>$1Mbudget
Common Ontrack
component Component component Notsignificantlybehind
<$1Mbudget Component
Significantlybehind

Figure5'14.Fullprogramstatusforaprograminvolvingthreeapplicationssittingonacommonarchitecture(Cockburn
2005g).
The next thing that can be done with the governance
graphicisthat it canbeoverlaidonasystemarchitecture
diagram to give a total program snapshot. Figure 5'14
showssuchapicture(thefigureisquitebusy,andthe in
terestedreaderisreferredtotheoriginalarticleinwhichit
isdescribedindetail(Cockburn2005g)).
Briefly,therearethreeapplicationsbeingdevelopedon
acommonarchitectureconsistingofaworkstationportion
and a backend portion. Some of the backend portion is
applicationspecificandsomeisapplicationindependent.
Therearethreethingstonoticeaboutthegraphic:
Thethermometerbarsarelaid horizontally instead of
vertically,forreasons ofspace.This does not change
their reading. Time and completeness flow to the
right.
Weareabletoshowthestatusofeachsubproject in
theprogram,andwecanimmediatelysee whichsub
projects are ontime, a little behind, and significantly
behind.Thisisexactlytheinformationthegovernance
boardwantstoseeataglance.
We can show even more information than discussed
so far. The technical lead for the program for which
this graphic was first developed wanted thethickness
ofthecomponentstoindicatehowmuchmoneywasat
stake in each. As he said, "If a small project or sub
systemisbehind,Iwon'tworryaboutitasmuchasif
a large one is behind." On that project, we also had
system migration issues to show, and used additional
coloringandmarking.
Whenthesteeringcommitteesees aproject that is be
hind,they willnaturally want to turn to a detail page for
that project.The third piece of good news is that we can
use the same marking mechanism to show the accom
plishmentsofeachsubteam.
Figure 5'15 shows subproject detail for two projects
usingverydifferingstrategies.
ProjectA'steamisusingaconcurrentdevelopmentap
proach. Their graph show that they intend to complete
about a quarter of their requirements in the first quarter,
almost twothirds by the end of the second quarter, and
about90%bythe endofthethirdquarter.TheirUIteam
willrunjustbehind,completinglessthanaquarterofthe
UI design work in the first quarter, then about half, and
over three quarters in the next two quarters. The pro
gramming team will run just behind them, completing
roughly20%,45,78%respectivelyinthosequarters.
The team of project B is using a waterfall approach.
Thatteamplans toget therequirements completed in the
firstquarter,theUIdesigncompletedinthesecond quar
ter,andtheprogrammingdoneinthenexttwoquarters.

57
 Sw DevasaCooperativeGame
Requirements
A UIdesign
Programming
Requirements
B UIdesign
Programming
Figure5'15.Detailsheetsfortwoprojectswithdifferent
strategiesandstatus(fromCockburn2005g).
Bothstrategiescanbeshownonthesamegraph,sim
plifying the job of reporting status on multiple projects
using differing mixes of waterfall, incremental and con
currentdevelopment.
More on the use of these projections and the use of
colorisgivenin(Cockburn2005g).
UseCasesandUserStories
XP brought with it the idea of marking requirements in
shortphrases(userstories)onindexcards(storycards)It
isimportanttonotethattheshortphrasesonthecardsare
not "the requirements," they are markers that promise a
conversation about what is associated with the phrase on
the card. In this sense they are efficient markers and to
kensinthecooperativegameasdescribedinChapter1.
However,unwarybeginners,mistakingtheearlyXPas
defining agile practices, mistakenly thought that all agile
development mustbedone withrequirementscapturedas
userstoriesonstorycards.
UserStoriesOverloaded
TheproblemisnotthatXPcontainsapracticeofmarking
requirements in short phrases on index cards. That is a
useful practice in many instances. The problem is that
since XP was so popular, many people just starting with
agiledevelopmentthoughttheywereallowed onlytowrite
requirementsassinglesentencesandonlyonindexcards,
thatanythingelsewouldunagile(andthereforebadinthe
eyes of their peers). Just as story cards make a strong
strategyincertainsituations,theymakeaweakstrategyin
others.
XP was created and tested in situations with a small
userbase.Developerscouldanddidsimplyasktheirusers
what they wanted. With short delivery cycles and only a
few users, seated close by, it was not necessary to spend
muchtime writingdowndetails and sorting through con
flictsintherequests.Theteamsimplywrotedownthekey
phrases, asked the designated "customer" what to do at
page 58
each choice point, programmed that up, and showed the
resulttothedesignatedcustomer.
Thereare,however,manysituations wherethose con
ditions arenot present:shrinkwrapped products, systems
withaverylargeordiversesetofusers,orsystemsbeing
deployed into large, multicultural organizations. In these
situations,theverynotionofaskingthecustomer,orget
tingaquickanswertoaquestion,don'tmakesense.
Herearetwoexamples from organizations I have vis
ited:
A set of hospitals, some small, simple and remote,
some large, urban and sophisticated, were collecting
requirementsfora new medical system to use by the
patient bedside.Not only were the different hospitals
concerned about their respective hospital rules, they
had to include into the requirements the differences
between emergency and regular care, inpatient and
outpatient care,and between the different specialists:
doctors,nurses,pharmacists,andassistants.
A state government organization was working to
changeandstreamlinetheiroperatingprocessesindif
ferentofficesaroundthestate.Thenewsoftwarewas
to support both the (slowly) evolving recommended
processandthevariationsallowedforthedifferentlo
cations.
Inthesesituations,it oftentakes weeks toget the answer
toaquestionabouthowtheuserinterfaceshouldwork,or
thedetailsofaseeminglysimplebusinesspolicyquestion.
Sadly, I have heard numerous people on stage telling
thefollowingsortofstoryinanexperiencereport:
We did very well with our XP/agile project, except
thatwecouldn'tseemtogetthe right Customer on
theproject.Itoftenhappenedthatwewouldaskthe
Customer a question, and it would take several
weeks before she came back with an answer. Our
project ran into many delays as a result. We can
recommendthatyougetaproperCustomeronyour
projecttoavoidthesedelays.
Afterhearingthisrefrainonanumberoftimes,itdawned
on me that the problem was not with their customer, but
withtheirprocess.Theyhadbuiltintotheiritthemiscon
ception that there was one person anywhere who could
giveadefinitiveanswerto business policy questions that
werelikelytocrossmultipledepartments.
Thesolution to the problem is not to look for an om
niscient customer, but to base the project's strategies
aroundtheconceptthatsomequestionswilltakeacertain
(long)timetoanswer.Thetrickis to ask those questions
far enough in advance so that the delay in getting them
answered doesn't delay the project. I call that "look
ahead."
58
 Sw DevasaCooperativeGame
(This is agoodtimetoreinspect Figure 23. Imagine
in that decisionflow diagram that asking the customer a
question is putting an inventory item into their queue.
Some of these inventory items take a short time to com
plete,whileotherstakealongtime.)
Therearethreepointsof damagefromusinguser sto
riesandstorycardsinthewrongplace:
Lackoflookahead
Lackofcontext
Lackofcompleteness
Thefirstpoint ofdamageistheonejustmentioned:it re
liesondevelopers being able to get quick answers to the
detailedbusiness policyquestions thatariseastheycode.
Thereareorganizationswheresoundanswerscan'tbede
cided quickly. The team needs a better form of look
ahead,todetect earlieron what questions arelikelytobe
asked, which will be easy to answer and which will take
time.
Thesecondpointofdamageislackofcontext.Awell
writtenuserstoryisaveryshortdescription,oftenjustone
sentencelong,ofsomethingauserwantstohavethesys
temdo:"Italicizetext","Addalinetoaninvoice","Com
putetheadditionalovertimepayforanhourlyemployeeH
hoursat1.5timesRrateofpay."TheshortestuserstoryI
haveheardofistheoneword"Kaboom"onanavalartil
lery projects, meaning "Take a shot and tell me where it
hit."
Agoodthingaboutuserstoriesisthattheycanbesub
divided into tinier and tinier pieces to fit within shorter
and shorter iterations, and still be considered valid user
stories. On one project, a user story was written: "Select
text."As theteam went toimplement it inan early itera
tion,theydecidedtosplit it intotwosmalleruserstories,
"Select text with the mouse" and "Select text with the
keyboard".Theirintention,quitereasonableforthat proj
ect,wastogetsomethingworking earlyand growit over
time.Havingonewaytoselecttextearlymeanttheycould
developotherpartsofthesystemseparatelyfrom extend
ingthetextselectionmechanisms.
Theonlyrulesforauserstoryarethatithasuservalue,
theteamcandraftanestimate ofhow longit willtaketo
develop,andthatestimatefitswithintheiriterationperiod.
There is nothing in the idea of a user story about how
muchvaluetotheuseritcontains.
Being able to split user stories into very small slices
generatestroublewhentherearehundredsorthousandsof
user stories. The developers and users find themselves
lookingatsentencesthatareveryhardtorelatetobusiness
situations.Theyare presented without an operations con
text,andwithoutbeingrelatedtoeachotherwhichones
comefirst,whichonesurroundothers,andsoon.
page 59
Atthetimeofthiswriting,thereisadiscussiononYa
hoo's "agileusability" discussion group about just this
point.Onepersonis askingforideas on how to integrate
hundredsoftinyuserstoriesintoacoherentwhole,sothat
hecancomeupwithadecentuserinterfacedesignforthe
system. UI design requires context to be done properly
userstoriesdon'tprovidethatcontext.
Forafeatureinisolation,forauser story in isolation,
or(forsystems engineeringtypesofcontracts)fora shall
statementinisolation,thecontextisinformationthatcan't
bederivedfrom otherinformation.Onlythe mostexperi
encedbusinessorusageexpertscansewtogetherthehun
dreds ofsentences intoacoherent andsound whole.This
isexpensiveanddifficultworktodo.
Thethirdpointofdamageis lack ofcompleteness.As
the developers ask questions, the answers generate more
userstories,often morethan wereanticipated.On a plot
ted burnup chart (as Figure 5'16), the total number of
stories keeps rising as they encounter unexpectedly com
plexbusinessrulesandsplitstories.
storypoints
170
160
150
140
130 Growingpredicted
120 totalsize
110 Scopecreep,misestimate,
100 ornormal?
90
80
70
60 Completed
50 todate
40 Predicted
30 completion
20
10
0
Iteration1 2 3 4
Figure5'16.Growthinestimatednumberofuserstories
neededtocompletetheproject.
Onaprojectthatissuitedtotheuserstorymethoda
smallproject writtenforafew,localusers this is not a
problem. The development team simply delivers a new
systemeveryfewweeksandthesponsorscantellwhether
they are happy with the rate of delivery. They view the
ongoing work as a flow of cash for value, and steer ac
cordingly.
On a fixedprice, fixedscope project, however, the
burnupchartinFigure5'16presentsamajorproblem.Is
that sharp growth in the size of the system due to scope
creep,poorinitialestimates,orsimplysplittingstoriesina
normalway?Iwatchedanagileteamattempttocomplete
afixedprice,fixedscopeproject bidinwhichthis prob
59
 Sw DevasaCooperativeGame
lemarose.Theclientsidesponsorsfeltthey werenot go
ing to get the system they had been promised the con
tractorsideexecutives felt that theywerehavingto over
performonthecontractthedevelopersfeltthattherewas
too much scope creep and the users felt that the project
wasnevergoingtogetdelivered.
UseCasesRevisited
Usecasessolvethoseparticularthreeproblems However,
we must first repair the bad reputation use cases have
pickedupfromthepeoplewhowritethempoorly.
Mostorganizationsproduceinteractionusecases36 that
are long (think 20 30 pages), contain as much screen
design detail as the writer can include, and are hard to
read.Itisnowonderthattheyhaveabadreputation.
Thatreputationappliesonlytointeractionusecases.A
gooduse cases is short (think 13 pages37),readable, and
containsnoUIdesign.Iusedtocallthemintentionaluse
cases, but I actually prefer Larry Constantine's term, es
sential use cases (Constantine 2001). Interaction and es
sential use cases are worlds apart in terms of easeofuse
andeconomics.
On the $15M project mentioned earlier, we had over
200 use cases that served as the contract basis for the
fixedprice,fixedscopeproject.Eventhere,theusecases
were essentialuse cases written in "casual" style38,about
twoparagraphsofsimpleprose.Theywereupdatedatthe
startofeachthreemonthdeliverycycletopickupthelat
estbusinessneedsanddevelopmentdetails.
Essentialusecases,twoparagraphsortwopageslong,
can be drafted, read and updated easily. The team can
writethemallupfront or incrementally, each to comple
tion or one scenario at a time, at a low or high level of
precision at any moment. Implementation can begin im
mediatelyorbedeferred.Costandvaluecanbeestimated
on a lineatatime basis or on a usecase basis. In other
words, you can arrange their construction and use ac
cordingtoyourproject'spreferredstrategies.
Wellconstructed essential use cases solve the three
problemsmentionedearlier:
Completenessandlookahead
Theextensionconditionssectionoftheusecaseisaplace
wheretheusageandbusinessexpertscanbrainstormofall
36
Oddly,althoughInamedthesethingsbackin1994,specificallytotellpeople
notto writethem, thatnomenclature never made itinto any of my public arti
cles.PerhapsIcanfixthatmistakenow.Inanoddtwistoffate,offshoredevel
opment has caused a need for interaction use cases as the carrier of high
precision,lowbandwidthcommunicationacrossculturesandcontinents.
37
IfIgotonlyoneruletoimposeonanorganization,itwouldbe,"Everyteam
delivers running, tested features to real users every three months." If I had to
nameasecond,itwouldprobablybe:"Nousecaseexceedstwopages."
38
See Writing Effective Use Cases (Cockburn 2001) for description of briefs,
casualandfullydressedusecases,levelsofprecisionin writing,andlow,me
dium,andhighlevelusecases.
page 60
the situations that the developers will have to deal with
relatedtotheusecase.Brainstormingis doneina matter
ofminutes.Thelistofextensionconditionsthenactsasa
completenesscriterionforthesystem'srequiredbehavior.
Theproject teamcan(andshould)strategize overthat
listtodecidewhichextensionconditionsshouldbedevel
oped in which delivery cycle. They can (and should) at
tachdevelopment estimatesandperceivedbusinessvalue,
even at "low, medium, high" levels, to understand what
theyareconstructingforthebusiness.
Intheagile environment,ausecaseprovidesthecon
text forwhat is wantedoverall,but it is not the case that
the team delivers all of it at once (Dave Churchill called
theinitialdelivery"asparseimplementationofausecase,
withasubsetofextensionconditions")
Inexaminingtheextensionconditions,theteammakes
an assessment of how hard it will be to gather the infor
mation needed to complete the requirements associated
witheachcondition("low,medium,high"isoftenagood
enoughmeasure).Thoserequiringalotofinvestigationor
discussion should be started earlier, ahead of when the
item is scheduled for development. Extensions estimated
to have a quick response time can be left alone longer,
possiblyuntilthestart oftheiteration.Interms ofFigure
23, the team adopts is a workscheduling strategy that
arrangesforinformationtoreachthepersonneedingitina
timelymanner.
Context
Sincethestory line of the system's use is captured at the
same time as the system's behavioral features, use cases
providethecontextneededforeachfeatureinthesystem.
Kite or highlevel use cases give context to individual
usergoal use cases39, and the usergoal use cases give
contexttospecificuseractions.
MappingUseCasestoUserStories
GerardMeszarosworkedouthowtofitusecasesanduser
stories together (Meszaros 2005).The problem he solved
isthis:
A user story may be a request for new functionality,
extensionoffunctionalityordata,orimprovedusabil
ity(UIdesign).
A use case does not contain data or UI design infor
mation.
Auserstorymustbesmallenoughtobeimplemented
in less than an iteration, however short the iteration
maybe.
Ausecasemaycontain10,20,or30userstories,but
itisnotthecasethateachstepinausecaseis auser
story: it may take several use case steps to capture
39
(Cockburn 1995sucwg,Cockburn 2001uc).
60
 Sw DevasaCooperativeGame
what is a single user story, or one use step may be
complicated enoughthat it needs tobe split into sev
eraluserstories.
The first user story to implement is the simplest
conceivable path through the main success sce
nario, leaving out any complications whatsoever.
Thisisauserstorythat maps tomultipleusecase
steps.
Most of the leftover steps and most of the exten
sionconditionsmaptooneuserstoryeach.
Some steps describe business rules or behaviors
difficulttoimplement,eitherofwhichmayneedto
be split into several user stories, implemented in
differentiterations.
This is the mismatch between user stories and use cases:
some user stories are in the use cases and some are not.
Thatmakes it difficult to"convert"usecases to user sto
ries.
Gerard'ssolution is simple and clever. He names four
typesofuserstory:
New functionality. Implement the simplest possible
path through the main success scenario of the use
case.Chooseittobeasnarrowaspossible,tofitinto
youriterationlength.
New rule. Implement part of a business rule, usually
fromanotherstep or extension in the use case (occa
sionally not in the use case at all, as with complex
businessrulesthatliveintheirowndocuments).
Newdata.Implementpartofadatastructure(whichis
probablynotintheusecaseatall).
Improved usability. Correct or refine UI features,
whether they were part of the original plan or come
fromuserfeedback.
Gerard solved the conceptual problem of relating use
casesanduserstories.Wenowhavetoolingproblem.
One organization constructed a special tool to help
themtrackthe mapping.People writeuse cases and non
behavioral requirements to define project scope. They
break those down into user stories, or chunks of work
(COWs)as the team refers to them (the team recognized
the trouble with the term "user story" and changed their
vocabulary). They attach effort estimates to the COWs
PersistentQuestions
Overthelastfiveyears,thesamesortsofquestions keep
arising: the limits of the agile model, agile's relationship
with the Software Engineering Institute's Capability Ma
turityModel(SEI'sCMMI),withISO9001conformance,
withcustomerrelations,withdomainmodeling.Theyalso
ask how to introduce agile into a company, what "more
page 61
and assign them to development teams for specific itera
tions.
Thetoolallows theusertotypeanythingintheCOW
descriptionandassociatethat withausecaseorastepin
theusecase,and,independently,withateamandwithan
iteration.
Thetool has three panes, with draganddrop between
panes.
Pane 1: A tree view of use cases and COWs (a use
cases cancontainotherusecases,anda use case can
containCOWs).
Pane2:AlistofCOWsassignedtoteams.
Pane3:AlistofCOWsassignedtoiterations.
With this tool, the team can write and evolve their use
cases, and develop them according to any strategy they
like. They can always tell what portion of a use case is
implemented,tomakesurethatthefunctionalityprovided
toauseris"fitforbusinessuse."Theycanseethecontext
surroundingeachCOW.Theycangenerateburnupcharts
showingtheirrateofprogress.
(Beforeyou write measking for a copy of the tool, it
wasdevelopedforinternaluseonly,andtheaboveisallI
am allowed to say about it, except that it took about a
month to prototype and another month to get into use.
With moderndevelopment environments,this sort oftool
isnotalargetask.)
Forthosewhodonothavesuchatool,thereisaneven
simplermethod:
Printoutthe(1or2page)usecaseandpostitonthe
wall.
Highlight with yellow highlighter the sentence or
sentencesbeingimplementedinthisiteration.
Annotatetothesidethedatastructureorbusinessrule
associated with any complex step and highlight it
similarly.
Highlight the sentences with blue (or green) high
lighter as they get completed. They will now appear
green.
Withthismethod,peoplewillalwaysknowwhattheyare
workingonandwhathasbeencompleted.Bestofall,they
willbeabletotellwhat portion of a meaningful user ac
tivityisavailableandwhatportionisbeingleftout.
agile"means,andhowtotellwhethertheirorganizationis
agileatall.
Thisistheplacetoconsiderthosequestions.
SweetSpotsandtheDropOff
When applying good practices, there is a gradient and a
steepdropoff.Alongthe gradient,doing moreandbetter
61
 Sw DevasaCooperativeGame
isgood,butonlyalittlebitbetter,butacrossthedropoff,
doinglesscanbecatastrophic.Isuggestthatgettingallthe
key practices above the dropoff is more important than
gettingjustoneortwoofthemtothetopofthegradient.
Recallthefivesweetspotsofagiledevelopmentmen
tionedonp.???:
TwotoEightPeopleinOneRoom
OnsiteUsageExperts
OneMonthIncrements
FullyAutomatedRegressionTests
ExperiencedDevelopers
It is not the case that if you have those sweet spots in
place, then you can use the agile model. Rather, it is the
case that to the extent that you can get closer to those
sweet spots,thentheeasier it is to take advantage of the
agilemodel,andthelighterandfasteryoucanmove.
Forthefirstone,collocation,weseethat ifthepeople
are not in the same room, but in adjacent cubicles, com
municationisnotasgoodthisisthegradientbutitstill
adequatefor eventheCrystalClearmodeltowork.Once
peoplemovefartherapartthanthelengthofaschoolbus40
andaroundacornerortwo,theircommunicationbecomes
so constrained that very particular dangers arise this is
thedropoff.
Similarly,itisnotreallynecessarytohaveafulltime,
onsiteexpertuserinordertogetgoodusageandusability
information.Ihaveseenprojectsdoverywellwithexpert
userstwohoursaweekonsitewithphonecallsduringthe
rest of the time. This is the gradient. Less than once per
monthisonthelowsideofthedropofftherejustisnot
informationandfeedbackfromtheexpert,andtheproject
is indangerof deliveringthe wrong system41. Most proj
ectsnevergettoseearealuserexpertatall.
Oneweek, onemonth and threemonth deliveries all
lie on the gradient. Oneyear deliveries are off the drop
off.
Continuous, daily, even everyotherday integrations
all lie on the gradient. Weekly integration and manual
testingareoffthedropoff.
Having all competent and experienced developers is
reallygreat.Onecompetentandexperienceddeveloperfor
everythree not so outstanding or young and learning de
velopers is still onthe gradient. Having only one compe
tentandexperienceddeveloperforsevenortenoftheoth
ersisoffthedropoff.
Understanding the gradient and dropoff helps us un
derstand the different agile methodologies being pub
lished.OneofthegoalsofXPistogetashighupthegra
40
SeetheBusLengthCommunicationPrinciple,p.30???
41
Seetheresearchstudydescribedin(Cockburn1998,pp.????)on"userlinks"
ascriticaltoprojectsuccess.
page 62
dient as possible. Thus, the original XP called for estab
lishingthecenterofeachsweetspot.
ThegoalofCrystalisprojectsafety,withregular,ade
quate deliveries. Therefore, Crystal only calls for estab
lishing the top of the dropoff. Every improvement from
thereislefttothediscretionoftheteam.
Think about where your practices are relative to the
dropoff. Consider that getting all of the practices above
thedropoffismoreimportantthangettingjustoneortwo
ofthemtothetopofthegradient.
FixedPrice,FixedScopeContracts
Mydebutasaleadconsultantwasonan18month,$15M
fixedprice,fixedscopecontract, with eventually 45 peo
pleonthe development team.Ifoundonthat project that
alltheideas we later wrote into the agile manifesto were
neededtopulloffthecontract:incrementaldevelopment,
reflection,frequent integration,collocation,close user in
volvement (wesucceeded without automated tests, which
thesedaysIwouldtryhardertogetinplace).
Most fixedprice, fixedscope contracts are priced ag
gressively, and typically require large amounts of over
time. The problem is not rapidly changing requirements,
but development inefficiency.Fortunately,theagile ideas
increase development efficiency, and there is almost al
ways wiggle room in the development process that the
teamcanexploittoincreasetheirefficiency(See"Process:
the4th Dimension"(Cockburn2004pt4d)).
Thus, I came to the writing of the agile manifesto
through the door marked "efficiency" instead of the door
marked"changingrequirements."
Ifyouareworkingonfixedscopecontracts,remember
twothings:
Attheendofeachiterationordelivery,ifyouneedto
keep the scope constant, simply don't change the re
quirements! There is nothing in the agile manifesto
that says you havetochange requirements at the end
oftheiterationonlythatagiledevelopmentfacilitates
requirements changes in those situations where it is
appropriate.
The contract putsa bounding box on the time, scope
and money you can apply. Within those limits, you
cancollocatetheteam,workincrementally,payatten
tion to community and communication, automate
testing, integrate often, reflect and improve, and in
volveusers.
Agile,CMMI,ISO9001
Rich Turner highlighted for me the key difference be
tween the CMMIand the agile methodologies: The agile
methodologies are focused at the project level, whereas
theCMMIisfocusedatthe organizationallevel.
62
 Sw DevasaCooperativeGame
Thereareadditional,philosophicaldifferencesthatcan
bedebated,but one mustfirsttakeintoaccount that their
targetsaredifferent.
Anagile initiativeaddresses the question:How do we
make this software on this project come out well? A
CMMIinitiativeaddressesthequestions:How well is the
organization doing at being what it wants to be? Do the
differentgroupshaveincommon what theyaresupposed
to have in common? Do they train newcomers to behave
inthewaysthegroupwant?Andsoon.
Thus,itisnotameaningfulquestiontoaskwhetherXP
is a CMMI level 3 methodology, because XP does not
containanyrulesabouthowtotrainanXPcoach,howto
detectwhetherpeoplearepairprogrammingorrefactoring
(orwhytobotherdetectingthat).Yetthosearethethings
theCMMIwantstheorganizationtothinkabout.
Sincethe writingoftheagile manifesto,anincreasing
numberofagilepractitioners havebeenasked to help in
stall agile processes across an entire organization. Inter
estingly,wefindourselves askingthesame questions the
CMMIassessmentprocessasks:Isyourteamreallydoing
daily standup meetings, and how can you tell? What is
thetrainingforanewScrum master?Whereare your re
flection workshop outputs posted? Where is your infor
mationradiatorshowingtheresultsofthelatestbuild?
It may be time for agile practitioners to take a close
look at the lessons learned from the CMMI as relates to
creatingcommonprocessesacrossanorganization.
Taking into account that the targets are different, we
findthat
GettinganagiledevelopmentshopassessedatCMMI
level2or3maynot be so difficult, especially as the
SEI is starting to train assessors to work with agile
processes.
Deep philosophical differences remain between the
CMMIapproachandtheagileapproach.
There are two very fundamental, philosophical differ
ences betweenCMMI and agile that generate tension be
tweenthetwoworlds.
Thefirstdifferenceisthis:
TheCMM(I)isbasedonastatisticalprocessassump
tionrejectedbytheauthorsoftheagilemanifesto.
Process engineering literature categorizes processes as
eitherempiricalortheoretical(alsocalleddefined).Inthe
process engineering literature, a theoretical or defined
process is onethat is wellenough understand to be auto
mated (quite a different definition of defined than the
CMMI uses!). An empirical one needs human examina
tionandintervention.Thetextbookby Ogunnaike (1992)
hasthistosay:
page 63
Itistypicaltoadoptthedefined(theoretical)modeling
approach when the underlying mechanisms by which
a process operates are reasonably well understood.
When the process is too complicated for the defined
approach, the empirical approach is the appropriate
choice.
For a defined or theoretical process to work two things
mustbetrue.First,predictionmustbepossiblethesystem
mustbepredictableinitsresponsetovariations.Secondly,
onemustknowandbeabletomeasurealltheparameters
neededtomaketheprediction.
I don't think either is satisfied in software develop
ment.First,wedon'tyet knowtherelevant parameters to
measure. The purpose of the agile movement and this
book has been and still is, to some extent, to get people
(includingresearchers)topayattentiontonewparameters,
such as quality of community, amicability, personal
safety, and factors affecting speed of communication
("ergsecondspermeme").
Secondly, even when we get far enough to name the
relevantparameters,Ithinkitquitelikelythatteambased
creative activities such as software development are cha
otically sensitive, meaning that a tiny perturbation can
cause an arbitrarily large effect. As one example, I once
watched in amazement as a highlevel employee quit the
organizationinangeroverwhatseemedtosomeofusasa
seeminglysmalloffhandcomment.I'msureshehadbeen
inflicted with this comment and ones similar before, but
onthisday,thesamecommentwasjustonetoomuch,and
shequit.
TheCMMIladderisbuiltontheassumptionthat both
conditionsaresatisfied42.Thisassumptionis embeddedin
levels 4 and 5. At level 4, the organization captures nu
mericalmetricsabouttheprocesses.Atlevel5thosemet
rics are used to optimize the process. The assumption is
thatgainingstatisticalcontrolofthesoftwaredevelopment
processisthekeytodoingbetter.
The second philosophical difference between CMMI
andagileisthis:
The CMMI places optimization of the process at the
finallevel,level5.Agileteams (teams usingCrystal,
in particular) start optimizing the process immedi
ately.
Attheverymomentofstartingtheiragile work,theteam
will be challenged to ask themselves how they can do
better.
In asking how to do better, the statistical process as
sumptionshowsupagain.Inwhatfollows,Iwillspeakfor
42
Ilja Preumentionsthatthe book MeasuringandManagingPerformancein
Organizations [[ref???]]hasinterestingmaterialaboutwhatdysfunctionsariseif
youworktosuchanassumptionwhereitiswrong.
63
 Sw DevasaCooperativeGame
Crystalinparticular,inordernot to speak incorrectly for
anyoneelse.
In the reflection workshop or postiteration retrospec
tive,theprocess andthe project's condition are evaluated
by people's emotional responses in addition to numerical
metrics.
Myworkingassumptionisthatahuman,asadevice,is
particularly good at taking in a lot of lowgrade analog
informationalongvariouschannels,andsummarizingitin
a feeling or emotional statement. Thus, when a person
says they feel "uneasy" about the state of the project, or
"uncomfortable" with the last iteration's communication
patterns,theyare,infact,sayingagreat deal, even when
they can't provide numerical values or details. It is the
veryfact of feeling uncomfortable that the team must at
tendto.
This view, which seemed out of fashion at the time I
first formulated it, has been getting attention in recent
years. Several books have been written around it, most
notablyBlink(Gladwell2005???),??Thefirebook???and
SketchesofThought(Goel1995).
Fromsharingtheirfeelingsaboutwhatisgoingon,the
teamisinapositiontostartimprovingtheirworkinghab
its long before they get statistical data, and even before
theyareconsistentintheirhabits.Thisisafundamentally
differenttotheCMMImodel.
There is one final, significant point to be made about
combiningagileandCMMI:Itappearstobeeasiertoin
corporate agile practices into an organization already as
sessed at CMMI level 3 or higher than to move an agile
projectteamintoCMMI.
A CMMI level3, level4, or level5 organization has
alreadydemonstratedtheabilitytoadoptaprocessorgani
zationwide to train the people and the leaders in their
roles.Theagileelementstheywilladdareunlikelytoen
dangerthatratinginanyway:
Collocation.Theteammaynotbecollocatedinitially,
butiftheychoosetocollocate,thatwillnotaffectany
otherpartoftheirprocess.
Daily standups. Getting the team together daily to
talkaboutwhattheyaredoingshouldnotaffectanyof
theteam'sotherritualsordeliverables.
Incremental development. Many CMMIcertified
shops do not do incremental development, but work
ing in increments should not break any part of their
process.
User viewings. Having one or more users visit and
givefeedbacktothedevelopmentteameachweekisa
good practice, and will not affect any part of their
documentedprocess.
Continuous builds, automated regression unit and
acceptancetests.Theseareprobablyrecommendedin
page 64
theirprocess,andwon't bedamagedfor being turned
up.
Reflectionworkshops.Gettingtogethereach monthto
discusshowtodobetterwillnotendangeranyprocess
assessment.Thetrickypartcomes iftheteamdecides
itneedstochangesomepartofthetheirprocesstodo
better,andthatchangeputsthem out ofstepwiththe
greaterorganization'sprocess..
In other words, a CMMI organization should, theoreti
cally, have no trouble in adopting the key recommenda
tionsoftheagileapproach.Mostorganizationsstrivingfor
CMMIassessement that Ihave talked to are unwilling to
dothosethingsbecausetheydon'tseethemascompetitive
drivers.
The agile organizations I have visited generally have
no interest in CMMI certification at all, viewing the
CMMI ladder as a simple waste of money. That is, they
don'tneedthe CMMI certification to get contracts, but it
willcosttimeandmoneytogetthatcertification.
ThewayIunderstandthesetwoviewsisthatorganiza
tions that profit from having a CMMI level3 assessment
for certain government contracts are not competitively
hamperedbynothavingthelevelsofproductivityandre
sponsivenessofferedbytheagileapproach.Organizations
operating in a highflux, competitive environment and
needing the agile approach for organizational survival,
can'taffordtoordon'tseethevaluetospendthemoneyor
time to create the process superstructure required to get
theCMMIlevelcertifications.
Thedifferencehereisbased,notonphilosophy,butin
prioritiescreatedbythebusinessoperatingenvironments.
The CMMI question transfers to the equivalent ques
tionabout ISO9001certification.ISO9001certificationis
easier,in onesense:there is only one step on the ladder.
Thestatisticalassumptionandthelateoptimizationobjec
tionsthereforedon'tapply.
Onecompany,ThalesResearchandTechnology(TRT
UK), as part of its Small Systems Software Engineering
activity,ranatrialprojectusingtheCrystalClearmethod
ology,andhadanISO9001auditorevaluatewhatitwould
taketogetthatproject'sprocesstopassanISO9001audit.
The report is too long to reprint here it is presented in
CrystalClear(Cockburn2004cc),pp.??????.The inter
estedreaderisencouragedtoexaminethatreport.Thesort
ofcommentweseefromtheauditor,thoughisofthisna
ture:
Inordertobefullycompliantwiththisclause ofISO
9001,whiteboardrecords[ed.note:theyusedprinting
whiteboards]] would need to indicate who was in
volvedwiththeviewingsandworkshops.Inaddition,
theSponsorand/orUsershouldbepresentatsomeor
allinordertoensurereviewerindependence. Actions
64
 Sw DevasaCooperativeGame
should be clearly identified to enable tracking at the
nextworkshop.Thewhiteboardrecordswouldneedto
bekeptforthe mandatoryrecords of review required
byISO9001.(Cockburn2004cc,p.320???).
In other words, there was not a problem in using design
andreflectionsessionsatwhiteboards,aslongaseveryone
presentsignedtheirnames onthewhiteboardanddatedit
(andtheneitherphotographedorprintedit).
When the team updates their working conventions, as
called for in Crytal, they would presumably similarly
print,signanddatethenewlist.Theywouldthenusethat
asthenewprocesstoevaluateagainst.
page 65
Another View of Agile and CMMI, by Paul
McMahon,Principal,PEMSystems
WhileinsomecasesIagreeitiseasiertoincorporate
agile practices into an organization assessed at CMMI
level3orhigher than to move an agile project team into
CMMI, my experiences indicate that this is not always
true.
I am helping a number of organizations with high
CMMImaturity(Levels3,4,5)becomemoreagile.ButI
am also helping small organizations, which started out
agile, use the CMMI model for process improvement.
Last year I participated on a formal appraisal for a small
companythatisverySCRUMorientedandtheyachieved
aCMMIlevel3rating.IfyouusetheCMMImodelasit
wasintendedIdontbelieve you havetomovetheteam
intoCMMI.
TheCMMImodelisareferenceframeworkforprocess
improvement. It isnt a set of required practices. In the
caseImentioned,wedidntchangethebehaviorinsidethe
smallcompany,exceptinisolatedinstanceswherechange
wasclearlybeneficial.Forthemostpartwedemonstrated
wherewhattheydo(largelyScrum)meetstheintentofthe
Level 2 and Level 3 reference practices. To accomplish
this requires a good understanding of the CMMI model,
includingtheuseofwhatisreferredtoasalternateprac
tices.
Asanexample,theagiledailystandupmeetingscanbe
viewedasanalternatepracticewithintheCMMImodel.
Thesedailymeetingsalongwiththefollowupactions by
theScrumMastercanachievetheintentofanumberofthe
specificpracticeswithintheProject MonitoringandCon
trolProcessArea.
Userviewingsmeetpartoftheneedforstakeholderin
volvement which is an important aspect of the Project
Planning and Requirements Management Process Areas
andtheGenericGoalswithintheCMMImodel.
With respect to reflections workshops, the CMMI
modelactuallyrecognizesthatchangeisagoodthing.It
expects the team to capture lessons learned and improve
the process. So reflections workshops support lessons
learnedfeedbackandimprovement asrequiredwithinthe
generic goals of the model. The one subtle difference is
that if you are going for Level 3, then improvement rec
ommendations that come out of the team should not be
limited to the team, but should also be communicated to
the organization level so other teams in the organization
canbenefitfromwhatyouhavelearned.
Attaining CMMI Level 3 doesnt have to mean more
detailed process definitions. It means that the processes
that work for an organization are shared across that or
65
 Sw DevasaCooperativeGame
ganization and adhered to. Nothing says they cant be
agileprocesses.Institutionalizationisanimportantpart
of the model, which means the processes dont break
downintimesofcrisisandarentignoredwhennewpeo
plearebroughtin.Inmyviewitisofteneasiertoinstitu
tionalize agile practices because agile teams usually be
lievestronglyinhowtheydotheirjob.
As another example, the agile company I have been
helping has an open communication culture where lead
engineers arent afraid to walk into a senior managers
officeassoonastheyknowtheyhavearisk,orjustneed
help. The team members are also encouraged to raise
risksatthedailystandupmeetings,andtheyoftendo.
At first, based on the Risk Management Process Area
in the CMMI model, we created a form to capture risks
moreformally,but theformwas not well received in the
organization. So instead we defined a risk process that
capturedexactlywhattheteamdoes,andthentrainednew
personnelintheorganizations expectedriskmanagement
behavior.Wedidrequirethattheycapturetheirrisksina
periodicbriefingtoSeniorManagement,butwecontinued
to encourage the informal and immediate communication
thatwasalreadyworkingwell.
Ourleadappraiserhadnotroubleatallwithprocesses
like Risk Management that clearly were institutionalized
across theorganization,and met the intent of the process
areasaslongasthedirect artifactsandaffirmations
substantiated the effectiveness of the process (direct arti
factsandaffirmationsarediscussedbelow).
Myexperience has been that when we try to formal
ize effective processes too often this results in negative
sideeffects because we unintentionally change what
works. As an example, if we required formal written
meetingminutesontheagiledailystandupmeetings,peo
plewouldbelesslikelytospeakopenly,basedonmyex
perience.Ihaveobservedthistypeofbehaviorchangeon
numerousoccasions.
Another way to look at what we did was to capture
what the successful people in the organization were al
ready doingin this case mostly Scrumand then share
itacrosstheorganization.Thisisaneffectivewaytouse
theCMMImodelandagile methods together. These ex
amples demonstrate that agile practices can actually help
achieve CMMI goals, if the model is used correctly as a
framework.
Beawarethatoneofthekeystothisworkingistogeta
CMMI appraisal lead who understands how the CMMI
modelissupposetobeused,andunderstands agile meth
ods.Forexample,youneedtohavealeadappraiserwho
isnt afraid to use alternate practices as they were in
tendedbythemodel.Someleadappraisersdiscouragethe
useofalternatepracticesoutoffearitwillbeperceivedas
page 66
trying to get out of a required practice. This can be a
legitimateconcern,butitshouldntbeusedasareasonto
change what is already working in a successful agile or
ganization.
Althoughitistruethatsomeorganizationsstrivingfor
CMMIassessmentareunwillingtoemployagileprac
tices, my experience indicate that many organizations in
volvedwithDoDworkareactuallyverywillingandinter
ested.
I have worked with multiple large U.S. Defense con
tractors who came to me, already having achieved a
CMMILevel3,4or5rating,but wantingtoinfuse more
agilepracticesintotheirworkprocesses.Theirmotivation
hascomefrommultiplesourcesincludingcustomerinter
est,developerinterest,anda belief that to continue to be
successfulandmaybetosurviveincreasedagilitywill
berequired.
A question I am hearing frequently from large DoD
contractorsis,Howcan weinfuse moreagile operations
into our existing processes? In one case, we created an
agiledevelopersguidetohelphisprojectstailortheirtra
ditional company process assets employing agile prac
tices.
The DoD acquisition community has also expressed
interestthroughquestionslike,Howcanweget ourpeo
pletrainedinagilemethodssowecanbemoreeffectiveat
evaluatingtheagile implementations of our contractors?
In this case, we are training acquisition community per
sonnelandprovidingevaluationsandrecommendationson
DoD projects that are already moving toward increased
agility.
It is certainlytruethat many Organizations operating
in a highflux, competitive environment and needing the
agile approach for organizational survival, can't afford to
(ordon'tseethevalueto)spendthemoneyortimetocre
atetheprocesssuperstructure.
But, at the same time, my experience indicates you
dont necessarily need a process superstructure to
achieve a high CMMI Process Maturity Rating. Let me
explainwhyIbelievethis,andwhysomanyorganizations
stillgotheprocesssuperstructureroute.
ToattainastagedCMMILevel3involves 18process
areas and 140 expected specific practices. Today, many
CMMIbasedprocessimprovementinitiativesfocusonthe
stepwiseproceduraldefinitions whichcanbeimplied(al
though erroneously in my view) from the specific prac
tices.Thisapproachoftenleads organizations toproduce
explicit objective evidence for each expected specific
practice.Theseeffortsfrequentlyleadtoteamfrustration
andreducedperformance.Commentssuchas,ourproc
esses dont reflect what our people really do, and, our
66
 Sw DevasaCooperativeGame page 67
processes force us to do nonvalue added work, are not Thereisalotofnegativetalktodayconcerningtheef
uncommon. fectivenessoftheCMMI model.One of mygovernment
I believe this approach goes wrong based on the way clients told me that he doesnt care anymore about the
objectiveevidenceis handled.Objectiveevidence(OE)is CMMI rating because he cant see the difference in the
criticaltotheappraisalmethod,butmorethanonetypeof performance of an organization that says its level 5 from
OE is allowed. To achieve an expected specific practice onethatsaysitslevel2.Myviewisthattheproblemisnt
an organizations adherence to the practice must be veri withthemodel,butthewaycompaniesapplyit focusing
fied by an appraisal team through what is referred to as on the rating, rather than its real intent. In my opinion
directand indirect artifacts. agile methods can actually help us use the CMMI model
Direct artifactsrelatetothereal intent of the practice. asitwasintendedforrealprocessimprovement.
Examplesarerequirements,design,codeandtestartifacts Ourphilosophy,withthesmallagilecompanythathad
(Note here that the model doesnt dictate the form these a business goal to achieve CMMI Level 3, was not to
direct artifactsmusttake,northe orderin whichthey are drive the team to perform any unnatural, or nonvalue
produced). Indirect artifacts are a consequence of per added acts in preparation for the appraisal. The teams
forming the practice, but they are not the reason for the affirmationsandthedirectartifactsbecametherealproof
practice,noraretheyrequiredbythepractice.Examples the products they produced, their satisfied customers,
aremeetingminutesandstatusreports. and their business success: the business is currently
But this is where I have seen many process improve growing30%ayear.
ment initiatives goofftrack.Too often I have found or
ganizations being driven to perform unnatural and non
value added behaviors to produce unnecessary indirect
OE,ratherthanmaintainingfocusontherealtarget,qual
ityproductsproducedfortheircustomers(directOE).
My point is that indirect artifacts (e.g. meeting min
utes, status reports, and so on) are not required by the
model. I am not saying that meeting minutes and status
reports are not important, but I am saying you can use
whatarecalledaffirmationsduringanappraisalinstead.
This means you interview people and they tell you what
theydo.
Forexample,theappraisalteamcaninterviewanagile
teamandtheprojectteammemberstelltheappraisalteam
what they do. As an example, a response from a team
member might be, We hold daily standup meetings
where the team members report status and the team lead
listensandthenremovesobstacles.
Theappraisalteamtakes notes on what they hear (af
firmations). These notes are then used as evidence that
the organization is meeting the intent of many specific
practicesinthemodel.We dont havetoforceunnatural
and nonvalueaddedbehavior, and extra timeconsuming
work to create unnecessary artifacts to get ready for a
CMMIappraisal.Thedirectartifactsandtheaffirmations
aresufficient.
So why then do many large DoD contractors spend
huge amounts of money to get ready for a CMMI ap
praisal?OnereasonIhaveobservedis manycontractors
dont trustwhat theirpeople willsayinthose interviews.
Theythereforeforcethecreationofhugeamountsofindi
rectevidence(e.g.meetingminutes,statusreportsetc.)to
reducetheriskthatsomeonemightsaythewrongthing
anditmightleadtoanunsuccessfulappraisal.

67
 Sw DevasaCooperativeGame
WhenToStopModeling(reprise)
Ifyouarenot doingany modeling at all on your project,
thereisastrongpossibilitythat youcanbenefit bythink
ing carefully about the structure of your domain (the do
main model). If you think that your models need to be
complete, correct and true before you start coding, then
youarealmostcertainlydoingtoomuch.
At the time of writing the first edition of this book,
most people modeled either too much because they
thought modeling was good or not at all, typically be
causetheydidn'tthinkaboutitatall.Onceagiledevelop
ment became fashionable, overzealous wouldbe agilists
proclaimedthat modelingwas bad.Onceagaintheygave
incorrectadvice.
Scott Ambler, in his book Agile Modeling (2002) set
out to correct both imbalances. He describes, for those
whomodeltoo much,lighterandsimplerways to model.
Forthosewhodon'tbothertomodelatall,heencourages
lightweight modeling to assist in thinking and communi
cation.
Scott's approach lends itself well to the text I wrote on
page37??:
Constructingmodelsisnotthepurposeoftheproject.
Constructing a model is only interesting as it helps
winthegame.
The purpose of the game is to deliver software. Any
otheractivityissecondary.A model, as any commu
nication, is sufficient, as soon as it permits the next
persontomoveonwithherwork.
Theworkproductsoftheteamshouldbemeasuredfor
sufficiency with respect to communicating with the
target group. It does not matter if the models are in
complete, drawn with incorrect syntax, and actually
not like the real world if they communicate suffi
cientlytotherecipients....
Somesuccessfulprojectteamsbuilt moreandfancier
models than some unsuccessful teams. From this,
manypeopledrawtheconclusionthatmoremodeling
isbetter.
Somesuccessfulteamsbuilt fewerandsloppier mod
els than some unsuccessful teams. From this, other
peopledrawthe conclusionthatless modelingisbet
ter.
Neitherisavalidconclusion.Modelingservesaspart
oftheteaminventionandpartoftheircommunication.
There can be both too much and too little modeling.
Scrawling on napkins is sufficient at times much
moredetailisneededatothertimes....
Thinking of software development as a cooperative
gamethathasprimaryandsecondarygoalshelps you
page 68
developinsightabouthowelaborateamodeltobuild
orwhethertobuildamodelatall.
The difficult part of this advice is that it requires you to
periodicallystop,thinkaboutwhatyou'vebeendoing,and
discuss with yourcolleagues about whether to turn up or
turn down the dial labeled modeling. There is no correct
answer.Thereisonlyananswerthatbetterfitsyoursitua
tionthansomeotheranswer.
TheansweriscomplicatedbytheShuHaRilevels of
thepeopleintheroom.SomeRilevelpeople willstepto
thewhiteboardorCASEtoolandmodelalmostasfastas
theycantalk.Other Rilevelpeople will do the modeling
in their spoken language, in their tests (using TDD or
XXD43),andintheircode.ARilevelperson'sadvicetoa
Shulevel person is likely to be to copy the Rilevel per
son'sstyle.Thatmayormaynotsuitthe Shulevelperson.
My suggestion is that Shulevel developers need to
modelanddiscussthosemodelswiththemostexperienced
peoplearoundthem, inorderto learn how tothink about
their models. As part of their professional growth, they
canlearnto modelinbothUMLandintests. CRC cards
andresponsibilitybaseddesign(Beck1987,Cunningham
???, Cockburn ???crc url, CRC book, Evans book, WB
book2)areverygoodwaystogetstartedwithlearningto
thinkaboutmodels.
The tangible artifact that exits the modeling activity
can take many forms. snapshots of whiteboards, UML
diagramsinaCASEtodrawingtool,collections ofindex
cards taped to the wall, videotaped discussions of people
drawingandtalkingatthewhiteboard,alltheseareuseful
indifferentsituations44.
Alwaysremembertopayattentiontobothgoalsofthe
game:deliverthissystemsetupforthenextroundofthe
gameandthenextpeoplewhowillshowupforthatgame.
For comparison, here are comments from three other
agile experts on the subject of how much modeling to
do45:
Jon Kern: "I am subconsciously stomping out risk
toagivenlevelsothatIcanproceedwithsomede
greeofconfidence.Ifonepartofthemodelremains
prettylightweight because you have done it before
100times,sobeit.Ifanotherpartofthemodelgot
very detailed due to inherent complexity and the
need to explore the depths looking for "snakes in
thegrass"well,thatjustiswhatitis!"
David Anderson: "I think I'd stop have enough
confidence when three features fail to add any
43
44
XXDisdescribedonpage???.
Icollectedanumberofphotosanddrawingsasworksamplesin CrystalClear
(Cockburn2005cc).Thereisn't spacetoreprintallthoseagain here.The inter
estedreadercanlookthroughthoseandotherworksamplesthere.
45
Allthreefromhttp://blogs.compuware.com/cs/blogs/ jkern/archive/
2006/03/29/Depth_of_Initial_Modeling.aspx
68
 Sw DevasaCooperativeGame
significantnewinformationtothedomainmodeli.e.
no new classes, associations, cardinality or multi
plicitychanges.Notsignificantwouldbemethodsor
attributechanges.Whenitlooks like the shape will
stand up to a lot of abuse without the need for re
factoringthenyouarereadytostartbuildingcode.
"However, in recent years I've done two layers of
domainmodeling.Thefirstwiththemarketingfolks
to help flush out requirements and help them un
derstand the problem space better. I have a lower
barfor"done"inthisearlystage.
"The second phase domain modeling done by ar
chitectsandsenior/leaddevshasthisverywellde
fined bar that the shape must hold because we
don'twanttopayarefactoringpenaltylater."
PaulOldfield:"Ihavesimilarexperiences[asJon]
I always know when I know enough about the do
maintomove on, and when I need to know more.
The only time I have a problem is when I can't go
back for more information later. For me the key
questionis,doIknowenoughtokeepmebusyuntil
the next time I get contact? If I'm fronting for a
team, the question is very similar Do I know
enoughtokeeptheteambusyuntilnexttime?"
Seewhatyourteamthinksistheappropriatethresholdfor
modeling.
TheHighTech/ HighTouchToolbox
The editors at CrossTalk magazine asked me to write an
articleaboutwhattheagile"toolbox"contains (Cockburn
2005tools???). This turned out to be doubly interesting,
because the agile toolbox contains both social and tech
nologicaltools,andbothhightechandhightouchtools.
Hightech tools are those that use subtle or sophisti
catedtechnology.Theseincludeperformanceprofilersand
automated buildtest machines, and hightouch social.
Hightouch tools are those that address social and psy
chological needs of people. These include daily standup
meetings,pairprogramming,groupmodelingsessionsand
reflectionworkshops.
People often find technology depersonalizing, so we
tend to see hightech tools as lowtouch, and tend to see
hightouchtools deliveredinlowtech.Thus, agile devel
operswilloftenexpressaninterestinusinglowtechtools
fortheirsocialsessions,suchaspaperflipchartsandindex
cards("sowecantouchthem,movethem,andremember
the discussion by the stains on the napkins"). More re
cently, people are using highbandwidth communication
technology to increase thetouch factor on distance com
munications (and indeed, the touch factor is one of the
reasons people might prefer watching videotaped discus
sionsoverreadingpaperdocuments).
page 69
Agile teams use an interesting mix of hightech and
hightouch tools, and an interesting mix of technological
andsocialtools.
The technological tools are interesting in their diver
sity.Therearethewellknownlowtech,hightouchtools:
lotsofwallspace,indexcards,stickynotes,flipchartsand
white boards. There are the wellknown hightech tools
for automated testing, configuration management, per
formanceprofiling,anddevelopmentenvironment.
Thereareautomationtoolsthathadlittleexistencebe
foretheagilewavehit,buthavebecomeindispensablefor
the modern agile team. Foremost among these are con
tinuous integration engines such as CruiseControl. These
runthebuildeverytwentyorthirtyminutes,runtheauto
mated unit and acceptance tests, and notify the develop
mentteam(inalltheirvariouslocations)abouttheresults
ofthetests(oftenbyannouncingwhosecodefailed).The
continuousintegrationengineholdstheteamtogetherboth
sociallyandacrosstimezones.
Therearethedistancecommunicationtools.These in
clude instant messaging tools with conversation archival,
microphones and webcameras to get "realperson" inter
action, speakerphones for daily standup meetings across
timezones,technicaldocumentationoninternalwikisites,
and PCconnected whiteboards to keep records of design
discussions.Alltheaboveservetofillthe gapleft bythe
absenceoffrequentpersonalencountersbetweenthepeo
pleondistributedteams.
Mostinteresting,however,arethespecificinclusionby
agileteamsofsocialtools.Thetopsocialtoolsaretocol
locatetheteamandattackproblemsinworkshopsessions.
Othersocialtoolsrevolvearoundincreasingthetolerance
oramicabilityofpeopletowardeachother,givingthema
chance to alternate highpressure work with decompres
sion periods, and allowing them to feel good about their
workandtheircontributions.
Thefollowingisthelistoftoolsfromthearticle:
Social roles such as coach, facilitator, and scrum
master.
Collocatedteams,forfastcommunicationandalsothe
abilitytolearnabouteachother.
Personalinteraction,withinandacrossspecialties.
Facilitatedworkshopsessions.
Dailystandupstatusmeetings.
Retrospectivesandreflectionactivities.
Assisted learning provided by lunchandlearn ses
sions,pairprogrammingsessions,andhavingacoach
ontheproject.
Pairprogramming,toprovidepeerpressure,aswellas
camaraderie, better pride in work, and energy load
balancing.
Asharedkitchen.
69
 Sw DevasaCooperativeGame
Toys,toallowhumorandreducestress.
Celebrations of success and acknowledgment of de
feat.
Goldcardsissuedatanestablishedrate,toallowpro
grammers to investigate other technical topics for a
dayortwo.
Offwork get togethers, typically a Friday evening
visit to a nearby pub, wineandcheese party, even
volleyball,foosball,orDoomcompetitions.
Postinginformation radiators in unusual places to at
tract attention (I once saw a photo of the number of
opendefectspostedinthebathroom!)
The interesting thing is probably less that agile teams do
thesethingsthanthattheyconsiderthemessential tools.
TheCenterofAgile
What wouldit meantoget "closerto the center" of agile
development?ThisisaquestionIoftenheardebated.The
troubleis,thereisnocenter46.
Most development teams are so far away from doing
agiledevelopmentthatitiseasyto givethema meaning
ful,"moreagile"direction:
decentralizedecisionmaking,
integratethecodemoreoften,
shortenthedeliverycycles,
increase the number of tests written by the program
mers,
automatethosetests,
getrealuserstovisittheproject,
reflect.
Theproblemonlyariseswhentheteamisdoingrelatively
well,andasks,"Whatismoreagile?",thinkingofcourse,
thatmoreagileequateswith better.
When we wrote the agile manifesto, we were seeking
thecommon points among people who have quite differ
entpreferencesandpriorities.
Forsome,testingwasimportant
Forsome,selforganizationwasimportant
Forsome,frequentdeliverieswasimportant
For some, handling latebreaking requirements
changeswasimportant.
These are fine things to strive for, and they are typically
missingontheaverageteam.Onceateamgetsathreshold
amountofeachinplace,however,itisnot clearwhichis
most important, which is the "center" of the word agile.
None ofthoseis most important across all project teams.
Each team must decide what is most important for it to
46
Rather like certain old European cities. The center of the city is the "old
town." But there is no center to the old town. It is just a maze of twisty little
passages, all different. Once you are there, it doesn't make any sense to ask,
"HowdoIgetclosertothecenterfromhere?"
page 70
addressatthistime.Eventually,there'snopointinasking
"whereismoreagilefromhere?"
HowAgileareYou?
Agile developers dreadbeingasked how to evaluate how
"agile"aprojectteamis.Partlythisisduetofearofman
agementintroduced metrics. Partly this comes from an
understanding that there is no "center" to try to hit, and
there is therefore no increasingly high numeric score to
target.
SCORINGAGILITY POINTS
Much to my chagrin and frustration, and over my
strenuous objections, the (really very experienced)
Salt Lake City agile round table group decided to
usethetableinthissectiontoevaluatetheprojects
they were involved in. After they had assessed
themselves for each property in the table, they
asked:"Butwhere'sthefinalscore?"
Tomyfurther chagrin andfrustration, and over my
further strenuous objections, they found ways to
score numbers for each property(and argued over
them, to try to raise their scores). After they had
added up all the numbers and declared a winner,
one of them said, "But this is no good we got a
high agility score and we haven't delivered any
softwareintwoyears!"
Which, as far as I'm concerned, proves my point
47
(seealsomyblogonthesubject ).
Nonetheless, a manager, the sponsoring executive, or the
team itself will want to track how it, or different teams,
are doing with their move into agile territory. Scott Am
blerwroteashort testthat provides a good starting point
(Ambler2005.12).Hewrote:
"My experience is that if the team can't immediately
fulfillthefirsttwocriteria then there's a 95% chance
thatthey'renotagile.
They
1. can introduce you to their stakeholders, who ac
tivelyparticipateontheproject.
2.canshowandruntheirregressiontestsuite.
3.produceworkingsoftwareonaregularbasis.
4. write highquality code that is maintained under
CMcontrol.
5.welcomeandrespondtochangingrequirements.
6.takeresponsibilityforfailuresaswellassuccesses.
7.automatethedrudGryoutoftheirwork."
Thefollowingisamoredetailedwaytoexaminehowyou
aredoing.It cameduringavisit toacompanythat hada
numberofprojectstryingoutdifferentaspectsoftheagile
47
See http://blog onagilitypoints???(cockburn url)
70
 Sw DevasaCooperativeGame page 71
approach. We characterized each project by how many
people were involved and the project's iteration length.
Since iteration length is secondary to frequency of deliv
ery (see "How short should an iteration be?", page ???),
weincludediterationlengthonlytocharacterizetheproj
ects,nottoevaluatethem.
We filled out this table, marking how frequently the
deliveries,thereflectionworkshops,theviewings,andthe
integrationshadhappened.Osmoticcommunicationgot a
Yesifthepeople wereinthe same room, otherwise we
wrote down the team's spread. Personal safety48 got 'No,'
'1/2,' or Yes, depending on a subjective rating. (If you
don'thavepersonalsafetyonyourprojects,canyouposta
'No'?)
For focus, we put down "priorities" if that was
achieved, "time" if that was achieved, or Yes if both
wereachieved.Forautomatedtesting,weconsideredunit
and acceptance testing separately (none had automated
acceptancetesting).
We marked some of the times with '!' if they seemed
outofrange.Seeinga'!'inoneplaceleadsyoutolookfor
a compensating mechanism in another part of the chart.
Forexample, both SOL and EVA had only one delivery,
after a year. Both received '!' marks by that delivery fre
quency.However,SOLhasacompensatingmechanism,a
user viewing every week. EVA, which had no compen
sating mechanism, did all the agile practices except get
tingfeedbackfromrealusers(missingbothdeliveriesand
user viewings). When that company finally produced a
product,theproductwasrejectedbythemarketplace,and
thecompanywentbankrupt(thisshouldhighlight theim
portanceof"Easyaccesstoexpertusers.")
UsethetableinFigure5'17togetalloftheproperties
above the dropoff (see "Sweet Spots and the DropOff,"
p.???),butdon'ttryforasummaryscore.Instead,usethe
tableto decide what towork onnext.Iwould,of course,
post the chart as an information radiator and update it
monthly.

48
From Crystal Clear, p. ???: "Personal Safety is being able to speak when
somethingisbothering you, without fearofreprisal.It may involve telling the
managerthat the schedule is unrealistic, a colleague that her design needs im
provement, or even letting a colleague know that she needs to take a shower
moreoften.PersonalSafetyisimportantbecausewithit,theteam can discover
and repair its weaknesses. Without it, people won't speak up, and the weak
nesseswillcontinuetodamagetheteam."

71
Sw DevasaCooperativeGame page 72

Project EBU SOL EVA GS BNI THT Ideal

#People 25 25 16 6 3 2 <30
FrequentDelivery 2weeks !1year! !1year! 1month 2months 4months! <3months
UserViewings 2weeks 1week !1year! 1month 1/iteration 1month <1month
ReflectionWorkshops 2weeks 1month 3weeks No No 1month <1month
OsmoticCommunica 1floor 1floor Yes Yes 1floor Yes Yes
tion
PersonalSafety 1/2 Yes 1/2 Yes Yes Yes Yes
Focus(priorities, priorities Yes Yes priorities priorities Yes Yes
time)
EasyAccesstoExpert No 1day/week No No voice, Yes Yes
Users email
ConfigurationMan Yes Yes Yes Yes Yes Yes Yes
agement
AutomatedTesting No No unit No No unit Yes
FrequentIntegration 3/week 3/week daily 1/week monthly 1/day continuous
Collaborationacross Yes Yes No No 1/2 Yes
Boundaries
Iterationlength 2weeks 1month 3weeks 1month 2months 1month <2months
Exploratory360 No Yes No No No Yes Yes
EarlyVictory Yes Yes Yes No No Yes Yes
WalkingSkeleton Yes Yes Yes No No Yes Yes
IncrementalRearchi Yes Yes Yes No No Yes Yes
tecture
InformationRadiators Yes Yes Yes Yes No Yes Yes
PairProgramming No No Yes No No No Maybe
SidebySideProgram No No No No No No Maybe
ming
TestFirstDevelopment No No Yes No No No Maybe
BlitzPlanning Yes Yes Yes No No Yes Yes
DailyStandupMeeting Yes Yes Yes Yes Yes No Yes
AgileInteractionDe No No No No No No Yes
sign
BurnCharts No Yes No No No Yes Yes
DynamicPriorityLists Yes No Yes No 1/2 Yes Maybe
Figure5'17.Awaytotrackprojects'useoftheagileideas.

72
 Sw DevasaCooperativeGame
IntroducingAgile
The question, "How do I introduce agile software devel
opment into my organization?" has no tidy answer. Here
are three ways to rephrase the question to highlight the
differentunanswerablequestionsthisonecontains.
"How do I get my company to change its corporate
culture?"
"How do I get someone else to change their way of
workingtomatchmine?"
"How do I convince my boss that his way of doing
thingsiswrongandmineisright?"
Eric Olafson, the CEO of Tomax whose move to agile
development was described in Chapter 8 (see page ???),
offeredanexcellentinsightintotheproblem.Hesaid:
"Youdon'ttransitionyourprojectstoagileprojects,
youhaveto transformyourpeopletothinkinagile
ways."
Transitioning projects you can put on a schedule. Trans
forming people you can't. Many executives since then
haveechoedEric'sinsight.
I wish I could write that in the last five years I have
seen enough organizations move to agile development to
formulateagoodsuccess strategy. Unfortunately, I have
n't,andhave,instead,becomewaryoflargeorganizational
initiatives.Myownskepticalphrasingis:
"ForanyorganizationwideinitiativeX,Xgetsre
jectedbytheorganizationalantibodies49."
AgiledevelopmentisjustonevaluewecanpluginforX.
The failure often comes from a backlash effect that
shows up after one or more projects have delivered suc
cessfullyandsometimesevenbecausetheprojectdeliv
ered successfully. Apparently, simply delivering projects
successfullyisnotsufficienttomakeachangestick50.For
more discussion on organizational change, see "Business
asaCooperativeGame"onpage11.
Canwesayanythingabout introducingagile develop
ment into an organization? The book Fearless Change
(Rising2003???)containssomeobservationsfromchange
groups. Here are some starter do's and don'ts from other
teams.Bearinmindthatmanyoftheseideashelpyouget
started,butnoneisadequatetomakethechangestick.
Don't make an executive proclamation that all devel
opment will be done using the agile approach and then
hiretrainingforeveryone inthecompany.This approach
page 73
will burn up a lot of money quickly, and fuel the resis
tancemovementfromthebeginning.
Do seek support at both the highest and lowest levels
of the organization. The programmers, at least, have to
want the change, and they need the input and support of
someoftheexecutiveteam.Eithergroupwithouttheother
willbecomeisolatedandunabletoproceed.
Dogetoneprojectteamworkingsuccessfully.
Do staff that team with at least two people who are
competent,respected,andcanpullofftheagileapproach.
Don'tshower that team will an undue amount of sup
port and attention. The other teams will just feel left out
andgetannoyedatthatteam.
Dogetexpertsintohelp.Placethemintheteams,not
outsideasadvisors.
Doconsidertheusers and the executive sponsors part
oftheteam("There'sonly us").
Do reflect on what you are doing each month, and
change your working convention to get better. If you are
not changing something, trying out something new, each
month for the first few months then you probably aren't
gettingatasteofityet.
Do deliver real software to real users, quarterly, or
betteryet,monthly.
Do prepare for a backlash to come from somewhere
youcan'tsee.
Finally,onewordofcomfort:The higherlevel execu
tivesprobablywantwhattheagileapproachoffers,which
is
"Earlyandregulardeliveryofbusinessvalue."
Ihavenotyetmetanexecutivewhofindsthatatroubling
proposition.Theyusuallyagreethatthedevelopmentpro
cess needs lightening, testing needs to be beefed up, and
users more involved. The increased visibility given by
agilestatusreportsareacomforttothem.Theyappreciate
being able to make midcourse corrections. Early and
regulardeliveryofbusinessvaluehelpsthebottomline.

49
ThankstoRonHolidayforthisoutstandingconcept("organizationalantibod
ies")!
50
ThisisagoodtimetorereadGeraldWeinberg'sThePsychologyofComputer
Programming (1999).Hiswritingscontainmanystoriesinthisvein.

73
 Sw DevasaCooperativeGame page 74
about2pages
Introducing Agile from the Top 10 Lessons, by
EricOlafsson,CEO,Tomax
about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages

74
Sw DevasaCooperativeGame page 75

about2pages

75
 Sw DevasaCooperativeGame
AgileOutsideSoftwareDevelopment
Agilesoftwaredevelopment calls forcustomercollabora
tion.Collaboratingactivelywiththecustomerwillimme
diately bring into discussion the company's contracts,
sales,maintenanceandcommunicationsrelationshipsin
otherwords,thewholebusiness.Acompanythattakesthe
agilemodelseriouslywillhavetomakeadjustmentsinall
thoseareas.
Fortunately, the agile approach works well in most
business environments. Let us look at a series of cases
starting from the software arena and moving outward to
businessingeneral.
Projectportfoliomanagement.
Any large organization has a portfolio of projects under
way at one time. The management team should balance
theeffortbeingspentoneachprojectonaquarterlybasis,
ifnot moreoften.Theyrunintotwo problems: staff spe
cializationandfindingstoppingpoints.
Inmostcompanies,onepersonbecomes the expert on
onepieceofcode.Everytimeafunctionischangedinthat
piece of code, the organization is dependent on that one
persontodothework.
One of the characteristics of agile development is in
creased communication, hopefully with osmotic commu
nication. In some cases, as with XP shops, programmers
work in pairs, and change programming partners fre
quently. This means that more people learn to work in
each part of the system. With rotating pairprogramming
partners,theorganizationcanshiftaprogrammertowork
onamorecriticalprojectwhenneeded,with(possiblyless
qualified)peopleabletoworkontheothercode.
Even without pairprogramming,it is stilla good idea
to crosstrain people on each other's code bases. The un
derstudy may be less proficient, but will still be able to
carryouttheneededwork.
The second problem with project portfolio manage
ment should be easier to deal with. With properly exe
cuted agile development, the system is put into a stable,
shippable state every week, month, or quarter. At those
points, the people on the project can be moved to other
projectsasneeded.Thereisadangerofthrashing mov
ingpeoplebackandforthsooftenthattheylosetrackof,
or interest in, what they are working on but there is at
leastthe optionofrebalancingtheproject portfolio to re
flecttheorganization'scurrentpriorities.
With properly executed agile development, project
teams will be working on the most valuable features of
page 76
eachsystem51 in eachincrement.This means that when a
projectistrimmedorputonhold,itisalwaysinauseable
state.Itmight happen that the organization never restarts
theproject,orchanges its direction. These are both valid
outcomesofprojectportfoliomanagement.
There is, of course, one remaining problem: the diffi
cultyinobtainingmeaningfulmarketdatatodecidewhich
featurestomoveforwardintoearlyincrements,andwhich
tomovebackordrop.Ihavenotyetmetanymarketana
lysts who can provide comparative market forecasts for
productsdown to the feature level. Real project portfolio
managementrequiresthatthemanagementteambeableto
comparecostand benefit numbers at the feature level, in
ordertodecidehowtobestbalancetheiruseofscarcere
sourcesindevelopment.
It probably will take a combined group of senior de
velopers(toprovidethecostnumbersatthefeaturelevel),
market specialists (to provide the return numbers at the
featurelevel)andcreative management facilitation to en
gage the group in discovery of interesting strategies for
development sequences, in order to come up with good
answerstotheproject portfolioquestion.Note,as before,
the importance of keeping the cooperative game and
"there'sonlyus"mindset.
CustomerRelations
Companiesthatdocustomdevelopmentmayhavetrouble
with agile development because their relationship with
their customers doesn't support the point of view that
"there is no them everyone is us". When the contracted
company proposes that the customer visit the project
weekly to provide input and steer the priorities on the
project, the customer replies, "But that's what we hired
you to do!" This is a loselose worldview. The customer
doesn'tgetthebestsystemtheycan,andtheprovideradds
risktotheproject.
Experiencedreaderswillrecognizethattheagilemodel
ofcustomerrelationshipmatchesthatcomingfromToyota
and lean development (toyota 1995?). One would there
forehopethatclosecustomercollaborationwouldbeeasy
to achieve. However, my reading of the lean literature
doesn't make me very optimistic on this score. Toyota's
customer and vendor relation model has not penetrated
the minds of most executives even after decades of pub
licity and exceptional results. I can only think that every
51
Seethediscussionofworksequencingstrategies(CockburnCC2005,pp.??)
andtheuseofthe"iceberglist"(CockburnbcURL2004)fora more complete
discussionofthisidea.
76
 Sw DevasaCooperativeGame
additionalpushfromtheagilesidehelps.Tomax'sresults
(see next sidebar) are heartening, because they show that
customerscanbecomeusedto,andthenexpect,topartici
pateinsteeringtheirprojects.
Contracts
Companiesthatdoworkoncontractarealwaysfacedwith
the problem of price, scope, and time (this applies to all
industries). Clients oftenwant allthreetobefixed,to re
duce their own risk. I see only (to date) only a few op
tions:
Fixedprice,fixedscope(andpossiblyfixedtime)
Thisoptionistheoldone:Doyourbest,howeveryoudo
it,tocomeup withanumberfortheproject.Once inside
theproject,squeezeallthefatoutoftheprocess,usingall
thebestagiletechniquesyoucanmuster(see"Process,the
4th Dimension" (Cockburn 2005 Pt4D)) to deliver it as
well as you can. As far as I can tell, agile techniques do
not change yourabilityto estimatea project. Despite our
most fervent wishes, estimating a project is still a matter
of previous experience, feel, and guesswork. Fixed
everythingprojectsmakesensewhentherequirementsare
verystable.Theyarealsousedwhenthetwopartiesdon't
trust each other, even though there is usually plenty of
leeway for one party to twist the situation to the other's
disadvantageiftheywant.
Fixedprice,fixedscope(andpossiblyfixedtime)but
collaboratewiththecustomerstoalterscopeanyway
Ariskyapproach,Ihaveseenitdonesuccessfullyseveral
times,twiceforcommercial projects and once for a state
government project. Jeff Patton (Patton 2004) describes
workingcloselywiththecustomersatthestartoftheproj
ecttoidentifyneeds,wishesandpriorities.As theproject
proceeded, Jeff made sure they were always working on
themostimportantitems.Astheygotclosetotheendof
thetimeperiodanditwascleartheywouldcomeupshort
onfeatures,hemadesurethat theitems left undone were
clearlytheleastimportantones.Thosethecustomereither
forgaveorrolledintoafollowoncontract.
The government contract I tracked was again a fixed
everything contract. The team worked closely with the
users of the system, delivering and installing running,
tested, usable software every month. After each delivery,
theydiscussedwiththeuserswhethertocontinuewiththe
contractaswritten,orchangedirectionsbasedonwhatthe
users really needed. I found it remarkably brave of the
contractedcompanytofollowtheusers'requestsindevia
tion,becauseinahostilesponsorshipsituation,theywould
havebeenatriskofnonpayment.However,theuserbase
was sohappywiththeusefulness of the functionality de
liveredthat thecontractedcompanygot paidinfull. This
page 77
wasacaseofconvertingafixedprice,fixedscope,fixed
timecontractintoatimeandmaterialscontractonthefly.
Adangerousbutwonderfulstrategyifyoucanaccomplish
it.
Timeandmaterials
Thisissimplyamatterofpayingforworkasitgetsdone.
It is obviously the best format to use if the requirements
arevolatile.InonecaseIwon'tevencall it a project
the sponsor changed the requirements wildly, even up to
daysbeforedelivery.Thecontractedcompanyalways de
liveredwhatevertheyhadrunningattheend ofthe quar
ter, and the sponsor always had complete control as to
what was onthe top of the priority list. Over a period of
years,itbecamesimplyabalancedflowofusefulsoftware
inonedirectionandmoneyintheotherdirection..
Ifthesponsortruststhecontractedcompany,thisisthe
simplestcontracttouse.Thedifficultyisthatitrequiresa
certainleveltrust.Whatsomecontractorsdoistorequest
a trial period. Using the agile approach, they deliver us
able functionality early, and so establish the trust of the
sponsor for subsequent work (see the house construction
exampleonpage95???)
Nottoexceedwithfixedfee(NTE/FF)
This is the contract method used in the airport construc
tion example on page 97???. It presupposed stable re
quirements. "Fixed fee" means that the contracted com
panyisguaranteedacertainprofitmarginovertheirmate
rialsandsubcontractors'fees.Thisprotectsthecontracted
company in case requirements are reduced or the work
goes fasterthanestimated."Not to exceed"putsaceiling
onthetotalamountpaidtothecontractedcompany,which
protects the sponsor in case the work goes slower than
expected. With protection for both sides, both sponsors
and contracted company can look for ways to speed the
work, and live with unfortunate events. The airport con
structionproject on page 97??? used this form with Pay
mentonincrementalacceptance.
Fixedpriceperfunctionpointorstorypoint
Whenthecustomerandcontractedcompanycanagreeon
aunitofdelivery,suchasfunctionpointsorstorypoints,
then they can settle on a price for each unit delivered. A
numberofcontracthousesthesedays estimatethesizeof
a project in function points, create a price per function
point delivered, and then have an certified function point
auditorassess theactualnumberoffunctionpoints deliv
eredinthe end.Thecustomerthenpays thatamount,not
the originally estimated amount. This is a nice contract
form, because it encourages the contracted company to
work more efficiently(toincreasetheirpayper delivered
77
 Sw DevasaCooperativeGame
function point) and it allows the customer to change the
requirementsalongtheway.
ThesamecanbedonewithXPstylestorypoint(Cohn
2005), except that there aren't any certified story point
examiners tojudgethefinalresult.BobMartinof Object
Mentor posted an interesting variant to get around this
problem: a base fee per story point, plus a lowerthan
usual(closetoorbelowcost)feeperhour.Thisbiasesthe
contracted company's to deliver early, but gives them
some protection in case work proceeds slower than ex
pected.BobMartindescribeditthisway:
"[A]greetopayacertainamountforeach point com
pleted, plus a certain amount for each hour worked.
For example, let's say you've got a project of 1000
points. Let's also say that a team of four has estab
lished an estimated velocity of 50 points per week.
This looks like about an 80 manweek job. At
$100/hour this would be a $320,000 job. So lets re
ducethehourlyrateto$30/hour,andaskthecustomer
for$224perpoint.
This sets up a very interesting dynamic. If the job
really does take 80 manweeks, then it will cost the
same. If it takes 100 manweeks then it will cost
$344,000. If it takes 70 manweeks it will cost
$308,000.Notice thatthisisasmall difference fora
significant amount of time. Notice also that you, as
developer feel strong motivation to be done early,
since that increases your true hourly rate." (Martin
2006)
I have not seen that model in action myself, but several
peoplehavewritteninrecommendingit.
Venturecapitalfinancingmodel
Thiscanbeusedwithanyoftheabovecontractforms.In
this model, the sponsor gives a round of financing for a
certainamountofwork,andthecontractedcompanymust
produceresultsinordertoget morefunding.Thesponsor
cancuttheirlosses atanytime iftheyarenot gettingthe
resultstheyneed.Theycanpresumablyaltertheterms of
thecontractaftereach work period. The result of a work
periodneed not beworkingsoftware it could be a paper
study,orarequirementsdocument,oranythingthespon
sorselects.
Theventurecapitalfinancemodelworkswellwithag
ileproviders,sincetheagileproviderisusedtodelivering
useful,workingsoftwareearlyandregularly.
Ifinditanoddironythattheventurecapitalfinanciers
running startups that I have encountered don't take ad
vantage of their own model to the extent agile teams do.
The venture financiers let the evaluation markers occur
toofarapartintime.Ifthey attached funding to monthly
releases, that would oblige the startup team to think
through what it really can accomplish each month. The
page 78
monthlyprogresswouldgivethefinanciers abettersense
ofthestartupcompany'srealprogress.
Incrementaldeliverywithpaymentonincrementalaccep
tance
Thiscanbeusedwitheitherfixedeverythingcontractsor
the NTE/FF contract. The sponsor expects incremental
deliveryofintegrated,testedsystems,constructsandruns
acceptance tests at each delivery increment, and pays the
contractedcompanyaftereachsuccessfulincremental ac
ceptance.Thiswasusedintheairportconstructionproject
(p.97??)andinSolystic'sFrenchPostOfficecontract (p.
101???). Both project leaders told me that this payment
schedule has a wonderful motivating effect on the con
tracted company. The requirement, of course, is that the
sponsors have an understanding of incremental develop
ment and can make acceptance tests for the incremental
deliveries.
Hereis asidebarabout revisitingthecustom contract,
byEricOlafsson,theCEOofTomax(whoalsoprovided
the sidebar on page 85???). Tomax produces customized
retailsystems.
A few years ago, Tomax worked to fixedeverything
contracts.Theywere,ofcourse,problematic,sincesome
thing was certain to change even within a simple, three
month contract. Eric used the agile model to change the
company's relationship with its customers. They now
writes contracts so that the customer gets early results
through incremental development, and can cancel or
change direction after each increment. In exchange, the
customer promises in the contract to make its experts
availabletothedevelopmentteamandtoactivelysteerthe
project'sdirection.
The contract converts the customer from "them" to
"us", part of the larger development team. The customer
gains early returns and greater steering control. Tomax
reduces itspricingriskandget betterinput from the cus
tomersidestakeholdersandusers.
78
 Sw DevasaCooperativeGame page 79

about2pages
RevisitingtheCustomContract,byEricOlafsson,
CEO,Tomax
about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

about2pages
about2pages

79
Sw DevasaCooperativeGame page 80
about2pages

about2pages

80
 Sw DevasaCooperativeGame
IntroducingChangeIntoAnOrganization
Introducingchangeintoanorganizationisscaryanddiffi
cult.Agiledevelopmentisdoublyscarybecauseitsays:
First,changethewayyoudothings
Next,keepchanging,forever.
This puts agile development fully within the topic of in
troducingchangeintoorganizations,averydifficulttopic,
indeed.
The noted family psychotherapist Virginia Satir stud
ied, among other things, people's reactions to change. A
key observation of hers was "if theres ever a question
between comfort and familiarity, familiarity will almost
alwayswinout."(Satir1999).Thatis,evenifthefamiliar
modeisinefficientanduncomfortable,peoplestaywithit.
TheProcessMiniature
A useful corollary of that observation is that things are
easier the second time they are more familiar. This
shows onepossiblewayout ofthe unfamiliarity trap: the
ProcessMiniature(CockburnCC2005).
Aprocessminiatureisnothingmoreorlessthangoing
throughthenewprocedureinasshortatimeaspossible:a
minute,15minutes,anhour,adayor a week, depending
ontheprocess.
We can work through a simple example of the plan
ning game (XP planning game ref???) or the blitz
planning technique(CockburnCC)in15minutes.
Inthe"ExtremeHour"game52 peoplerunthroughtwo
iterationsofXPinonehour.Thereisaonehourver
sionusedinshowingpeoplehowScrumworks.Icre
ated a theatre piece of Crystal Orange Web (see p.
???),runningthroughtwoiterationsofdeliveringreal
codeontheirsystemplatformin90minutes53.
In my usecase course, I run a onehour process
miniature of gathering use cases, from defining sys
tem scope to stakeholders' interests, naming all use
cases,andwritingdefiningoneusecases completely,
toshowhowallthepartsoftheprocessfittogether.
Onecompanyhad every new employee go through a
full development and deployment cycle in one week
to learn their company's process. After having com
pleted that initial miniproject, the new employee
couldbeplacedonanyproject,inanystageofdevel
opment, and would have an understanding of what
wasgoingon.
Going through a process miniature creates in the mind
whatGradyBoochneatlybutmysteriouslycalledagestalt
52
http://c2.com/cgi/wiki?ExtremeHour
53
http://c2.com/cgi/wiki?ExtremeHourWithActualProgramming
page 81
roundtrip(ref?).Afterthegestaltroundtripiscompleted,
the process exists as an entirety in the mind, can be
viewedinternally,andimportantforushere,isabitmore
familiarandlessfrightening.
AnchoringNewBehaviors
The process miniature also creates what sociologist Karl
Weick calls a 'small win' (Weick 1975??). Weick found
that small wins strengthen a group's strength and self
image. Good groups look for early, small wins to
strengthen their sense of team accomplishment. One of
these that system designers use is the Walking Skeleton
architectural strategy ("a tiny implementation of the sys
tem that performs a small endtoend function" Cock
burn2005ccp.55???)).
Oneofthesurprisestomewasthatpeoplegetmileage
outofsmallrewards,evenverysmallrewards.Evidently,
thesealsocountassmallwinsinthemindofthereceiver.
Iwas onthereceivingend ofthis technique onetime:
Acolleaguevisiting myhousesaw how myassistant had
createda"project wall" showing all my ongoing projects
andtrips.Hesaid,"Wow,that'sgreat!Here,I'llgiveyoua
quarterforshowingmesuchagreatidea."Afewminutes
later he found something else that he liked and gave me
another quarter. I found myself irresistibly drawn to of
feringhimideasandlookingtoseewhichhethoughtwas
worth his little token offering. I managed to get six of
thosequartersbytheendofhisvisit,andIstillkeepthem
inaspecialplaceasamemoryofhisappreciation.
You might not thinkthat atokenas small as a sticker
wouldhaveanyimpact onpeople's behavior, but justthe
act ofgivingandreceivingatoken ofappreciationorac
complishment has meaning to the receiver. Here is Kay
Johanssen'sstoryofusingstickerstohelpcreatechange:
Creating Change with Stickers, by Kay Johans
sen,TestManager
Ourcompany's product was a variety of internet services
not amenable to commercial automated testing tools, so
we needed a programmingintensive approach to auto
matingthetests.AsTestManager,Iputtogetherateamof
fivetesters,mostofwhomhadsomecodingbackground.
Frustratingly, we made no progress on automation.
Everyday,wecametowork,intendingtoprogramanew
automated test, but we could always see the backlog of
material that needed testing right now, manually. Being
goodcitizens,weperformedthosemanualtestsinsteadof
startingprogramming.
I knew something had to be done, or we'd never get
ahead of this mountain of manual work. Since we were
runningiterations withXPlike "stories,"Icreatedstories
for a test framework. After a few iterations, we had
81
 Sw DevasaCooperativeGame
hacked together a framework and about three tests. That
was as far as it went for a while. The mental switch re
quiredtofigureouthowtowriteeffectiveautomatedtests
seemedtoogreat.Andthemountainofmanualtestingwas
alwaysthere.
My first strategy was posting posted a large, visible
chart with the number of tests on it. The number was
three.
I waited for it to increase. We made little progress
during the next couple of months. Interest seemed low. I
created stories for writing tests, and the team would
sometimes obligingly force a test out, or as often as not,
fail to complete their automated test story because they
spent extra time doing areally good job on their manual
testing stories. They were looking out for the customers,
and I couldn't criticize them for that. Still, something
neededtobedone.
Onedaywhileatthegrocerystore,Inoticedapackage
of shiny stickers, I think they were colored stars. On a
whim, I bought the package and took it to work. At the
start of the next iteration, I announced that anyone who
completed an automated test would get a sticker. That
caught their interest. After they finished laughing, they
signedupforthefewautomatedteststories withalacrity.
My impression was that they finally felt they were not
being perceived as "selfish" if they signed up to write
automated tests they had permission to do what they
wantedto do anyway. Even better, they were competing,
playingthegame!
Overthenext few weeks,thechart of automated tests
shotup,eventhoughtherewereno"prizes"for"winning"
andnoconceptofanenddateorfinalcounting.Theteam
wasenergizedandenjoyedaspiritoffriendlycompetition
andcooperation.Ididnothing morethancount tests and
handoutstickers.
Someteam members collected stickers on their moni
tor for all to see. Others pasted them on 3 by 5 cards so
theycouldcarrythemtomeetingstobettershowthemoff.
Thetesterwhohadnocodingexperiencegotalotofhelp.
..andendedupwiththemoststickers.
Before long, an online, automatically updated, full
colorchartreplacedmyhanddrawnbigvisiblechart.Test
problems and framework problems got solved quickly.
Soonwehadarobustframeworkthatevenincludedatest
scriptrecorder.
Theteam grew confident, and set a goal for 550 tests
bytheendoftheyear,whichtheyeasilyachieved.
I eventually stopped handing out stickers, but the en
ergy and confidence continued. One year later the team
hadwellover1,000automatedtests.
page 82
ALargeChangesisManySmallOnes
If people are afraid to make small changes in their
habits,theyaremoreafraidoflargechanges.
MikeCollins,anexpertatleandevelopment,addressed
this problem in an interesting way at the O.C. Tanner
Manufacturing Company in Salt Lake City (see the next
sidebar). In reading the sidebar, you many note that his
method draws on Satir's idea of growing familiarity and
Weick'sideaofsmallwins.
Mikeunderstoodthatifheshowedupattheircustom
awardsmanufacturingfactorywithadesignforatenfold
improvement in their system, he would encounter resis
tance from employees and management. Instead, he cre
atedanewproductionareawithaminorset of modifica
tions,fromwhichtheygotanoticeablebutnotrevolution
aryimprovement.Hepostedtheresults,reflectedwiththe
peopleinvolvedaboutpossibleimprovements,andcreated
a second trial production area that was both smaller and
faster.
WhenIfirstvisitedO.C.Tanner,theywereusingtheir
thirdnew production area.The original and the first trial
productionareaswerestillinuse.Thenewoneusedabout
aquarterofthefloorspaceoftheoriginal,andfilledcon
tractsinaboutathirdthetimeoftheoriginal.
Atthetimeofthis writing,the entirefacility has been
convertedtofourthgeneration'minifactories'astheynow
callthem.Productionlead times have been reduced from
over18daystoabout6hours,withathreefoldincreasein
efficiency.Withthesmallerfloorspace,productionwork
ersgetosmoticcommunication.Aninformationradiatorat
theentrancetotheirproductionarealetsthemandtheir
managers see what is being worked on as well as the
productivityeffectsoftheimprovedsystem.Theyexpect
todoubletheirefficiencyagainduring2006.
What I found impressive was not so much the im
provements the team had made (which Mike might have
been able to accomplish from his prior experience and
lean manufacturing theory), as his patience in working
through a sequence of small changes and victories rather
thangoingforonebigwin.Inoteinparticular:
Eachprocessgotgoodenoughbusinessresultstopay
foritselfasitproceeded.
Sincetheworkersintheproductionareawereinvited
to help set the direction of improvements, there was
betterbuyinfromtheworkers.
Both management and workers get usedto having an
evolvingproductionprocess as a normal part of their
workingclimate.
82
 Sw DevasaCooperativeGame page 83
Mike and I both noticed that he would almost certainly
have met too much resistance to succeed if he had pro
posedthethirdorfourthlayoutattheverybeginning.
Noticeinthebusinessliteraturethefrequentreportsof
a company achieving breakthrough results by making
manysmallchangesandreflectingonthosechanges.The
latestIreadwas about the Outback Steakhouse soliciting
ideasfromemployees,tryingthem out inselectedrestau
rants,andthendecidingwhichonestofranchise.
Theseideastendtocomefromwithintheorganization,
ratherthanfromanoutsider.This is the "wearetuningit
for us" principle, something I consider a critical success
factorfortheadoptionofnewprocesses.
There is one other factor that assists in installing
change:athreat tothecompany'ssurvivalfroman exter
nalsource.Thisiscoveredinthenextsection("Program
mersReadtheHarvardBusinessReview").

83
 Sw DevasaCooperativeGame
Lean Manufacturing at O.C. Tanner, by Mike
Collins, Vice President Lean Enterprise Devel
opment,O.C.Tanner
The O.C. Tanner Company produces and ships about
9,000 employee recognition awards a day. Our work can
bestbedescribedasmasscustomization,inthatwepro
videseveralmillioncombinationsofawardswithanaver
ageordersizeof1.3awardsperorder(91%oftheorders
areforoneaward).
Five years ago, we started down the lean manufac
turingtrack.Overthosefiveyears,
the time from when an order is placed until we ship
thefirstpiecehasdroppedfrom18daystosixhours,
qualityhasrisenfromalowof80%to99%,
ontimedeliveryhasrisenfromalowof60%to99%,
workinprocess (WIP) has dropped from almost
500,000piecestolessthan6,000.
WIP used to be so large partly because we used large
batchsizesbetweenstations,butalsobecauseweranpro
duction quantities at 10% or more over the actual order
quantitytocompensateforthequalityproblems.Thelarge
WIP meant we had people working fulltime to move,
find,expediteandotherwisemanagetheWIPpieces.
To measure our production improvement, we use a
QualityEfficiencyDelivery (QED) metric that averages
improvementsinquality,efficiency,and ontime delivery
of the current year over the previous year. The improve
mentscorewas34%ineachofthelasttwoyears.Thisisa and creative improvement therefore had to move to the
notableachievementgiventhatcurrentperformancelevels
withbothqualityandontimedeliveryarenear99%,with
efficiencynearly3timesbetterthanitwas5yearsago.
Even though virtually every system, process and
practicehasbeenrethought,themostcriticalaspectofthe
change has been a change in how the people think about
theirjobs andthecompany.Changingpeople and culture
is much more difficult than changing systems, processes
andpractices.Infact,toeffectivelychangesystems,proc
esses and practices requires that people and culture be
changedfirstoratleastinparallel.
Most of the employees had been with the company
formanyyearsandwerewellentrenchedintheroutinesof
their work. The company was reasonably profitable with
good employee benefits and few saw any reason for
change.
Initially,productionconsistedof28departmentswith
each department working more or less independently of
the others. Within each department, employees generally
had only a single or perhaps two job skills. Work was
passed in batches from employee to employee and from
page 84
department to department. Most employees focused on
theirsingleskilljoband few of the employees made any
suggestionsforchangeandevenfewereverparticipatedin
anychangeeffort.
To make the progress realized to date has required
severalcriticalchanges:
Teams hadtobeimplementedinwhichthecollective
creativethoughtofallcanbeharnessed.
O.C.Tannerwentfrom28productiondepartmentstoone
department of 11 teams. Each team is in and of itself a
selfdirected minifactory capable of producing every
awardcombination.
Working as a team member is not natural for those
coming out of many of todays school systems. Think
aboutit.Schoolislargelyaboutcompetition,aboutgetting
the best grade. It means that there must be both winners
andlosers.If,however,ateamistobesuccessful,thefo
cusmustchangetomakingeveryteammemberawinner.
Working as a team member requires that we greatly im
prove many of our skills, such as our communication
skills.Thischangeinthinkingisnotaneasychange.
Management had to move out of the management
mindsetandmoreintoamindsetofleadership.
Thejobofmanagement jobisnow muchlessofthe day
today management of work and much more one of fa
cilitating,teachingandsupportingtheeffortsoftheteams.
The first change to managements thinking was to
learn that teams not only can, but most often will make
better decisions than the manager. Most decisionmaking
teammembers.
Because the manager often has had greater experi
ence,heorshewillseethattheteamonoccasionis mak
ingamistake.Itisleadershipthatallowsthemistaketobe
made,recognizingthatwelearnmostlyfrommistakes.
Soundjudgmentisofcoursenecessary.Themanager
must balance the potential learning that comes through a
mistake with the potential damage to the company. This
changeinthinkingisalsonotaneasychange.
Team members had to learn multiple job skills, and
were expected to participate in the many of the im
provement efforts of the company. Most employees
rotatebetweenassignmentsduringtheday.
Astheteammembers learntodothis,theyfindthat they
aremoreselfmotivated,moreinvolvedandmoresatisfied
withtheirworkexperience.Thejobsarelessmundane.
Almost all of the employees will tell you that they
wouldnevergobacktotheoldsystem.
Trainingwasakeyfactor.
Trainingmeantnotonlyjobskilltrainingbutalsotraining
in many other areas, such as team skills, communication
84
 Sw DevasaCooperativeGame page 85
skills,creativeproblemsolving,coaching,conflictresolu
tion, etc. Training included handson efforts at making
improvementsandsolvingproblems,and eventheunder
standing and use of statistics, which is very often neces
sarytothemakingofgooddecisions.
Atfirstonemayevenquestionthewisdomofmaking
thesechanges.O.C.Tannerislearning,however,thatitis
onlywithtimeanditisonlybydoingthatanorganization
canbegintoseethebenefitsofstayingontheleantrack.
The change rate at O.C. Tanner is accelerating. We
expect efficiency to double again in the next 12 months.
Leadership,insteadofcontinuallypushingthecompanys
employeesformore,isnowfindingitselfinapositionof
not being able to support or even stay on top of the
amount ofchange nowtakingplace.It is an enviable po
sition.

85
 Sw DevasaCooperativeGame
ProgrammersReadtheHarvardBusinessReview
An odd cultural shift has been the increasing number of
programmers and testers who are reading the Harvard
Business Review (HBR). This is a direct consequence of
theirwatchingthebusinessconsequencesoftheirfrequent
deliveries andtheirprioritization choices. Enough techni
calleadshavewrittentometoalertmetosomearticlein
theHBR that I ended up subscribing to it myself, just to
keepupwithwhattheagiledevelopmentcommunitywas
discussing.
Asasampleexample,theApril2006issue(thetimeof
thiswriting)containstwoarticlesrelevanttothetopicsin
thisbook.
Ram Charan's article, "Home Depot's blueprint for
Culture Change" (Charan 2006) details Home Depot's
massiveculturalchangeprocess as it went from a decen
tralized, entrepreneurial set of stores that could not or
would not collaborate, to a centrally orchestrated set of
storesthatdidcollaborate.ThenewCEO,RobertNardelli,
wasbroughtinfromGE exactlyto makethat sort ofcul
turalchange.
Nardelli had one force on his side their competitor,
Lowe's,wasgainingquickly,anditsoonbecameclearthat
Home Depot's survival was at stake. Nardelli used that
forceto make manychanges veryquickly.While hard, it
hadtheadvantagethatresultsalsoshowedupquickly.
When people complained about the pace of change,
Nardelli was able to answer back, "Good point. Give me
fiveminutes.I'mgoingtogocallLowe'sandaskthemto
slowdownforus."
This sort of external threat helps a lot in installing
change.
Keytotheirchangeprocesswastheinstitutionofmet
rics.Ifounditinterestingtoreadthatmetricswereusedto
increasecollaboration,the"we'reallus"mindset:
"At the same time, the metrics made clear and rein
forced the collaborative behavior and attitudes that
Nardelli and Donovan wanted to encourage.
. . . Companywide metrics also provided a platform
forcollaboration."
They used the metrics to show that they made a greater
profit when working together than working separately or
competingamongstthemselves.
Theyinstituted
anannualstrategicconference,
learning forums for managers in which they ran
simulations of various collaborative and competitive
strategies,and
page 86
weekly conference calls among the top executives
aroundthenation.
Alert readers will recognize all of these as staples of the
agileapproach.
Inotedtwomorekeypointsinthearticle,thefirstcon
cerninghowlongittakestogetaculturalchangetostick,
andthesecondabout theimportance of suggestions from
insidetheteam:
"AyearandahalfafterNardellitookoverasCEO,he
andDonovanknewthattherestillwassignificantop
position within the organization to the changes they
weremaking."
"Assuming the rate of change is more or less right,
how do you make it stick? . . . Where possible, get
people affected by a change to help define the prob
lemanddesignthesolution."
Notehowsimilarthesepointsare to those raised by Eric
OlafsonandMikeCollinsintheirsidebars.
ThesameissueoftheHBRheldanarticleaboutglobal
localization(Rigby2006):
"Standardized offerings discourage experimentation
andareeasy forcompetitorsto copy . . . Customiza
tionencourageslocal experimentation and is difficult
forcompetitorstotrack,letalonereplicate.Whenwell
executed, location strategies can provide a durable
competitive edge for retailers and product manufac
turersalike."
"...successfullocalizationhingesongettingthebal
ance right. Too much localization can corrupt the
brand and lead to ballooning costs. Too much stan
dardizationcanbringstagnation..."
The recommended strategy is to standardize within a re
latedcluster of situations, and localize separately in each
cluster.
Thisstrategymatchesthediscussionearlieroftailoring
methodologies toprojects(see "Methodologies across the
organization",page24???).
Several organizations I have visited came to the con
clusion that they could benefit from three base method
ologies (for each major project type they encountered),
andtheyshouldthentunethebasemethodologylocallyon
the project. This allows them some scale advantages and
sometailoringadvantages.
TherearetwopointsIwishtodrawfromtheabove:
Modern agile programmers do care about how their
work influences the organization, and are studying
business management withintheirprofessional devel
opmentasprogrammers.
Agile development practices are applicable to busi
ness management life in general, and vice versa, as
86
 Sw DevasaCooperativeGame
evidenced by writings in professional business writ
ings.
Houseconstruction
Manypeoplearguethathouseconstructionisn't(oris)like
software development. Since I have been making exten
sionstomyhouseforseveralyears,Inowhavesomefirst
handevidencetooffer54.
You can probably imagine how I would go about
making house extensions. They should be done incre
mentally, using timeandmaterials (trustbased) plus
venturecapital (cut your losses) funding, and in a close
collaboration with both the architect and construction
contractors.Youwouldberight.
Inourfirstconversation,thearchitect suggestedcreat
ing a "master plan" of all the desired changes, and then
doing the work incrementally. I declined, because I was
prettysurethat wewouldchangetoo muchfortheinitial
plantohave meaningbythehalfwaypoint, andit would
endupbeingawasteofmymoney.Aseventstranspired,I
wascorrect.
Wechosetoruneachideaasastandaloneproject,but
were careful to ask at each key moment, "If we were to
extendin[someparticularway]nextyear,howwouldthat
affectourdecisionnow?"Surprisingly,wefoundnocases
where the future choice affected the present decision, in
cludingputtingapartialbasementunderthehouse.
Our first project was to put a basement under our
house55. This turned out to be easier than expected, be
cause our house was built on short stilts, to provide an
insulatingaircushionovertheground.
Ratherthanexcavatethe whole basement, we decided
to excavate only 1/3 of the basement. This gave us the
basement entrance we needed, and left open the question
whether we would extend the basement or build a side
wing to the house (in the next project). We learned that
there would be no cost savings for excavating more than
weneedednow,evenifwechosetoexpandthebasement
later.TheXP communitycalls this the YAGNIprinciple,
for"YouAren'tGonnaNeedIt".Weexcavatedonlywhat
weneeded.Threeyearslaterwestillhavenoplanstoex
tend the floor space, either above or below ground.
YAGNIisholding.
Thearchitectandthecontractorlookedunderneaththe
housetoseehow to support the house while digging un
derneath it. The architect launched into a dissertation on
54
Yes,Iknowthisisnotnew house development. I know others who use the
Walking Skeleton (Cockburn 2005) and related agile strategies even with new
housedevelopment.
55
Iamtoldthatpeopleusuallyputthebasementin first.Puttingit inlast isan
unintended but amusing echo of the XP strategy to plan a project as though
featurescanbeimplementedinanyorder.
page 87
the various choices. The contractor cut in with, "Why
don'twe justruna giant beam right down the center and
hold the whole thing up while we excavate?" Note here
theapplicationofthe11th principleoftheagilemanifesto:
"Simplicitytheartofmaximizingtheamountofwork
notdoneisessential."(seep.371???)
The architect adopted the suggestion, and after that, the
architect, the contractor and the construction crew had
excellent conversations that merged their best ideas. To
this day they always trade construction ideas back and
forthalongwithhowthosemightchangethedesignofthe
houseitself.
Asurprisehitusonthefirstdayofconstruction.They
knockedaholeintheconcretewallwheretheyweregoing
toexcavate,peekedin,anddiscoveredthatthebeamsun
derthatpartofthehouseranperpendiculartothosewhere
theyhadlookedunderthehouse.Thisruinedtheirplanfor
thesupport beams, and showed that once again, civil en
gineering is ahead of software engineering. It usually
takes software teams a week or two to invalidate plans.
Thesepeoplewereabletodoitwithinhours.
AsweprogressedIquicklynoticedthat thecontractor
keptchanginghis"fixedprice"bidfortheproject as new
information appeared. I finally suggested we drop the
fixedprice faade, and just work to time and materials.
His reply surprised me: "If you are willing to carry the
extrarisk,thatwillbefinewithus."Isaid,"Idon'tseeany
extra risk. You'll just change the price whenever some
thing changes anyway." He said, "That's true but most
peopledon'trecognizethat."Inexchangeformyaccepting
the"extrarisk,"heloweredhisprofitmarginfrom13%to
10%.Weeachfeltwehadbenefitedfromthischange.
Withthenewcontractinplace,hiscrewwasabletodo
anynumberofothersmallprojectsforus,suchaschang
ing the kitchen counters, adding closets, and fixing the
fence around the yard. Neither these, nor the other usual
surprises,twistsandturnsontheprojectworriedeitherof
usanymore.
Inoticedwithsomeinterestthatheandhiscrewhelda
daily standup meeting56 each morning to set their day's
work goals. In this short meeting, they checked that they
knewwhattheywereworkingon,andhadthematerialsto
getitdone.
The project came to a successful conclusion, and we
gaveasmallbonustothecontractorandtheworkers.Un
beknownsttome,ourpromptpaymentsmadeuspreferred
customers,whichprovedusefulforthenextprojects.
The second project was to sculpt the yard, move in
stone slabs and do some general landscaping. Although
thiswasa"minor"project,thecontractorwasdelightedto
56
PartoftheScrummethodology(Schwaber2005),alsousedinXP.
87
 Sw DevasaCooperativeGame
help.Hesentdiggingandmovingcrewstohelpwhenwe
neededit,andevenoperatedmachinerywhenhiskeymen
wereill.Thiswaspart ofus beingpreferredcustomers,a
rollforwardbenefitfromthefirstproject.
The third project was to add a twostory porch to the
sideofthehouse.Atthispoint,weweregladnot tohave
doneamasterplan,becausethis addition was completely
differentthananythingwehadoriginallyhadinmind.
By now, there was trust and good communications
between the architect, the contractor and us. The small
wins with reflection, the venture capital funding model,
thewillingnesstodancewiththesituation,wereallpaying
off. The contractor passed along our preferred customer
rating to his suppliers, so we got extremely fast service.
Healsotookituponhimselftoseethattheygaveusgood
rates,sowesavedmoney.
Sincewecontractedbytimeandmaterials,itwasnatu
ral to have the subcontractors do additional projects
aroundthehouseasweneededit.Thefinalbillforallthis
extrawork was muchlowerthan it would have been had
wecontractedeachoneseparately.
Whilethecontractorsare finishing the side porch, the
architect is starting on a redesign of the front porch. His
designis quitedifferent than what heoriginally proposed
whenhewasenamoredofhismasterplan.Thatisbecause
we nowhaveall the other major changes to the house in
place,andhecanseehowtotiethemtogetherinthefront
approach.
Thepointofthislongstoryistoillustratehowtheles
sons from agile software development transfer to a com
pletely different field. Incremental development, archi
tectural changes, daily standups, YAGNI, timeand
material contracts, venture capital funding, customer in
volvement and steering, small wins, process miniature,
and developing collaboration and trust each of these
proveduseful.
Airportconstruction
There might be those of you who think that house con
struction is too easy.Iwas delightedto meet an architect
who uses the agile processes in airport design and con
struction.
OnaflighttoBoston,IsatnexttoJoeWolfe,whoan
swered,inreplytomyquestionabouthisoccupation,that
hedesignsairportterminals(TerminalEinSaltLakeCity
and the new Delta terminal at Logan Airport). Not being
abletoresist,Iaskedhowheworked.Hisreplyastonished
me,becauseherecountedalmostpointforpointtheCrys
talClearmethodologyexcept hewas doing it withsev
eraldozensubcontractorsonairportterminalconstruction!
IshowedhimmydraftofCrystalClear,includingtheblitz
page 88
planningtechnique, and he said, "Oh yes, that's what we
do."
Atthebeginningoftheproject,hecollectsthesubcon
tractorsinaroom,andhasthembrainstormtheworkthey
willhavetodo.Theywritetheirtasks andtime estimates
on sticky notes, and post them on a large wall. They se
quence the tasks on the wall until they have a sensible
startingworkingplanthatshowsbothtasksanddependen
cies.Someonetranscribesthecontentsofthewallintothe
computerafterthesession.
IaskedJoewhetherhe hadanotion ofearlyintegra
tion in his project, and how he would motivate sub
contractors to do that. He said they did do that, that
the subcontractors get paid at integration milestones,
andthecashflowmotivatesthem.
Inreplytomyquestionaboutcontracts,heintroduced
me to "nottoexceed plus fixedfee" contracts (see
"Contracts", page 91???) "Not to exceed" means that
thesubcontractorpromises not to exceedacertain fi
nalamount."Fixedfee" means that the subcontractor
is guaranteed a certain profit if the work takes less
timethanexpected.Thus,thesubcontractor'sprofit is
protected,andtheairport'sspendingbillisprotected.
I asked him about the agile notion of exposing bad
news early how would he get subcontractors to re
veal their problems early? He said that incremental
funding motivates them to integrate their work, and
also to seek help when they ran into trouble. An ex
amplemightbeaninternationalshortageofsteel.
I was concerned that even with those, subcontractors
arenot usedtoexposingtheirproblems tothepeople
hiring them, and it must take some time to get them
used to it. He highlighted that he, as project coordi
nator, had to deliberately build a climate of trust
withintheteam,sothattheywouldrevealtheirprob
lems.
Note the similarity of his working style with that de
scribedinthediscussionofpersonalsafetyintheCrystal
Clear(Cockburn2005,p.50?):
Skillful leaders expose their team members (and
themselves!) to these situations early, and then dem
onstratewithspeedandauthenticitythatnotonlywill
damagenotaccrue,butthattheleaderandtheteamas
awholewillacttosupporttheperson.
One projectleader57 told me that when a new person
joined herteam,she wouldvisitthatperson privately
todiscusshisworkandprogress,and waitforthein
evitablemomentwhenhehadtoadmithehadn'tdone
ordidn'tknowsomething.
57
ThankstoVictoriaEinarssoninSweden.
88
 Sw DevasaCooperativeGame
Thiswasthecrucial momentto her, because until he
revealedaweakness,she couldn't demonstrateto him
that she would cover for him or get him assistance.
She knew she was not going to get both reliable in
formationandfull cooperationfrom him until he un
derstoodproperlythatwhenherevealedaweaknessor
mistake, he would actually get assistance. She said
thatsome people gotthe messageafter her first visit,
while others needed several demonstrations before
openingup.
I was stunned by Joe Wolfe's account of designing and
buildinganairport,asitdidn'tmatchmypreconceptionsat
all.Asafinalquestion,Iaskedhimifthiswayofworking
wasnormalintheairportdesigningindustry.Hesaid,no,
it wasn't, but he couldn't see how anyone could work in
anyotherwayandgettheterminalcompletedontime.He
addedthathehadbeenworkingthis wayforseveraldec
ades, and his clients were so happy that he never had to
lookforwork.
Bookpublication
Finally,onecanapplyagiledevelopmenttobookpub
lication. I did this for the first edition of this book. The
normalbookpublishingprocess takes about four months.
Since we had onlytwo months before the conference an
nouncingthebook,Iaskedtomanagethepublicationpro
cessmyself,usingtheprinciplesinthisbook.
The first thing I did was to select people all living in
SaltLakeCitytheclosestIcouldgettofullcollocation.
In a normal production process at that time, the manu
scriptwouldbemailedinpaperformfrompersontoper
son,withpencilmarksonitforchangestobemade.These
days,themanuscriptismarkedelectronicallyandemailed,
butthatonlypartiallyimprovesthematter.
HavingeveryspecialtylocatedinSaltLakeCityisnot
yetosmoticcommunication,butatleastwecouldallmeet
at someone's house to discuss the manuscript. Naturally,
weusedelectronicmarkupandemailinsteadofpaper.
Thesecondchangewastoworkincrementally.Mostof
the editors I have encountered like to mark up the entire
manuscript in one pass.This is largely a consequence of
people working separately across large distances. Know
ingwewouldmeetperiodically,wearrangedtobuildeach
chapterseparately.Imadeadependencygridmarkingthe
workneedingtobedonebyeachpersonsothat theillus
trator could work at a different pace and on different
chaptersthanthecopyeditorandthepagelayoutperson.I
allocatedacertainnumberofreworkcyclesforeachper
son.Thisway,eachpersoncouldbebusydoingtheirwork
asindependentlyaspossiblefromeachotherperson.
Imet withthe copyeditoraftershe markedupeachof
the first several chapters, so we could synchronize the
styleandnatureofthechanges.As weformedagreement
page 89
on what counted as a mistake versus what to leave as
author's style, the number of marks she had to make got
smaller, and the number of corrections I had to make to
her corrections got smaller. This was an improvement
overtheusualmode,inwhichthecopyeditormarksupthe
entire manuscript,andthentheauthorhas to unmark any
partsthatarestyleinsteadofmistake.
Onthefinalday,wemetatthehouseofthepage lay
out person. We several times found ourselves working
aroundanawkwardcolumnbreakandcorrectingsentence
structureatthesametime.Withallofus sittingtogether,
sometimesIwouldreviseasentencetomakeitfitbeforea
columnbreak,sometimesthelayout personwouldreduce
theinterlinespacingbyasmallamounttomakethe extra
linefitwithintheverticalspace.
This experience with book production taught me sev
eralthings.
Agile development practices work very well with
book production. We reduced production time from
fourmonthstothreeweeks.
Thecopyeditorwasnevercomfortablewiththeproc
ess we used. One reason was that she never knew
what state the book was in at any point in time (she
was not accustomed to the high flux). However, I
came to realize that one of her pleasures in life was
sittingdownwithapapermanuscriptandapotoftea,
and havingaquiet morning marking up the text with
herpencil.Workingonline, working one chapter at a
time,andrunningouttomeetingswiththeauthordid
not suit her working style. (Does this sound like any
programmersyouknow?)
There was an extra cost to working the way we did.
When she submitted her invoice, she wrote that the
invoicewashigherthansheoriginallybidbecausethe
author made last minute changes that cost her time,
andalsobecauseofthe extrameetings she had to at
tend. (Does this sound like any programmers you
know?) This matches the prediction of the economic
model in Chapter 4 (p. ???). That model shows that
concurrentdevelopmentshouldbefasterbutmoreex
pensive than sequential development. We worked
aboutfourtimesfasteratabouta10%costincrease.
Finally, not everyone enjoys iterative and concurrent
development.Atonepoint,whenthecopyeditorwas
resistingmeetingmetodiscussthe markup,Istarted
explainingthebenefitsofourgettogether.Shecutme
off, saying, "I know I'm editing that chapter!" She
was happy afterwards to go back to her paper manu
scriptsandpotofteaandputagilebookproductionin
herpast(forthetimebeing!).
89
 Sw DevasaCooperativeGame
Conference Organization and Limits of the Agile
Model
Icanthinkofonlytwoenvironmentalfactorsthatlimitthe
applicabilityoftheagile model: distributedteams andin
abilitytouseincrementaldevelopment.
Distributing the team slows communication and feed
back, which makes it more difficult, though not impossi
ble,tousetheagileapproach.Thiswasdiscussedatlength
in"Agileteamsmustbecollocated"onpage39???.When
workinginadistributedteamsituation,morecaremustbe
placedonfollowingtheagileprinciplesingeneral.
Any situation in which incremental development can't
be done loses someofthebenefitsof the agile approach.
Spaceexplorationisone.
Theincrementalversionofputtingamanonthemoon
would be to put his foot on the moon in the first space
shot, and then to add other parts of his body and equip
mentonsubsequentspaceshots.Clearlythatdoesn'tmake
sense. What we employ instead is use of iterated proto
types:putting a whole man in orbit, putting a man and a
craft around the moon, and then, finally, ten years later,
puttingawholemanonthemoon.
Notethatalltheotheragileprinciplescanbeusedeven
inspaceexploration.
Possiblythemostdifficultsituationtotrytoapplythe
agile model is in organizing a conference, particularly
with volunteers (as is often the case) located in different
parts of the world (as is often the case). There are no it
erations, there are no increments, there is no opportunity
forfeedback,therearenouserstogetfeedbackfrom.
Here is our story from organizing the Agile Develop
mentConferenceof2003and2004,andhowwe"ateour
ownagiledogfood."
Beforewepitchedtheconferencetothefirstpotential
hosting group in 2001, we created a vision statement
for the conference that stated why a new conference
shouldcomeintoexistenceandhoweachpartofitfit
into the overall purpose (ADC2003 URL). Clear vi
sion statements are part of aligning teams. They are
core to agile projects because they allow people to
movefast,inharmony,andwithlessbureaucracythan
otherwise.
We recognized that while incremental and iterative
developmentaren'tmeaningfultotheorganizationofa
single conference, they are meaningful to the organi
zationofanannualconference.Wethereforerannu
merous reflection and feedback sessions, starting on
the last day of the 2003 conference. We collected
from both attendees and organizers what they would
liketokeepthesameorchangeforthenextyear.
page 90
We compared the feedback comments to the original
vision, and decided whether it was our vision or just
our implementation of the vision that needed correc
tion.
Some of the people organizing the following year's
conferencesataroundmyhousewithourfeetup(and
some beer in hand), discussing the differences be
tween software development and conference organi
zation.Wewantedtoseewhatmightbedonetocopy
intoconferenceorganizationwhatweknewworkedin
softwaredevelopment(noticeouruseofafacetoface
settingandarelaxedatmospheretosparkinvention).
We decided to collocate most of the conference or
ganization committee. We established the idea of a
"designepicenter"fortheconference.Thedesignepi
center could be in a different place than the confer
ence.Thatwouldallowustochooseageographically
constrainedregionwherewecouldfindalltheneeded
track chairs. We selected London as the design epi
center for 2004, and Silicon Valley as the one for
2005.
The Londonbased track chairs met periodically at
pubs to discuss ways to better integrate the different
conferencetracks.Iattendedafewofthese,andeven
I was surprised at the number of new, ideas that
showed up at each meeting. The group made more
progressinasingle eveningtogetherthaninamonth
of emails. (The ideas were surprises that they made
suchprogress was not it was whythey met at pubs
inthefirstplace.)
Oneofthebetterinnovationswastoborrowfromthe
apprenticeship model. We decided that the following
year'strack chairs would work as understudies to the
Londongroup.Then,whenit was theirturntoact as
trackchairs,theywouldcometothetopicwarmedup,
understanding the thoughts that had gone into the
variousdecisions(thisisborrowingfromPeterNaur's
theorybuildingmodel,seeAppendixA).
Alessonfromthefirst ADC was that even the Open
Spacesessions(Owen1997)weretooformalforwhat
weintended.Peoplestillenjoyedtheconversationsin
the hallway the most. We therefore created the posi
tionofHallwayChair.Thispersonwastoseethatthe
hallway itself could maximize communication and
community. The things we decided as crucial in the
HallwaySessionwere:
ahallway(don'tmove it intoaroomandgiveit a
sessionname),
coffee(makesurethe hotelstaffneverclearaway
therefreshments,but makesuretheyareavailable
andfreshallday),
90
 Sw DevasaCooperativeGame page 91
tableswhereprogrammerscouldsitandshoweach
othertheirspecialtricksandinterests,
lotsofbutcherpaperandwhiteboardsforpeopleto
drawonwhilestandingaroundandtalking.
The Agile Development Conference somewhat typically
became the victim of a hostile takeover and was merged
withacompetingconference.Manyinnovationswerelost:
the idea of a design epicenter, the apprenticeship model,
the use of a vision statement, the reflection workshops
followingtheconference.As predictedinthecooperative
game model, with the change of team came a loss in the
understandingofwhatmadetheconferencespecial58.
While I feel sad about the loss of ADC's innovative
ideas and vision, all the above is to be expected in busi
ness, whether agile or otherwise. It is partially satisfying
toseethatthetheorypredictsproperly.
Icatalogtheseideashereincasesomeoneelsehasoc
casiontousethemintheirownconferencedesign.

58
The continued presence ofToddLittlekept most of theconference structure
together. Todd helped design the first ADC, chaired the second, and then
chairedthefirsttwoyearsofthemergedconference.IfToddhadnotcontinued,
muchmorewouldhavebeenlost.

91
Sw DevasaCooperativeGame page 92

6'
TheCrystalMethodologies:
Evolution
Crystalismyconsideredeffortto construct apackageofconventionsthatraisesthe
oddsofsucceedingintheprojectandactuallybeingused.
ThebigshiftsincethefirsteditionisthecompletionofCrystalClear,theversionfor
small, collocated teams. Since Crystal Clear is described at length in its own book
(Cockburn2005cc),whatbelongshereistosharetheinsightsIgainedintoCrystaland
agilemethodologiesingeneralwhilewritingthatbook.Thoseinclude,Crystal'sgenetic
code,installingCrystalClear,stretchingCrystalCleartoYellow,andnewtechniques.

92
Sw DevasaCooperativeGame page 93

6'THECRYSTALMETHODOLOGIES:EVOLUTION ........................................................................................ 92
THE CRYSTAL GENETIC CODE 94
TheCooperativeGameMindset 94
MethodologyDesignPriorities 94
MethodologyDesignPrinciples 95
SevenPropertiesofHighlySuccessfulProjects 95
TechniquesDiscretion 96
SampleMethodologyDesigns 97
CRYSTALCLEAR 97
Sidebar:IntroducingCrystalClear,byJonathanHouse........................................Error!Bookmarknotdefined.
STRETCHING CRYSTAL CLEARTO YELLOW 100
Sidebar:TailoringCrystalYellow,byGryDerbier,ProjectManager,Solystic ............................................. 102

93
 Sw DevasaCooperativeGame
TheCrystalGeneticCode
Crystal is a family of methodologies with a common ge
netic code. The genetic code helps you to design a new
family member when you need one, and tell whether a
given methodology is a member of the family. Jens
ColdeweysummarizedCrystalneatly:
The Crystal methodologies are about frequent deliv
ery,closecommunication,andreflectiveimprovement.
Crystalis my considered effort to construct a package of
conventions that work well together, and that taken to
getherincreasetheoddsofprojectsuccessandtheoddsof
actually being used by the team. It is possible that the
package is faulty, but teams that have used it have re
portedgoodresultsonbothfronts.
The Crystal methodologies are intended to be tailored
at the start of each project (and periodically within the
project). I put bounds on the tailoring, identifying the
places where I feel a sharp dropoff in the likelihood of
success occurs ("Sweet Spots and the DropOff", p.
47???). My observation is that when people do things
similartoCrystal,theyusuallydon'treflectontheirwork
habits very seriously. Without reflection, they lose the
opportunity to improve their output. (They also usually
don't deliver the system very often, and they don't have
verygoodtests,butthoseareseparatematters.)
TheCrystalgeneticcodeconsistsofsixelements:
Thecooperativegamemindset
Themethodologydesignpriorities
Themethodologydesignprinciples
Thesevenpropertiesofhighlysuccessfulprojects
Techniques selected per personal discretion, but with
"interesting"startertechniquestoconsider
Samplemethodologiestocopyfrom
TheCooperativeGameMindset
Treating software development as a cooperative game of
invention and communication frees the team to consider
whatmovesmakesenseat any moment intime and what
strategies create a good position for the next move. It
frees theteamfromtheillusionthat there is a single for
mulatouseacrossallprojects.
Treatingtheprojectaspartofaninterconnectedseries
ofgameshighlightstheimportanceofbalancingthe need
todeliverthissystemwiththeneedtoset upforthe next
andadjacentgames.
This book has described the cooperative game model
indepth.
page 94
MethodologyDesignPriorities
Every methodology author has some priorities in mind
whileselectingwhattoincludeandwhattoexclude.Mine
are:
Projectsurvival(itshoulddeliverthesystem)
Processefficiency
Processhabitability,ortolerance
Thefirstpriorityistheoverridingone.Iftheproject does
notdeliverthesystem,thereisabasicfailure.
The next two priorities compete with each other. On
theonehand,thereareextremelyefficient ways of work
ing that people will simply refuse to use. It still happens
todaythattheprogrammerscanavoidorsubverttheproc
ess if they don't like it. To be successful, a methodology
needstobeacceptedbytheteam.Therefore,habitability
thatthatpeoplearewillingtolive withtheseconventions
iscritical.
Iusedtowritethispriorityastolerance,meaninghow
muchvariationwouldbeconsideredacceptablefromper
son to person and from project to project. From my per
spective, the methodology needs the tolerances on the
conventions to be as loose as possible. It should work
acrossthewidestpossiblevariationsinpractice.However,
Iwastoldthatthewordtolerancetranslates withundesir
able sideeffects into other languages, and so we chose
habitability.
Habitabilityruns against efficiency, because the team,
orindividualsontheteam,maydeclinetousesomemore
efficient technique orconvention.Myfeeling is that pos
siblylessefficientconventionsthatareactuallyusedmay
servetheteambetterovertime.
Balancing efficiency against habitability is not a Shu
levelskill.It requires one or more people on the team to
haveaRilevelunderstandingofsoftwaredevelopmentto
make this balance. This matches the acceptance level I
have seen for Crystal. Beginner teams look at Crystal,
don'tseeaclearformulatouse,andmoveontoXP(ver
sion1)orScrum.
Advanced teams know that methodologies out of the
box are unlikely to fit their situation. They like Crystal
becauseitselectsjustenoughrules to get theproject into
thesafetyzone,andleavesthemplentyofroomtoincor
poratetheirsituationspecificadjustments.
94
 Sw DevasaCooperativeGame
MethodologyDesignPrinciples
The principles used to design Crystal were presented in
Chapter 4 . Crystal particularly emphasizes the value of
facetoface communications, adjusting methodology to
projecttype,andattendingtoprojectspecificbottlenecks.
Theseprinciplesarevisible inthe differences between
theCrystalfamilymembers.
SevenPropertiesofHighlySuccessfulProjects
I only recently awoke to the realization that top consult
ants trade notes about the properties of a project rather
thanontheprocedures followed.Theyinquire: Is there a
mission statement and a project plan? Does the team de
liverfrequently?Arethesponsorandvarious expertusers
inclosecontactwiththeteam?
Consequently, and in a departure from the way in
whichamethodologyisusuallydescribed,Istartedasking
teams to target key properties for the project. "Doing
Crystal" becomes a matter of achieving the properties
ratherthanfollowingprocedures.Threemotivesdrivethis
shiftfromprocedurestoproperties:
Theproceduresmaynotproducetheproperties.Ofthe
two,thepropertiesarethemoreimportant.
OtherproceduresthantheonesIchoosemayproduce
thepropertiesforyourparticularteam.
I hope to reach into the feeling of the project. Most
methodologydescriptionsmissthecriticalfeelingthat
separatesasuccessfulteamfromanunsuccessfulone.
Naming the properties provides the team with catch
phrases to measure their situation by: "We haven't done
any reflective improvement for a while." "Can we get
moreeasy access to expert users?" The property names
themselves help people diagnose and discuss ways to fix
theircurrentsituation59.
A Crystal team measures its condition by the team's
moodandthecommunication patterns as much as by the
rateofdelivery.
InoticedthiswhileinterviewingGryDerbierofSoly
sticabouthis experienceswithhisCrystalYellowproject
(see"ExtendingCrystalCleartoYellow"anditssidebar).
IwastryingtoworkoutwhyhesaidhewasusingCrystal,
andIrealizedthathehadbeenfocusingonthe qualityof
thecommunicationswithinhisteam,acrossorganizational
boundaries,withbothhiscustomersidesponsorsandwith
the external test team. He watched the delivery cycles,
reflected with the team each month on how work better
together, and experimented with fitting different authors'
ideasintothegroup'sworkingpatterns.
59
PaulOldfieldcatalogsproblemsateamisrunninginto,and what counteract
ingpracticestheymaywanttoconsider:
http://www.aptprocess.com/whitepapers/risk/RiskToPatternTable.htm
page 95
The following list presents seven properties of highly
successfulprojectsalongwithtestquestionsforeach.The
first three are the unifying theme across the family. The
other properties increase the safety factor for the project.
The properties are described in greater detail in Crystal
Clear(Cockburn2005cc)
FrequentDelivery
Havewedeliveredrunning,tested,andusablecodeat
least twice to our user community in the last six
months?
ReflectiveImprovement.
Didwegettogetheratleastoncewithinthelastthree
months for a half hour, hour, or half day to compare
notes,reflect,discussourgroup'sworking habits,and
discoverwhatspeedsusup,whatslowsusdown,and
whatwemightbeabletoimprove?
Close/OsmoticCommunication
ForCrystalClearprojects:Doesittakeus30seconds
or less to get our question to the eyes or ears of the
person who might have the answer? Do we overhear
something relevant from a conversation among other
teammembersatleasteveryfewdays?
For other Crystal colors, replace those specific times
with an inquiry into how long it does take to get a
questiontotherightperson,andthefrequencyofser
endipitousdiscovery.
PersonalSafety
Can we tell our boss we misestimated by more than
50percent,orthatwejustreceivedatemptingjobof
fer?Canwedisagreewithhimorheraboutthesched
uleinateammeeting?Canweendlongdebatesabout
eachothersdesignswithfriendlydisagreement?
Focus
Do we all know what our top two priority items to
workonare?Areweguaranteedatleasttwodaysina
rowandtwouninterruptedhourseachdaytoworkon
them?
EasyAccesstoExpertUsers
Doesittakelessthanthreedays,ontheaverage,from
whenwecomeupwithaquestionaboutsystemusage
towhenanexpertuseranswersthequestion?Canwe
gettheanswerinafewhours?
TechnicalEnvironmentwithAutomatedTests,Con
figurationManagement,andFrequentIntegration
Can we run the system tests to completion without
havingtobephysicallypresent?Doallourdevelopers
95
 Sw DevasaCooperativeGame
check their code into the configuration management
system?Dotheyput inausefulnote about it as they
check it in? Is the system integrated at least twice a
week?
There is one additional property worth mentioning, one
thatonlyshowsupontheverybestofprojects:
collaborationacrossorganizationalboundaries.
Collaboration across organizational boundaries is not a
given result on any project. It results from working with
amicabilityandintegritybothwithinandoutsidetheteam.
It is hard to achieve if the team does not itself have per
sonal safety and, to a lesser extent, frequent delivery. I
considerthepresenceofgoodcollaborationacross organ
izational boundaries as evidence that others of the top
sevensafetypropertiesarebeingachieved.
TechniquesDiscretion
A common mistake of the beginning methodologist is to
believe that latest technique he just learned is the master
technique that all people must use. As Andy Hunt and
DaveThomas,the"pragmaticprogrammers"havegoneto
great lengths to point out (Hunt 2000???), there are a
steadily growing number of useful techniques in the
world.Itistheresponsibleoftheprofessionalinhis field
tolearnhowtousethem.
Itmakesnosenseforme,astheauthorofamethodol
ogytobeusedbywidelyvaryingpeopleonteams in dif
ferent countries, working on different sorts of projects
withdifferentsortsoftechnologies,tolegislatewhattech
niquewillworkbestforeachofthosepeopleandeachof
thoseteams.That is something for each person and team
toworkout.
FromtheperspectiveoftheCrystalfamilyof method
ologies, any technique of invention is quite all right, as
long as the person can explain the idea to the rest of the
teamafterwards.
Thus,some people will like to model in UML, others
willnot.Somewillliketoprograminpairs,otherswon't.
Some will thrive on testfirst development, others will
write code first and tests after. Some teams will use the
XP planning game, some my Blitz Planning technique,
andotherstheScrumbackloglist.
What I have done in this book and the Crystal Clear
bookistolisttechniquesandstrategiesthatyouandyour
teammayfindinterestinganduseful.
Here is short summary of interesting strategies and
techniquesforyoutoconsider:
Exploratory 360: Preproject safety check. In a few
days or a few weeks, sample the project's business
value,requirements,domainmodel,technologyplans,
projectplan,teammakeup,andmethodology.
page 96
Early Victory: Small wins helps a group develop
strengthandconfidence.Arrangeforsomeearlyinthe
project.WalkingSkeletonisagreatstart.
Walking Skeleton: A tiny implementation of the sys
temthatperformsasmallendtoendfunction.Itneed
not use the final architecture, but it should link to
getherthemainarchitecturalcomponents.
IncrementalRearchitecture:Evolvethearchitecturein
stages, keeping the system running as you go. This
appliesbothtotheWalkingSkeletonandtolaterrevi
sions.
Information Radiator: A display posted in a place
where people can see it as they work or walk by. It
shows readers information they care about without
having to ask anyone a question. Ideally it is large,
visible to the casual observer, easily kept up to date,
understood at a glance, and changes periodically, so
thatitisworthvisiting.
Pair Programming: Two people sit sidebyside,
working on the same code. They can be two pro
grammers,oraprogrammerandauser,business spe
cialistortester.
SidebySide Programming: Two people sit sideby
side,but atdifferent workstations,working on differ
ent assignments. The workstations need to be close
enough that each one can read the read the other's
workstation simply by turning her head (60 cm 90
cm,or12"18").Theyhelpeachotherasneeded.
TestDrivenDevelopment:Thetest,orexecutableex
ample, is written before deciding how to design the
code.Itservestestbothasspecificationofwhattode
signandasapracticerunatusingthecallsequenceto
thefunction.AlsocalledXXD(seepage61???).
BlitzPlanning:Anindexcardbasedplanningsession
inwhichthesponsor,businessexpert,expertuser,and
developers,together, build the project map and time
line. Unlike XP's Planning Game, the cards in the
BlitzPlanningtechniqueshowtasksandtaskdepend
encies.
DailyStandupMeeting:Everyoneintheteammeets,
standing, for a maximum of 10 minutes to announce
what they each are working on and where they are
gettingstuck.
Agile Interaction Design: A one or two day sticky
noteandindexcardbasedsystemusagemodelingses
sion, based on the ideas in Software for Use
(Constantine2000).Describedin(Patton2005cc).
BurnCharts: A timebased graph of number features
tobe completed over time and features completed so
far.
DynamicPriorityLists: A list of features to work on
in the next iteration or the whole project, prioritized
96
 Sw DevasaCooperativeGame
and put into ranking order by the sponsors, and up
datedbythemattheend of eachiteration ordelivery
cycle.
ReflectionWorkshop:Aworkpause,foranhourperi
odically,certainlyaftereachdelivery,toreflectonthe
product,progress,andprocess.
SampleMethodologyDesigns
Humans are better at modifying than inventing. For this
reason,Crystalcontainssamplemethodologydescriptions.
Think of "cutting and pasting" the following into your
methodology.
It is not the intention with these descriptions that you
pickthemupandusethemuntouched,butratherthatyou
pick them up and critique them, adding and subtracting
detailsuntilwhatyouhavesuitsyoursituation.Methodol
ogymodificationis,afterall,acoreelementofCrystal.
page 97
ways to stretch the sentence for different circum
stances,
strategiesthatarelikelytobeemployed,
lessknowntechniquestheteammightliketotry,
samplesofthe workproducts that are likely to be
generated(besidescode),
and (best of all) an experience report on using
Crystal Clear, with commentary by an ISO 9001
auditor.
CrystalClearis anextensionofthis bookfromtheoryto
practice, what a small project team needs at the ground
level, for teams at the mixed Shu, Ha and Ri levels. Ri
levelleadersandpeopleonlargerteamscanusethebook
toget ideas ofboth work samples and new techniques to
try.

CrystalClear
Atthetimeofthefirstedition,theCrystalClearbookwas
still in draft form, and the description of it fit into one
page.
The book Crystal Clear: A HumanPowered Method
ologyforSmallTeamscameoutlatein2004.Init,Isum
marizedCrystalClearwithasingle(long)sentence:
"Theleaddesignerandtwotosevenotherdevelopers
inalargeroomoradjacentrooms,
using information radiators such as whiteboards
andflipcharts,
havingeasyaccesstoexpertusers,
distractionskeptaway,
deliver running, tested, usable code to the users
everymonthortwo(quarterlyatworst),
reflectingandadjustingtheirworkingconventions
periodically."
Thebook itselfruns toabout 350pages,which of course
promptsthequestion,"Howcanyouspend350pagesde
scribingonesentence?"
TheanswerisexactlythedifferencebetweenShuand
Rilevel descriptions. The onesentence version was de
rivedfromtalkingtoexperienceddevelopers,andissuffi
cient description for experienced developers. The 350
pagesareneededtodescribe
the background behind the parts of that (long)
sentence,
the Crystal genetic code and the seven properties
ofhighlysuccessfulprojects,
theboundaryconditionsforCrystalClear,

97
 Sw DevasaCooperativeGame
Introducing Crystal Clear, by Jonathan House,
ManagerofSoftwareDevelopment,Amirsys
InMarchof2005,Ihadjusttakenamanagementposition
with Amirsys, a medical informatics company. I was ex
citedaboutjoininganewcompany,butfeelingasenseof
resignationat all of the heavy lifting that was in front of
metogetthenewcompanytoadoptanAgileapproachto
developingsoftware.
Thesenseofresignationwasfrommypreviousexperi
ences as an agile mentor, working to bring agile soft
waredevelopment practices into various companies I had
consultedwith.Ineachcase,the newpractices werewell
received,but neverreallycaught on, for a variety of rea
sons.
AsIwaspreparingtoleaveourmonthlySaltLakeAg
ile roundtable meeting, Zhon Johanssen, a longtime XP
practitioner and one of the roundtable oldtimers ap
proachedme.Likeme,hewasintriguedbythecleanslate
thatAmirsyspresented,butunlikeme,he wasn'tcarrying
mysenseofresignation.Hehadanideaselforganizing
adoptionofagilepractices..
Ratherthanmepushingthepracticesontotheteam,he
suggestedthatitwouldbeinterestingtoseewhatpractices
theteamwouldadoptwhengivenspecific"stimuli.
Ilikedtheideabecauseitwouldallowmetobecomea
minimalist project manager (or maximalist," as one
person corrected me I get the maximum results from
eachaction). My sense of resignation was gone, just like
that.
Although I had experience with XP, Scrum, DSDM
andFFD,IdecidedtouseCrystalClearasourmethodol
ogy framework, partially because the lightweight ap
proachappealedtome,andpartiallybecauseofmyexist
ingrelationshipwithit'sprogenitor,AlistairCockburn.
The very next day I reached my first crisis with my
new philosophy as I started to prepare to fight with the
executive team about the need to adopt an incremental,
iterativeapproach.ThiswasalwaysthefirstfightIfought
inmyothermentoringengagements.
I stopped. I closed the door of my office, closed the
shades,turnedoffthelightandstartedthinkingabouthow
toget the executive team to decide that they had to have
iterations.ItwasthenthatIrememberedalessonfrommy
highschoolbiologyclass.Put simply,theexecutiveteam
hadtofeelthepain.
Iwalkedintothedirector'smeetingarmedonlywitha
notepad and a goal of ferreting out the pain that would
page 98
lead to a realization that an iterative approach would be
thenecessarycure.
As soon as the meeting began I realized that I wasn't
goingtohavetoworkveryhardtogettheexecutiveteam
to feel the pain. First on the agenda was a discussion of
howtogetthedevelopmentteamtobemoreresponsiveto
changing business requirements. After about 10 minutes
ofcarefullydirectedquestioningonmypart,thePresident
ofthecompanysaidIsitpossibletogetthedevelopment
teams to deliver just a part of the functionality that we
needmorefrequently?
Igrudginglyagreedthatitmaybepossible,andthatI
wouldseewhatIcoulddowiththedevelopmentteamsto
get them to deliver functional code on a more frequent
basis. As I walked out of the meeting I was shocked to
realize that we had become an incremental development
shopwithoutsomuchasasinglePowerPointslideshown.
Now that I was mandated to implement iterations, it
became clear that a lack of automated tests would be a
seriousdragtous.
Continuing the experiment, and looking to install the
right paininkeyplaces,Iaskedthat weincreasethefor
malityofthetestingprocess.
Painimmediatelysetin.Testingbecameanallhands
on deck operation that completely halted other efforts.
Forafulltwoweeksthispainwenton,andnotoncedidI
mentionautomatedtestsortestfirstdevelopment.
Attheendoftheiteration,Igottheteamtogetherand
askedthemiftheythoughtitwasagoodideatotalkabout
the previous iteration (thereby introducing the reflection
session practice). After letting the team vent about the
painofthetestingprocessforawhileIsaid,Youknow,
it wouldbe niceif we wereabletoautomate most of the
testingeffort,wouldn'tit.
Thedevelopmentteamdecidedthatitwouldbeagood
idea to write codebased tests at the same time they
worked onapplicationfeatures. Our director immediately
allocatedresourcestodevelopautomatedtestsandreduce
the80orsopagesofmanualtests.
Istillhadn'tgiventhattwohourlongPowerPointpres
entationabouthowautomatedtestsareagoodidea.
Thepatternhademerged,andthebestpart wasthat it
wasselfreinforcing.Asourdevelopmentteamsreacheda
point where a specific Agile practice was needed, I went
lookingforthepain.OnceIfound it,Imadeit apoint to
insurethateveryonefeltthatpain.Assoonasthepainwas
established I would lightly introduce the team to the
neededpracticeandthengetoutoftheirway.
one of the developers mentioned that a critical user
story had been missed in the last iteration planning ses
sion. I took the developer aside after the meeting and
98
 Sw DevasaCooperativeGame
showed him the iceberg list (Figure 512 in Crystal
Clear).Icameinthenextdaytodiscoverthatourbacklog
listshadbeenreorganizedintoiceberglists.
The newapproachworked withthe executive team as
well.
Executive team members were introducing conflicting
priorities on the goals of the iteration (this is known as
feature thrashing). So I began convening meetings in
front oftheiterationchart (Figure 522 inCrystal Clear)
whenever a change was requested miditeration, with the
development team and all of the executive team
stakeholders. Not only did the executive team members
resolvetheconflictsthemselves,buttheynow godirectly
to the iteration charts on their own initiative to discuss
changestothefunctionalgoalsoftheiteration.
Strangelyenough,withallofthissuccess,Istillwasn't
happy. As a project management minimalist I felt I was
doingallofthepaindiscoveryandinflammation.
Ourdailystandupmeetingsweretakingtoolong,and
Icouldtelloneofthedeveloperswasgettingannoyedand
spacing out during the meeting. Rather than me policing
the meeting as I might have done before, I just showed
him the one page description of the standup meeting in
page 99
Crystal Clear. The next day, he objected during the
meetingthat it was takingtoo long,andstarted enforcing
thecorrect,shorterformat.
During another standup meeting, one of the develop
ersmentionedthatacriticaluserstoryhadbeenmissedin
the last iteration planning session. I took the developer
asideafterthemeetingandshowed himtheiceberglist
(Figure512inCrystal Clear).I came in the next day to
discover that our backlog lists had been reorganized into
iceberglists.
Today, Amirsys is a great place to be a project man
ager. We can tell the state of every project simply by
walkingintothe developer areaand looking at the walls.
Developer team members handle most of the status re
porting tasks themselves.There are several copies of Al
istair'sCrystalClearbookfloatingaroundthe office,and
we have matured to the point where team members are
startingtoidentifypainsontheirown and look for ap
plicablesolutions.
AndIstillhaveyettocreateasinglepowerpointpres
entation.
99
 Sw DevasaCooperativeGame page 100
In terms of the agile evaluation framework presented at
theendofthelastchapter,weseeforthisprojectthefol
StretchingCrystalCleartoYellow lowing:

Manypeople have noticedthe gapbetweenCrystalClear #People 25

(38people)andCrystalOrange(3050people).What FrequentDelivery 1 year (a danger sig
doesCrystalYellowlooklike,for1530people? nal), but early integra
I am indebted to Gry Derbier, of Solystic, now a tion with acceptance
French subsidiary of Northrup Grumman, for deriving a tests attached to pay
versionofCrystalYellowandreportingbackonit. ments every six weeks
Solysticwonabidtobuildanewpostoffice justout (a safety factor miti
side Paris to handle all the international mail going into gating the danger sig
and out of northern France. The overall project included nal).
the building itself, plus the mechanical, optoelectronics UserViewings 1week(asafetyfactor
and information processing systems, and also hiring and mitigating the danger
training the staff. Gry Derbier was the project manager signal)
fortheinformationprocessingsoftware.
ReflectionWorkshops monthly
It was significant that the purchasing sponsor, the
OsmoticCommunication 1floor
French Post Office, was looking for a supplier who was
willingtodoincrementaldevelopmentandgetpaidevery PersonalSafety yes
six weeks in exchange for demonstrating integrated fea Focus(priorities,time) both
tures that often. It was also significant that the external EasyAccessto 1day/week
test team was located at the site of the new post office ExpertUsers
building,notatGry'slocation.
ConfigurationManagement yes
HerearethehighlightsofGry'steam'sconventions:
AutomatedTesting no
Seating: The software development team occupied
onefloor,whichwasshapedratherlikeadonut.Itwas FrequentIntegration 3/week
lessthanaminute'swalkfromanyone'sofficetoany Collaborationacross yes
one else's. The programmers sat several people to a OrganizationalBoundaries
room in several adjacent rooms. There was a "com Iterationlength 1month
monroom"wheretheyheldstandup,status,andother Intermsoftechniqueandstrategyuse,weseethefollow
meetings. ing:
Timecycles:
Iterations: Iterations were one month, and started
off with a planning session and a reflection about Exploratory360 Yes
thepreviousmonth'swork. EarlyVictory Yes
Standups: They experimented with daily stand WalkingSkeleton Yes
ups,andmovedtostandupsonMonday,Wednes IncrementalRearchitecture Yes
day,andFriday. InformationRadiators Yes
Integration:Theytriedbutnevergotdowntodaily
PairProgramming No
builds.Fullbuildsweredonethreetimesaweek.
Programming: The team tried and rejected pair pro SidebySideProgramming No
gramming, so they programmed in near proximity to TestFirstDevelopment No
eachother. BlitzPlanning Yes
Deliveries and user viewings: The key representative DailyStandupMeeting Yes
fromthePostOfficevisitedonedayeachweek.Inte AgileInteractionDesign No
grated code was evaluated for acceptability and pay
menteachsixweeks. BurnCharts Yes
Externaltestcollaboration:Arepresentativefromthe DynamicPriorityLists No
externaltestteam visitedand worked with the devel
opmentteamonedayeachweek. Iamhappytoreportthattheprojectdeliveredontimeand
thedevelopmentteamwasrecognizedfortheirsuccess.

100
 Sw DevasaCooperativeGame page 101
I asked Gry what contributed particularly to the end
success, particularly given a schedule that looked overly
optimistic when I visited the project. He answered that
monthly incremental development was key. Developers
who might otherwise have spent weeks worrying over
what was the"right"or"best" way to do something, rec
ognizedthatwithonlyonemonthtodeliverfunction,get
ting an acceptable design out the door was better than a
perfectdesignthatdidn'tgetdelivered.
What Inoticed was how much attention Gry gave to
thequalityofthecommunity,moraleandcommunication,
and how much attention he gave to the quality of the
team'slinkagetothesponsorsinthePostOfficeandtothe
external test department. He was able to build close col
laborationacrossorganizationalboundaries.
Finally,wecan'toverlooktheeffectof havingaspon
sor who paid for integrated, running features every six
weeks. Whatever Gry's bosses may have been think
higherupthemanagementchaininSolysticandNorthrup
Grumman, they saw a team presenting features to a cus
tomereverysixweeks,andacorrespondingcheckcoming
from the customer shortly thereafter. That simplifies dis
cussionwithmanagementawholelot.
HereisGry'sstory.

101
 Sw DevasaCooperativeGame
TailoringCrystalYellow,byGryDerbier,Project
Manager,Solystic
Theprojecthadseveralchallengingaspects:
Itwasbusinesscriticalforthecustomer
Itwasthefirsttimethe customer was contracting
withaintegratortoprovideaturnkeysystem
It was the first time Solystic was leading a com
pletesystemproject,althoughitsmothercompany
Northrop Grumman had previous experience of
thisbusiness
Though Solystic has a long experience in the
automationofdomesticmailprocessing,this pro
gram was one ofthefirstbusiness in the interna
tionalfield
Itwas afixedprice,fixedtime contract tobede
liveredinashorttimeframe.
Istartedwithprettyfewideasandguidingprinciples.The
cooperativegamemodelwastheframeworkofthoughtsI
would always come back to in order to make sense of
what I was seeing happening. The team = product for
mula, which I consider a stronger form of the Conway's
law (see Software for your head (McCarthy 2002) was
howIunderstoodhowtoinfluencethefinalproductqual
ity through the group shape and characteristics. Incre
mentalgrowthofbothproductandprocessrequiringperi
odic reflection and adaptation was at the core of the
method.We employedusecases tospecifythesystem as
amongthequalitiesofusescaseswastheyactasatoolto
link several teams together, especially development and
integrationteams.
During the RFP process I elaborated a development
plan built on the principle of fixedlength iterations and
frequent interactions withthecustomerteam.Ihave later
been told the customer considered this feature to be a
competitive advantage. Timeboxed iterations came to me
through Jim Highsmith's (2000) book Adaptive Software
Development book and the reading of DSDM (Stapleton
1999???). At that time, I borrowed the iteration structure
from Stappleton's book. During the project, we brought
small variations about the form of communications with
thecustomerduringaniteration.
Theoverallprojecthadaphaseandgatestructure.Six
monthsaftercontractaward,wehadtohaveanapproved
system specification, a socalled baseline. The thirteen
monthmilestonewasthebeginningofthesitefullsystem
integration. Then eighteen months into the project the
sorting center would open to real production with a six
page 102
monthsperiodofstagedrampupconcludingwiththefinal
acceptanceofthesystem.
We had to demonstrate running features as early as
nine months after the contract was awarded. These con
tractual demonstrations were interim acceptance tests
linked to payment by the customer. All these milestones
were defined in the contract with a very high level func
tionaldescriptionofthecontent.
Organizational patterns (Coplien 2005) was the body
of knowledge we used to design the group structure and
communications.Asanexample,westartedwithalimited
thenumberofroles(fewrolespattern)toinclude:
projectleader
subteamleader
businessexpert
leaddesignerprogrammer
otherdesignerprogrammer
tester
We estimated the team would amount to a peak 25 per
sons.Howeverwequicklyassembledateamwiththenec
essarycorecompetencies:theprojectleader,thetestlead,
thedatabaseleadwithadatabasedesigner,theapplication
development leadandacouple of designerprogrammers.
Theapplicationdevelopment leadwasassignedthearchi
tecture responsibility (the Architect Also Implements
pattern). Then we slowly incorporated additional pro
grammers.
One subteam leader was the overall project leader.
Subteams were application domain teams (e.g. realtime
operation control, production management tools) or tech
nicalteams(wehadoneDBAandonetesterteamforthe
whole group). The leader and business expert roles were
cumulatedby oneperson.Inthe earlypartoftheproject,
the team leaders were writing the uses cases. During the
last third part of the project the leaders' time was mainly
devotedtointegrationandtest.
We got several adjacent 2 to 4 persons offices on the
same floor of the building. The leaders were grouped in
thesame office. Developers would be grouped per office
as much as possible by application domain or technical
activity.
It was a core practice to hold regular reflection ses
sions.Ithappenedeverymonthoncetheteamwas mainly
staffed,then everytwo months bythe end of the project.
These sessions were essentially informal discussions on
what was happeningintheproject.I played the role of a
facilitator.Alongthediscussions,whenIwouldrecognize
the need for a common decision to be taken on a given
subject,Iwouldformulateaproposalandtrytocometoa
consensus (inthesmallest groupIusedunanimous vote).
AmongthesubjectsIledtheteamtoexplore:conventions
102
 Sw DevasaCooperativeGame page 103
betweenthe developers and the internal test team, values quickly noticed. The meeting duration was targeted for
(courage to tell things), fear, configuration management, thirtyminutes.
codingstandards,integration frequency, relationship with Iinsistedonhavingtwodedicatedspaces fortheproj
theexternaltestteam. ect:ameetingroomandthetestinglab.Themeetingroom
So, during the course of the project, we changed sev wasaplacewithmanywhiteboardswheretheteamcould
eralworking conventions and stuck to others. We tried a hold collective design sessions. On the white boards was
number of strategies and techniques, some attempts aninformationradiatordedicatedtotheiterationplanning
worked, another good number failed miserably. Here are and tracking: the team progress was tracked during the
somepiecesofthestory. standup meeting by moving around the sticky notes on
Itwasmyplantosplittheleadersgroupseatinginthe this taskboard. The room was big enough to permit the
sameroomandseat eachofthem intheirsubteam room standupmeetingwiththefullteam.
once the system specification would be sufficiently com Despite all my efforts to build a collaborative culture
pleted.However,werecognizedtheadvantage of leaving withintheteam,thewholemembers didnot workinper
thingsastheywere. fect amicability. A good deal of storming occurred and
As the project was about automation and evolution of unresolvedtensions remained all along the project. How
thecustomer'sprocess,weknew we had to face progres ever,asmallpartof the team was truly willing to ignore
sive discovery of the customers needs until relatively far positionalgames and invest all their energy to get a suc
intotheproject.Soitwasclearthatwewouldnotsucceed cessfulsoftwareoutofthedoor.
without afairamount of concurrency of the different de AllalongthisprojectIhavebeenalittlenervousabout
velopmentactivities(theGoldRushstrategy(Cockburn thelightnessoftheprocess,fearingof missingsomething
1998)). We naturally resorted to the Build Prototypes thatshouldhavebeenpresent.Iretrospectivelythinkthat
pattern. this lightness is precisely what helped me to be always
We soon recognized the need for a specific build efficientlyonguardinsteadofbeingstifflyinguard.
manager role and a rolling assignment strategy for this
role.
Despite several discussions and commitments during
the reflection sessions, we failed to have a disciplined
protocolforinternalsoftwaredeliverytothetestteam.
Theamount ofunit tests was not satisfactory until we
decided to have one team member responsible for moni
toringtheunittestcoverageandhavinghimget theother
developers to invest time in writing their tests (we were
farfromdoingTDD!).
I encouraged people to pairprogram. Because they
worked in near proximity, people would occasionally
workbypairtoanalyzeordebugapieceofcode,but the
truepracticeofpairprogrammingnevergetadopted.Idid
not insist on having it as I considered we were asking
manynewthingsfromthisteam,iterativeandincremental
developmentnotbeingtheleastchangeformostpeoplein
thegroup.
I borrowed from the Scrum methodology the way we
implemented the standup meeting pattern. Given the
number of people, we considered splitting the standup
meeting into scrum of scrums several times during the
project . However, as we did not have sufficiently auto
mated integration tests, we decided to keep the standup
meetingwiththefullteamtoholdtheteamtogether. We
adopted small strategies to cope with the team size: The
meetingwouldoccureverytwodaysinsteadofeveryday
duringthemeetingwewouldfocusonfunctionalaspects.
Technical aspects would be raised if necessary or only

103
Sw DevasaCooperativeGame page 104

104
Sw DevasaCooperativeGame page 105

APPENDIXA'
TheAgileSoftwareDevelopment
ManifestoandtheDeclarationof
InterDependence
AstheManifestoforAgileSoftwareDevelopmentgrewinsignificance,peoplewanted
toknowhowtoapplytheideastoprojectsoutsidesoftwaredevelopment,andalsotodis
tilloutthegeneralmanagementprinciplesinvolved.Adozenandahalfproduct,project,
andmanagementspecialistsfrominsideandoutsidethesoftwareindustrymetoverasix
monthperiodtowritethemoregeneralagileleadershipversionof theagile manifesto.
Completed in January, 2005, they called this the Declaration of Interdependence, or
DOI,andstartedtheAgileProjectLeadershipNetwork.
In the following sections, I review the writing of the agile manifesto and discuss in
moredetailtheDOI.

105
 Sw DevasaCooperativeGame page 106

THEAGILESOFTWAREDEVELOPMENTMANIFESTO(II)ANDTHEDECLARATIONOFINTERDEPENDENCE
........................................................................................................................................................................................ 105
THE AGILEMANIFESTOREVISITED 109
THE DECLARATIONOF INTERDEPENDENCE 108

106
 Sw DevasaCooperativeGame
TheAgileManifestoRevisited
The writing of the Manifesto for Agile Software Devel
opment wasawatershedmoment.Wedidn't knowthat at
thetimeofwriting,ofcourse,althoughtherewereanum
ber of prolific authors in the group. The rapidity with
whichpeoplearoundtheworldundersignedthemanifesto
on the web site surprised me. Even more surprising was
that withinsix months conferences already hadpanels on
the subject. In 2006, I saw "requiring an agile approach"
writtenintoacosourceagreementbetweentwoverylarge
companies, and the Software Engineering Institute was
developingwaystohelpitsexaminersevaluateagileproj
ects.
Many people ask what it was like to write the mani
festo,andinparticular,whatourmeetingprocesswas.I'll
offer myownpersonalobservations ofthat meeting,why
it was unusual, and perhaps why it worked. There isn't
needorspacetogointogreatdetail,soIshalljustpickout
whathasseemedinthelightofsubsequent experiencesto
beinterestingobservations.
BobMartincalledthemeeting,saying,"Isitjustcoin
cidence that so many of us are saying things that sound
alike?"Headdedthathewasinterestedinwritingamani
festo.(I,forone,wascompletelyuninterestedinwritinga
manifesto, so the reaction to the manifesto was perhaps
moresurprisingtomethantohim).Bobinvitedawonder
ful set of people to the meeting, both proponents of the
"lightweightprocess"viewaswellassomeothers.Notic
ing that we had people only from North America, we
asked for a representative of the UKbased DSDM con
sortium to be present. Ari van Bennekum flew in from
Hollandjustforthemeeting.Weendedupwithrepresen
tatives for XP, Scrum, Crystal, Adaptive, Feature Driven
Development, DSDM, and generally light and pragmatic
development (Andy Hunt, Dave Thomas, and Brian
Marick).
After the round of "Hello Who Am I", we sat around
and stared at each other for a minute, and someone said,
"Howdowe makeanagenda?"Someonesuggestedwrit
ingagendaitemsonindexcards,andsincetheXPpeople
intheroomofcoursehadindexcardsintheirpossession,
they immediately pulled some out, started writing on
them, and threw them into the center of the floor. Sud
denly there was a critical mass of people casting index
cards onto the floor. The rest, whatever they thought,
starteddoingthesame,untilweranoutofideasandhada
pileofindexcardsonthefloor.
Someoneasked,"Howdoweorganizethosecardsinto
an agenda?" Someone said (you will notice that by this
page 107
time, I had already lost the ability to note who was sug
gesting what),"Allthose whocareabout the orderof the
agenda sort them out, and the rest can leave us to it."
Since I didn't care about the sequence of topics, I took a
break. When I came back, the index cards were being
tapedontothewall.
Later on, someone asked, "I just thought of another
agenda item. What should I do with it." Someone an
swered,"Findtheplaceintheagendayou'dlikeit,andput
itthere."
Ispendtimeonallthisbecausetwothingsstrikemeas
verysignificantaboutthisgroupsofar:
Respect. There was enormous trust in the room of
eachpersonforeachother.Noonetriedtohijackthe
meetingeveryonelistenedverycloselytoeveryother
person, giving at all times greatest credence to what
thatpersonwassaying.
Selforganization. This was selforganization of the
highest caliber. Under other circumstances I have
been in, one, or worse, multiple people have tried to
"run" the meeting. With senior people in the room,
many of whom don't know the others, it is easy a
power struggle to show up in the first minutes. That
neverhappened.
We spent time on around of "What am I recommending
andwhatdoIstandfor,"bywayofintroduction.Inoticed
that each of our processes, when described in only 15
minutes,seemedstrangetosomeoftheothersintheroom.
Wequicklydecidedthatitwasnotanaccidentthatour
recommendations sounded so similar, there was some
thing underlying that similarity, and we should discover
whatitwas.Thereasonthisisimportanttomentionisthat
wedisagreedbackthenonhowtorunprojectsontheday
todayand minutebyminutebasis,and we disagree still.
Notwithstanding those disagreements, there is a very
strong commonality that separated then and still sepa
ratesourviewsfrommanyothers.
Someone said, "I don't like the word "lightweight", it
doesn't sound like we're serious." Someone else said,
"Lightweight is a reaction against something. I want a
word that stands for something." So we spent an hour
searchingforatagwordtocapturewhatwewereafter.
Ifoundtheprocessofdoingthatwordsearchinterest
ing:
First,webrainstormed20or30namesandwrotethem
down.
Second,wepickedoutafewnamesanddiscussedfor
eachwhywe didn'tlikeit.
107
 Sw DevasaCooperativeGame
The latter tactic helped us understand what we stood for
and what we stoodagainst. Writing down why we didn't
likeaworddidn'tdisqualifytheword,itmerelyhelpedus
understandwhatwasinsideourheads.
Forexample,foroneword,anobjectionwas,"I'dhave
tobewearingpinktightstosaythatword.Irefusetowear
pinktights."Wewerelookingforastrongword,tomatch
Musashi's,"Whateverguardyouadopt,do not think of it
asbeingonguardthinkofitaspartoftheactofkilling" gestedthatithadtobeamoreorlessfairvaluecompari
(orforus,deliveringausefulsystem).
Agile development is aggressively delivering what is
needed,not merelyavoidingpaperwork.Hence myselec
tionoftheBengaltigerforthecoverofthis book,as op
posedtoagymnastoradancer.Myotheragile mascot is
thiswickedlooking,deepseamonsterIfoundonatshirt:
FigureA'1.Thistshirtshowsmyfavoriteagilemascot
(PhotowithandcourtesyofJonasKongslund).
Boththetigerandthedeepseamonsterlookcertainto
eat dinner. They are not merely avoiding paperwork or
practicingflexibility.
Third,havingclarifiedourthoughts,wevotedforour
topthreechoicewords,andrankedtheresults.
Thetoptwowordswereagileandadaptive.Wehada
round of discussion and a final vote, settling on the
word agile. As I mentioned earlier (p. 66???), al
though adaptive has certain advantages, agile is the
wordwewerelookingforatthetime.Thesedays,we
expect our methodologies to be both agile and adap
tive.
TheDeclarationofInterDependence
Asthemanifestogrewinsignificance,peopleasked:
page 108
Then someone said, "Well, now we have a word. What
stands behind it?" What followed was interesting. Lunch
was served, and various people sat in front of the white
board discussing ideas. The space in front of the white
boardwastoosmallforall17people,sopeoplemovedin
and out, intermixed with eating lunch. Somewhere along
the line, someone suggested contrastingthis against that,
andthe valuecomparisonshowed up. Someone else sug
son,sothatpeoplecoulddisagreemeaningfullyonevalue
atatime.
Whenittookshape,wesatinfrontthewhiteboardand
wordsmithedit.Anyonecouldsaywhytheycouldn'tsup
port a particular wording, and we worked to understand
their view until someone came up with a better wording.
When we were done, each of us could sign for the full
manifestowithoutreservation.
Having the nameagile and the four value statements,
wethen movedtocreatethe12principles.Hereis where
thingsstartedtobreakdown,becauseitisatthislevelthat
theindividualdifferencesstarttoshowup.
For example, does the customer or user have to be
there daily, or is weekly good enough, or perhaps some
mixofhoursperweekplusbeingavailableforquestions?
Should we write that the system gets deployed daily,
weekly, monthly, quarterly? Is selforganization the crux
oftheapproach,orismanagementallowedtoplay?
Compoundingthesecomplications,it was gettingtime
for people to get on planes (we only budgeted two days
for this whole thing, after all). Once people started to
leave,werecognizedthatwewouldnotbeabletogetclo
sure on finergrained recommendations. This is, indeed,
whathappened.
Someonepointedoutthatwestillwantedtobeableto
disagreeatthedetaillevel,since we wereallstill explor
ing development methods. To use the term precision
(p.???),weagreedwith each otheron precision level 0
the single catchphrase agile. We agreed on precision
level1thefourvalues.We(barely)agreedonprecision
level2the12principles.Weagreedtoallow ourselves
todisagreeatthenextlevelofprecision.
Finally,wereviewedwhywehadbeenabletocoverso
muchterritorysoquickly.Theanswerwasrightinfrontof
us:Wehadpaidattentionto individuals and interactions,
we had worked facetoface, we had worked collabora
tively,wehadfocusedonourproduct.Inotherwords,we
hadjustlivedwhatwehadjustwritten.
108
 Sw DevasaCooperativeGame page 109
What is the corresponding version for nonsoftware UnderstandingtheDOI
productdevelopment?
Thesixsentencesareformedastwoclauses,"Weaccom
Whatisthecorrespondingsetofprinciplesandvalues
plishthisbydoingthat".Inotherwords,youseeusdoing
formanagement?
that, and the reason we care about that is because we're
JimHighsmithnotesthattounderstandtheagilemanifesto tryingtosetupthis.
for products at large instead of just software, simply re
Personally, I like to read the DOI in a 2column for
placethewordproductforthewordsoftwareinthemani
mat,wheretheleftcolumn identifies thewhat we'rehop
festo,andthemanifestoisstillclearandcorrect:
ingtoaccomplishandtherightcolumnidentifiesthehow
Working products over comprehensive documenta weintendtoaccomplishthat.Consideritinthisform:
tion
Indeed, this evidenced by the myriad applications of the
agile values and principles outside of software already Goal: Throughdoing:
discussedinthisbook.Reread,inparticular,MikeCollins' Focuson"flowofvalue"(not
sidebar(p.40???)toseehow lean manufacturing already IncreasedROI "trackingeffort"),preferablyin
anticipatedwhatwewerewantingtosay. continuous(onepiece)flow.
On the management side, a number of people voiced Engagecustomersinfrequentin
Reliableresults
an interest in exploring the extension of the agile mani teractionsandsharedownership
festo to project management and product development Iterations,anticipationandadap
Manage
outsidesoftware.Weheldthefirstmeetingtoexplorethat tation(Thinkahead,plan,iterate,
uncertainty
topicattheAgileDevelopmentConferencein2004.That deliver,reflect,adapt).
groupmettwice more,finallyonFeb1,2005writingthe Recognizeindividualhumanbe
sixpointsoftheDeclarationofInterDependence,orDOI: ingsastheultimatesoureofvalue
Unleashcreativity
We increase return on investment by making con andinnovation Createanenvironmentwherein
tinuousflowofvalueourfocus. dividualpeoplecanmakeadiffer
Wedeliverreliableresultsbyengagingcustomersin ence.
frequentinteractionsandsharedownership. Groupaccountabilityforresults
We manage uncertainty through iterations, antici (thewholegroupissinglyac
Boost countable,nointeamblame)
pationandadaptation. performance
We unleash creativity and innovationby recogniz Sharedresponsibilityforteamef
ing that individuals are the ultimate source of fectiveness.
value, and creating an environment where they Situationallyspecificstrategies,
Improveeffective
canmakeadifference. processesandpractices.(Noone
nessandreliability
Weboostperformancethroughgroupaccountability answer,folks,getusedtoit)
for results and shared responsibility for team ef
fectiveness. The alert reader will notice that there is precious little
We improve effectiveness and reliability through about the Declaration that is unique to project manage
situationally specific strategies, processes and ment.Thepointsapplyacrossallmanagement, evenself
practices." organizingandselfmanagingteams.
Thesignatories to the DOI were David Anderson, Sanjiv Ifthereis oneproblem withtheDOI,it is thatthesix
Augustine, Christopher Avery, Alistair Cockburn, Mike points sound like platitudes. Perhaps that is because, un
Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, like the Agile Manifesto, the DOI doesn't name the bad
OleJepsen,LowellLindstrom,ToddLittle,KentMcDon guys.Itstatescauseandeffectrelations.Onlywhentrying
ald,PollyannaPixton,PrestonSmithandRobertWysocki. toapplythepointsdothesurprisesshowup.
Thatlistofpeople is notableforthebreadth of exper Herearesomeofthesurpriseslyinginstore:
tise, ranging from project management to product devel "... continuousflow ofvalue..."
opment to agile software development, to line manage
Leanmanufacturingteachesusthataprocessimprovesas
mentandtoteamworkspecialist.
thebatchsizes shrink(see "Lessons fromLeanManufac
Here below, I elaborate on my thinking about this turing" onp.37???).While developing software, the unit
declaration. of inventory is the unvalidated decision. Every written
requirement, architectural decision or document, design

109
 Sw DevasaCooperativeGame
drawing ordecision,andpiece ofwrittencode,counts as
inventoryuntilitisintegratedandtested!
Shrinking each of these to a unit piece, or continuous
flow is a stretch goal to consider for software develop
ment.Itimpliesthateverydecision,whetherrequirements,
architecture, design or code, must be implemented, inte
gratedandtestedasasingleunit.I'mnot goodenoughto
dothatyet,butIdounderstandtheimportanceofthegoal.
"...continuousflowofvalue..."
Mostmanagersmanagetasks,checkingtasklistsandtask
completion,whentheyshouldbemanagingthegrowthof
value.
In software development as well as in other fields,
valueaccrues(orfailstoaccrue)suddenly,atthemoment
of integration. All the work leading up to that moment
carries no value to the buyer. This is the reason agile
teams havereplacedthestandard earnedvalue chart with
burnup charts showing accumulation of running, tested
features(RTF),notjustcompletionoftasks.
"...byengagingcustomersinfrequentinteractionsand
sharedownership."
Shared ownership is difficult to imagine for certain con
sumerproducts,buteasytoimagine forsmallercustomer
groups. I am thinking in particular here of development
for any internal user group, and custom development of
any kind. See the sidebars describing Tomax's new con
tractswithitscustomers (p.???)andGryDerbier'srela
tionshipwiththeFrenchPostOffice(p.???).
Despite that, very few organizations take the idea of
sharing ownership with their customers seriously, and
equally dangerous, very few custoemrs take the idea of
shared ownership (and responsibility) with their contrac
torsseriously.Manyofcustomers don'teven want shared
ownershipmanywillsay that they hired you to do "all
thatstuffjustdeliverausefulsystemsoon."
Surprisingly,theothersurpriseinthesentence is "fre
quent interactions." I write 'surprisingly' because the im
portance of frequent interactions has been highlighted,
researchedandreportedfordecades.Itshouldn'tbeasur
prise at all. However, how often does your customer,
buyer,sponsor,oruserbaseshowupontheprogramming
floor and check out what the team is really doing? The
Agile Manifesto says the desired answer is "daily." The
DOI says "frequent." I'll bet that in most of your organi
zationsitisneither.
"We expectuncertainty..."
Many managers and management advisors advocate that
the point of project management is to eliminate uncer
tainty?TheDOItakes the stand that uncertainty is a fact
page 110
oflife,thatmustbemetonitsownterms,andinthis,dis
tinguishesitselffromothermanagementadvisories.
"...iterations,anticipation andadaptation."
TheDOIdivergesfromtheAgileManifestobycallingfor
anticipation.Thefeelingamongusincludingbothofthe
AgileManifestoauthors inthegroupwas thattheagile
communityhasbeenforgettingtousetheinformationthey
alreadyhaveat hand,andhavebeencostingtheirorgani
zationsbyforcingthemtoreacttoeventsthatshouldhave
beenforeseen.
To test this point of the DOI, consider in what ways
andto what extent your management balances the use of
iterations with anticipation, and to what extent they ever
adapt.
". . . by recognizing that individuals are the ultimate
source of value, and creating an environment where
theycanmakeadifference."
Betruthful,now,"Peoplearetheultimatesourceofvalue"
how many managers really take that seriously. We do.
ButtheDOIextendstheAgileManifestobyremindingus
that the environment also matters.People treated as cogs
inamachinedonotdoaswellaspeoplewhofeelnotonly
that they matter, but that they can make a difference in
otherpeople'slives.
Thisisindangerofbecomingaplatitude,andIsuspect
that organizations that aren't already paying attention to
thispointwon'tchangejustonthebasisoftheDOI.How
ever,Ikeepreadingbusinesscaseswhereacompanydis
ruptsitscompetitors,andinsidethecasedescriptionalot
ofspaceisgiventowayinwhichpeoplearenot just em
powered,butfeeltheyhaveachancetochangetheworld.
"...groupaccountabilityforresults...."
Group accountability for results has long been known its
effectiveness.Onewaytoachieve groupaccountabilityis
through crossfunctional teams. These teams have been
documented and recommended for several decades be
cause they outperform the other teams (Hammer Reengr
theorganizationref,Toyotawayref,HolisticDiversityref
Cockburn1998soop).
Leanandagile manufacturingtextsrecommend cross
training people at adjacent work stations. The DOI goes
further and suggests that people on the team develop an
awareness ofwhat theothers ontheteamneed,sothat if
theycan'tdothejob,theycanhelpin whateverwaythey
can.
Sociologist Karl Weick, studying teams that work in
lifecriticalenvironmentssuchasaircraftcarriersandfire
fighting, calls this mindfulness: people being aware of
what other people are doing (Weick 2003???). Mindful
ness is a perfect term for one of our objectives with os
110
 Sw DevasaCooperativeGame
moticcommunication,andagoaltokeepwhencommuni
cationisnolongerosmotic.
Mysteriously, this idea gets overlooked in most com
panies.
". . .group accountability for results and shared re
sponsibilityforteameffectiveness."
Chris Avery, the teamwork specialist among the DOI
authors, clarified the shared accountability phrase. He
wrote,
"Mostpeopleassumethatsomeoneelseisresponsible
fortheeffectivenessorlackthereofintheirteam,
andthatsomeoneelseshoulddosomethingsothatthe
teamismoreeffective.TheDOIsaysthatiftheteam
isn'taseffectiveas"I"like, thenit's up to metotake
responsibilityforcorrectingthesituation."
Zhon, Johanssen, a senior programmer, describes that he
views improved business impact as the programmer's
responsibility,asisimprovedusabilityandsystemquality.
Heappliesthatsentimentforeachjobinthecompany,and
practicesithimself.
"...situationallyspecificstrategies ..."
OfallthepointsintheDOI,this oneshould be most ex
pected to anyone who has read this far in the book. We
have discussedat lengththat what works in one situation
maybackfireinanother.
Thisisnotobvioustothosemanymanagerswhokeep
lookingfor a closedform formula to apply. Surprisingly,
it is also not obvious to otherwise enlightened people re
searching "best practices." The optimal strategy for a
situation may require a reversal of what would normally
beconsideredabestpractice(see"BalancingStrategies",
p.23).
The successful team stays alert to changing circum
stances,andadjustsstrategiesandpracticestosuit.
Those are some of the surprises in the DOI. There is
much more one can write about it, just as there is much
more one can write about the agile manifesto. A longer
discussionof my interpretation of the DOI, including the
DOIasa"12stepprocess"isonmywebsite60.
Finally, it is useful to know that in constructing the
DOI, each coauthor embedded in it their own personal
framework for management. We collected those personal
frameworks and checked that each person could operate
their personal framework from the DOI, even if that
frameworkwasn'texplicitlynamedinit.
Just so you can see one, here is my personal frame
work.Itconsistsofthreeelements:
60
http://alistair.cockburn.us/ htdocs/crystal/articles/ doi/ declarationofinterde
pendence.htm???UPDATETHIS!!!
page 111
People Not only their hearts and minds, but also
theireyes,earsandmouths.(Communication:the
cooperativegame,remember?)
Situationally specific strategies All recommenda
tionsarespecifictothecontextathand.
Feedback Close in and endtoend, within each
workgroupandacrossthetotalsystem,withinthe
team'sprocessandontheendproduct.
You mayfind it useful to write down your own personal
frameworkforprojectmanagement,andseehowitfitsor
contraststowhatisintheDOI.
UsingtheDOI
IwishthattheprinciplesintheDOI maybecomethede
fault modeofmanagementinthefuture,nottheexception.
ImprovedProjectManagement
Aproductionmanagerforoneofmybookstriedtosched
ule the entire fourmonth book production process up
front. She did this because she was worried meeting a
deadline.
Tomakesuresheleftnothingout,sheassignedevery
one's time in halfday increments . . . and then ignored
smallrealities,suchasthat Iwouldbeonasmallboat in
the Caribbean for ten days. Naturally those were exactly
thedayshescheduledformetorevisethemanuscript.
She phoned each person's manager each day to check
thattheactivitywasproceedingaccordingtoherschedule.
Shehadthe300+pagemanuscriptmailedfromperson
topersoninitsentirety(alargebatchsize,seep.???and
p.???),sonoparallelworkwaspossible.
Sheallowed no time for second revisions by any per
son,sinceofcoursenoonewouldmakeanymistakesona
projectthisimportant.
Needless to say, the project immediately ran off the
rails, starting with my tenday vacation. People made
mistakes, had other work to do, and so on.. The project
wasbehindinnotime,andeverybodywasmiserable.
She was not malicious and not even particularly in
competent. She was trying to maximize business value,
cut costs, maintain quality, and so on. Her mistake was
onlyinunderstanding.
I want every person, untrained or trained, to think in
termsoftheDOI.Iwant itspreceptstaught in kindergar
ten,andusedbyreflexby everyone on a project. "Tradi
tional,"impersonal,batchorientedprojectmanagement,is
what ought to be questioned in every case. That's what I
thinkthisdeclarationshouldleadto.
Whenyounextput'agile'intoyourcontract,writeus
ing the project management Declaration of Inter
Dependence. That way you'll not only get working soft
111
 Sw DevasaCooperativeGame
ware,butalsothebenefitsofthethings in the right hand
sideoftheabovetable.
SelfManagedTeams
A final comment is appropriate for selfmanaged teams.
We were quite aware that there are many selfdirected
teamswithnodistinguishedmanagerposition,andwanted
theDOItobeapplicableforthem,also.
A selfmanaged team should have no trouble signing
upforgroupaccountabilityforresultsandsharedrespon
page 112
sibility for team effectiveness. Also flow of value (not
effort), shared ownership, iterations, anticipation, adapta
tion, recognition of individual human beings as the ulti
matesourceofvalue,andanenvironment where individ
ualpeoplecanmakeadifference.
Actually,itseemstomethattheDOIisexactlythesort
of declaration a selfmanaged team would hang on their
wall.
112
Sw DevasaCooperativeGame page 113

APPENDIXB'
Naur,Ehn,Musashi:Evolution

113
Sw DevasaCooperativeGame page 114

14NAUR,EHN,MUSASHI(II) ERROR!BOOKMARKNOTDEFINED.
NAUR ERROR!BOOKMARKNOT
DEFINED.
EHN ERROR!BOOKMARKNOT
DEFINED.
MUSASHI ERROR!BOOKMARKNOT
DEFINED.

114
 Sw DevasaCooperativeGame
Ihavereferredat lengthinthis booktothe ideas ofthe
three people quoted in Appendix B: Peter Naur, Pelle
Ehn,andMusashi.
From Peter Naur's writing, we get the idea that the
team is working to create a common theory for their
work.IntermsoftheSwampGame(p.10???),theteam
startsoffnot knowing what they are supposed to build,
whereintheswamptobuildit,orwhatthelayoutofthe
swampis.Thetheorytheyarebuildingis theanswerto
thosethreequestions.
Part of the communication aspect of the cooperative
gameis establishingashared directionfortheteamand
asharedviewofwhattheresultsneedtolooklike.This
iscalledcommonvisioninsomewritings.Naur'stheory
includesthat,andalsoacommonunderstandingofwhy
thethingisputtogetherthewayitis.
FromPelleEhn'swriting,wegettheideathattheun
derstandingofthetasktobedonemayneverbeperfect,
butmayneverneedtobeperfectl.Themagicliesinthe
backandforth between developer and user, creating
new understanding about the task at hand and the tools
beingcreated.
It is easy to look at Ehn's team's assignment from
1986and think we are long past the days when people
I use the Musashi quites to start off my oneday work
shops introducing agile development. At first, it seems
strange to use samurai quotes to understand software
development, but then later it becomes so obvious how
much his writings have in common with modern soft
waredevelopment.
Ihighlightthreeofhismotifs:
Wastenomovement.
Learneachtool'sstrength don'tbecomeattachedto
anyonetool.
Reflectandadapt.
The one thing in Musashi's writing that is different and
onemustgrapplewith,isthatMusashikeepsreferringto
killingtheopponent.Whoorwhatistheopponent?
page 115
After five years of living with their words, I can
mostlysuggestthatyoureadandrereadthoseextracts.I
continuetofindvalueinthem.
Naur
Common vision,andcommonunderstandingof why
the thing is put together the way it is, are both part of
anycooperative game,and mostcertainlyfor our coop
erativegamesofinventionandcommunication.
Naur'sdiscussionoftheorybuildingasapersonalac
tivity helps us to understand modes of transmitting un
derstandingfromonepersontoanother.Thereisnothing
that says that written documentation is the best way to
conveyunderstandingpossiblyitistheworst.Ifwetake
the challenge to "convey understanding," then we can
experiment with different ways until we find some that
workbetter.
Ehn
couldn'tunderstand howthe computer could help them.
However, every organization working on improving
their organizational process is faced with this problem.
Untilthesystemgetsdeliveredandputintouse,thereis
reallynowaythattheuserscantellhowthepresenceof
the new system will change the ways they work with
each,andthewaystheycarryouttheirjobs.
Musashi
Iwasshockedinoneorganizationwhensomeonean
swered,"Theusers!"Lookingforotheropinions,Iasked
anotherperson,whosaid,"Theotherspecialists,likethe
databaseadministrator!"Anotherpersontriedtoclarify,
"Sometimesyouhavetotakeoutoneoftheotherpeople
onyourteaminordertogetyourworkdone."
Justincase any reader is tempted to make a similar
response,Iwishstressthatyourteammateisnottheop
ponent,noristheuser,yourmanagerorthesponsor.
The "opponent" is the problem you are trying to
solve,theobstaclestodeliveringthesystem."Killingthe
opponent"issolvingtheproblem,deliveringthesystem.
Yoursituationwillthrow enoughobstacles in yourway
that you don't need to consider your team mates oppo
nents.
Remember:"There'sonlyus."
115
Sw DevasaCooperativeGame page 116

7(newchapter)
Afterword
Yourcenterofinterestdetermineswhatyoushoulddowiththeideasinthisbook.

116
Sw DevasaCooperativeGame page 117

7(newchapter)AFTERWORD 116
BUSINESSASA COOPERATIVE GAME 118
LEADERSHIPANDPROJECTMANAGEMENT 119
AGILE SOFTWARE DEVELOPMENT 118
EVERYONE 120
REFERENCES 121

REFERENCES 121

117
 Sw DevasaCooperativeGame page 118

AgileSoftwareDevelopment
Designingtheuserexperience(studyingtheusers,de tegration with automated testing lets the team ex
signingthesystemmetaphor,detailingthescreens)has periment, recover from mistakes, and follow
a lot of crossdependencies with programming the evolvingneedsmoreeasily.
functions. Since there is no simple answer, use the Demand frequent delivery of running, tested fea
principles in this book and watch closely the depend tures62.Negotiateoverhowfrequent "frequent" is,
encies between user experience (UX) design and pro andhowdelivered"delivered"is,butbeclearthat
gramdesign. demeritsaccrueforeach layer of the software not
Youwillprobablyinvestigatetheusers'needs and integrated, and each stage removed from the real
develop the initial system metaphor as a separate endusersthatyour"delivery"consistsof.Connect
activitypriortosystemsoftwaredevelopment,be thefrequentdeliveriestobusinessvalue.
causethereisprobablyalongleadtime neededto
makethosedecisions.
OncetheinitialUXmodelisbuilt,youcanproba
bly grow the screens incrementally just ahead of
thesoftwarethatsupportsit.
TheUXdesignersprobablyneedatleastaweekor
two lead time (ahead of the programmers) to get
theirthoughtsinorderforanygivenfunction.The
lead time question has to be revisited frequently,
sincetheanswerislikelyvarybyteamandbyas
signment.Don'tgettrappedintothinkingthatthere
is only one answer. Here, more than in other
places,theoptimalstrategyvarieswidely.
Avoid the common misunderstandings that have at
tachedtoagiledevelopment.
Bear in mind that agile means "pay attention to
current realities" (as opposed to "no planning").
Alwayshaveacoarsegrainedlongtermplananda
finegrainedshorttermplan.Learnafastplanning
technique61,andrebuildtheplanfrequently.
Don't believe that "more agile" equals "better."
Agility,howevernifty,isonlyoneprioritythatcan
attach to a project. Balance the desire for agility
with the other priorities clamoring for attention.
Learntomixagilestrategiesintoyourotherpriori
ties.
Don'tbelievethat"shorteriterations"equals either
"better" or "more agile," otherwise your iterations
will degenerate into nothing more than planning
windows that are not connected with either busi
nessvalueordeliveringavaluablesystem,Findan
iterationlengththatworks foryourteamandcon
nectswithbusinessuse.
Incorporate automated unit testing, automated
system testing, and automated system builds with
tests into yourteam's daily activities. Frequent in

61
See, for example, the Blitz Planning technique described in (Cockburn
62
2005) ThanksagaintoRonJeffriesforthisoutstandingphrase.

118
 Sw DevasaCooperativeGame
BusinessasaCooperativeGame
Most of business is nothing more than a cooperative
(andcompetitive!)gameofinventionandcommunica
tion.This means that thechapters onthe impossibility
of communication, quirks and motivators of individu
als, rules of teams, all apply directly. Consider doing
thefollowing:
Reread the Declaration of InterDependence
slowlyandonephraseatatime.Askyourselfwhat
stops you from incorporating each clause (some
few may prove inapplicable). Ask yourself what
your core operating principles are keep the num
ber to three, four, or five. Look to see whether
thosecoreprinciplesarecapturedthere,andifnot,
whatwouldyouneedtoadd.
Improve the quality of your team by paying close
attention to goodwill in the communications and
the quality of the community. The speed of the
team is limited by the speed at which ideas move
(plus, not to forget, the talent present). Anything
that slows the movement of ideas slows the prog
ressoftheteam.
Holdareflectionworkshoponceamonth,nomat
ter what business you are in. Discuss your team's
operating conventions, what is slowing the team
down, and what it might try to differently. Track
ongoing problems, because those may need to be
escalatedtohighermanagementforresolution.
Revisityourvendorcontracts.Incorporatetheidea,
"Theyarealsous."Aslongas youtreat yoursup
plychainasthem,itslowstherateofcriticalfeed
Everythingjustmentionedregardingbusiness asa co
operativegameapplies directlytoleadershipandproj
ect management, in software development or another
business, in a managementoriented organization or a
selforganizedgroup.Consider:
Noticethattheroleoftheleaderormanagerisam
plydescribedinthefollowinglist.
Get executive nourishment (both money and
decisions).
Developtalentandskills.
Integrateresultsfrequently.
Reflectively incorporate feedback on both the
productandtheprocess.
Buildamicabilityandpersonalsafety.
Monitor communication for frequency and
quality.
page 119
back and the movement of ideas, and slows your
business.
Try some friendly competition inside your team,
makingsureto handout interestingrewards atthe
end.Youwillprobablydobetterifyoudon'tmake
the competition directly affect the team's output,
because people will try to cheat the system. Ide
ally,whentheycolludeandcheat,theyshouldim
prove,nothurt,yourtotaloutput.
Revisit the 2D Crystal grid of projects (the one
showing team size and criticality) and the sweet
spotsofagile development. Wherever you can re
duce team size, collocate the team, or get faster
feedback, you have a chance to reduce communi
cationandcoordinationoverhead.
Findopportunitiestoget"smallwins."Evenjusta
few to start with will make the team stronger and
morerobust,improve moraleandcommunity, and
giveyouchancestotuneboththedirectionyouare
headed and the operating conventions the team is
usingtogetthere.
Smallwins plus periodicreflectionareas close to be
ingamagicsauceas Iknow.Makethempart of your
core.
Leadership
Arrangeforadequatetimetofocusonthework.
Generate clarity in both direction and priori
ties.
Afteryoustripallthepaperworkanddrudgeoutof
the leader or manager's assignment, those items
remain. They become the heart of the leader or
manager'swork.
Learnthe language of lean manufacturing, in par
ticularthenotionofapullsystemandthepenalties
of queues of work in progress. Learn to think of
developmentasanassemblylineofdecisions,and
visualize the dependencies between the individual
peopletocreatemeaningfulstrategies.
Separateproject management strategies from your
organization's process policies to the greatest ex
tent possible.Different situations call for different
management strategies, and you don't want to be
119
Sw DevasaCooperativeGame page 120
constrained to an obviously ineffective strategy opment strategies into the corporate methodology
just because someone unwittingly bundled devel standard.

Everyone

Alwaysremember:"There'sonlyus."

120
 Sw DevasaCooperativeGame page 121

REFERENCES
References
(Allen1998)Allen,T.J.,ManagingtheFlowofTechnology,MITPress,Boston,MA,1984.
Austin, R., Devin, L., Artful Making: What Managers Need to Know about How Artists Work, Financial Times
PrenticeHall,UpperSaddleRiver,NJ,2003.
(Augustine2005)Augustine,S.,ManagingAgileProjects,PrenticeHallPTR,UpperSaddleRiver,NJ,2005.
(Boehm 2004) Boehm, B., Turner., R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison
Wesley,Boston,MA,2004.
(Booch1996)Booch,G.,ObjectSolutions:ManagingtheObjectOrientedProject,AddisonWesley,MenloPark,
CA,1996. emailhim?
(Cerasoli 2001) Cerasoli, R., Office of the Inspector General, Commonwealth of Massachusetts, "A History of
CentralArtery/TunnelProjectFinances19942001:ReporttotheTreasureroftheCommonwealth",availableonline
athttp://www.state.ma.us/ig/publ/cat01rpt.pdf.
(ChaseURL)[9]Chase,T.,"Revelation13:TheBigDig,"onlineathttp://www.revelation13.net/bigdig.html.
(Cockburn)Cockburn,A.,SurvivingObjectOrientedProjects,AddisonWesley,Reading,MA,1995.
(Cockburn ) Cockburn, A., Crystal Clear: A HumanPowered Methodology for Small Teams, AddisonWesley,
Boston,MA,2005.
Highsmith,J.,AgileProjectManagement:CreatingInnovativeProducts,AddisonWesley,Boston,MA,2004.
Holtzblatt, K., Wendell, J., Wood, S., Rapid Contextual Design: A HowTo Guide to Key Techniques for User
CenteredDesign,Elsevier,SanFrancisco,CA,2005.
Laufer,A.,SimultaneousManagement:ManagingProjectinaDynamicEnvironment,Amacom,New York,NY,
1997.
Marcus, A., Big Winners and Big Losers: The 4 Secrets of LongTerm Business Success and Failure, Wharton
SchoolPublishing,UpperSaddleRiver,NJ,2005.
(NATO1968)Naur,P.Randell,B,SoftwareEngineering:ReportonaconferencesponsoredbytheNATOScience
Committee, Garmisch, Germany, 7th to 11th October 1968, Naur, P., Randell, B., eds., 1969, online at
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/
Ohno,T., ToyotaProductionSystem:BeyondLargeScaleProduction,ProductivityPress,Portland,OR,1988..
Poppendieck,M.,Poppendieck,T.,LeanSoftwareDevelopment:AnAgileToolkit,AddisonWesley,Boston,Mam
2003.
Rich94:Rich,B,Janos,L.,SkunkWorks:APersonalMemoirofMyYears atLockheed,Little,BrownandCom
pany,Boston,MA,1994.
Reinertsen, D., Managing the Design Factory: A Product Developer's Toolkit, The Free Press, New York, NY,
1997.
(Schn1983)Schn,D., TheReflectivePractitioner:HowProfessionalsThinkinAction,BasicBooks,1983.
Schwaber,K.,Beedle,M., AgileSoftwareDevelopmentwithScrum,PrenticeHall,UpperSaddleRiver,NJ,2002.
Stapleton,J., DSDM:BusinessFocussedDevelopment,2nd Edition,AddisonWesley,London,UK,2003.

121
 Sw DevasaCooperativeGame page 122
Weick,K., TheSocialPsychologyofOrganizing,2nd Edition,McGrawHill,NewYork,NY,1979.
Womack,J.,Jones,D.,Roos,D., TheMachineThatChangedtheWorld:TheStoryofLeanProduction,HarperPer
ennial,NewYork,NY,1991.
(Wright 1953) Wright, O., How We Invented the Airplane: An Illustrated History, edited by F.C. Kelly, Dover,
1953.

Charan,R.,"HomeDepot'sBlueprintforCultureChange",HarvardBusinessReview,April,2006,pp.6070.
Rigby,D.,Vishwanath,V.,"Locatization:TheRevolutioninConsumerMarkets",HarvardBusinessReview,April,
2006,pp.8292.

open
http://alistair.cockburn.us/crystal/talks/easq/efficiencyasaspendablequantity020.ppt, ICAM paper: Case Studies
MotivatingEfficiencyasa"Spendable"Quantity
"LearningfromAgileSoftwareDevelopment",parts1and2,CrossTalkMagazine,Oct,2002(pp.1014)andNov,
2002(
CockburnEiE:[http://c2.com/cgi/wiki?ExpertInEarshot]
CockburnPrrP:[http://alistair.cockburn.us/crystal/articles/prrp/projectriskreductionpatterns.html]
CoplienOP:[http://www.belllabs.com/cgiuser/OrgPatterns/OrgPatterns?OldOrgPatterns]

todo
cockburnprocessthe4th dimension
cockburngovernancearticle
SketchesofThought,Goel,V.,MITPress,Boston,MA,1995.
ogunaike1995
gladwell,Blink,???2005
boehm,b,"Getreadyforagilemethodswithcare,"IEEEComputer,jan2002?pp.???
boehm,turnerBalancingagilitywithdiscipline
goldrattcriticalchain
goldratttoc
ADC2003URL
Andersonbook
Andersonexperiencereport:
http://www.agilemanagement.net/Articles/Papers/BorConManagingLeanDevWithCFDs.pdf
http://www.agilemanagement.net/Articles/Papers/Feature_Driven_Development_
_towards_a_TOC__Lean__Six_Sigma_solution_v1_0.pdf
http://www.agilemanagement.net/Articles/Papers/From_Worst_to_Best_in_9_Months_Final_1_3.pdf
anderson:http://www.agilemanagement.net/Articles/Papers/Feature_Driven_Development_
_towards_a_TOC__Lean__Six_Sigma_solution_v1_0.pdf
http://www.agilemanagement.net/Articles/Papers/From_Worst_to_Best_in_9_Months_Final_1_3.pdf

JeffriesRTFURL
Larmaniterativebook

122
 Sw DevasaCooperativeGame page 123
Brooksnosilverbullet
inevitableillusions
coareiterationshazardous
Co A Governance Model For Agile and HybridAgile Projects Alistair Cockburn, Humans and Technology,
arc@acm.org,AlistairCockburnHaTTR2005.03,Sept.23,2005)
patton20042005articles
extremehoururl
walkingskeletonrefCC
Orbanes,?,"EverythingIknowaboutbusinessIlearnedfromMonopoly",HarvardBusinessReview,2002.
Cumins,D.,"TheDevelopmentGame,"AgileDevelopmentConference,2003,onlineat...
ArtfulMaking?
theendofs.e.andthestartofcoopergaming
Mathiassen2002articleAalborgcurriculum?
Olsonarticle
GoldrattTheGoalref
Anderson,D.,AgileManagementforSoftwareEngineering:ApplyingtheTheoryofConstraintsforBusiness Re
sults,PrenticeHallPTR,2003.
Augustine,S., ManagingAgileProjects,PrenticeHallPTR,2005.
Highsmith,J.,AgileProjectManagement:CreatingInnovativeProducts,AddisonWesley,2004.
DeCarlo,D.,eXtremeProjectManagement:UsingLeadership,Principles,andToolstoDeliverValueintheFace
ofVolatility,JosseyBass,2004.
Schwaber,K., AgileProjectManagementwithScrum,MicrosoftPress,2004.
Wysocki,R.,EffectiveProjectManagement:Traditional,Adaptive,Extreme,ThirdEdition,Wiley,2003.
Ambler,S.,AgileModeling,???
Cohn,M., UserStoriesApplied,AddisonWesley,2005???
ScottAmblerDecember2005issueofSoftwareDevelopment"HowAgileAreYou?",
http://www.sdmagazine.com/documents/s=9933/sdm0512h/0512h.html
Weick,K.

Anderson:ManagingLeanSoftwareDevelopmentwithCumulativeFlowDiagrams,BorCon,2004.

Glen Alleman's "Making Agile Development Work in a Government Contracting Environment" (Alleman 2003)
[http://www.niwotridge.com/PDFs/ADC%20Final.pdf]
JohnRusk's"AgileCharts"(Ruskurl)[http://www.agilekiwi.com/agile_charts.htm]
MikeCohn'sAgileEstimatingandPlanning(PrenticeHallPTR2005)

(Constantine2001)Constantine,L.,Lockwood,L.,"StructureandStyleinUseCasesfor
UserInterfaceDesign",invanHarmelen,M.(ed.),ObjectModelingandUserInterfaceDesign,
AddisonWesley,2001.Extractavailableonlineathttp://www.foruse.com/articles/structurestyle2.pdf.

(Cockburn 1995sucwg) Cockburn, A., "Structuring Use Cases with Goals," online at
http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm.

(ambler2005.12)http://www.sdmagazine.com/documents/s=9933/sdm0512h/0512h.html
123
 Sw DevasaCooperativeGame page 124

patton2004unfixingthefixedpricecontract

Satir,V.,"FromVirginiaSatir:ModelsofPerceivingtheWorldAttitudeTowardChange",inCouplesTherapyin
ManagedCare:FacingtheCrisis,Brothers,B.J.,ed.,HaworthPress,1999,p.4..

(Martin 2006), Martin, R., "Estimating Prices Up Front," in the comp.software.extremeprogramming Google
Groupsdiscussion,Sep2620047:42am,fullURL=http://groups.google.com/group/comp.software.extremeprogram
ming/browse_frm/thread/7a063ecc282d852a/9a203fad85f3d363?hl=en&lr=&rnum=1&prev=/groups%3Fq%3D%252
2We%2520aren't%2520talking%2520about%2520throwing%2520anything%2520together.%26hl%3Den%26lr%3D%
26selm%3Dhsedl0p0n9a0i5hunfu69l5ledcr03c483%25404ax.com%26rnum%3D1#9a203fad85f3d363

(cockburn2002.10crosstalka)Cockburn,A.,"LearningfromAgileDevelopment"parts1and2,inCrossTalk:The
JournalofDefenseSoftwareEngineering,onlineat http://www.stsc.hill.af.mil/crosstalk/2002/10/cockburn.html
and http://www.stsc.hill.af.mil/crosstalk/2002/11/cockburn.html.

(Marcus2006)Marcus,A.,BigWinnersandBigLosers:The4SecretsofLongTermBusinessSuccess andFail
ure,WhartonSchoolPublishing,2006.

(Owen1997)Owen,H., OpenSpaceTechnology:AUser'sGuide,2ndedition,BerrettKoehlerPublishers,1997.
(Coplien2005)Coplien,J.,Harrison,N.,Organizational PatternsOfAgileSoftware Development, Prentice Hall,
2005.

12680= 46pagesleft7/037pm
12685= 41pagesleft7/0310pm
13591= 44pagesleft7/046pm
141101= 40pagesleft7/052pm
143112= 31pagesleft7/055pm
143124+2= 21 pagesleft7/055pm
13pagesleft7/066pm

124