Bi

[AgileAg

[AgileAg

[AmblSc

[AmblScco

[AmblScat

[AmblSced

[AmblScco

[AnanBa

[BasiliViDepa

[Beck Keed

[Beck Ke

[Beck KeAd

[BoehmBa

B. Meye© Sprin

bliography

All URLs checked January 2014.

2001]ile Manifesto, at agilemanifesto.org. 2011]ile Alliance: Velocity page at guide.agilealliance.org/guide/velocity.html, 2011.

er 2006]ott Ambler: Agile Adoption Rate Survey, at www.ambysoft.com/surveys/agileMarch2006.html. er 2001]ott W. Ambler: Agile Modeling and the Rational Unified Process (RUP), at www.agilemodeling. m/essays/agileModelingRUP.htm (part of Ambler’s “agile modeling” site), 2001.er 2010]ott W. Ambler: The Agile Maturity Model (AMM), in Dr. Dobbs Journal, April 2010, available www.drdobbs.com/architecture-and-design/the-agile-maturity-model-amm/224201005.er 2012]ott W. Ambler and Matthew Holitza: Agile for Dummies, Wiley, 2012. See also “IBM limited ition” available online at www-01.ibm.com/software/rational/agile/agilesoftware.er testing]ott W. Ambler: Agile Testing and Quality Strategies: Discipline Over Rhetoric, at www.ambysoft. m/essays/agileTesting.html#AgileTestingStrategies, undated.d site]chan Anand: Conscires site at agile.conscires.com. 1975]ctor R. Basili and Albert J. Turner: Iterative Enhancement: A Practical Technique for Software velopment, IEEE Transactions on Software Engineering, vol. SE-1, no. 4, December 1975, ges 390-396, available at www.cs.umd.edu/~basili/publications/journals/J04.pdf.2000]nt Beck: Extreme Programming Explained — Embrace Change, Addison-Wesley, 2000. (First ition; see also [Beck 2005].)2003]nt Beck: Test-Driven Development — By Example, Addison-Wesley, 2003.2005]nt Beck, with Cynthia Andres: Extreme Programming Explained — Embrace Change,, dison-Wesley, 2005. (Second edition; see also [Beck 2000].)

1981]

rry W. Boehm: Software Engineering Economics, Prentice Hall, 1981.

r, Agile!, DOI 10.1007/978-3-319-05155-0, ger International Publishing Switzerland 2014

156

[BoehmBaAd

[BrookFr

[ChromCh

[CMMCMbeIn

[CockbAlCo

[CockbAl

[CockbAlali

[CockbAlAd

[CockbAlalibo

[CohnMco

[CohnM

[CohnM-d

[CohnM

[CohnMso

[CohnM

[CollaCo

[Cox 1Br

BIBLIOGRAPHY §

2004]rry W. Boehm & Richard Turner: Balancing Agility and Discipline – A Guide for the Perplexed, dison-Wesley, 2004.s 1975]

ed Brooks: The Mythical Man-Month, Addison-Wesley, 1975.atic 2003]

romatic: Extreme Programming Pocket Guide, O’Reilly, 2003.I 2010]MI Product Team: CMMI for Development, Version 1.3, Improving processes for developing

tter products and services, Technical Report CMU/SEI-2010-TR-033, Software Engineering stitute, November 2010, available at www.sei.cmu.edu/reports/10tr033.pdf.urn 2001]

istair Cockburn and Jim Highsmith: Agile Software Development: The People Factor, in mputer (IEEE), vol. 34, no. 11, November 2001, pages 131-133.urn 2001a]

istair Cockburn: Agile Software Development, Addison-Wesley, 2001.urn 2003]

istair Cockburn: The cone of silence and related project management strategies, online article at stair.cockburn.us/The+cone+of+silence+and+related+project+management+strategies, 2003.urn 2005]

istair Cockburn: Crystal Clear — A Human-Powered Methodology for Small Teams, dison-Wesley, 2005.urn 2010]

istair Cockburn: Vid of Alistair describing Shu Ha Ri, video lecture, 7 July 2010, available at stair.cockburn.us/Vid+of+Alistair+describing+Shu+Ha+Ri. See explanatory text (from 2001 ok) at alistair.cockburn.us/Vid+of+Alistair+describing+Shu+Ha+Ri. 2003] ike Cohn: The Need for Agile Project Management, online article at www.mountaingoatsoftware. m/articles/the-need-for-agile-project-management. 2006]ike Cohn: Agile Estimating and Planning, Addison-Wesley, 2006. 2009]ike Cohn: Intentional Yet Emergent, online article at www.mountaingoatsoftware.com/blog/agile esign-intentional-yet-emergent, 4 December 2009. 2010]ike Cohn: Succeeding With Agile, Addison-Wesley, 2010. 2010a]ike Cohn: The Role of Leaders on a Self-Organizing Team, online article at www.mountaingoat ftware.com/blog/the-role-of-leaders-on-a-self-organizing-team, 7 January 2010. site]ike Cohn: Succeeding With Agile site, www.mountaingoatsoftware.com.bnet site]llabnet Scrum Methodology site, at scrummethodology.com.

996]ad Cox: Superdistribution: Objects as Property on the Electronic Frontier, Addison Wesley. 1996.

§

[CunnWat

[CusumMSoSc

[DeMaToDo

[DeMaToHo

[DemiW

[DennStma

[DerbyEsm/

[DhawKrEn

[DijksEdno

[EvansErAd

[EveleJ. SoBu[G

[GammErRe

[FowleM

[GhezzCaEd

[GlassRoCo

157

ingham 2004]ard Cunningham (interviewed by Bill Venners): The Simplest Thing that Could Possibly Work, www.artima.com/intv/simplest.html.

ano 1995]ichael A. Cusumano and Richard W. Selby, Microsoft Secrets: How the World’s Most Powerful ftware Company Creates Technology, Shapes Markets and Manages People, Simon and huster, 1995rco 1999]m DeMarco and Tim Lister: Peopleware: Productive Projects and Teams (Second Edition), rset House, 1999. (First edition was published in 1987.)rco 2001]m DeMarco: Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency, Dorset use, 2001.

ng 1966]. Edwards Deming: Some Theory of Sampling, 1966, reprinted by Dover Publications, 2010.ing 2012]eve Denning: The Case Against Agile: Ten Perennial Management Objections, in Forbesgazine, 17 April 2012, at onforb.es/HQ8i6J. 2011]ther Derby: Misconceptions about Self-Organizing Teams, online article at www.estherderby.co 2011/07/misconceptions-about-self-organizing-teams-2.html, 19 July 2011.an 2008]ishankumar Dhawan, Geste Kopfschuetteln Indien (Indian head-nodding), YouTube video (in glish), 30 June 2008, , at bit.ly/dmIoGj (short for www.youtube.com/watch?v=3hCV2oO2akw).

tra 1968]sger W. Dijkstra: Go To Statement Considered Harmful, Communications of the ACM, vol. 11, . 3, March 1968, pages 147-148. 2003]ic Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, dison-Wesley, 2003.

ens 2010]Laurens Eveleens and Chris Verhoef: The Rise and Fall of the Chaos Report Figures, in IEEE ftware, vol. 27, no. 1, Jan-Feb 2010, pages 30-36. See also S. Aidane, The “Chaos Report” Myth sters, 26 March 2010, www.guerrillaprojectmanagement.com/the-chaos-report-myth-busters, and lass 2006].a 1994]

ich Gamma, Richard Helm, Ralph Johnson and John Vlissides: Design Patterns: Elements of usable Object-Oriented Software, Addison-Wesley, 1994.r 1999]

artin Fowler: Refactoring: Improving the design of existing code, Addison Wesley, 1999.i 2002]rlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: Fundamentals of Software Engineering. 2nd

ition. Prentice Hall, 2002. 2006]

bert L. Glass: The Standish Report: Does it Really Describe a Software Crisis?, in mmunications of the ACM, vol. 49, no. 8, pages 15-16, August 2006.

158

[GlazeHiNoww

[GualtMat

[HadamJaPr

[HalliwLuco

[HumpW20

[IBM IBww

[IEEEIE19

[JacobIvAd

[JacksMan

[JacksMAd

[JacobIvAd

[JeffrieRoAd

[JeffrieRo

[KnibeHe

[Kraft PhUn

[LarmCran

BIBLIOGRAPHY §

r 2008]llel Glazer, Jeff Dalton, David Anderson, Mike Konrad and Sandy Shrum: CMMI or Agile: Why t Embrace Both!, Technical Note CMU/SEI-2008-TN-003, November 2008, available at w.sei.cmu.edu/library/abstracts/reports/08tn003.cfm.

ieri 2011]ike Gualtieri: Agile Software Is A Cop-Out; Here’s What’s Next, blog article, 12 October 2011, blogs.forrester.com/mike_gualtieri/11-10-12-agile_software_is_a_cop_out_heres_whats_next.

ard 1945]cques Hadamard: Psychology of Invention in the Mathematical Field, Princeton University ess, 1945

ell 2008]ke Halliwell: The Agile Disease, blog article, 16 November 2008, at lukehalliwell.wordpress. m/2008/11/16/the-agile-disease.hrey 2005]

atts S. Humphrey: PSP: A Self-Improvement Process for Software Engineers, Addison-Wesley, 05.2012]M-sponsored study by Project At Work: Agile Maturity Report, 2012, available online at w-01.ibm.com/software/rational/agile/agilesoftware.

1998]EE: Standard 830-1998, Recommended Practice for Software Requirements Specifications, 98, available (for a fee) at standards.ieee.org/findstds/standard/830-1998.html.son 1992]ar Jacobson: Object Oriented Software Engineering: A Use Case Driven Approach, dison-Wesley, 1992.

on 1995]ichael Jackson: Software Requirements and Specifications: A Lexicon of Practice, Principles d Prejudices, Addison Wesley / ACM Press, 1995.on 2000]ichael Jackson: Problem Frames: : Analysing & Structuring Software Development Problems, dison-Wesley, 2000.

son 1992]ar Jacobson: Object-Oriented Software Engineering: A Use Case DrivenApproach, dison-Wesley, 1992.s 2001]n Jeffries, Ann Anderson and Chet Hendrickson: Extreme Programming Installed, dison-Wesley, 2001.s site]n Jeffries: Xprogramming site at xprogramming.com. rg 2010]nrik Kniberg and Mattias Skarin: Kanban and Scrum — Making the Most of Both, InfoQ, 2010.1977]ilip Kraft: Programmers and Managers: The Routinization of Computer Programming in the ited States, Springer Verlag, 1977.

an 2010]

aig Larman and Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, d Offshore Product Development with Large-Scale Scrum, Addison-Wesley, 2010.

§

[LeffinDePr

[Lutz 1RoISww

[MadeLeSp

[MarkDaww

[MartiAnVi

[McBrPe

[McCoSte

[McCrDaSI

[MeyeBe

[MeyeBeCo

[MeyeBe

[MeyeBeAC

[MeyeBeSp

[MeyeBethase

[MeyeBeat

[MeyeBebe

159

gwell 2011]an Leffingwell: Agile Software Requirements — Lean Requirements Practices for Teams, ograms, and the Enterprise, Addison-Wesley, 2011.993]byn Lutz: Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems, in

RE 93 (Proc. Int. Symposium on Requirements Engineering), IEEE, 1993, also available at w.cs.iastate.edu/%7Erlutz/publications/isre93.ps.

yski 2010]ch Madeyski: Test-Driven Development – An Empirical Development of Agile Practice, ringer Verlag, 2010.ham 2010]niel Markham: Agile Ruined My Life, blog article, 7 September 2010, available at w.whattofix.com/blog/archives/2010/09/agile-ruined-my.php.

n 2009]gela Michele Martin: The Role of Customers in Extreme Programming Projects, PhD thesis,

ctoria University of Wellington, New Zealand, 2009.een 2002]te McBreen: Questioning Extreme Programming, Pearson Education, 2002.nnell 2006]ve McConnell: Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.

acken 1982]niel D. McCracken and Michael A. Jackson: Life cycle concept considered harmful, in ACM

GSOFT Software Engineering Notes, vol. 7, no. 2, April 1982, pages 29-32.r 1988] rtrand Meyer: Object-Oriented Software Construction (first edition), Prentice Hall, 1988.r 1995]rtrand Meyer: Object Success: A Manager’s Guide to Object Orientation, Its Impact on the rporation and its Use for Reengineering the Software Process, Prentice Hall, 1995.r 1997] rtrand Meyer: Object-Oriented Software Construction, second edition, Prentice Hall, 1997.r 2008]rtrand Meyer: Design and Code Reviews in the Age of the Internet, in Communications of the M, vol. 51, no. 9, September 2008, pages 66-71.

r 2009]rtrand Meyer: Touch of Class: Learning to Program Well, Using Objects and Contracts, ringer-Verlag, 2009.r 2009a]rtrand Meyer, Ilinca Ciupa, Andreas Leitner, Arno Fiva, Yi Wei and Emmanuel Stapf: Programs t Test Themselves, IEEE Computer, vol. 42, no. 9, September 2009, pages 46-55, available at

.ethz.ch/~meyer/publications/computer/test_themselves.pdf.r 2012]rtrand Meyer: A Fundamental Duality of Software Engineering, 14 October 2012, blog article bertrandmeyer.com/2012/10/14/a-fundamental-duality-of-software-engineering/.r 2013]

rtrand Meyer: Apocalypse no! (part 1, includes a link to part 2), 12 March 2013, blog article at rtrandmeyer.com/2013/03/12/apocalypse-no-part-1/.

160

[MeyeBebe

[Mills HaDi

[MittaNizin

[Mob M

[MozilM

[MülleMpe

[NASAMat CN

[NATOPetheho

[NawrJeEu

[NonaIkCo

[ParnaDaIEav

[PfleegShEd

[PichleRo

[PoppeMww

[PoppeM

[PoppeM

BIBLIOGRAPHY §

r 2013a]rtrand Meyer: What is wrong with CMMI, 12 May 2013, blog article at rtrandmeyer.com/2013/05/12/what-is-wrong-with-cmmi/.1971]rlan D. Mills: Chief programmer teams, principles, and procedures, IBM Federal Systems vision Report FSC71-5108, Gaithersburg, 1971.l 2013]tin Mittal: Self-Organizing Teams: What and How, at scrumalliance.org/articles/466-selforgani g-teams-what-and-how, 7 January 2013.

site]ob Programming site, at mobprogramming.org.la modules]ozilla Modules and Module Owners, at www.mozilla.org/hacking/module-ownership.html.r 2005]atthias Müller: Two controlled experiments concerning the comparison of pair programming to er review, in Journal of Systems and Software 78, 2005, pages 166-179. 1999]

ars Climate Orbiter Mishap Investigation Board Phase I Report, 10 November 1999, available bit.ly/Ot7mJ8 (short for ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf). See also the N article at bit.ly/d51nla. 1968]

ter Naur and Brian Randell (eds): Software Engineering, Report on a Conference Sponsored by NATO Science Committee, Garmisch, Germany, 7-11 October 1968, republished in 2001 at mepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF.ocki 2001]rzy Nawrocki and Adam Wojciechowski: Experimental evaluation of pair programming, in ropean Software Control and Metrics (Escom), April 2001, pages 269-276.

ka 1995]ujiro Nonaka and Hirotaka Takeuchi: The Knowledge-Creating Company: How Japanese mpanies Create the Dynamics of Innovation, Oxford University Press, 1995.s 1986]vid L. Parnas and Paul C. Clements: A Rational Design Process: How and Why to Fake it, in EE Transactions on Software Engineering, vol. 12, no. 2, February 1986, pages 251-257, ailable at y.web.umkc.edu/yzheng/classes/doc/IEEE86_Parnas_Clement.pdf.er 2009]ari Lawrence Pfleeger and Joanne M. Atlee: Software Engineering: Theory and Practice. 4th

ition, Prentice Hall, 2009.r site]man Pichler Consulting: Scrum site at www.romanpichler.com.ndieck 2001]

ay Poppendieck: Lean Programming, in Dr Dobb’s, two-part article, 1 May and 1 June 2001, at w.drdobbs.com/lean-programming/184414734 and www.drdobbs.com/lean-programming/184414744.ndieck 2003]

ary and Tom Poppendieck: Lean Software Development — An Agile Toolkit, Addison-Wesley, 2003.

ndieck 2010]

ary and Tom Poppendieck: Leading Lean Software Development, Addison-Wesley, 2010.

§

[PoppeM

[PoppeM

[ReeveJaco

[RoyceWW

[SchwKe

[SchwKe

[SchwKe

[SchwKeDe

[SchwThManvo

[ScrimJa

[ScrumSc

[ShoreJa

[ShoreJaco

[ShoreW

[SilverM20

[SobelDaPr

[StellmAn

[StephMAp

161

ndieck essays]ary Poppendieck, Lean Essays site, www.leanessays.com.ndieck lean]

ary and Tom Poppendieck: Lean Software Development site, www.poppendieck.com.s 1992-2005]

ck W. Reeves: What is Software Design?, in C++ Journal, Fall 1992, available with two mplementary essays (2005) at www.developerdotstar.com/mag/articles/reeves_design.html. 1970]

inston D. Royce: Managing the Development of Large Software Systems, in Proc. IEEE ESCON, 1970, pages 1-9, at www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf.aber 2002]n Schwaber and Mide Beedle: Agile Software Development with Scrum, Prentice Hall, 2002.

aber 2004]n Schwaber: Agile Project Management with Scrum, Microsoft Press, 2004.

aber 2004a]n Schwaber: Managing Agile Projects, Addison-Wesley, 2004.

aber 2012]n Schwaber and Jeff Sutherland: Software in 30 Days: How Agile Managers Beat the Odds, light Their Customers, And Leave Competitors In the Dust, Wiley, 2012.

eigert 2012]omas Schweigert, Risto Nevalainen, Detlef Vohwinkel, Morten Korsaa and Miklos Biro: Agile

aturity Model: Oxymoron or the Next Level of Understanding, in Software Process Improvement d Capability Determination (SPICE), Communications in Computer and Information Science l. 290, 2012, pages 289-294, at link.springer.com/chapter/10.1007%2F978-3-642-30439-2_34.shire site]mes Scrimshire: Hurricane Four site, hurricanefour.com. Alliance]

rum Alliance site at scrumalliance.org. 2008]mes Shore and Shane Warden: The Art of Agile Development, O'Reilly. 2008. 2008a]mes Shore: The Decline and Fall of Agile, blog article, 14 November 2008, at www.jamesshore. m/Blog/The-Decline-and-Fall-of-Agile.html. site]eb site for [Shore 2008] at jamesshore.com/Agile-Book. 2007]elanie Silver: Am I, or Am I Not, Using Scrum? That is the Question, Scrum Alliance site, 18 March 07, www.scrumalliance.org/articles/41-am-i-or-am-i-not-using-scrum-that-is-the-question. 2007]va Sobel: Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific oblem of His Time, Walker, 2007.an site]drew Stellman and Jennifer Greene: Building Better Software site, www.stellman-greene.com/.

ens 2003]

att Stephens & Doug Rosenberg: Extreme Programming Refactored: The Case Against XP, ress, 2003.

162

[SurowJaCo

[SurowJaww

[SutheJeww

[SutheJeM20

[SutheJe

[SutheJeav

[WakeBi

[WallaDoAd

[WaterKe

[WeiseCoww

[WellsDo

[WenzJo

[WirthNi64

[YeggeStblo

[YourdEd

[Zave PaTOpa

[Zave Paa p

BIBLIOGRAPHY §

iecki 2004]mes Surowiecki: The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How llective Wisdom Shapes Business, Economies, Societies and Nations, Knopf Doubleday, 2004.iecki 2013]

mes Surowiecki: Requiem For a Dreamliner, in the New Yorker, 4 February 2013, available at w.newyorker.com/talk/financial/2013/02/04/130204ta_talk_surowiecki.

rland 2009]ff Sutherland: Self-Organization: The Secret Sauce for Improving your Scrum Team, video at

w.youtube.com/watch?v=M1q6b9JI2Wc.rland 2010]ff Sutherland, Carsten Ruseng Jakobson and Kent Johnson: Scrum and CMMI Level 5: The agic Potion for Code Warriors, in Proc. 41st Hawaii Int. Conf. on System Sciences, 7-10 Jan. 08, at ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4439172&tag=1 (and bit.ly/17LZE2R).rland 2012]ff Sutherland, Rini van Solingen and Eelco Rustenberg: The Power of Scrum, CreateSpace, 2012.rland 2013]ff Sutherland: Scrum: The Art of Doing Twice the Work in Half the Time, tutorial notes, 2013, ailable at jeffsutherland.com/CSMjsv16.pdf. site]ll Wake: Exploring Extreme Programming site at xp123.com.ce 2002]ug Wallace, Isobel Raggett & Joel Aufgang: Extreme Programming for Web Projects, dison-Wesley, 2002.s site]lly Waters: All About Agile site, www.allaboutagile.com.rt 2010]nrad Weisert, Are Agile Methods and Reusable Components Incompatible?, online article at w.idinews.com/agileReUse.html.

site]n Wells: Extreme Programming site, www.extremeprogramming.org.

el site]el Wenzel, In Point Form site, joel.inpointform.net. 1995]klaus Wirth: A Plea for Lean Software, in IEEE Computer, Vol. 28, no. 2, February 1995, pages -68. 2006]

eve Yegge: Good Agile, Bad Agile, blog article, 27 September 2006, available at steve-yegge. gspot.com/2006/09/good-agile-bad-agile_27.html.on 2003] Yourdon: Death March, 2nd edition, Prentice Hall, 2003. (First edition published in 1997.)1997]mela Zave and Michael Jackson: Four dark corners of requirements engineering, in ACM SEM (Transactions on Software Engineering and Methodology), vol. 6, no. 1, January 1997,

ges 1-30.FAQ]

mela Zave, Feature Interaction FAQ, at www2.research.att.com/~pamela/faq.html, with links to age listing many publications on feature interaction.

InIn the e

a priorisee a

abstractadditiveAffordaagile

and Cand dand r

cw

artifaasses

teassumbookclaimLuddManimethpract

amte

precaprinc

ooshte

rolesosese

transvalue

all-or-nAmbleranecdot

see aanti-patApacheAPI 10approva

dexlectronic version, clicking a page number will take you to the corresponding occurrence.

A, a posteriori 113lso dual developmentness 49, see under complexityble Care Act (Obamacare) 61

MMI 46-47esign 39-41equirements 32-37hange criticism 35aste criticism 33-34cts 10-12, 117-131sment xi-xii, 12-15, 145, 149-154chniques xi-xiiptions 2-4

s 133, 136-139s 28-30ite tendencies 131festo 1-2, 5, 7, 50, 66, 68, 91, 97, 135, 140ods 2, 133-143ices 8-10, 89-115lso called “ceremonies” in Scrum 89anagerial 89-102chnical 103-115utions in reading agile texts 17-30iples 4-7, 49-78fficial 5, 50-51rganizational 5, 51-69ould be prescriptive 49chnical 6-7, 70-78 7, 79-87nly three in Scrum 80e manager, product owner, scrum master, teamparation 86-87

ition 145-147s 2-4othing ix, 22, 27, Scott W. 43, 47, 118, 145e viii, xi-xii, 17-22, 54, 57, 61, 119, 135-136lso under prooftern 110 101

separate from arousal 106-107architecture 3-4, 9, 14, 19, 21, 31, 33, 35-41, 43,

46, 50, 54, 56, 59-62, 66-67, 69-70, 74-75, 82, 86, 97, 100, 109-114, 120-121, 125, 129-130, 135-138, 149, 152-154associated with “design” 37

Aristotle xiArmstrong, Lance 22, 135-136arousal

separate from approval 106-107artifact, see under agileassertion 118assessment

in CMMI 44-45of the agile approach, see assessment under agile

Atlee, Joanne M. 32

Bbachelor’s degree 47backlog 80-81, 89, 98, 117, 126-129balance point 27-28Basili, Victor R. 70Baudoin, Claude xiiiBeck, Kent xiii, 26, 32-33, 35, 52-53, 58, 60, 77, 94,

101, 104-107, 109-111, 113-114, 117, 123, 125, 137-138, 146-147

Beedle, Mike xiiiBerkeley Unix 108-109Big Bang approach to integration 72, 103, 105, 154Big Idea 133-134, 136-137, 139, 141Big Upfront, see upfront tasksBishop, Judith xiiibloat 58, 61, 135, 152blog xiiiboard (story board, task board) 10-12, 117, 127-128Boehm, Barry W. ix, xiii, 25, 31, 52, 62, 124, 145Boeing Dreamliner (787) 61booking.com 68Brecht, Bertolt 25bug, see defectbullpen 125

0l

burndown, burnup, see under chartBusiness Week 66

164

Calvin catastroceremocertificachange

see aas cricontrincidmust

cChaos rchart

burndburnudepeearneGant

chickenchief prChina SClausewClear, sClemenclosed-cloud-bcluster CMM, CMMI

75, and Ilevel

coach 7see a

Cockbu 81,

code 3 65- 122see aassoccentrdifferdifferinspeobjecowne

aa

reviesmelstand

Cohn, M 84,

INDEX

C 24phism 22, 26-27ny, Scrum name for practice 89tion (CMMI, Scrum) 45, 47, 84, 140

lso extendibilityticism of requirements 33, 35ol 101ental and essential 112 be accepted 4, 6, 35, 68-69, 90, 139-140, 154ontradiction with minimalism 69, 151eport 26-27

own 10-11, 117, 128-129p 128-129, 131

ndency 61, 129-131, 150d-value 131t, see dependency under chart 82, 139, 153ogrammer 86-87hop rule 104itz, Carl von 39

ee under Crystalts, Paul C. 39window rule 90-91, 139-140, 154ased tools 131 70see CMMI(Capability Maturity Model Integration) 43-47, 99, 141ndia 45s 44-45, 47, 29, 55, 84-87, 99, 151

lso Master under Scrumrn, Alistair xiii, 21, 26, 47, 56-57, 60, 73-74, 96-97, 101, 108, 125, 130, 141-4, 6, 9-10, 13, 15, 35-39, 46, 57-58, 60-61, 66, 69-70, 77, 100-107, 109-115, 117-118, , 125, 129-130, 135, 137-138, 151-153lso implementationiated with tests 118al role 4, 15, 39, 60, 117, 129ence with documentation 37-39ence with “implementation” 37ction xii, 13, 107, 138, 152t-oriented 69rship 8-9, 100-102, 138, 153

nd cross-functionality 102ssessment 100-102, 153w, see inspection under codel, see this termards 10, 109

collective code ownership, see ownership under codecologne, strong 106Columbus, Christopher 24

Columbus syndrome 24commit then review (CTR) 101communication

see documentation, verbal communicationcore, see core communicationosmotic, see osmotic communication

Communications of the ACM xiiicomplexity 120, 123

see also simplicityadditive and multiplicative 58, 63-65, 71, 100, 112,

150cone of uncertainty 124configuration management 35, 44-45, 76, 101, 104consumables 60, 65continuous integration viii, 8-9, 103-105, 118, 138,

154control

subtle, surreptitious, by love, see subtle controlcore communication 141core participant, see members and observers under teamcover-your-behind 22, 27-28creep, see under featurecross-functionality 81, 98, 102, 130, 153

and code ownership 102Crystal vii, ix-x, 2, 57, 97, 101, 125, 128, 131, 133,

141-143, 153assessment 142Clear 141principles 141

cubby 125cubicle 3, 57, 96

see also space under workingCunningham, Ward 59, 137customer xii, 2-7, 11, 13, 21, 33-36, 41, 50-53, 60-

62, 68, 70, 73, 75, 79-83, 90, 94-96, 99, 102, 119-120, 127, 129, 134-135, 137-138, 151-152, 154see also product ownerat the center 51-53embedded 53, 83, 86, 96, 151interaction 83onsite 83, 96, 151

Cusumano, Michael A. 14, 104CVS 104

Ddaily build 14, 72, 103-105

at Microsoft 104daily meeting 8, 15, 81-82, 84, 89, 91-93, 98, 140,

153

ike xiii, 17, 19-21, 32-33, 40, 54-55, 65, 78,

91, 95, 122-124, 126, 130, 139also known as daily scrum 91also known as standup meeting 91

INDEX

threedaily ScDavid (death mdebt, sedefect

118class

defineddefinitiDelphi DeMarcDemingDenninDepartmdepend

chartDerby, design

see adifferpatteseparsmelupfro

Design develop

distrido nodual,iterattest-d

DhawanDijkstraDijkstraDilbert Disneyldistribudocume

differversu

domainmodevs m

done, seDonizeDreyfusdual deDuboisDuluth dynami

Easiest egoless

165

questions 8, 91, 153rum, see daily meetingMichelangelo statue) 67arch 56e technical debtxiii, 6, 18, 44, 46, 64, 72, 75-76, 105, 110, , 126, 135ification 76 (CMMI level) 45on of done 71, 117, 123, 125, 140 95o, Tom 56, 58, W. Edwards 57

g, Steve 23-25ent of Defense 43, 45

ency 71, 99-100, 102, 104, 112, 129-131, see dependency under chartEsther 54, 56

lso architectureence with “architecture” 37

rns, see this termate from implementation? 37-39l, see this termnt, see upfront tasksby Contract x, 118mentbuted, see distributed under teamt start until all tests pass 76

see dual developmentive, see iterative developmentriven, test-first, see these terms, Krishankumar 20, Edsger W. xi, 38, 40, 67, 75. Edsger W. 77 3, 109and 23ted, see under teamntation 21, 27, 34-35, 38-39, 60, 123, 129ence with code 37-39s verbal communication 19-21

l 120-121, 150achine (in requirements) 36-37, 120, 150e definition of done

tti, Gaetano 107 model 47

velopment 28, 74, 113, 121, Paul xiii, 18 101c binding 69

E

Eiffel 118, 126Eiffel Software xiiiEinstein, Albert 24-25either-what-or-when x, 71, 146-147Emacs 108embedded, see under customerempirical software engineering viii-ix, xi-xiii, 25, 27,

29, 52, 58, 62, 105, 107-108ESEC (European Software Engineering Conference) 25essential change 112-113estimation 8, 58, 93-95, 98-99, 121-124, 130, 153Estler, Hans-Christian xiiiETH Zurich xiiieuro, scheduling of introduction 146Eveleens, J. Laurens 26Everest 73experience xiextendibility 5, 10, 13-14, 40, 59, 68-69, 75, 112,

151see also change

Extreme Programming vii, x, 1-3, 6-10, 13, 32, 53, 57-58, 60, 68, 73, 77, 83-84, 93-94, 96, 100-106, 108-110, 112-114, 117-118, 123-125, 133, 135, 137-139abbreviated as XP 2assessment 139books 137-138notion of simplicity 110, 135, 137

extremism, see all-or-nothing

FFacebook 69, 86falsification, falsifiability xi, 49, 77feature

creep 61, 77, 90, 100dependency, see this terminteraction 63-65

featurismcreeping, see creep under feature

Federal Aviation Administration 62fellow traveler, see members and observers under teamFibonacci sequence 94, 123flexible working schedules 92Forbes 23Ford, Henry 79formal methods 19-20, 39, 75, 154fox 133Freud, Sigmund 42function point 122

GGalileo Galilei xigame, see under planningGamma, Erich 38, 109, 112, 117

Thing First, Hardest Second 73 programming 109

Gantt chart, see dependency under chartgeneralization 109

166

genericGerstneGhezzi,GIGO (Git 104Glass, RGoogle

DocsGötterdgravity Gries, Dgummi Günthaguru 2gut feel

HadamhandovhardestHarrisoHawthohead nohedgehHighestHighsmHoare, Holitzahotel boHowardHumphHyatt 1hygiene

I MusicIBM 2ICSE

Engiimpedimimplem

97-9see adiffer“prodseparsepar

incidenIndia 1

and Cindividuinformainspectiintegratinteract

of fea

INDEX

ity 69r, Ralf xiii Carlo 32Garbage In, Garbage Out) 111

obert L. 26 14, 58, 86, 101 32ämmerung 30 145-146avid 67

bears 123rt, Claudia xiii3, 79ing xi

Hard, Jacques 39er 36 thing the team can succeed with 73n, John 24rne effect 29dding 20og 133 Business Value First 73-74ith, Jim 81C.A.R. 67, Matthew 145oking 17, 19, Mark xiiirey, Watts 467, personal 106

Ii 55-569, 42, 145-146( In te rna t iona l Confe rence on Sof tware neering) 25ent 8, 15, 68, 84, 91-92, 117, 129, 140, 153

entation 3, 9, 34, 36-37, 40-43, 82, 86, 89, 8, 120, 128, 149, 152

lso codeence with “code” 37uction” is a synonym 37ate from design? 37-39ate from requirements? 36tal change 112-1139-20, 45, 85, 87, 94MMI 45al code ownership, see ownership under codetion hiding 69on, see under codeion, see big bang, continuous integration

with customers 83International Standards Organization 43intimidation viii-ix, 22-26ISO standards 43Italy xi, 94iteration, see iterative development

backlog, see this termiterative development 2-3, 5-7, 9, 11, 13-15, 34, 40-

43, 51, 56, 65, 70-72, 74, 89-90, 94, 98-99, 103, 105, 111, 121, 123-124, 126-127, 135, 138-140, 149assessment 72-75freeze requirements during iterations 71-72

see also closed-window ruleiteration planning 98-99kinds 70-71length of iterations 71, 138, 154order of tasks 73-74working iterations 5-6, 14, 50-51, 60, 65, 70-75,

117, 135, 154

JJackson, Michael A. xiii, 36, 41-42Jacobson, Ivar xiii, 10, 119Jazayeri, Mehdi 32Jeffries, Ron 58-59, 83, 137Jobs, Steve 25, 66, 79Joy, Bill 108-109JUnit 76, 117

KKanban 4, 128, 133-134, 136, 146

board 136card 136

Kanban board 136Knuth, Donald Erwin 108-109Kolb, Peter xiiiKraft, Philip 57

LLa Fille du Régiment 107Larman, Craig xiii, 26, 32, 40, 84, 99, 108, 126, 139lasagne 63Lean Software vii, x, 2-3, 13-14, 27-28, 33, 46, 57,

67, 91, 119-120, 129, 133-136, 146assessment 135-136books 136

Leffingwell, Dean 31length of iterations, see under iterative developmentlifecycle 7, 31, 39, 41-43, 46, 68, 82

model 41-42, 82V-model 82

linguine 63, 71Linux 108-109

iontures, see interaction under feature

Lister, Tim 56LOC (line of code), see SLOC

INDEX

logical Louis Xlove, seLudditeLutz, R

machinmake (cmanagemanage

61-6 92, incomtechn

MandriManifemaster’mathemmaturit

for agMcBreeMcConMcCracmeetingmembe

see mmentor

differpro

methodsee mdefin

metho“me

Meyer,Meyer,Meyer,MichelaMickeyMicroso

ProjeMills, Hminiatuminima

artifaassescontrfunctnot thprodusoftw

minimaMitin, RMittal,

167

reasoning xiIV 42e subtle control 131obin 52

Me vs domain (in requirements) 36-37, 120onfiguration management tool) 38, 104d (CMMI level) 45r vii, x, 2-3, 5, 7, 13, 25, 28-29, 36, 53-56, 3, 68, 71-72, 74, 76, 79-81, 84-87, 89-90,

97, 104, 107-108, 123, 131, 135-136, 150petent 25, 29, 36, 68, 74, 97, 107

ical 87oli, Dino 32sto, Agile, see Manifesto under agiles degree 47atics, see formal methods

y model 43-47ile methods 47n, Pete ix, xiiinell, Steve 124, 145ken, Daniel D. 41-42, see daily meeting, retrospective review meeting

r (in meetings)embers and observers under team 7, 55, 107ence between mentoring and pair gramming 107

ethods under agileition of the term 133dology , compar i son of th i s t e rm wi th

thod” 133 Annie xiii Raphaël xiii Viktoria (no relation) xiiingelo (di Ludovico Buonarroti Simoni) 67 Mouse 23ft iv, 9, 14, 72, 86, 100, 104

ct 130-131arlan D. 86

re, see under processlcts 4, 51, 60sment of minimalism 61-67adiction with acceptance of change 69, 151ionality 4-5, 51, 58, 152e same as simple 66-67ct 4-5, 51, 58-60are 4-5, 10, 13, 51, 58-67lism, see minimal

mob programming 107model

domain, see model under domainlifecycle, see model under lifecyclematurity, see maturity model

Moltke, Marshall Helmuth von 35Morgan, Carroll xiiiMozilla 100MS-DOS 60Müller, Matthias 107multiplicative, see under complexity

Nnanny 79napkin, as a substitute for documentation 21Napoléon Bonaparte 97NASA 21, 52NATO 1968 conference 37Naur, Peter 37Nawrocki, Jerzy 107no estimates 107Nonaka, Ikujiro 54

OObamacare 61object-oriented programming 9-10, 37, 39, 69, 121-

122, 154agile criticism 69

Observer pattern 38-39observer (in meetings)

see members and observers under teamonsite customer 96OOPSLA conference 25open

room, see space under workingspace, see space under working

Oprah 62optimizing (CMMI level) 45, 141oracle 118order of tasks, see under iterative developmentosmotic communication 125, 141, 153ownership

code, see ownership under code

Ppace

sustainable, see sustainable pacepair programming xii, 8, 10, 13, 89, 96, 101, 105-

109, 138, 152assessment 13, 107-109, 152definition 106-107difference with mentoring 107

paper napkin, as a substitute for documentation 21Parnas, David L. 39, 67

oman xiiiNitin 55

partisanship viiipatterns, design viii, 37, 112, 154

168

see aObseVisit

PeopleWpersonaPersonaPfleegePhD dePiccionPichler,pig 82,plannin

gameiterat

mepoke

platitudpoker, spolymoPoppen

37, PowerPpracticepredicti

not thprescripprincipl

agiledefindiffer

processminiamode

productproduct

96, product

termsProgramprogramprogram

anarcchief

programsee aegoleextremob,objecpair, struc

proofby anby ci

PSP, se

INDEX

lso anti-patternrver 38or 37, 112

are 56-57, 126l safety 56-57l Software Process (PSP) 46-47, 107r, Shari Lawrence 32gree 47i, Marco xiii Roman 80 139, 153g viii, 8, 93-94, 121, 123, 153ion, see iteration planning under iterative develop-ntr 8, 93-95, 98, 121, 123, 153e 5, 49, 138ee under planningrphism 69dieck, Mary and Tom xiii, 22, 27-28, 33, 36-46, 58, 60, 65, 69, 81, 105, 119-120, 134-136oint 60s, see under agileve 31-32e same as waterfall 31tive principle 49e, see principles under agileition 49ence with a platitude 49

ture 97-98l, see CMMI backlog, see backlog owner 7, 53-54, 68, 80, 83, 86-87, 90, 95-98-99, 151, 154ion, see implementation used as synonyms 37 Design Language 39, see code, implementation, programmingmer

hy 107, see chief programmerming

lso design, architecture, code, implementationss 109me, see Extreme Programming see mob programmingt-oriented, see object-oriented programmingsee pair programmingtured, see structured programming

ecdote xi, 17-22

Qquantitatively managed (CMMI level) 45questions, see three questions under daily meeting

RRational Unified Process 42-43RCS 104Red Army 85Reeves, Jack W. 38refactoring 3, 8-9, 40, 60, 62, 72, 109-114, 130,

137-138, 149, 151, 153assessment 110-113covered in part by “generalization” 109definition 109-110must improve quality 110pattern 110

regression test suite 4, 35, 68, 75-77, 101, 103-105, 114, 117-118, 139

Reinertsen, Don 126requirements xii, 3-7, 9, 12-15, 17, 19-20, 27, 31-37,

43, 45, 49-53, 56, 60-62, 65-66, 68, 70-72, 77-78, 82-83, 91, 97, 109, 119-121, 123, 126-127, 135, 139, 149-152, 154see also specification, user storysee also user storyagile criticism 32-36as design or implementation 36-37as software 35as source of errors 52as waste 33domain

vs machine ??-39, 120domain vs machine 36-37elicitation 32techniques 32upfront, see upfront tasksworkshops 53

retrospective 9, 99, 141Return On Investment 3-5, 57, 77reusability, reuse 5, 10, 13, 40, 59, 112, 151review

see inspection under codemeeting 99review then commit (RTC) 101

rhetorical devices 17-30Rite of Spring 73ROI, see Return On Investmentroles, see under agileroom, see space under workingRosenberg, Doug ixRoyce, Winston D. 31RUP, see Rational Unified Process

tation 67e Personal Software Process

SSaint-Exupéry, Antoine de 66-67

INDEX

scenarioschedulSchwab

96, Schweiscope

creepScrimshScrum

45, 91-9 139AlliaassesbookdailyMast

99cin

of scscrumm

der SseamlessecuritySelby, Rself-orgseminarShu Haside-bySilicon simplic

see aas desimpsimp

61Skype slack 5slanderSLOC (Smacchsmell 1Sobel, Dsoftwar

compcrisisestimminim

Softwarsource,spaghetspeakinspecific

78,

169

, see use case, user storye, see iterative development, schedules under worker, Ken xiii, 22, 26, 30-31, 54, 57, 80-81, 84, 99-100, 139gert, Thomas 47

, see creep under featureire, James 85-86

vii, x, xiii, 2-3, 6-8, 15, 22, 26, 28, 31, 42, 47, 53-54, 57, 63, 68, 71-72, 74, 79-87, 89, 4, 98-100, 103, 124-127, 129, 133, 136-137,

-140, 146, 151nce 29, 139-140sment 139-140s 139, see daily meetinger xiii, 7, 47, 53, 57, 79-81, 84, 86-87, 92, , 129, 139, 151

ertified xiii, 84 vacation 57

rums 99-100aster, Scrummaster, ScrumMaster, see Master un-crums development 39 40, 42ichard W. 14, 104

anizing team, see self-organizing under teamist 17-21 Ri (or Shuhari) 47-side programming 108Valley 126ity 50, 58, 66-67, 91, 110lso complexityfined by Beck 110, 135, 137le is not the same as minimal 66-67lest solution that can possibly work 3, 8, 10, 59-, 64, 66, 73-74, 111198 by association 23, 31source line of code) 106, 111, 122ia, Patrick xiii01, 109-110, 113, 130ava 24

eonent, see reusability 26ation, see this termal, see this term

e Engineering Institute 43 see code, implementation, SLOCti, see linguineg, see verbal communication

see also requirements, testingspeed of light 37sprint 3, 7, 33, 42, 57, 68, 71-72, 74-75, 80-81, 84,

89-91, 98-99, 124, 126, 140assessment 91backlog, see this termretrospective 99review, see review meeting

stakeholder 19, 21, 32, 45, 52-53, 61-62, 83, 90, 98-99, 123

Stallman, Richard 108standards, see under codeStandish Group 26-27stand-up meeting, see daily meetingStephens, Matt ixStockholm Syndrome 86story

see user storyboard, see this termcard, see story card under user storypoint, see story point under user story

Stravinsky, Igor 73structured programming viii, 57, 154subtle control 54, 57Subversion 104Surowiecki, James 62, 95sustainable pace 4-5, 50-51, 56-58, 92, 152Sutherland, Jeff xiii, 2, 26, 28, 30-31, 47, 54, 125,

139

TTaboo 42Takeuchi, Hirotaka 54task

board, see this termcard 127order of tasks, see under iterative development

TDD, see test-driven developmentteam vii-viii, 2-5, 7-12, 14-15, 19-21, 25, 28-29, 34,

40-41, 46-47, 50-60, 62, 68, 71-75, 79-81, 83-87, 89, 91-93, 95-96, 98-102, 104-106, 108-109, 111, 115, 118-119, 121, 124-125, 127-130, 134-135, 137-139, 150-154cross-functional, see cross-functionalitydistributed xiii, 20, 92-93, 126, 128, 152-153empowerment 14members and observers 82, 98, 153multiple 99self-organizing viii, 4-5, 7, 25, 50-51, 53-56, 80-

81, 96, 101, 137, 150, 152Team Software Process (TSP) 46technical debt 117, 125, 129-131telephony 64-65

ation 6, 13, 18-20, 23, 36-37, 45, 49, 75, 77-115, 118, 120, 151

test, see testing, test-driven development, test-first devel-opment

170

test-driv 118assescycle

test-drivtest-firs

assestesting

49, 101 127do nointegregretests unit t

TeX 10TFD, sethrashinthree qutime-botime zoTintin TorvaldTotem Tour deToyota traps, rhTschanT-shirt TSP (TTurner,

UML 3uncertaunit tesunverifupfront

57, 149

use caseuser sto

81, 138assesboardstorystorystory

velocityasses

verbal cVerhoe

INDEX

en development 6, 8-9, 15, 77, 89, 113-115, , 138, 151sment 115, 151 113en development. 138

t development 77, 113-115, 138, 151sment 115, 151 2, 4-6, 8-9, 12-13, 15, 23, 32, 35, 44, 46, 51-52, 58, 60-61, 66, 68, 75-78, 82, 89, 98, , 103-105, 111, 115, 117-118, 120, 123, 125, -129, 136-139, 151, 154t start new development until all tests pass 6, 76rating tests into the code 118ssion, see regression test suiteas a key resource 6, 15, 75-76est 82, 117-1188-109e test-first developmentg 107estions, see under daily meetingxed 3, 15, 71, 146-147, 154ne 9213s, Linus 108-109

42 France 135 4, 57, 134, 136etorical 22-30

nen, Julian xiiisizing 95eam Software Process) 46 Richard ix, xiii, 25, 31

U9, 43, 60-61

inty, cone of, see cone of uncertaintyt, see under testingiable claims 28-30 tasks 2-4, 9, 13, 31-32, 35, 40-41, 43-47, 52, 61-62, 65, 69, 73, 77, 83, 93, 109-113, 135, -150, 152-154 6, 10-13, 78, 119-120ry viii, 6, 10-13, 43, 60-61, 64, 74, 78, 80-84, 89, 94, 98, 115, 117, 119, 123-128, 130, , 140, 150-151sment 119-121, 150, see this term

board, see board card 10-11, 127 point 93-94, 117, 120-125, 127-128

V viii, 11, 117, 122-124, 127-129, 140, 154sment 124, 154

video tape manufacturing 136Visitor pattern 37, 112V-model, see under lifecycleV&V (Verification and Validation) 41

Wwaste 3-5, 13, 18, 27, 33-34, 36, 46, 52, 57-59, 67,

91, 117, 120, 122-123, 125, 127, 129-131, 134-136, 151, 153as criticism of requirements 33-34

waterfall 31, 39, 41-42not the same as predictive 31

Western Electric 29Wikipedia 101Wirth, Niklaus 67, 134Wojciechowski, Adam 107work in progress 4, 136working

code, see working iterations under iterative develop-ment

days 128schedules 92, 153space 10, 12, 57, 96-97, 125-126, 138, 152

work-in-progress 136workshop, see under requirementsWorld Bank 23Worst Thing First 73writing, see documentation

XXML 112XP, see Extreme ProgrammingX-rated 106xUnit 109, 114, 117

YY2K 60YAGNI 58-59, 69, 77Yourdon, Ed 56YouTube 20

ZZave, Pamela 36, 64zoology 82Zuill, Woody 107

ommunication, versus documents 17-21f, Chris 26