Agile!

Bertrand Meyer

Agile!

The Good, the Hype and the Ugly

Bertrand MeyerETH Zurich, Zurich, Switzerland

Eiffel Software, Goleta, USA

ITMO, Saint Petersburg, Russia

ISBN 978-3-319-05154-3DOI 10.1007/978-3-319-05155-0

ISBN 978-3-319-05155-0 (eBook)

© Springer International Publishing Switzerland 2014This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, repro-duction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law.

p. 13 (Tintin), Le Lotus Bleu by Hergé, © Hergé/Moulinsart 2014 , © Reprinted with Permissionp. 24 CALVIN AND HOBBES © 1988 Watterson. Reprinted with permission of UNIVERSAL UCLICK. All rights

reserved.p. 55 (I Musici), I Musici di Roma, www.imusicidiroma.comp. 63 (lasagne), Kit James, finefettleguide.blogspot.chp. 127 (story card), Steven Thomas, itsadeliverything.comp. 128 (task board), Gareth Saunders, blog.garethjmsaunders.co.ukp. 129 (burnup chart), Alistair Cockburn in [Cockburn 2005], © 2005 Addison-Wesleyp. 1, 50 (Agile Manifesto) © 2001, the authors. This declaration may be freely reproduced in any form, but only in its

entirety, through this notice.p. 118 Design by Contract is a registered trademark of Eiffel Software.p. 131 (Gantt chart) from the documentation of “GanttView for WinForms”, used with permission from Microsoft

(www.microsoft.com/en-us/legal/intellectualproperty/Permissions/default.aspx), © Microsoft

The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply , even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein.

Printed on acid-free paper

Springer International Publishing Switzerland is a brand of SpringerSpringer is part of Springer Science+Business Media (www.springer.com)

Library of Congress Control Number: 2014936182

Sho

The fu

Prefa

Conte

1 Ov

2 De

3 Th

4 Ag

5 Ag

6 Ag

7 Ag

8 Ag

9 Ag

10 De

11 Th

Biblio

Index

rt contents

ll table of contents appears on page xv.

ce vii

nts xv

erview 1

constructing agile texts 17

e enemy: Big Upfront Anything 31

ile principles 49

ile roles 79

ile practices: managerial 89

ile practices: technical 103

ile artifacts 117

ile methods 133

aling with agile teams 145

e Ugly, the Hype and the Good: an assessment of the agile approach 149

graphy 155

163

Pr

This ispose is— to b

Agenginedinaryits ovesuch aparagrdamag

Noor thattal, theagile tedo notthe prospareskey ag

DESC

The firapproayou, thown prmore smost ehaps pin dep

eface

not a philosophical, theoretical or motivational book, but a practical one. Its pur- to enable readers — software developers, managers involved in IT, and educators enefit from the good ideas in agile methods and stay away from the bad ones.

ile methods are undeniably one of the important recent developments in software ering. They are also an amazing mix of the best and the worst. This is an extraor- situation: usually, when a new set of concepts bursts forth, one can quickly assess rall contribution as beneficial, neutral or detrimental. Agile texts, however, defy simple judgment: you may find in one paragraph a brilliant insight, in the next aph a harmless platitude, and in the one after some freakish advice guaranteed to e your software process and products.

wonder then that practitioners have massively disregarded injunctions to use this agile method — such as Scrum, Extreme Programming, Lean Software and Crys- most prominent ones today — in its entirety. Industry knows better, and every am in the field makes up its own cocktail of agile practices, rejecting the ones that

fit. Until now, however, each organization and project has had to repeat for itself cess of sorting out the gems from the gravel. What a waste of effort. This book

you the trouble by presenting a comprehensive description and assessment of the ile ideas.

RIPTION AND ASSESSMENT

st goal is description: you can use this book as a primer on agility, presenting the ch concisely, coherently and comprehensively. If agile development is new for is presentation will, I hope, teach you what it is about, enable you to apply to your ojects the agile ideas you decide to retain, and prepare you if you wish to read the pecialized literature (such as the texts advocating a particular agile method) in the ffective and profitable way. If you have already read about agile methods, and per-

racticed them, I hope it will help you put all the concepts in place, understand them th, and apply them better.

viii

Whof the where techniqintersppeopletinuougame”

Theout whand thmean study agree wagree y

Theat any discusright. Tit genethe ful

KEEP

Anyonods haidation

Moenon oders onpresencite thbuilds motingyou artions t

Thescornfprocepointyobjectirity”. Tstroke

PREFACE

at makes this descriptive component of the book necessary is that until now, in spite already enormous literature on agile methods, there was no place, as far as I know, you could find a complete yet concise presentation of the essential agile ideas and ues, not tied to a particular agile method, not drowned under anecdotes, and not ersed with a constant exhortation to join the cult. Sermons have a role, but for most , I think, it is more interesting to find out what exactly is meant by “velocity”, “con-s integration”, “user story”, “self-organizing team”, “sprint review”, “planning , “mob programming” and so on. That is what I have tried to provide — in 162 pages.

second goal is assessment: we take an even-handed look at agile methods and sort at helps, what is not worth the attention, and what harms — the good, the hype

e ugly. The assessment is unbiased (I have no horse in this race) but that does not it is the only possible one, since empirical software engineering, the objective of software processes, is still a science in progress. So you will not necessarily

ith all the conclusions, but I think you will agree with most, and where you dis-ou will be able to appreciate rational arguments on both sides.

two aspects — “news” and “editorial”— are separated: you are entitled to know stage whether you are reading the factual presentation of an agile technique or a

sion of its merit. Judgmental elements are marked by the icon shown here on the he scope of its application will be clear from its position: at the start of a paragraph,

rally applies to the remaining part of the current section; at the start of a section, to l section; and in the case of the final assessment, to the full chapter.

ING A COOL HEAD

e trying to gain a clear, cool-headed understanding and appreciation of agile meth-s, so far, faced three difficulties that I hope this book removes: partisanship, intim- and extremism.

st of the existing texts are partisan. At issue here is not just the normal phenom-f inventors arguing for their inventions, but a lack of restraint that sometimes bor- religious fervor and demands from the reader a suspension of disbelief. The first

tations of structured programming, object technology and design patterns — to ree earlier developments that each imprinted a durable mark on how the world software, as agile methods have already started to do — were enthusiastically pro- new ideas, but did not ignore the rules of rational discourse. With agile methods

e asked to kneel down and start praying. This is not the right way to approach solu-o engineering problems involving difficult technical and human aspects.

agile literature is often intimidating. It dismisses previous approaches as passé, ully labeling them “waterfall” (even though no company applies a strict waterfall ss), and leaving the impression that anyone supporting them is a rigid, -hair-boss type. We will encounter the typical example of an author for whom any on to agile methods is a mark of “bureaucracy”, “incompetence” and “medioc-

?

→ See “Intimi-dation”, 2.2.3, page 23.

he very name for the approach, “agile”, a brilliant marketing decision — no, a

of genius! —, is enough to make any would-be skeptic think twice: who wants to

PREVI

be cassuch nyou, I unemo

Clesome mtions; the preplicatewhich

PREV

AmonadorintioningExtremdoes nany ppro-anBoehmtraditioon emclassicperhapbeing

Doworrieit enco

STRU

The bo

Thefirst ovof it.

Theform oples inconvin

Chalove toderide

OUS ATTEMPTS ix

t as not agile? If you search the dictionary for antonyms to “agile”, you will find iceties as “awkward”, “lumbering” and “ungraceful ”. If those are the alternatives, and everyone else want to be agile! This name is just a name, however; we must tionally assess, one by one, the concrete principles and practices that it covers.

ar, no-nonsense assessment is also complicated by extremism: the insistence of ethod designers that you must apply their prescriptions entirely. There are excep-

Crystal, for example, is more of a flexible, your-mileage-may-vary approach. But valence of the all-or-nothing view in many of the foundational texts further com-s the task of identifying which techniques will work for your own project, and will not.

IOUS ATTEMPTS

g the many books on agile methods, I know of only three that have not taken an g tone. The first is McBreen’s Questioning Extreme Programming, whose “ques-” is plaintive, leaving the reader uncertain about any serious problems with XP. e Programming Refactored: The Case Against XP by Stephens and Rosenberg

ot suffer from such angst; it is a pamphlet, both funny and enlightening, but like amphlet it does better at highlighting absurdity than at performing a fair d-con analysis. The book that made the most serious attempt at such an analysis, and Turner’s Balancing Agility with Discipline, contrasts agile approaches with nal plan-driven software engineering techniques. Its great strength is that it relies

pirical data from studies comparing the effectiveness of agile techniques to their al counterparts. For my taste it tilts a trifle too much to the side of cautiousness; s because Boehm is such a respected figure in software engineering and feared

branded as a proponent of the old order, the authors avoid sounding too critical.

not expect such timidity in the present book (mentioning this just in case you were d). Respect yes, deference no. It will highlight and praise the good ideas, and when unters balderdash it will call it balderdash.

CTURE OF THE BOOK

ok has a simple structure and is intended for sequential reading.

opening chapter, entitled “overview”, presents a summary of agile ideas and a erall assessment. It sets the stage for the rest of the book and serves as a summary

second chapter is a short foray into the style of agile descriptions, serving as a f immunization against the risk of unjustified generalization. Working from exam- the agile literature, it analyzes the intellectual devices that agile authors use to ce the world.

pter 3 is a sketch of everything that agile methods do not want to be and agile texts

[McBreen 2002].

[Stephens 2003].

[Boehm 2004].

lambast: traditional plan-based software engineering methods, including the d “waterfall”.

x

The4, roletices indo notall or methotional of theincludters re

ThaprincipCrysta8, we cof printhe chbig ide

Chaadoptithe la“either

Chaing whbook’s

• The—

• Theresu

• Theprohar

PERS

Any bmix of

It issoftwadevelospecifiEven wsucces

PREFACE

next five chapters, the core of the book, review agile ideas: principles in chapter s (in the sense of personnel roles, such as managers and users) in chapter 5, prac- chapters 6 and 7, and artifacts, both material and virtual, in chapter 8. Here we

focus on any specific method but look instead at the concepts and tools shared by most. This approach illuminates the many commonalities between the various ds. It will allow you to examine agile ideas by themselves, in a non-denomina-way, so that you can decide which ones are suitable for your context. When some m apply more specifically to one method, the discussion points this out, and es in the margin one of the icons shown here on the right. The focus in those chap-mains, however, on individual methodological concepts and techniques.

t focus moves to the methods themselves in chapter 9, which studies four of the al agile methods in existence today, the four already cited: Scrum, Lean, XP and l. Since the constituent ideas have been presented in the preceding chapters, 4 to an in the presentation of each method concentrate on the particular combination ciples, roles, practices and artifacts that it has chosen, and just as importantly on

aracteristic spirit of that method. The analysis shows that each of them has “one a” that sets it apart, supported by a number of auxiliary concepts.

pter 10 is brief; it describes precautions that organizations should take when ng agile methods, in particular when some are more agile than others. It warns that ws of software engineering continue to apply, and cautions against the -what-or-when” fallacy that works well for consultants but not for their clients.

pter 11 is the final assessment: an overall examination of the agile canon, apprais-ich ideas stand up and which just do not make sense. It shows indeed that, as the subtitle indicates, agile ideas can be classified into three categories:

good (including the “brilliant”): principles and practices — some new, some not that agile authors rightly present as helpful to software quality and productivity.

hype: widely touted ideas that will make little difference, good or bad, to the lting software.

ugly: agile-recommended techniques that are just plain wrong, contradicting ven rules of good software engineering, jeopardizing the success of projects, and ming the quality of the resulting software.

PECTIVE AND SCOPE

ook is colored by its author’s experience. What mostly characterizes mine is the industrial practice (for most of my career) and academic work (for the past decade).

also useful to note what this book does not include: a comprehensive approach to re development. My previous books describe techniques of quality software pment and argue for specific approaches, particularly object technology, formal cation and Design by Contract. This one, in contrast, studies other people’s work.

These symbols were designed for the present book and are not official logos of the methods.

hen I felt that my own work is relevant to the discussion or predates some of the sful agile ideas I have (except for a hint or two) refrained from talking about it.

ANALY

ANAL

Softwaideas gthey ar

Auempiri

Doware mrelied

Receffepro

But if vince t

Exp

Forof ppro

Experibook iprojecably, aand sohow malmost

Anedispto ntolddrop

Logica(and fothoughand th

SIS: INSTINCTIVE, EXPERIENTIAL, LOGICAL OR EMPIRICAL? xi

YSIS: INSTINCTIVE, EXPERIENTIAL, LOGICAL OR EMPIRICAL?

re methodology is a tricky business because it is difficult to prove anything. Many et adopted on the strength of an author’s powers of conviction. It does not mean e good, or bad.

thors use four kinds of argument: gut feeling, experience, logical reasoning and cal analysis.

not laugh at gut feeling as a means of persuasion; after all, the mother of all soft-ethodology texts, Dijkstra’s 1968 Go To Statement Considered Harmful, largely

on it:

ently I discovered why the use of the go to statement has such disastrous cts, and I became convinced that it should be abolished from all higher-level gramming languages.

you are not Dijkstra your gut feeling will not take you very far in a quest to con-he community.

erience was also part of Dijkstra’s rationale:

a number of years I have been familiar with the observation that the quality rogrammers is a decreasing function of the density of go to statements in the grams they produce.

ential arguments are among the favorite tools of agile authors. The typical agile s a succession of alternating general observations and personal anecdotes of t rescues (rescued, remarkably, by the author) and project failures (failed, remark-fter not following the author’s advice). These anecdotes are usually entertaining metimes enlightening, but a case study is only a case study, and we never know uch we can generalize. One can, after all, summon an experience in support of any recommendation.

cdotes and individual cases, by the way, can have force of proof, but only in one case: roving a general law. If such a law has been proposed, it suffices of a single experiment egate it (the technical term is “falsify”). For example if someone — say, Aristotle — you that bodies fall at a rate that depends on their mass, just go up that tower in Pisa, a light ball and a heavy ball, and see them reach the ground at the same time.

l reasoning is a powerful tool; it played a significant role in Dijkstra’s advocacy r Galileo too, who according to some authors proved his hypothesis solely by

[Dijkstra 1968], emphasis added.

t experiment). But it is only as convincing as the hypotheses from which it starts, ere is the risk that it will remain academic.

xii

Ideresultsrequiresystemavailabengineperhapeviden

I haconfinmentio

FREE

Given in whi

ProIn reviauthorto tasksoftwacriticis

I wmethoThe pathe les

In nfessionviews

PREFACE

ally, we should use empirical analysis. Does pair programming lead to better than code inspections? Is constant customer interaction preferable to a solid ments process? Credible answers to questions of software methodology require atic, rigorous, realistic studies of projects. This book relies on such results when le, but there are not enough of them; the burgeoning field of empirical software ering has not yet provided answers to many fundamental issues. This has been s the biggest obstacle in the preparation of the book. Where not enough empirical ce was available, the discussion largely relies on analytical reasoning.

ve not completely avoided anecdotes and personal experience, but have tried to e them to the illustration of points supported by logical argument and to the task, ned above, of disproving undue generalizations.

CRITICAL INQUIRY

that this work includes critical comments, a word is in order to explain the spirit ch it has been written.

gress in science and engineering relies on free, critical inquiry of previous work. ewing the agile literature, I have found a number of reasons to disagree with its s, and a few reasons to be shocked; I have not been coy about taking their claims . I have also, however, found elements to admire, and learned new insights about re development. This observation is worth remembering whenever you encounter m in the following pages.

ould not have spent a good part of my last three years immersing myself in agile ds and the supporting texts if I had not felt that I had something important to learn. th has been tortuous at times; with this book I hope to spare you the path and share sons.

o case does the criticism mean disrespect; the agile pioneers are experienced pro-als, passionate about software. Even when I find them to be wrong, I value their

and share the passion. We are all in the same boat.

Bertrand Meyer January 2014

ACKN

ACKN

Since thauthor imply tgroup oagile bothe booCohn, Cfirst encBréau Etwo of enablin

I haticipantof the brecent aand IvaHowardAnnie Mform anled to e

If I back toTogetheation thrously cbut we

I hablog at ments o

I amsions onBay warelease of impoEngineon a chcontribEstler) of publ

OWLEDGMENTS xiii

OWLEDGMENTS

is book makes a number of judgments, the customary caveat that its content commits only the is more than perfunctory: by acknowledging sources of influence and help I do not mean to hat anyone listed endorses the views expressed. This caveat particularly applies to the first f people to be thanked, some of whom may be expected to disagree: the authors of the best oks. I have learned a lot from reading about agile methods, and am particularly indebted to ks and articles of Kent Beck, Barry Boehm with Richard Turner, Alistair Cockburn, Mike raig Larman, Mary and Tom Poppendieck, and Ken Schwaber with Mike Beedle. I credit my ounter with agile ideas to a presentation of Extreme Programming by Pete McBreen at the Le DF/CEA summer school in 1999. I am grateful to Mike Cohn for clarification of the origin of

his citations. I also benefited from a lively Scrum workshop by Jeff Sutherland in Moscow, g me to become a proud Certified Scrum Master.

ve given several industry seminars at ETH on the theme of this book and gained from the par-s’ comments. I am grateful for the advice of Ralf Gerstner at Springer on refining the focus ook, and am also indebted to his colleague Viktoria Meyer. Patrick Smacchia brought some gile practices to my attention. Claude Baudoin, Kent Beck, Judith Bishop, Michael Jackson r Jacobson were kind enough to encourage me after seeing a draft. Paul Dubois and Mark sent me important comments which helped focus and refine the text. Claudia Günthart and eyer helped with editing. Carroll Morgan sent me particularly perceptive comments on both

d content. I have a special debt to Raphaël Meyer’s for his thorough reading of the text, which ssential improvements.

ever felt like pontificating abstractly about software engineering, I would quickly be brought earth by the development group at Eiffel Software; we are fighting the battle every day. r we have seen it all: successes as well as those less glorious moments, the development iter-at seemingly will never end, the critical bug that surfaces two days after a release, the amo-rafted feature that turns out to interest nary a user. We are agile, in the best sense of the term, are learning all the time.

ve drawn on some material published on my personal blog, at bertrandmeyer.com, and on my Communications of the ACM (cacm.acm.org/blogs/blog-cacm). I am grateful for reader com-n blog articles.

indebted to members of the Chair of Software Engineering at ETH Zurich for many discus- software engineering issues. I cannot cite everyone but should mention that a remark by Till s the spark that led to switching the EiffelStudio development to an agile-style time-boxed process, and that Marco Piccioni first brought Scrum to my attention. He also made a number rtant suggestions on the draft of the present book. In the ETH course “Distributed Software

ering Laboratory”, where students from a dozen universities around the world work together allenging distributed project, my co-instructors of many years, Peter Kolb and Martin Nordio, uted numerous insights, as did the assistants (Roman Mitin, Julian Tschannen, Christian

se.ethz.ch/dose.

and the students and instructors from the participating universities. The course led to a number ished empirical studies which significantly helped my understanding of the field.

BOOK PAGE

Further material associated with this book is available at

bertrandmeyer.com/agile

Co

PrefaD

K

P

S

P

A

F

A

Conte

1 OV

1

1

1

1

1

1

ntents

ce viiescription and assessment vii

eeping a cool head viii

revious attempts ix

tructure of the book ix

erspective and scope x

nalysis: instinctive, experiential, logical or empirical? xi

ree critical inquiry xii

cknowledgments xiii

nts xv

ERVIEW 1.1 VALUES 2

.2 PRINCIPLES 4Organizational principles 5

Technical principles 6

.3 ROLES 7

.4 PRACTICES 8Organizational practices 8

Technical practices 9

.5 ARTIFACTS 10Virtual artifacts 10

Material artifacts 11

.6 A FIRST ASSESSMENT 12Not new and not good 12

New and not good 13

Not new but good 14

New and good! 14

xvi

2 DEC

2

2

P

3 TH

33

3

333

4 AG

4444

CONTENTS

ONSTRUCTING AGILE TEXTS 17.1 THE PLIGHT OF THE TRAVELING SEMINARIST 17

Proof by anecdote 18When writing beats speaking 19Discovering the gems 20Agile texts: reader beware! 21

.2 THE TOP SEVEN RHETORICAL TRAPS 22Proof by anecdote 22Slander by association 23Intimidation 23Catastrophism 26All-or-nothing 27Cover-your-behind 27Unverifiable claims 28

ostscript: you have been ill-served by the software industry! 30

E ENEMY: BIG UPFRONT ANYTHING 31.1 PREDICTIVE IS NOT WATERFALL 31.2 REQUIREMENTS ENGINEERING 32

Requirements engineering techniques 32Agile criticism of upfront requirements 32The waste criticism 33The change criticism 35The domain and the machine 36

.3 ARCHITECTURE AND DESIGN 37Is design separate from implementation? 37Agile methods and design 39

.4 LIFECYCLE MODELS 41

.5 RATIONAL UNIFIED PROCESS 42

.6 MATURITY MODELS 43CMMI in plain English 44The Personal Software Process 46CMMI/PSP and agile methods 46An agile maturity scale 47

ILE PRINCIPLES 49.1 WHAT IS A PRINCIPLE? 49.2 THE OFFICIAL PRINCIPLES 50.3 A USABLE LIST 51

.4 ORGANIZATIONAL PRINCIPLES 51

CONT

4

5 AG

555

5555

6 AG

6

66666666666

ENTS xvii

Put the customer at the center 51Let the team self-organize 53Work at a sustainable pace 56Develop minimal software 58Accept change 68

.5 TECHNICAL PRINCIPLES 70Develop iteratively 70Treat tests as a key resource 75Do not start any new development until all tests pass 76Test first 77Express requirements through scenarios 77

ILE ROLES 79.1 MANAGER 79.2 PRODUCT OWNER 80.3 TEAM 80

Self-organizing 80Cross-functional 81

.4 MEMBERS AND OBSERVERS 82

.5 CUSTOMER 82

.6 COACH, SCRUM MASTER 84

.7 SEPARATING ROLES 86ILE PRACTICES: MANAGERIAL 89.1 SPRINT 89

Sprint basics 89The closed-window rule 90Sprint: an assessment 91

.2 DAILY MEETING 91

.3 PLANNING GAME 93

.4 PLANNING POKER 94

.5 ONSITE CUSTOMER 96

.6 OPEN SPACE 96

.7 PROCESS MINIATURE 97

.8 ITERATION PLANNING 98

.9 REVIEW MEETING 99

.10 RETROSPECTIVE 99

.11 SCRUM OF SCRUMS 99

.12 COLLECTIVE CODE OWNERSHIP 100

xviii

7 AG

77

77

7

8 AG

8888888888888

9 AG

9

9

CONTENTS

The code ownership debate 100Collective ownership and cross-functionality 102

ILE PRACTICES: TECHNICAL 103.1 DAILY BUILD AND CONTINUOUS INTEGRATION 103.2 PAIR PROGRAMMING 105

Pair programming concepts 106Pair programming versus mentoring 107Mob programming 107Pair programming: an assessment 107

.3 CODING STANDARDS 109

.4 REFACTORING 109The refactoring concept 109Benefits and limits of refactoring 110Incidental and essential changes 112Combining a priori and a posteriori approaches 113

.5 TEST-FIRST AND TEST-DRIVEN DEVELOPMENT 113The TDD method of software development 113An assessment of TFD and TDD 115

ILE ARTIFACTS 117.1 CODE 117.2 TESTS 117.3 USER STORIES 119.4 STORY POINTS 121.5 VELOCITY 123.6 DEFINITION OF DONE 125.7 WORKING SPACE 125.8 PRODUCT BACKLOG, ITERATION BACKLOG 126.9 STORY CARD, TASK CARD 127.10 TASK AND STORY BOARDS 127.11 BURNDOWN AND BURNUP CHARTS 128.12 IMPEDIMENT 129.13 WASTE, TECHNICAL DEBT, DEPENDENCY, DEPENDENCY CHARTS 129ILE METHODS 133.1 METHODS AND METHODOLOGY 133

Terminology 133

The fox and the hedgehog 133

.2 LEAN SOFTWARE AND KANBAN 134

CONT

9

9

9

10 DE

11

11 TH

A

1

111

Biblio

Index

ENTS xix

Lean Software’s Big Idea 134Lean Software’s principles 134Lean Software: an assessment 135Kanban 136

.3 EXTREME PROGRAMMING 137XP’s Big Idea 137XP: the unadulterated source 137Key XP techniques 138Extreme Programming: an assessment 139

.4 SCRUM 139Scrum’s Big Idea 139Key Scrum practices 140Scrum: an assessment 140

.5 CRYSTAL 141Crystal’s Big Idea 141Crystal principles 141Crystal: an assessment 142

ALING WITH AGILE TEAMS 1450.1 GRAVITY STILL HOLDS 1450.2 THE EITHER-WHAT-OR-WHEN FALLACY 146

E UGLY, THE HYPE AND THE GOOD: N ASSESSMENT OF THE AGILE APPROACH 1491.1 THE BAD AND THE UGLY 149

Deprecation of upfront tasks 149User stories as a basis for requirements 150Feature-based development and ignorance of dependencies 150Rejection of dependency tracking tools 150Rejection of traditional manager tasks 150Rejection of upfront generalization 151Embedded customer 151Coach as a separate role 151Test-driven development 151Deprecation of documents 151

1.2 THE HYPED 1521.3 THE GOOD 1531.4 THE BRILLIANT 154

graphy 155

163