AN EXAMINATION OF THE AGILE MANIFESTO

Understanding
An Examination of
Agile Values
the Agile & Principles
Manifesto
Scott Duncan
Scott Duncan

ENTERPRISE SOFTWARE
DEVELOPMENT SERIES
 Contents

An Overview...............................................................................................5
The Agile Manifesto................................................................................................6
Not just for software...............................................................................................9
The next chapter.......................................................................................................9
Fundamental Considerations................................................................11
Communication..................................................................................................... 12
Collaboration.......................................................................................................... 13
Commitment.......................................................................................................... 14
Continuous improvement.................................................................................. 15
Trust.......................................................................................................................... 16
Excellence................................................................................................................ 16
Individuals and Interactions.................................................................17
Individuals and interactions............................................................................... 18
Processes and tools............................................................................................... 19
Committing to interaction................................................................................. 20
An experiment........................................................................................................ 20
Understanding Agile Values & Principles
© 2019 Scott Duncan. All rights reserved. Working Software....................................................................................21
Communicating with the software.................................................................. 23
Published by C4Media, publisher of InfoQ.com. Comprehensive Documentation....................................................................... 24
ISBN: 978-0-359-52387-0 Customer Collaboration........................................................................27
No part of this publication may be reproduced, stored in a retrieval Contract negotiation............................................................................................ 29
system or transmitted in any form or by any means, electronic, Responding to Change............................................................................31
mechanical, photocopying, recoding, scanning or otherwise except Following a plan..................................................................................................... 33
as permitted under Sections 107 or 108 of the 1976 United States
Copyright Act, without the prior written permission of the Publisher. Satisfy the Customer...............................................................................35
Our highest priority.............................................................................................. 36
Production Editor: Ana Ciobotaru Early and continuous........................................................................................... 37
Copy Editor: Lawrence Nyveen Valuable software.................................................................................................. 37
Design: Dragos Balasoiu
Welcome Change......................................................................................41 Self-Organizing Teams...........................................................................83
Customer’s competitive advantage.................................................................. 42 The best.................................................................................................................... 84
Welcome changing requirements..................................................................... 42 Self-organizing teams.......................................................................................... 84
Late in development............................................................................................. 44
Team Reflection.......................................................................................87
Deliver Frequently..................................................................................45 Regular intervals.................................................................................................... 88
Deliver working software frequently.............................................................. 46 The team.................................................................................................................. 89
From a couple of weeks to a couple of months............................................ 46 Become more effective......................................................................................... 90
With a preference to the shorter timescale.................................................... 46 Tune and adjust...................................................................................................... 90
Why the short iterations?.................................................................................... 47 Retrospective “smells”.......................................................................................... 91
Some retrospective ideas..................................................................................... 92
Working Together....................................................................................49 What next?............................................................................................................... 98
Business people and developers........................................................................ 50
Work together daily.............................................................................................. 50 Epilogue.....................................................................................................99
Throughout the project....................................................................................... 51 One older and two recent perspectives........................................................... 99
Motivated Individuals.............................................................................53 Further Reading.....................................................................................104
Motivated individuals.......................................................................................... 54
Environment and support.................................................................................. 54 About the Author...................................................................................106
Trust them............................................................................................................... 55
Face-to-Face Conversation.....................................................................57
Modes of communication................................................................................... 58
Distributed teams.................................................................................................. 61
Dealing with distribution.................................................................................... 62
Daily meetings........................................................................................................ 64
Iteration reviews.................................................................................................... 65
Working Software… Again?...................................................................67
Measuring progress.............................................................................................. 68
Burn-up chart......................................................................................................... 69
Definition of done................................................................................................. 70
Sustainable Development......................................................................73
Sustainable development..................................................................................... 74
Constant pace indefinitely.................................................................................. 74
Technical Excellence...............................................................................77
Continuous attention........................................................................................... 78
Technical excellence............................................................................................. 78
Good design............................................................................................................ 79
Enhances agility..................................................................................................... 80
Simplicity..................................................................................................81
Foreword Other Comments on the Book

Agile was founded on a set of values and principles in a short document “Whenever I engage with people who are looking to practice agile, my
known as the Agile Manifesto. To implement these agile values and prin- first goal is to ensure they understand the core agile values and principles.
ciples, teams follow certain practices, such as writing user stories or doing This is the foundational “why” that underlies the practices in a framework
pair programming. like Scrum. Without first establishing this core, practitioners will not be
well equipped to inspect and adapt their approaches to practicing Scrum.
In the early days of agile, I remember participating in many raging de- Scott has provided important commentary on and elaboration of the val-
bates about whether principles or practices should come first. That is, if ues and principles in the Agile Manifesto. This is a good read whether you
a team followed a set of practices long enough and well enough, would are an agile novice or an experienced practitioner.”
team members come to learn the principles underlying those practices?
Or was it necessary for teams to start with a solid understanding of the - Ken Rubin author of Essential Scrum: A Practical Guide to the Most Pop-
principles of agile before implementing its practices? ular Agile Process and creator of the Visual AGILExicon® (https://innolu-
tion.com/)
These debates often raged at the early agile conferences and Scrum gath-
erings. I met Scott at one of these conferences: the Agile Development “Scott Duncan has written an interesting and valuable book. He works
Conference in Salt Lake City in 2004. through all the values and principles of the Agile Manifesto, considering
each phrase and its implications for an individual or organization inter-
In the ensuing 15 years, I have been consistently impressed with Scott’s ested in taking an Agile approach to their work. This is in sharp contrast
mastery of agile. When he weighs in on the question of principles versus to almost all the other Agile advice you’ll find: Scott has no particular
practices, as he does in this book, we all benefit. framework or product, no particular axe to grind. The book is essentially
In Understanding Agile Values and Principles, Scott analyzes each of the 12 a series of short meditations on each of the ideas in the Manifesto. He
principles and four value statements of the Agile Manifesto. Along the leads us through a clear and comprehensive look at the Manifesto and
way he explains the intent and importance of each. But he also describes what it really means to those of us who try to apply it in our work and
how teams may struggle to put a principle or value into practice. And he lives. Highly recommended!”
offers practical, ready-to-use advice on living the principles and values of - Ron Jeffries, co-author of the Agile Manifesto and author of The Nature
the Agile Manifesto. of Software Development: Keep It Simple, Make It Valuable, Build It Piece by
The Agile Manifesto fits on one page. But, as short and concise as it is, Piece (https://ronjeffries.com/)
much is left open to debate and interpretation. Those debates will nev-
er — and probably should never — stop. It is through discussing what it
means to be agile that we uncover better ways of developing software.
Scott’s thoughts and advice in this book represent a significant step in
forwarding that discussion.
Mike Cohn
Co-founder of the Scrum Alliance and Agile Alliance
Author of User Stories Applied, Agile Estimating and Planning,
and Succeeding with Agile
www.mountaingoatsoftware.com
www.agilementors.com/
Preface

Many years ago I began what I planned to be a much larger book with Third, I want to thank Ken Rubin for the opportunity to read an early
this same title. I felt that many organizations I had been working with had draft of his book Essential Agile and, now, for his suggestions for improve-
started their Agile journey without a good (or any) coverage of the Agile ments to this book (which I’ll do a better job with on the next book) and
Manifesto’s Values and Principles. The book was too grand an effort and his overall perspective on it.
I put it aside. However, over the years, my concern for the lack of organi-
zational knowledge of the Agile Values and Principles has not lessened. If There are many others whose work and insights have helped me along my
anything, it has grown. I decided about a year ago to put up some essays personal Agile journey:
on Medium.com and that turned out to be the precursor to this book. Jurgen Appelo, Lyssa Adkins, and Barry Boehm & Richard Turner were
People talk of “being” agile rather than just “doing” agile and, someday, others who allowed me an early look at their books;
that longer book may get done and be about the latter. This book, how- Kent Beck, of course, through his eXtreme Programming Explained, pushed
ever, tries to be about the former with enough examples of “doing” to me in the direction that has led me to this point in my career;
illustrate how one might behave if they were “being” agile.
Alistair Cockburn has always added to my appreciation for thinking in an
I would not have gotten to this point, though, without many people who Agile way every time I have read what he has written or heard him speak;
have influenced my thinking about Agile software development. Since I
first read eXtreme Programming Explained in 2002, there have been enough Then there have been people such as Mary & Tom Poppendieck, Robert
people that I doubt I could never list all of them. And before that for about Galen, Roman Pichler, Brian Marick, David Anderson, Ken Schwaber, Jeff
25 years, even more people influenced how I viewed traditional software Sutherland, Scott Ambler, and a host of people whose books, conference
development/engineering topics. talks, blogs, and videos have offered me guidance over the years.
Acknowledgements And, before I encountered the Agile Manifesto, during my ‘phased se-
quential” days, especially 14 years in the Bell environment, there was the
I would like to thank a few people specifically for reading the draft of this work of Barry Boehm, Tom DeMarco, David Parnas, Gerry Weinberg,
book and for their comments about it: and Fred Brooks to mention just a few.
First, knowing him for about 15 years, and since he (along with Ken Finally, my thanks to:
Schwaber) was my CSM trainer, I want to thank Mike Cohn. I have had
the pleasure of being at conferences with Mike, taking classes from him, Ben Linders who showed the initial interest in getting this book published
working on the Scrum Alliance Board of Directors with him, and partic- and has offered much help along the way;
ipating in his Agile Mentors Community. I also had the opportunity to
read and comment upon the draft of his Succeeding with Agile book. Lawrence Nyveen for his editorial review;

Second, knowing him almost as long as Mike, I want to thank Ron Jeffries Ana Ciobotaru and Dragos Balasoiu for their work on the cover of this
for looking through the draft of this book. Over the years I have enjoyed book and other publishing details.
presentations he has given on Agile development practices and his ear-
ly writing on eXtreme Programming practices. Before I learned about
Scrum, Ron’s (and Kent Beck’s) work on XP was my introduction to Agile
practice once I encountered the Agile Manifesto.
PART 1
An Overview
 UNDERSTANDING AGILE VALUES & PRINCIPLES AN OVERVIEW

I have been coaching and training teams in agile approaches to software often sounded as if they misunderstood or even ignored the preposition
development for over 13 years. During this time, many frameworks and and final statement.
practices have been proposed and used. In my experience, one thing
seems clear: as framework-specific training has increased, many of those
trained seem to have limited familiarity with the Agile Manifesto’s val- The initial statements
ues and principles (http://agilemanifesto.org). As a result, people tend to The Agile Manifesto’s first paragraph is “We are uncovering better ways
return to what they had been doing previously when practices advocat- of developing software by doing it and helping others do it. Through this
ed during training have been difficult or not possible to implement. This work we have come to value:”. All the people at the meeting that created
often seems to occur without reference to the values and principles to the manifesto had direct experience developing software. No one was a
consider how some alternative might be selected that more closely ad- pure academic or researcher. What one finds in the manifesto, therefore,
heres to them. I believe it is the limited understanding of the values and is based on practical, not theoretical, experience. Those in attendance
principles that excludes them from people’s thinking when choosing al- stated they felt this experience had led them to believe four key things:
ternative practices. the values.
It is for this reason that I offer my thoughts on what an understanding
of the values and principles could mean to an organization. Such under- The final statement
standing will make it easier to pursue an agile approach successfully by
using the values and principles as a reference point when considering I remember reading articles back in the early 2000s in which people sug-
practice alternatives. As many have pointed out, agile ideas are quite sim- gested or outright said that the manifesto authors advocated no process or
ple but not necessarily easy to implement. While based on ideas with a tools, no documentation, no contracts, and no planning. Such overt state-
lineage that goes back at least to the middle of the last century, they form ments ended some time ago, but you may hear this same sense expressed
a set of reinforcing ideas intended to be used together, not piecemeal. in statements like, “You can’t possibly do <some aspect of development>
without <some particular processes, tools, documentation, contracts,
I will take each value and principle and explore what I believe it can mean, or plans>.” Of course, the manifesto doesn’t say you should do without
suggesting along the way a variety of possible practices and consider- these things. The final statement says “That is, while there is value in the
ations that could help implement each one. items on the right, we value the items on the left more.” The manifesto
acknowledges value in processes, tools, documentation, contracts, and
To begin, this overview will address the Agile Manifesto as a whole. The plans while saying that the authors believe there is greater importance in
next chapter will address fundamental considerations basic to an effective individuals and interactions, working software, customer collaboration,
group work situation, but especially important for being agile: communi- and responding to change. Understanding matters of degree are therefore
cation, collaboration, commitment, continuous improvement, trust, and important.
excellence. After that, each value and principle will have a chapter dedi-
cated to addressing it.
The preposition
Note that the word forming the connective link in each value statement is
“over.” It is not “instead of”, “to the exclusion of”, “without”, or some other
The Agile Manifesto exclusionary form. The word “over” implies a precedence, not an exclu-
sionary relationship, within each value statement.
What’s covered below are three components of the manifesto that bear
on how one understands the value statements: the initial two statements, If an organization has difficulty:
the final statement, and the preposition. Early reactions to the manifesto
• with individuals interacting effectively, then more, or more rigorous
adherence to, process and tools probably won’t help;

6 7
 UNDERSTANDING AGILE VALUES & PRINCIPLES AN OVERVIEW

• producing working software regularly, then more, or more detailed,

documentation probably won’t help;
Not just for software
• collaborating with customers positively, then more rigorous con- One final point before ending this introduction is that the manifesto’s val-
tracts probably won’t help; and ues and principles easily apply to any activity where people need to work
in some way to produce some end product or service. If one replaces the
• responding to change directly, then more, or more rigorous adher-
word “software” with “product or service”, I believe the values and princi-
ence to, plans probably won’t help.
ples retain their validity.
• Looked at another way:
• Processes and tools should help individuals interact more effectively. At an agile conference held several years after the manifesto had achieved
broader visibility, I heard someone bemoan the attempt to apply agile
• Documentation should help achieve working software more regular-
outside the realm of software. They seemed to feel that agile, coming from
ly.
the field of software and having many early practices rooted in software,
• Contracts should be written to help collaborate with customers more would be diluted by efforts to apply it in other domains. I believe dilution
positively. of agile ideas occurs not from applying them in other domains but from
• Plans and planning should help the ability to respond to change more people not using them as a touchstone for becoming agile regardless of
directly. frameworks and practices.
Stated this way, if the former cannot help achieve the latter, then the for-
mer become impediments to success.

Since the manifesto

The next chapter
Hopefully, this overview will interest you in reading further. The next
Over the years, people have proposed updating the Agile Manifesto to ad- chapter will address the fundamental considerations of communication,
dress things they felt the original authors missed or were now out of date. collaboration, commitment, continuous improvement, trust, and excel-
I also heard someone once claim that the manifesto was “content-free”, lence noted above.
by which he meant that it was easy to agree with without committing to
anything specific. Who wouldn’t want effective interaction between peo-
ple, software that works, collaboration with customers, and being able to
respond to change? But as I have heard (and read) at least one author of
the manifesto say, it was a statement of what those 17 people in the room
during those four days in 2001 believed at that time. As such, the Agile
Manifesto (or any manifesto) isn’t something you update.
New ideas will appear and be pursued and can offer useful guidance to
what to consider in becoming and pursuing agile. In particular, two in-
teresting ways to think about what it means to be and to pursue agile are
Alistair Cockburn’s Heart of Agile and Joshua Kerievsky’s Modern Agile.
I will come back to these two at the end of the book as well as mention
comments made by Kent Beck in 2010.

8 9
PART 2
Fundamental
Considerations
 UNDERSTANDING AGILE VALUES & PRINCIPLES FUNDAMENTAL CONSIDERATIONS

In Chapter 1, I mentioned several ideas which I called “fundamental.” It of scope flexibility and the impacts of change should include custom-
seems hard to expect an organization (or a group or an individual) to be- ers and development organizations.
come (more) agile without them. As noted in Part 1, all these consider-
ations are important for any work situation, but seem essential for being Most development trouble occurs because communication is not effec-
agile. Being agile, as many have said, is more important than “doing” agile. tive.
That is, understanding how to apply the values and principles is more im-
portant than specific practices. Practices, of course, must exist, and there
are many ways to “do” agile. But perhaps, there is a narrower set of choic-
es in “being” agile. Collaboration
Collaboration is certainly an aspect of effective communication. Many
people working in teams believe they are collaborating when they are
probably just cooperating. There is nothing wrong with cooperation, but
Communication collaboration goes beyond cooperating. One can cooperate without col-
Every value in the manifesto is affected by communication, though the laborating.
forms differ: To “co-operate” literally means to operate together, to function in con-
• It seems impossible to expect positive interaction between individu- junction with, which can occur with limited interaction. Individuals can
als without effective communication. This requires an openness and have their own work assignments, work to get them done, and be willing
willingness to bring visibility to the relationship. It means having to to help out others when they can. But they can essentially focus on what
risk being wrong in front of people if ideas and information are going they feel they must accomplish individually, expecting others to do the
to flow freely back and forth. It means asking more than telling and same. People can cooperate without assuming any responsibility for any
being inclusive (“we”) rather than accusative (“you”). work other than their own.
• Achieving working software certainly requires effective communi- To “col-laborate” literally means to work together. It involves deliberately
cation between people, but also between the software itself and those sharing work, and responsibility for the work, involved in getting some-
people. This requires design, development, and testing practices that thing done. This means structuring tasks so people work closely with one
expose what is happening with the software at any stage in its cre- another to accomplish planning, estimation, commitment, development,
ation. Being able to know the stability of your system at any moment and testing. It also means communication must be more direct and fre-
encourages experimentation, builds trust, clarifies quality, and makes quent, which cooperation doesn’t necessarily demand.
change less risky.
Collaboration’s connection to individual interactions and working with
• As positive collaboration with customers (or any stakeholders) is
customers seems clear. Achieving working software and responding to
just a specific instance of individuals interacting, it would seem to
change are slightly more indirect, but not much. Achieving both occurs
go without saying that this requires effective communication. But
more effectively when collaboration, not just cooperation, exists. Achiev-
it is a two-way obligation. Customers must realize that, to get the
ing working software can be much harder (if not confounded) when there
benefit from an agile approach, they must involve themselves in the
is a hand-off mentality between skill silos.
approach at various points, providing feedback and clarification, and
even guidance when needed. Likewise, response to change may be less effective without a collabora-
• Finally, it is hard to imagine responding well to change without effec- tive stance. People, without intending any negative impact on others, can
tive communication between all those who need to know about, have sub-optimize the change in a way that improves (or maintains) their own
valuable insight into, and will be affected by such change. Discussions situation while sometimes making other people’s situations worse.

12 13
 UNDERSTANDING AGILE VALUES & PRINCIPLES FUNDAMENTAL CONSIDERATIONS

For example, you’ve probably been in a situation where departments in a People doing these things together, closely communicating, will more
company have been told to cut their budget by some percentage for the easily feel that the commitments are truly theirs, motivating them to
coming year. In one instance I experienced, IT support rightly pointed achieve, even exceed, them. People want the opportunity to take pride in
out that a lot of money was being spent supporting many versions of their work and commit to it. (Deming pointed this out in his work with
desktop machines used both for actual development and for basic admin- the Japanese after WWII and documented it in 1982 in his book Quality,
istrative and office activities. Clerical support staff were using powerful Productivity, and Competitive Position, later renamed Out of the Crisis in
engineering workstations, Macs, and Windows PCs to simply maintain 1986.)
management file systems, budget records, presentations, and memos.
IT Support noted that, unless required for development, one standard
desktop environment should be used. Windows 3.4 and relatively inex-
pensive PCs became the approved environment when development was Continuous improvement
not a consideration. This also reduced costs since support personnel for Perhaps nothing is more important in being agile than the pursuit of
such an environment were more plentiful and less expensive than for the continuous improvement. Indeed, the basic agile lifecycle instantiates
other environments. After converting many people, including all man- this through the retrospective held at the completion of every iteration
agement support staff, a serious, undocumented bug was exposed that of work. Unfortunately, it is sometimes a skipped step in that lifecycle,
took a couple weeks to track down (by technical staff other than IT Sup- trailing planning and daily meetings in frequency according to Version-
port) and another (the same technical staff) to correct the consequences of One surveys.
once identified. Hundreds were affected, including management whose
files had temporarily “disappeared,” the cost of which was never formally A variety of things may contribute to this, but a key one is that while peo-
recorded, but IT Support could show their budget was reduced by the ple come up with ideas for improvement, nothing ever changes or hap-
required percentage. pens to those ideas. Unfortunately, after making lists of possible changes,
people do not treat the ideas as serious work items. The ideas do not get
prioritized, estimated, or committed to actual work effort in the next it-
eration. Thus, the next retrospective occurs, and the same ideas are raised
again.
Commitment
Communication and collaboration are more easily improved when peo- Another reason is that people don’t feel there is time to conduct the retro-
ple see commitment from one another to achieve the work before them. spective given pressure to get going on the next set of customer require-
In turn, that commitment is more easily accepted when effective com- ments. Clearly, the time and effort to carry out improvement should show
munication and collaboration exist. It’s a bit of a circle of course, though benefit but it cannot if people aren’t given, or don’t feel they can afford,
not a vicious one. One requirement, however, is that the people doing the the time to try.
work take on and make their own commitments. These should not be im- Finally, I’ve heard people say, “Everything went fine this iteration so
posed on them. More will be said about this when self-organizing teams there is nothing to fix.” The retrospective is about improvement, not
are addressed in a later chapter. However, people should, for example: just “fixing” things. Unless a team never generates any defects, is always
• make their own estimates of the work to be done; completely accurate in its estimates, and is completely productive, there
is always something that can be improved. It doesn’t have to be a huge
• define their own work tasks and who will/can do them;
change. It’s about continuous improvement as a habit (i.e., what in lean
• agree on shared working agreements, including quality standards terms is called kaizen). All the values and principles of the Agile Manifesto
and practices; and can probably be more effectively implemented in one way or another in
• manage and track their own progress toward completing the work. any organization.

14 15
 UNDERSTANDING AGILE VALUES & PRINCIPLES

Trust
It’s has been said that trust is earned in pennies and lost in dollars, i.e.,
hard to come by but easy to lose. Probably nothing destroys a group’s
effectiveness more than lack of trust within the group or by those around
it. Unfortunately, typical project management practices are often based
on or conducted in some aspect of a lack of trust. But without trust, open
communication and collaboration just won’t happen. People will not pur-
sue new ideas or attempt new ways of working if they do not feel they can

PART 3
expect support from others when they do.
Of course, it has also been said that “In God we trust; everyone else brings
data,” “Trust in God but tie up your camel,” and “Trust, but confirm.” Trust
does not exist between people automatically. People may presume trust
until some problem surfaces, then begin finger-pointing among one an-
other. It is difficult to truly trust someone with whom you have had no
positive working experience, that is, have no “data” upon which that pre-
sumption exists. Effective, deliberate communication, collaboration and
commitment from the very outset of people working together provide
Individuals and
that “data,” contributing strongly to creating such trust.
Interactions

Excellence
Finally, there is the desire to achieve excellence. We cannot assume excel-
lence from everyone, but we can expect them to pursue it, collaboratively,
using continuous improvement. True excellence may be (or at least seem
to be) a distant target, but pursuit of it is certainly reasonable. Often the
problem is deciding what excellence means in a group’s work and how to
pursue it. Established group working agreements and quality practices
along with use of the retrospective should make such decisions easier,
building trust at the same time.

16
 UNDERSTANDING AGILE VALUES & PRINCIPLES INDIVIDUALS AND INTERACTIONS

This chapter begins a set of four chapters, each focusing on one of the
Agile Manifesto’s value statements.

Individuals and interactions

I think anyone who has worked with others — be it at work, on a ser-
vice project, for a local community group, or even a family effort — would
agree that the interactions of the individuals within the group had the
biggest impact on the result. If there is effective communication, collab-
oration, and trust among people in such situations, they are likely able
to overcome many limitations in process, environment, and tools. Those
who supervise or manage such efforts should make it a priority to see
that such communication, collaboration, and trust exists and that they, as
supervisors or managers, protect and encourage that existence.
Cockburn notes that this figure from his book captures “the findings of
But a major challenge to doing this in a work environment is that so many researchers, such as McCarthy and Monk (1994)” in Measuring the Qual-
teams are distributed. Indeed, I have not worked as a coach or trainer ity of Computer-Mediated Communication. There’s more to say about it
for any company in over a decade that did not have distributed teams. in Chapter 12, when the sixth principle is discussed. For now, a couple
The sixth principle says that “The most efficient and effective method of things can be pointed out.
conveying information to and within a development team is face-to-face
The vertical axis indicates how effective the mode is in communicating
conversation.” However, co-located teams are frequently not the default
information while the horizontal axis indicates the impact of the commu-
occurrence. While I’ll address distributed teams throughout future chap-
nication. Together, they show how little time and energy the modes take
ters, this value is certainly an appropriate place to start, given how dis-
to communicate information between people as we go right and up along
tribution creates challenges for communication, collaboration, and trust.
the axes. Note where purely text-based documentation sits (“Paper” on
Most people think of distribution as a matter of distance (and, hence, the diagram) compared to face to face (“2 people at whiteboard”).
time). Alistair Cockburn, in Chapter 3 of his book, Agile Software Devel-
opment, notes that what matters is “is the amount of energy it takes” to
pass ideas between people. Direct, face-to-face communication between
people can be discouraged at amazingly short distances, e.g., perhaps 30
meters. If the energy and time it takes to stop what you are doing, get up,
Processes and tools
and go to another person is perceived as too great, people will simply Many tools, of course, allow people to open them up and look at the status
not do so. They will communicate as if they were miles, even continents of team work whenever they want to know something or when the tool
apart, using various forms of text-based methods. (Interestingly, people alerts them that something has happened.
who recognize distribution across large distances and time use technolo-
gy that allows them to see one another (e.g., Skype, Google Hangout, We-
bex, etc.), but might never think to do this more locally when disinclined
to get up and go to visit another person.)

18 19
 UNDERSTANDING AGILE VALUES & PRINCIPLES

Committing to interaction
What’s important is that there is the commitment to interaction, to com-
munication, to a whole team atmosphere. Rather than finding it too hard
to do this, falling back on exchanging documents, and splitting up work
so people do not have to interact, look for ways people can share the work
— actually collaborate not just cooperate. According to one of Version-
One’s annual surveys, only about 20% of respondents say they looked for
agile to help them better manage distributed teams, while 61% of them

PART 4
said that, in fact, that turned out to be a benefit of adopting agile. I believe
this is because of a commitment to making communication work among
team members and between teams. It’s a challenge whether you are dis-
tributed or co-located but being agile expects this of us.

An experiment Working Software

Here’s a thought experiment (or perhaps an actual exercise you can do
with a group of people). Think of some very positive experience you have
had working with a group of people. Write down the characteristics of
that experience that make it so positive in your memory. Now categorize
them as:
• people — interactions between you and individuals in the group;
• culture — the overall group/organizational assumptions, agreements,
attitudes and expectations;
• process — the way(s) the group organized the work you did and car-
ried it out;
• environment — the actual physical environment in which you
worked; or
• tools — the tools (manual or electronic) you used to get the work done.
Now look at the pattern created by grouping your memories of that ex-
perience. Where do those characteristics fall in the groupings? (If you do
this with a whole group, write the ideas on notecards or stickies and put
them up on a board/wall with the headings listed so everyone can see the
total set of groupings.) What does this tell you about why the experience
was memorable?

20
 UNDERSTANDING AGILE VALUES & PRINCIPLES WORKING SOFTWARE

Who wants software that doesn’t work? But what does it mean that it then implement each CoS, verifying they each work as we add them, does
works? It shouldn’t have any defects, right? It should have been fully test- the software “work” at each point along the way? From a code quality
ed, correct? The agile approach to quality expects that at the end of every perspective, it could be said that it does. What if a customer will take a
iteration of work, the team feels the software is of production quality. useful subset of all the CoS because that subset will “work” for them in
That is, if it could be put into production, the team would not worry about the near-term. They’d prefer to get a useful increment sooner rather than
it failing to meet customer expectations. They are confident in the quality later. Everything they asked for initially isn’t there, but enough is to make
of what they have produced and not just based on being defect-free. it useful. Later, they’ll get more of the things they requested.
To be fully useful in production, all associated user guides, installation To start, then, the team could (depending on the length of the iteration)
procedures, help-system entries, etc. should also be completed. Without provide the first three capabilities, then add the next two in the next iter-
them, it may not be possible to use the software even if there were no ation, then the sixth one in the following iteration, etc. At the end of each
defects. The software wouldn’t “work” from the end-users’ perspective if iteration, new functionality could be put into production as the customer,
they could not use it regardless of how defect-free it might be. From an incrementally, gets more useful software.
agile perspective, the “software” includes that necessary user documenta-
tion. Such of documentation is considered part of what must “work,” as Discussing what makes the software minimally viable in this way can lead
well as the code itself. to customers getting something useful rather than waiting for everything.
This is part of the agile idea of ordering the work based on customer value
But sticking just to the code, what must work? Let’s look at a simple ex- and working to deliver high-value results soon and frequently during a
ample of what a customer might request: release/project cycle. It puts the decision about what constitutes a viable
release in the hands of the customer/business and not in the hands of the
“As a banking customer, I want a list of all my accounts and balances so I development team. The team just keeps adding the next-highest-valued
can manage my finances.” functionality and the customer says when it’s useful enough to be a re-
Seems like a simple enough request, but let’s add some acceptance crite- lease.
ria. These are often referred to as conditions of satisfaction (CoS).
• I want the list to be a pop-up list I can request from anywhere in the
system.
• If the list exceeds 20 items, I want it to scroll.
Communicating with the software
• I want the list sorted by account type or balance. The importance of effective communication between customer and de-
velopment is clear. What about effective communication with the soft-
• I want to be able to select to sort by balance then by account if I want. ware itself? People can communicate with the software simply by using it
• I want to be able to see due dates and required payments on debt ac- in some way. The software responds by performing as expected, or not.
counts (e.g., credit cards, loans). This begins with how the team verifies and validates the software through
• I want to sort by either due date or required payment if I have those forms of inspection and testing. Then the team’s product owner or cus-
showing. tomer can try the software to see how it works. Done frequently enough,
• I want to add other fields to each item such as <imagine a few others>. this communication will reduce risk by uncovering defects or new func-
tionality requests early, before they become too expensive, increasing
• I want to filter the list by account type, balance, due date, or required
customer satisfaction with the results.
payment to shorten a long list.
• I’d like to be able to search the list. The company Menlo Innovations likes to have a customer representative
present with their developers throughout the process of creating the soft-
Does the software “work” if any of the Conditions of Satisfaction don’t ware for that customer. At the end of each week, when the team shows
work or exist? If we implement the basic request and verify that works,

22 23
 UNDERSTANDING AGILE VALUES & PRINCIPLES WORKING SOFTWARE

what they have accomplished, they like the customer representative to Many years ago, I was at a conference and Barry Boehm spoke about the
demo the working software. That person was there all week discussing documentation “memorial libraries” he had seen in many companies,
the functionality with the developers, seeing it developed, and helping filled with shelf upon shelf of binders where the only people who ever
verify it. If they cannot show how it works, something must have gone looked at it were auditors when they needed to verify what happened
wrong in the relationship during the week and that needs to be addressed. when they weren’t there to see it for themselves.
Implementing small pieces of functionality, verifying they are correct, If you are going to generate any volume of documentation, you must ac-
and validating that they satisfy the customer’s expectations is the essence cept the total cost of ownership (TCO) make the investment to keep that
of agile development. When starting to work in an agile fashion, this pro- documentation current. As a developer, I often found that I could not
cess can be hard because people are used to long(er) development cycles trust documentation because it did not match the code. I spent a week
and think in terms of large(r) pieces of functionality. Getting the customer sometimes trying to debug a problem or add functionality believing in
(or business) to think in smaller pieces of functionality and smaller release text documentation, both outside and within the code.
cycles will take time, but is essential to get working software into produc-
tion sooner rather than wait a long time to get everything, with all the I once worked where, instead of updating the original design document
details completed. to match the new work, people created addenda documents which only
addressed the changes being made. After a few years, if you wanted to
I observed a team that worked very hard to break functionality down into use/rely upon the documentation, you ended up having to read 6–8 doc-
pieces that could be completed (including user-relevant documentation) uments: the original and various addenda. Eventually, people just didn’t
in just a few days rather than take a few weeks to get all of it done. This bother which also led to not bothering to document at all after a while.
increased collaboration between developers, quality analysts and tech The old development-centric view used to be that you needed to read the
writers, making collaboration easier. It also resulted in the team spending code to know what the system did. That was the only reliable “documen-
little time estimating the work. Everything was such a small effort that tation.”
they just called everything 2 points (using the Fibonacci story point scale).
They spent their time breaking stories down — which was the important The Agile approach does not mean to reject all documentation, of course,
thing to be able to develop, test, and deliver frequently — eliminating esti- just to apply some simple ideas so the documentation has “sustainable”
mation effort almost completely. value. By “sustainable,” I mean that the documentation is considered so
valuable for developing high quality, valuable software, that people will-
ingly create it and keep it updated. Agile development prefers executable
work products (e.g., tests) to static ones (e.g., traditional text documents).
Indeed, a strong automated test suite is, in effect, a set of executable re-
Comprehensive Documentation quirements.
User manuals, installation guides, help systems, etc. are considered part Going from user stories to working (i.e. tested) software using strong
of the “software” from an Agile perspective. The “comprehensive” docu- programming practices and meaningful naming conventions will mean
mentation this value mentions is internal, system forms of documenta- you need less of the traditional documentation. There is risk when code
tion which are often not used once a project/release is completed. The is written and not easily and quickly verified to be correct. The interval
argument can certainly be made that detailed documentation is import- between writing code and verifying code is that risk. In traditional devel-
ant for historical reasons, but it may not be the best way to communicate opment, that time can be weeks, even months. The goal is to shorten that
among people actively developing the current system. Such “comprehen- time as much as possible. (More will be said about approaches to quality
sive” documentation may contribute to the next project/release, but the and testing in future chapters.)
immediate goal is to deliver the current requirements as quickly and in-
expensively as a high level of quality and reliability allows. I once worked as a coach for a project with three teams (growing to five
over the 10 months of the project). At the outset, the teams could get one

24 25
 UNDERSTANDING AGILE VALUES & PRINCIPLES

build every four weeks (their iteration length). Such builds were done by a
separate group, in a separate state, supporting all the company’s projects.
You can imagine what that meant to team productivity if they were to
try to honor completed working software as their goal each iteration. It
took several months for the management of that project to get the teams
to a build a week, then a build each day, then, not too long after that, two
builds a day: one ready each morning for teams on the East Coast and
one done at the end of their day for the offshore members of the teams
to work on. The ability (and confidence) of the teams to be more produc-

PART 5
tive substantially increased at each one of these junctures. Their velocities
went up 10%-15% each time just based on this.
The key thing to remember is that communication, not documentation,
should be the goal. Since one size does not fit all needs, each release/proj-
ect should evaluate what needs to be communicated, to whom, and what
the best way to do that will be. Accepting “the way it’s always been done”
is likely not going to help you deliver working software frequently that
meets customer needs. It may, in fact, impede it.
Customer Collaboration

26
 UNDERSTANDING AGILE VALUES & PRINCIPLES CUSTOMER COLLABORATION

As mentioned in Chapter 2, this value can be looked upon as just a form “Do you always get everything you want by the project deadlines?”
of individuals interacting. But I think it is a different situation than how
people in the development organization interact and what the content of They look at me as if I am a bit dumb and say, “Almost never.”
that interaction would be. Collaboration with customers is focused on “But you do always get the most important things by the deadline, right?”
the “what” side of the work rather than the “how.” That is, it focuses on
what the customer wants as functionality and what they will need to see Now a look as if I am truly dumb, “No. Frequently I don’t.”
as evidence of the functionality being satisfactory to them.
“So that’s why we ask for prioritization and frequent feedback, so that if
Now, customers may get into the “how” quite often as they attempt to there are problems getting it all done by the deadline, you will get all the
define the “what”. Indeed, with traditional requirements documents, get- highest-valued functionality possible and it will be just the way you want
ting into details of both “what” and “how” is typical. Customers new to an it.”
agile approach could be expected to combine the two. They may consider
Sometimes the lightbulb goes off.
keeping them separated as restricting their ability to define their require-
ments. The agile approach recommends not diving deeply into “how” too
soon for a few reasons:
• It may mean spending a lot of time on something that ends up not
actually getting developed because the customer changes what they
Contract negotiation
want later in development. It’s unfortunate but a lot of contracts seem to be written not to describe
• Even if it will get developed, people will know more about what is how the vendor and customer will work together for success but to define
needed closer to the time they must make that decision. (The agile the penalties for when one or the other fails to meet their responsibilities.
approach recommends waiting until “the last responsible moment” This doesn’t seem like a way to establish a particularly collaborative rela-
before a commitment is made so you know as much as possible when tionship between people. Contracts also typically seem to be based on the
you must make that decision.) belief that everything needs to be defined up front. A more incremental
approach to defining how the work will be done and how people will
• When the time to implement the functionality occurs, you may find
work together, collaboratively, to produce the most satisfactory result
you have unnecessarily constrained your decision making. (One can
should be a critical part of any contract.
cram 10 pounds of potatoes into a five-pound bag by mashing them
early on, for example, but you can’t expect to get french fries later.) From the agile perspective, the customer and development organization
should explore expectations for customer participation in:
All of these are also good reasons for not getting overly detailed about the
“what” too soon. • the iterative process of requirements (e.g., user story) definition and
refinement,
It’s important that the customer sees the value in frequent, open com-
munication about what they want and what development can show to be • prompt response to questions during the release/project to clarify
working as a way to reduce risk and increase satisfaction with the results. functionality expectations,
• defining acceptance criteria (conditions of satisfaction) for each re-
When I have seen organizations forced to work with customers (internal quirement,
or external) who will not accept this, there has been noticeable stress on
• each iteration’s review of the functionality developed during that it-
both sides. More than once, I have heard the business side of an organi-
eration,
zation say they don’t have time for frequent meetings and that they just
“need it all done by the deadline” so don’t want to take time for prioriti- • offering feedback to confirm their acceptance of what the team has
zation. It doesn’t always work, but my basic discussion with them goes done or their desire for any changes,
somewhat like this:

28 29
 UNDERSTANDING AGILE VALUES & PRINCIPLES

• ongoing elaboration of functionality as the team moves from highest

to lowest priority in requirements, and
• prioritizing requirements from highest to lowest value so the devel-
opment team always works on the highest-valued remaining func-
tionality.
If customers are not prepared to do these things or enough of them
(which depends on the project), then perhaps a more “protective” contract
is smart.

PART 6
There are a variety of places to look for opinions about structuring ag-
ile contracts. Just type “agile development contracts” into your favorite
browser. A few possibilities are:
• https://en.wikipedia.org/wiki/Agile_contracts (which speaks mostly
of “agile fixed-price” contracts),
• https://www.mountaingoatsoftware.com/articles/writing-con-
tracts-for-agile-development (which takes a user story and conditions
of satisfaction approach to documenting contractual expectations), Responding to Change
• https://www.scaledagileframework.com/agile-contracts/ (addresses
this framework’s managed-investment contract), and
• http://www.agilecontracts.org/ (a 44-page extract from the book
Practices for Scaling Lean & Agile Development by Craig Larman and
Bas Vodde on contracts in an agile setting).

30
 UNDERSTANDING AGILE VALUES & PRINCIPLES RESPONDING TO CHANGE

Maybe nothing represents the traditional dictionary definitions of “ag- son states that Royce felt a waterfall approach “would not work for all
ile” more than this value. A typical definition reads “able to move quickly but the most straightforward projects” and how the rest of Royce’s paper
and easily” with synonyms being “nimble, lithe, supple, limber, acrobatic, addressed “iterative practices”.
fleet-footed, light-footed, light on one’s feet, alert, sharp, acute, shrewd,
astute, perceptive, quick-witted”. All of these imply an ability to change
with minimal effort, but there is something else implied.
Here are some thoughts from an article entitled “Mountaineering Train- Following a plan
ing | Body Awareness: Balance & Agility” which seem appropriate. (Also, There is plenty of agile-related literature about the difficulties and po-
the first article I remember reading about the agile approach was by Jim tential wastefulness of long-term, detailed planning when working in a
Highsmith comparing software development to climbing.) complex situation where change is inevitable and the ability to predict the
Body awareness is the combination of balance and agility that allows you to exact outcome desired is limited.
move comfortably and confidently through difficult and challenging terrain. Consider the typical project plan-creation approach of handing out a de-
Balance in mountaineering allows you to climb through challenging condi- tailed requirements document and asking people to estimate, in hours,
tions…while keeping your equilibrium and avoiding using excess energy or con- every task needed to produce the result described. This process of task-
centration to stay centered. Simply put, it’s being comfortable on your feet even ing and estimation takes many hours of effort itself. Eventually, all that
when you’re traveling through uncomfortable terrain. data is sent to a project manager who feeds it into a project-management
tool of some sort and, at some point, a project plan exists. That plan says,
Agility is being able to move quickly and easily — to be nimble and reactive…to for example, “Seven months from now on Wednesday at 3 o’clock, here’s
react to the unexpected…. what will happen.” Who believes that? Who can be sure the person who
provided the data to produce that result will really do the task that day?
...Both balance and agility are motor skills and can be improved over time. Everyone knows things will change and the project manager spends con-
So, it’s not just moving quickly, but maintaining stability during that siderable time each week of the project adjusting that plan.
movement. Responding to change in a meaningful, responsible manner This all assumes everyone understands what is being described and that
is not only about change but about directing that change toward greater the plan describes what the customer wants. But is it even fair to require
stability in the results. From a software perspective, it means change that (or assume) that people, especially the customer, can conceive of every-
produces a more satisfactory, useful delivery to the customer than before. thing and how it must work before anything has been designed or shown
It involves applying many faculties and skills, including alertness and per- to work? Then, as well as presuming this foreknowledge, can we also
ception to decipher the implications of the change, in deciding to change expect that once the considerable effort of doing all this definition and
and basing that on the best information available when such a decision is planning is completed (which by some estimates can consume up to 50%
to be made. It is not a license to be ad hoc or to do something when “You of the project schedule) nothing major should be expected to change or,
should know better.” (More on this in Chapter 15 on the ninth principle.) more critically, be learned?
From an implementation perspective, it means constructing a process for From sources in the history of military planning we have statements at-
working that allows change to occur with reduced risk and cost. An iter- tributed to people like von Moltke: “No plan survives contact with the en-
ative, incremental approach has long been accepted as the best way to do emy.” (He really said, “No operation extends with any certainty beyond the
this. In June 2003, Victor Basili and Craig Larman published “Iterative first encounter with the main body of the enemy.” The terse version seems
and Incremental Development: A Brief History” in IEEE Computer, in a bit easier to grasp at a glance, though.) We also have Eisenhower saying,
which they pointed out that this had been accepted 13 years before the “In preparing for battle, I have always found that plans are useless….” The
waterfall model that Winston Royce defined in his 1970 paper. Basili and ellipses, though, represents the remainder of Eisenhower’s quote, which
Larman have a lot to say about the waterfall model, including how Royce’s

32 33
 UNDERSTANDING AGILE VALUES & PRINCIPLES

is “but planning is indispensable” — which brings us to the agile approach

to planning which, like development itself, is early, frequent, and iterative.
It is the act of planning with the whole team involved that matters, not the
specific plan at any given time. Planning causes us to communicate, to col-
laborate, to build confidence and trust in how we will work to move in the
currently understood direction. Every day, an agile team has the chance
to see where everyone is and determine if where they are and where they
are headed needs to be adjusted in any way based on new information.

PART 7
Agile teams contribute to forming a release plan based on the known
functionality desired, how much of that the team believes it can deliv-
er each iteration, and how many iterations, therefore, it would take to
deliver all the known functionality. But things will change: teams may
get better at delivery; the customer may change what they want, having
seen some of the early working software; perhaps the business feels it
can release a valuable increment of software earlier than planned. And,
of course, it may be that not everything originally desired can get done
within the budget and schedule. But, using an agile approach, at least what Satisfy the Customer
does get done should be the highest-value functionality. (Refer to Chapter
5 for an example of an actual discussion with a product manager on this
topic.)

34
 UNDERSTANDING AGILE VALUES & PRINCIPLES SATISFY THE CUSTOMER

“Our highest priority is to satisfy the customer through early and contin- in the living room” and the “dead fish under the table”: those things every-
uous delivery of valuable software.” body ignores as they get their work done despite the “smell.”
This chapter begins 12 chapters, each addressing one of the Principles in
order as found at http://agilemanifesto.org/principles.html.

Early and continuous

Get working software into the customer’s hands right away. Keep doing
Our highest priority that every iteration and work collaboratively with the customer to get
feedback that lets you know they are satisfied with what they see and/or
Being agile means being dedicated, first and foremost, to satisfying the any changes they’d like made.
customer. This does not have to mean that “the customer is always right,”
but it does mean that the customer always deserves to be taken seriously. You want to start early so the customer is immediately engaged with you.
It also means that trying to satisfy the customer means both customer and There’s no going away for weeks or months while you do “infrastructure”
development team understand what that means and what both can do work and cannot show any actual customer functionality. You’ll lose the
to achieve that satisfaction. This brings us back to communication, col- customer’s commitment to be a part of the process and give you feedback.
laboration, commitment, continuous improvement, trust, and excellence. An agile iteration is expected to deliver customer-recognized value. Don’t
Achieving this highest priority won’t happen satisfactorily for everyone consider things agile iterations if they do not.
without pursuing these fundamental considerations.
You want to do this continuously to maintain customer engagement and
I suppose everyone’s heard the phrase (or something like it): “It’s hard to ensure no deviation from what the customer wants, even if they want
remember you’re supposed to be draining the swamp when you’re con- changes (in fact, especially if they want changes). Doing this requires
stantly fighting the alligators.” There are lots of things that can distract communication, collaboration, and continuous improvement while rein-
from remembering that your main goal is to satisfy the customer. There forcing commitment, trust, and excellence.
are other company priorities. There are organizational silo bureaucracies.
There are dependencies between teams. There are technology challenges. In this regard, active customer participation in iteration reviews/demos
There are the requirements themselves, which, in too much detail, can is crucial. (In a future chapter, I’ll say more about this review/demo in
actually obscure what’s truly needed. some detail.)

Remember that lean ideas are some of the roots of the agile approach. A
key lean idea is the elimination of waste, i.e., the elimination of anything
that does not directly contribute to the creation and delivery of customer
value. Doing a Value-stream mapping of your process can bring visibility
Valuable software
to where waste resides as well as assign quantitative impact them. This Who doesn’t want the software to be valuable? But there are a lot of fac-
is usually computed as time spent on each step of the process plus time tors that can go into what makes it valuable and what makes some fea-
spent (waiting) between steps. tures more valuable than others. Ultimately, value is in the eye of the be-
holder: the customer. This is what makes collaboration with the customer
You may believe that areas of waste are obvious, but perhaps not to every- so important in achieving satisfaction. What makes a piece of function-
one. A lot of the waste in an organization would not appear on a formal ality valuable to them? What will they expect to achieve by having such
process diagram. Honesty in communication is critical for this. You must functionality? How will things work better for them with it than without
be able to show what is really happening, not what everybody thinks is it? Understanding their value proposition for a piece of functionality can
happening. This will probably mean you have to talk about the “elephant

36 37
 UNDERSTANDING AGILE VALUES & PRINCIPLES SATISFY THE CUSTOMER

convey their sense of urgency/priority as well as better inform the devel- the team made the next iteration. Two iterations later, the database work
opment team how best to implement that functionality. was done and the “integration story” was accomplished successfully. The
fully live functionality was then demonstrated.
Despite this, sometimes other factors may affect priority more than pure
customer value. For example, I once worked with a team whose products It was not the purest way to work, but it upheld customer priority for
were used in nuclear power plants (among other places). They had to meet what they wanted to see while not misleading the customer about what
Nuclear Regulatory Commission requirements, which asked for substan- was and was not working. They, and the customer, felt this was the most
tially more documentation than other teams in the same company. That valuable approach possible.
documentation also had to be created and approved before work was sup-
posed to start on the functionality it described. Though the functionality
was of the highest value to the customer, there was a priority for that
team to create and approve the documentation ahead of the functionality.
Sometimes, the priority of various forms of compliance regulations may
override other, more directly functional value.
Even though you don’t want to delay working on things of value to the
customer, technology and infrastructure constraints may require that
some things must exist before one can show fully working software that
satisfies the customer. For example, if you need to make database changes
to support customer functionality, you could, while such internal work
is going on, develop the customer-visible functionality and get feedback
sooner than later. You would simulate the database and show the custom-
er what does work.
A team I worked with had to do just that. A customer requirement spec-
ified entering some (new form of) data and having the database respond
with some corresponding data that would be displayed. The database
work had to be done by a group outside the team and they weren’t going
to get to it for a few months. But the customer priority was to see the
functionality as the next highest-priority item. The team decided to break
that functionality into three separate stories: one to get the data from the
customer and send it to the database, another to get the data back from
the database and display it as the customer wished, and the third to inte-
grate the other two parts when the database group got around to making
the needed updates.
Now, the team could have pushed the whole thing out, but they felt that
would have been forcing the customer to deal too much with their orga-
nizational issues. So, they completed the first two stories, simulated the
database back end, and showed this to the customer at the next iteration
review, making sure the customer understood it would be two or three
months before the back-end work could occur. But the customer got to
see what they needed and had some suggestions for small changes which

38 39
PART 8
Welcome Change
 UNDERSTANDING AGILE VALUES & PRINCIPLES WELCOME CHANGE

“Welcome changing requirements, even late in development. Agile pro- However, if the customer does understand and accepts such impact(s), the
cesses harness change for the customer’s competitive advantage.” development team should make the requested changes. (It has been men-
tioned to me that this is no different than normal projects and the impact
of changes. This is true, except that one option is not supported by an ag-
ile approach as reasonable and that is to accept all changes without impact
to the cost, schedule, or other already defined scope.)
Customer’s competitive advantage
It’s appropriate that this is the second principle listed. Part of satisfying Ability to welcome change, however, can depend a great deal on the excel-
customers involves doing things that offer some advantage to their busi- lence in design of the existing system. If people cannot be confident about
ness. Building the right system (i.e., what the requirements state) is the system changes because the code is not well-designed and the tests for the
basic way to accomplish this, but what’s “right” at any moment can change existing system are inadequate or expensive (and slow) to run, developers
and that often means having to change the system in some fashion. It’s may be resistant to (or at least move more slowly in) making changes. If
important to remember how changing a system (including implementing you don’t feel you can go into the system, understand what it now does,
the stated requirements) provides value to the customer. Taking requests and make changes without fear of causing new or uncovering existing
for change seriously and not thwarting achieving better customer advan- defects that cannot easily be found, you will be more concerned about
tage is the point of this principle. making changes. At the very least, you may move far more slowly because
of that concern.
Change, of course, is easier when the system is easier to change. A tautol-
ogy, to be sure, but good technical practices will make changes easier. A
Welcome changing requirements couple quick examples of short development episodes and robust testing
might be helpful at this point, though.
Probably no developer exactly welcomes requirements that change on
them. Some discussion with a couple of the people who helped draft the One company I coached at was able to build and test their 40-million-line
Manifesto suggested that the spirit of this principle meant that the devel- system every night because they had invested significantly in automat-
opment team should not create unnecessary barriers to change by simply ed testing. (Indeed, I have not seen any large development effort get the
resisting such requests. Yes, they just spent a lot of time and budget to try productivity gains they hope to see from agile development without ro-
to make the system as correct as possible based on prior customer feed- bust automated testing.) One team at the core of the system’s function had
back, but the customer wants a change. If the customer understands and 20,000+ tests they ran nightly so they could be confident every morning
accepts the consequences of such a change, the development team should that their work should not impede other parts of the system.
work to make that change possible.
Another company had a smaller, but no less technically complex, system
Of course, the consequences could be that such a change will: of 1.5 million lines. They built and tested every two hours. If a developer
checked in any code and associated tests (which they had to include) with-
• extend the planned deadline (if the customer still wants everything in any two-hour period, at every two-hour mark, the system automati-
else they already expected to get within the original deadline), cally built and ran all tests, prior and new. If that automated run did not
• increase the budget (also if they still want everything else), happen for four hours, management would come around and ask why.
• push some previously expected functionality out beyond the current They expected small increments of new functionality to be put into the
deadline and/or budget (to stay within the deadline and budget), and system that frequently and proven to leave a stable system state. If it did
• affect architecture/design so that it limits future options (which is not, pulling out the troublesome code was easy for them. (I am reminded
less easily explained because of the more technical consequence it of the character in the movie Kelly’s Heroes, who, describing how fast his
represents). tanks can go in reverse, says “We want to know we can get out of trouble
even faster than we got into it.”)

42 43
 UNDERSTANDING AGILE VALUES & PRINCIPLES

Both organizations, each morning or two-hour cycle, knew the stability

of the system. You can make changes far more confidently if that sort
of visibility is possible. The longer the time between code creation and
testing, the larger the risk and the more slowly development may occur.

Late in development

PART 9
If developers don’t like change, they certainly won’t like it late in a re-
lease/project. A well-designed, easily tested system will mean that even
late changes (assuming understanding and acceptance of consequences)
should not cause great concern. The iterative nature of agile development
allows for considerable opportunity to review the state of the system and
make changes earlier rather than later through the opportunity to see and
provide feedback on working software at the end of every iteration. This
is typically not the case in a more “phased sequential” (a nice term for
“waterfall”) approach where the true state and adequacy of the system is
not seen until late in development.
Deliver Frequently
The dislike for change, and especially late change, derives from this tradi-
tional way development and change happens. Much time and budget has
been spent creating and implementing the rather detailed requirements.
Many design assumptions have been based on the initial understanding
of those requirements. Late changes usually mean much time and budget
will be spent going back and updating and correcting intermediary deliv-
erables, not just the code itself. While this is happening, technical work
may come to a halt, at least in parts of the system, and people will need to
shift to other work to keep busy. Then they will be asked to shift back to
where they were and make the changes. Multitasking and interruption in
flow leads to loss of productivity in pure terms because of time wasted,
but it also impacts people’s sense of accomplishment and satisfaction in
work.
Of course, under pressure to make changes fast, people may get the work
done by skipping certain quality practices (e.g., code reviews and unit
testing), working (a lot of) overtime, and skipping updating the documen-
tation. Naturally, all these can be bad ideas. I’ve mentioned the latter al-
ready in Chapter 4 of this series. I’ll get to the other two in later chapters.

44
 UNDERSTANDING AGILE VALUES & PRINCIPLES DELIVER FREQUENTLY

“Deliver working software frequently, from a couple of weeks to a couple though the Wikipedia article seems to have had numerous updates over
of months, with a preference to the shorter timescale.” the years. The dynamic systems development method (DSDM) remains
an active community that recommends the shorter timescales, though
it has rather voluminous online documentation in two sets: DSDM and
Atern. (The latter is described as “a framework based on best practice and
lessons learnt by DSDM Consortium members” and is the current form
Deliver working software of the DSDM approach. Commercial books date back to 2002.)
frequently
Chapter 7 discussed “early and continuous delivery” and Chapter 4 dis-
cussed working software. The “frequently” part was implied in contin-
uous delivery when I said “Get working software into the customer’s Why the short iterations?
hands right away. Keep doing that every iteration….” What I didn’t say For some, the idea of putting out, at least for customer review, working
was how long an iteration would be. I don’t know too many agile coach- software every few weeks (let alone every week like XP teams do) seems
es and trainers who aren’t encouraging clients to consider no more than inconceivable. And that does mean what I think it means: “not capable of
two-week iterations. That was not the case when the Agile Manifesto was being imagined or grasped mentally; unbelievable.” I would recommend
written. that most agile teams start with two-week iterations. I believe it takes
three to four iterations before teams begin to understand what it means
to work together in an agile fashion. A team may as well get those over
within a couple months rather than up to four months. You can always go
From a couple of weeks to three or four weeks later if that seems necessary.

to a couple of months Mike Cohn, one of my CSM trainers along with Ken Schwaber, has said
that when Scrum teams have come to him asking to extend their Sprints
When the Agile Manifesto was written, the various “lite” approaches had from four weeks to, say, six weeks, he says, “Let’s try two-week sprints
cycles from one week to three months. The phrase you see here was, it instead.” They feel they cannot get things done in four weeks and want
seems to me, a compromise among all the people involved. With people more time. Cohn says, in effect, let’s figure out how much you can really
from XP, Scrum, and like-minded approaches being about half the attend- get done in a couple of weeks. The idea is that if you can’t reasonably pre-
ees, I can believe a phrase such as “from one to four weeks” could have dict what can get done in four weeks, what are the odds you can predict
made them happy. That would not have worked for everyone, though. getting potentially more done in six weeks?
I worked with a team once that, because of the company policy, was ex-
pected to work in four-week sprints (because that’s what was in the origi-
nal Scrum book and what trainers were saying a decade ago). They want-
With a preference to the ed to set a shorter target for getting things done for themselves. While
shorter timescale working in four-week sprints as far as everyone else was concerned, they
established a planning approach that targeted weekly goals for having
This phrase, closing out the principle, represents those supporters of a working software.
shorter timeframe and perhaps the recognition by the others that this
seemed to be the direction things would head in. These days, there is Also as I mentioned in Chapter 4, there was a team that worked to get
not a lot written or heard about the approaches with longer cycles. Fea- functionality broken into pieces they could complete every two to three
ture-driven design seems to have had the last book written about it in 2002 days. Neither of those teams ever failed to deliver on their sprint goals and

46 47
 UNDERSTANDING AGILE VALUES & PRINCIPLES

they were not sliding through on easy effort commitments. Indeed, they
seemed to find it easier to get more done by defining smaller amounts of
work.
Another advantage, but also a challenge, of shorter iterations is the op-
portunity for more frequent feedback from customers about what the
team has done in the past few weeks. The problem is that customers (and
internal stakeholders) are likely not used to such frequent demands on
their time to interact with the team. I’ll have more to say about this in the

PART 10
next chapter.

Working Together

48
 UNDERSTANDING AGILE VALUES & PRINCIPLES WORKING TOGETHER

“Business people and developers must work together daily throughout one to four weeks, there isn’t much time to wait for answers to questions.
the project.” Hopefully, answers to questions can come in, say, no more than 24 hours.
Any greater delay may mean functionality does not get done during the
iteration or, worse, teams will guess what might be intended/needed and
spend time developing the wrong thing.
Business people and developers Customers may not have experienced, anticipated, or prepared for this
The term “business people” can include people with job titles such as cus- level of commitment to working with teams. In this case, some intermedi-
tomer, end user, product owner, project manager, product manager, exec- ary may need to exist (e.g., the product-owner role in Scrum). That person
utive, business analyst, or subject-matter expert. Sometimes this is gener- must know enough about what is wanted to provide/get answers rapidly
ically referred to as “the customer.” It’s anyone who wants some amount based on their understanding of the desired functionality (as expressed in
of functionality created and would communicate their ideas for that to stories).
those who will create that functionality. They own the project’s vision Sometimes this role is filled by more than one person due to the work
and roadmap, create/gather requirements, help manage the requirement required, but a team should only have to listen to one “voice.” It will be an
backlog, provide acceptance criteria, elaborate on requirement details, impediment to team effectiveness if they have to sort out the opinions of
and provide feedback on work done by the development team. many people to figure out what is wanted. The job of the intermediary is
All the very earliest agile teams consisted primarily (if not completely) of to provide that voice.
software developers who did design, wrote code, tested, and documented Proactive teams and product owners include plans for regular communi-
results. Therefore, the term “developer” has come to represent anyone on cation during iterations if ad hoc daily communication is an issue. I have
a team who contributes actual effort to some aspect of the deliverable seen teams and their product owners meet weekly to go over future (and
functionality. The Scrum Guide used to say that the only title on a de- current) work to prevent too much time elapsing between actual commu-
velopment team was “developer” to emphasize avoiding siloed behavior nication. The need for ad hoc communication is certainly going to occur,
on the team. The latest version now says, “Scrum recognizes no titles for but if the product owner is separated by substantive time and distance
Development Team members, regardless of the work being performed by from the team, more formally planned communication is necessary. The
the person.” One would expect people on the team to have (had) titles goal, however, is to avoid simply falling back on sending text-based com-
such as developer, business analyst, quality analyst or tester, tech writer munication for everything because actual talking is too hard.
or documentation specialist, user-experience designer, or database ana-
lyst. These people have the responsibility to estimate user stories, assist in
story refinement (what some call “backlog pruning”), participate in itera-
tion planning, commit to and deliver on the iteration goal(s), review and
demonstrate each iteration’s accomplishments with the customer, and Throughout the project
perform continuous improvement. Though tightly coupled to daily communication, having customers en-
gaged throughout the entire development time is a further challenge for
many organizations. The following diagram suggests what a client/proj-
ect manager may expect their attention commitment to be in multiple,
Work together daily overlapping waterfall projects. They spend considerable time up front
during requirements definition and clarification, then expect to go away
If an agile effort is to focus on “working software over comprehensive during implementation, and finally return at the end of the project to re-
documentation”, the expectation is that a lot of what is represented in view results.
traditional requirements documentation will be communicated verbally
and acted upon very soon after that. If a team is working in iterations of

50 51
 UNDERSTANDING AGILE VALUES & PRINCIPLES

Attention expectation by customers, based on waterfall experience.

People probably recognize the danger inherent in such long periods with
little or no communication. However, the traditional waterfall approach
presumes behavior like this, trusting in the adequacy of fully defined doc-
PART 11
Motivated Individuals
umentation to serve as the major communication approach.

52
 UNDERSTANDING AGILE VALUES & PRINCIPLES MOTIVATED INDIVIDUALS

“Build projects around motivated individuals. Give them the environ- trying to push a bunch of new practices (the square peg) into the existing
ment and support they need, and trust them to get the job done.” organizational approach (the round hole). This is the reason I think an
appreciation for what the agile values and principles have to say is so im-
Before I even get into the elements of this principle, I should say how I portant for an organization contemplating the transformation to an agile
have heard people react to it. I have spoken about and trained people on way of being (and doing). Part of that appreciation is that it is a transfor-
the values and principles many times. When I get to this one, I have heard, mation, not just a transition. It’s a change to the environment and system
more than a few times, a comment like “Well sure, if we could do all that, within which people work, not just sliding in new titles and ceremonies.
things would be great.” I ask them why from an agile perspective don’t/
can’t they do that then. Making these things true is an important contin- Sometimes, when people think of “environment”, they think of the physi-
uous-improvement goal, especially for management. cal structure and the move to open workspaces with no permanent walls
and totally moveable furniture. There has been plenty of criticism of such
structures. I’ve seen it work (in various forms) both wonderfully and not
so wonderfully. But I’ve seen that with more typical office and cube struc-
tures as well. The idea of the open space was to cut down barriers to the
Motivated individuals frequent interaction and communication assumed in agile teams. Not ev-
I’m not going to talk about how to motivate people. You’ve probably eryone is comfortable working that way, and I have certainly seen teams
heard talks like that. I’ve given talks like that. When I was asked to do that worked well without this. If the motivation to communicate, collab-
such a talk at one company, I heard the best comment on doing such talks. orate, improve, trust, and pursue excellence is there, people can work in a
I used to sit right by a VP in software development who said to me the variety of physical spaces.
day after I got the request to do such a talk, “Scott, we don’t need talks on
motivating people. We need to figure out how to stop demotivating them.
People don’t come to work here demotivated. What do we do to them
after they get here that people seem to feel we need to figure out how to
motivate them?” He was right. I still did the talk but it became a workshop
Trust them
on avoiding demotivational behavior. Maybe this is the hardest thing in the principle to achieve. Much orga-
nizational structure and process, as I noted in Chapter 2, seems to exist
W. Edwards Deming, in his book Out of the Crisis (1986), said, as part of because trust isn’t present. I’ve certainly seen examples of this.
one of his 14 Points of Total Quality Management, “Remove barriers that
rob people of pride of workmanship….” If you are not familiar with Dem- Before I became involved in agile methods, I worked at a place where the
ing’s work, you should look at it and understand his impact on quality and company president’s view of quality was that, “Some people just don’t do
productivity. The Japanese did, and so respected what he taught them that their work right. If we could find them and get rid of them, we’d be fine.”
in 1951, Japan named their national quality award after him: the Deming His view was that poor quality was about individual moral failure to per-
prize. form properly. He had turned what Deming decades before had treated as
an objective, engineering system matter into a moral, subjective, personal
one.
Many years before that, I gave a lecture on quality and process at a local
Environment and support university’s MS in software engineering program. I was asked how cheap-
If teams are going to be asked to deliver high-quality results to customers, ly one could expect to hire people if the process was rigorous enough.
then they should be given all they need and every opportunity to do that. That is, if we don’t want to trust/expect much competence from people,
It’s as simple as that. “But you don’t understand the reality here,” I have how inexperienced (and cheap) a staff could a process let us get away with?
heard people say. Becoming agile is about changing that reality, not just

54 55
 UNDERSTANDING AGILE VALUES & PRINCIPLES

The way many organizational processes grow over the years is often due
to similar thinking. When something goes wrong in a project, it’s often
decided to prevent that from happening again by instituting some more
rigorous rules/oversight procedures. Over time, the process bureaucracy
grows and grows bit by bit until more time is spent adhering to process
regulations then developing the product.
Kent Beck has said (and I’m paraphrasing a bit) that software development
is like “driving a car, not aiming a bullet.” Rules of the road and various

PART 12
traffic indicators exist as a framework within which we hope most people
can safely drive. We expect people to take a constant inspect-and-adapt
approach as things may unexpectedly happen and demand a more im-
promptu response than planned. On the other hand, once you fire a bul-
let, you’ve lost control over it, so a lot of up-front planning is needed.
Now, we could try to restrict people’s driving mistakes by building all cars
and roads like the old speedway ride in Disney parks where you cannot go
very fast, there are thick bumpers all around the car, and barriers channel
the path you can follow. Some organizational process seems a lot like that. Face-to-Face Conversation
I believe methods should be designed for people who know how to drive
rather than those who do not. Deming said that, in most cases, it was the
system people had to work under that needed to be reformed rather than
the people. Of course, some people need to change how they work and
Deming did address training people who need to perform better.
A great deal could be said about trust. But look at your existing process-
es (do a value-stream map as mentioned in Chapter 7) and ask what the
impact would be if teams were allowed to manage each one themselves
or between one another. Maybe it’s a trust issue if you find this incon-
ceivable.

56
 UNDERSTANDING AGILE VALUES & PRINCIPLES FACE-TO-FACE CONVERSATION

“The most efficient and effective method of conveying information to and rather than aggravated it; only 17% of those same people initially felt that
within a development team is face-to-face conversation.” pursuing agile would help in this regard.
This chapter, addressing communications modes, will comment upon For now, let’s just look at some of the modes and what they represent. It
distributed team issues, daily meetings and iteration reviews as examples is interesting that paper (text forms of documents) ranks the very lowest
of “conversations” that occur. on this scale yet is traditionally the most commonly (even highly) regard-
ed approach to (archival) communication. Projects spend a great deal of
time and money generating requirements specifications, architectural
designs, and lower-level detailed designs before they get to implement-
ing anything. Each of these usually involves many people in collecting
Modes of communication the information then reviewing and approving it, believing this due dili-
In Chapter 3, I showed this diagram and promised to get back to it. gence is the necessary and responsible way to plan and execute a project.
Alistair Cockburn had studied teams and came up with this spectrum of Of course, a major assumption is that people can think of everything up
communication modes and what he saw as their comparative effective- front and not change their minds much later. This is the classic waterfall
ness. (Other versions of this diagram that I have seen label the two lines or phased-sequential philosophy enshrined in traditional project man-
as “non-interactive” and “interactive”.) Clearly, the “question and answer” agement. The agile approach believes that this is not true and that it is
modes are shown as having higher effectiveness and richness. unreasonable to expect people to be able to do this. It is not some form of
moral/professional failure when they cannot.
One lifecycle model illustrating this approach and matching it to the ver-
ification/validation expected at each phase is the V-model as found in a
StackExchange discussion. Each phase of system specification is matched
with a testing approach that indicates the focus of the testing taken to
complete the system at that level.
At the other end of the diagram is “2 people at whiteboard,” represent-
ing the face-to-face, real-time interaction highly prized in being agile.
People can see one another, which dramatically increases richness since
more information is often conveyed by what we see than what we hear
(including being able to draw on that whiteboard and rapidly make ed-
its). When you are right there with other people, you can see quizzical
looks or when it seems someone might need to say something. You can
also avoid most clashes in trying to speak, which most people would like-

Comparative effectiveness of communication modes.

Perhaps most people can agree with the intent of this diagram, but some
will point out, “Sure, but we have distributed teams.” I’ll get to that, though
it is interesting that the VersionOne survey, run over many years, indicat-
ed in their 12th annual survey that about 40% of the respondents felt that
adopting an agile approach improved their distributed-team experience

58 59
 UNDERSTANDING AGILE VALUES & PRINCIPLES FACE-TO-FACE CONVERSATION

ly say is better than trying to conduct such a discussion when people: the session. (It was that long ago. There are certainly better video options
these days.) We’d copy the tape and send one to each stakeholder location.
They would watch the tape then communicate their thoughts back to us
and we could incorporate those ideas into the (ultimately still required)
design documentation. What was important was that the stakeholders got
to hear everything, not just what we thought was important to document.
This included things we might breeze by but the stakeholders picked up
on and never would have heard if we’d have sent our version of what they
should know. This led to changes that could have only been noted months
later when a lot of work had been done and the stakeholders got to see
some working software.
You must decide what modes work and when for your own situations, but
always ask whether it would be possible to move up and to the right on
Cockburn’s diagram.

Distributed teams
This principle does not say people must be co-located, only that it al-
• cannot see one another; lows the most effective communication to occur. If you are going to have
• forget they are on mute and talk then must start again when remind- discussions among people who are not together in the same room, use
ed they are on mute; some form of video. These days, it doesn’t cost much at all to add a USB
• do other things while supposedly listening and then ask for things to camera if people are not at a machine with one built in. Unfortunately,
be repeated; and I’ve worked with teams who went months without knowing what one
another looked like. My first suggestion was to get pictures of everybody
• try to talk at the same time then go silent, try to be polite and tell one
at least. When these teams did get video going, the changes in the discus-
another to go ahead and speak, then wait in more silence until finally
sion were clearly observable. People felt okay in calling on one another,
someone does.
recognizing those puzzled/worried looks. People’s attention, or lack of it,
Email is at the very bottom of the Q&A line (and can include any form of to the meeting could be noticed and they could be invited back into the
text messaging). It is interactive in a sense, but not at all guaranteed to be discussion. Putting faces to the disembodied voices over the phone helped
real-time and it has its own issues. Some people like the long email dis- with team spirit, which led to increased trust.
cussion thread as a form of standard documentation. Some like it because
But the key imperative for me is that we never let anyone go dark. That
it guarantees others cannot deny what was said (which suggests trust is-
is, we make sure everyone feels included in the team and has their chance
sues). Some like it because they don’t have to deal directly with other peo-
to contribute to the team. We don’t fall back on what’s easier to do (i.e.,
ple (see the “cube farm” example mentioned below).
go down and to the left on Cockburn’s diagram). This may mean getting
As to the non-Q&A modes, I’d like to describe an example of videotape some input/feedback using more text-based approaches, but sparingly.
being used at one place I worked. Instead of having someone at a design
One US-based team I worked with had never had any distributed mem-
discussion taking notes, writing them up, circulating them for edits/ap-
bers. Then, they added two team members in India. The US team held
proval, then sending the document to clients for review, we videotaped

60 61
 UNDERSTANDING AGILE VALUES & PRINCIPLES FACE-TO-FACE CONVERSATION

daily meetings at 8:00 a.m. local time, which could not occur earlier due simulate face-to-face contact rather than fall back on purely text commu-
to childcare considerations. During the non-Daylight Saving Time of the nication.
year, that would be about 7:30 p.m. in India. Most companies in India
when they work with US companies will shift their work hours from per- I should mention an extreme example of distribution that I have wit-
haps 10:00 a.m. to 7:00 p.m., so the stretch to 7:30 p.m. wasn’t so bad for nessed more than once. I’ve been in “cube farm” environments where
the two people in India. Sprint reviews were held at 8:00 a.m. as well and people sat in rows at cubicles walled off in front and to the left and right.
often ran until 8:30 p.m. in India, but that was once every four weeks, so If you stood up, you could see over the partitions, but sitting down, it
still not too bad. could feel like other people did not exist. In such cases, I have seen people
send emails and text messages rather than get up and go to a cubicle near
Since retrospectives followed the sprint review after about a half-hour them. It didn’t take 30 meters of separation. Sometimes, it was hardly 30
break (by then, 9:00 p.m. in India), the US folks and their Scrum Master centimeters.
agreed that the folks in India did not have to stay on a call (or call back)
because it could be 10:00 p.m. in India by the end of the retrospective. Another such process consideration is to never let people go dark — i.e.,
I heard about this and told the Scrum Master and local team members make sure everyone on a distributed team knows what is going on in the
that they can’t do that.” (They were used to me and saw this as an oddly same way that a face-to-face daily meeting could. For example, I once
directive statement coming from me.) When they asked why I said “can’t”, worked with a team where:
I simply told them that they could not exclude the members in India from • the product owner was alone in Denmark,
the retrospective process. They at least had to get the input from those
• a developer was alone on the East Coast of the US,
two people before the meeting if the two of them could not be in the ret-
rospective. • a developer and tester were together on the West Coast,
• a few developers and testers were together in India, and
Sometimes as a coach, I get lucky. The next retrospective, that’s what
• the Scrum Master was alone in Singapore.
happened. Text input from the people in India was sent to the US and
was included in the topics discussed by the US members. At the end of It was the most distributed team I’ve ever worked with yet among the
the retrospective, the highest-priority improvement item selected was most effective and satisfied in their distributed form. The Scrum Master
one of the inputs from India. The US members acknowledged that they and I (as coach) were on two meeting calls each day: one in the morning
wouldn’t have come up with this on their own, but, discussing it, agreed (Pacific time zone) and one at night (Pacific time zone). At the end of each
they should really work on that item. meeting, the Scrum Master would email a short set of notes to everyone
on the team about what each session had discussed. People on the team
then proactively got in touch with one another when they needed to ex-
change more detailed information. It was not ideal, but they made it work
Dealing with distribution because they committed to trying to communicate more effectively rather
than falling back on creating and sending formal documents.
To overcome the disinclination to move even short distances to speak face
to face, one place had a rule that, after going back and forth three times From my perspective, the absolute minimum would be to make sure peo-
with emails or texting, people had to get up and go talk to the other per- ple can see one another whenever they meet over a distance. The use of
son. If the distance prevented physically going there, people should call video dramatically improves the relationships among the people on a
the other person or use some video-based technology to contact them team. Seeing one another puts a face and a real person to an otherwise
for real-time communication. If the time difference was also large, then disembodied voice over a phone line. This increases the sense of being a
people should schedule a time when video communication could happen real team, which improves the collaborative inclinations and trust. Today,
and speak in real time that way. The idea was to make the effort to at least there is no reason not to have video in a meeting.

62 63
 UNDERSTANDING AGILE VALUES & PRINCIPLES FACE-TO-FACE CONVERSATION

speaking. They complete their daily meeting within that 15-minute time-
Daily meetings box. People cover their three main statements in 15–20 seconds each on
You can read a lot about the purpose of the daily (standup) meeting as well average, making it easy for 25 people to finish in 15 minutes.
as what it isn’t (i.e., not a status-reporting session nor a problem-solving
one). Personally, I view it as the team’s opportunity to make sure everyone
knows what’s going on within the team and, hearing all that, deciding if
there is any need to make changes in the sprint plans. At the end of the
meeting, I would want every team member to feel comfortable with the
Iteration reviews
plan going forward for the rest of the iteration. The forms of data that the This meeting, held the last day of the iteration, is for the development
team might collect in the meeting would be things such as: team to show to all stakeholders what they have accomplished in the it-
eration. It is an opportunity for those stakeholders to hear from the team
• what each person says about what they did since the last meeting, and for the team to get feedback from the stakeholders. The team can hear
what they plan for that day, and any things in their way (the classic directly how the stakeholders feel about the work that is presented. Any
three items recommended for such a meeting); changes needed can be identified and put on the product backlog for a
• the state of the team’s progress using some quantitative assessment future iteration. There are, however, some things I’d suggest people keep
(e.g., a burn-down chart); and in mind about the meeting.
• input they may request from people outside the team (who may or
Generally, the team members demonstrate their work, but there can be
may not be present at the meeting).
occasions when it would be appropriate for a product owner to do so
This last point raises the question of who participates in this meeting. It is (assuming the product owner has been closely in touch with the team
specifically for the development team, with their Scrum Master/facilita- and knows how to do so). This might be because of language differenc-
tor helping (especially by keeping a “parking lot” of items to discuss after es between team members and stakeholders or because a product owner
reaching the daily meeting’s 15-minute limit). It is not a secret meeting, knows better how to speak in stakeholder terms. (If this latter point is
so I have seen product owners there, people from other teams present, true, I would suggest an improvement item would be for the team to learn
myself standing by, and even management sometimes observing. But all more about how to engage the stakeholders at their level so no intermedi-
of us not on the development team keep quiet unless we are asked to com- ary is necessary in the meeting.)
ment. If we really want to address the team, we should contact the Scrum
The meeting is not for internal people (e.g., managers within the develop-
Master ahead of time who, with the team, could decide if such a request
ment company) to engage in debates with one another in front of other
should be fulfilled at the meeting or afterwards. (If they decide they want
stakeholders or to ask, because they have missed some prior reviews, that
to say something during the meeting, they could ask if there might be
prior issues be restated/explained for them. I’ve seen both things happen
time for their comments at the end.)
more than a few times. The product owner or Scrum Master/facilitator
After the meeting, the Scrum Master/facilitator can point to the parking needs to step in and, as politely as possible, cut this sort of thing off and
lot if there are any notes there, and the team can decide who must be deal with it outside the public forum of the iteration review.
present and how to address any issues noted. With a distributed team, the
Sometimes, especially when people are calling in to the review rather
invitation to the call might indicate 30–60 minutes, but the first 15 are
than being in the room with the team, the response from stakeholders at
reserved for the daily meeting. The rest of the time is to allow for other
the end of a particular demo of functionality or at the end of the review
discussion when and if necessary, not an indication that the daily meeting
may be little more than “nice job” if not, in fact, dead silence. That’s not
will take all that time.
much feedback for the team to. The product owner, (supposedly) know-
I know of at least one organization of around 50 people where all staff ing the stakeholders, should try to encourage more substantive feedback.
participate in the daily meeting. They work in pairs, so it is like 25 people They can ask specific stakeholders to comment on something they know

64 65
 UNDERSTANDING AGILE VALUES & PRINCIPLES

was of major interest for that stakeholder, politely putting the stakehold-
er(s) on the spot, as it were, to say something. Discussion at the review is
important. It should not be a one-way show-and-tell session by the team.

PART 13
Working Software… Again?

66
 UNDERSTANDING AGILE VALUES & PRINCIPLES WORKING SOFTWARE… AGAIN?

“Working software is the primary measure of progress.” ect has been completed at any time. As you will see if you check Wiki-
pedia, there are a variety of numbers that can be calculated and used to
Wait… wasn’t working software one of the Agile Manifesto’s values? Yep. compare planned to actual progress.
So they repeated it again. Yep… they did.
The agile approach simply takes the position that progress should be mea-
I asked one of the manifesto authors about this and his first comment was, sured based solely on how much working software exists at any point in
“Well, we thought it was important enough to repeat.” time. One could use story points, for example, instead of hours or dollars
Of course, it isn’t exactly a repetition. The value states the preference for as the baseline number. As the team completes requirements, the value
having working software over only having comprehensive documenta- is expressed in completed points and you can compare that to the total
tion. This principle states that working software is the main progress points for the entire project/release to compute percent completed.
metric.

Burn-up chart
Measuring progress One common visual tracking approach for this is a burn-up chart. The
Progress in projects traditionally has been measured by completion of diagram shows a simple form of this.
tasks in the project plan and how closely that tracks to expected com-
pletion: i.e., numbers of tasks completed and whether they complete at
the time originally estimated. In a traditional waterfall project, a substan-
tial number of tasks will be completed before there is any actual software
working, i.e., before functionality is designed, coded, reviewed, tested,
and documented. Indeed, a project schedule can be from two-thirds to
three-quarters completed (with all the associated tasks) before there is
any software verified and validated.
One approach to traditional tracking that associates tasks done with proj-
ect value is earned-value measurement. Very simply, one assigns a dollar
value to tasks based on the hours estimated and an estimated cost paid for
those hours of work. This can mean something like deciding the cost per
hour paid to a person who performs such tasks and multiplying that by
the hours assigned to the task. Or it may mean taking the total estimat-
ed cost of the project (however that is computed) and dividing it equally The vertical axis represents story points while the horizontal one rep-
across all the tasks based on the percentage of hours each represents for resents time (in this case, days in the iteration). The red line is an ideal or
the entire project. Either way, this gives a value for each task performed. baseline drawn from zero story points done at the start of the iteration
As a task is completed, its value is earned, accumulating throughout the to the total number of story points planned for the iteration (35 in this
project. example). The blue line tracks the actual number of accumulated story
But this doesn’t, and nobody suggests it should, represent value delivered points completed day by day in the iteration.
to the customer. It just means, given that every task is needed, that tasks From this, the team and product owner (and anyone else for that matter)
and hours spent can be used to track percent completion. Hence, it is a can see the progress the team is making toward completing all the stories
progress measurement since it shows how much of the work of this proj- they planned for the iteration. Being under the ideal (red) line means the

68 69
 UNDERSTANDING AGILE VALUES & PRINCIPLES WORKING SOFTWARE… AGAIN?

team is behind in completing stories. Being above the ideal line would Sample items that might be found in a definition of done would address:
mean the team is ahead. The chart does not explain why a team might be
behind or ahead, just that it is. • design tasks to be performed,
• coding needed and coding standards to be used,
From a product owner’s long-term view, the chart could show total points
• unit testing expected,
for an entire project/release with the time element being iterations in the
project/release rather than days in a single iteration. Both forms can be • peer (or other) reviews to be done,
used. If a team has relatively small-sized stories that they complete reg- • user documentation to create or update,
ularly, a chart of daily iterations produces a somewhat smooth-looking • successful build and test runs,
graph. If the team has larger stories that take many days to complete, you • customer acceptance criteria met (often called conditions of satisfac-
get a more stepped graph, which means that the graph is flat for days at tion),
a time until a stories get done, and then it jumps up as those points are
• non-functional requirement expectations for things such as perfor-
recorded. The full project/release version will produce a stepped graph
mance and security, and
since points are only recorded at the end of each iteration, but it will be
a smaller-looking jump each time given that the chart tracks an overall • any internationalization and localization concerns.
larger baseline of points. Such criteria would be expected to be used for any requirement, though
(I should note, however, that simply counting stories completed com- some may not need all the criteria, and some might need additional cri-
pared to total stories for the iteration/release is another approach used teria.
without using points. Such an idea can be found described in: Having met the criteria, the work would be shown at the next iteration re-
Do You Need to Use Story Points to Track Velocity – an IBM article view for approval by customers/stakeholders, and the story points would
be counted as completed. This would be the measure of progress, regard-
How estimating with story counts worked for us – a ThoughtWorks ar- less of other possible deliverables that might (have to) be generated to get
ticle to this point.
Story Counting – a Martin Fowler blog post
Stop Using Story Points – a Joshua Kerievsky blog post
How to Enable Estimate-Free Development – a Dave Rooney blog post)

Definition of done
Briefly, to claim that you have a piece of working software, all the quality
criteria established are expected to be met. This set of criteria is typically
called a Definition of Done. If all the criteria are met, everyone on the
team agrees that the requirement is done. Teams should have agreed upon
such a set of criteria (at least as an initial example) before starting any
work. During a project/release, they will likely adjust the criteria, perhaps
formally reviewing it as a part of the retrospective.

70 71
PART 14
Sustainable Development
 UNDERSTANDING AGILE VALUES & PRINCIPLES SUSTAINABLE DEVELOPMENT

 “Agile processes promote sustainable development. The sponsors, devel- worked iteration after iteration (13 a year using a four-week iteration
opers, and users should be able to maintain a constant pace indefinitely.” length) and been through well over 125 such iterations. The ability of
team members to work together smoothly and effectively is an asset to
the company. Deliberately splitting the people up, scattering them to oth-
er efforts, treats them like an inanimate resource that can be shifted with
no loss to the essence of what that resource represents.
Sustainable development
Sustainable development is a development approach that can be conduct- The challenge to an organization is to maintain such teams. This is far
ed over time without burning people out. Agile advocates avoiding man- easier in a product-oriented company than in a project-oriented one. At
dated overtime. If the latter exists, people are not taking a reasonable ap- the end of most projects, teams may routinely split up as people are as-
proach to planning work. Some might say, given how their organization signed to new projects. In a product environment, the team stays with
works, that this ignores reality. As I mentioned in Chapter 11, agile does the product, release after release, building significant domain expertise as
not ignore reality but aims to change reality. well as growing their skills and ability to work together. I have seen such
teams plan with very few words exchanged other than those that help
It is not merely the agile view that it’s a bad sign to have to routinely clarify the functionality they are to create during the upcoming sprint.
employ overtime to meet a deadline. At least by 1997, one of the main Someone will say, “I can handle that” and that ends the discussion on that
proponents of classical software methodologies noted how common the point. They have learned that when anyone says something, they mean
so-called “death march” projects were. The Project Management Insti- it and will do it, and they also know that if they need help, other team
tute also identifies such an approach as undesirable, citing an article de- members will support them. Communication and trust are high on such
scribing many signs of project trouble related to the death-march men- teams (though the verbiage needed to communicate is low as much is
tality. “said” through actions, not words).
A particularly scary sign is when a project starts with overtime already What may be more challenging is the ability of sponsors and users to
required to meet the deadline with all the functionality expected. What maintain such a pace because such a steady commitment to work with
happens when the unexpected happens during the project? Where does a development team is not usually something they are used to doing (as
the time come to handle that? Even more required overtime? noted in Chapters 9 and 10).
Tom DeMarco wrote an interesting book (Slack: Getting Past Burnout,
Busywork, and the Myth of Total Efficiency) just as the agile movement
was getting started (2001) discussing filling (and overfilling) people’s time
and what that means for effectiveness, including the impact of multitask-
ing.

Constant pace indefinitely

The idea of a constant pace is the idea of working within a predictable
rhythm, which the agile iteration and its various elements (i.e., iteration
planning, daily meetings, reviews, and retrospective) offer. I have worked
with teams that have continued together (with not very frequent person-
nel changes) for almost a decade. They are still going. These teams have

74 75
PART 15
Technical Excellence
 UNDERSTANDING AGILE VALUES & PRINCIPLES TECHNICAL EXCELLENCE

The first eight principles in many ways describe what might be viewed as Testing practices are another area where becoming better will lead to
the organization helping to make the work of teams more effective and greater agility. Being able to test frequently and easily will encourage
less stressful. The last four principles, viewed in one way, are specific ob- more complete test coverage and help ensure new changes do not break
ligations for teams to pursue to respond in an agile fashion. existing functionality. (Recall the two company examples about frequent
testing in Chapter 8.) With today’s IDEs, there is considerable support to
“Continuous attention to technical excellence and good design enhances do this at the team level. This would reduce the likelihood that defects
agility.” escape the team’s iterations and cause problems (and rework) further into
the project/release.

Continuous attention
Part of the urgency which agile teams are encouraged to pursue includes Good design
a focus on continuous improvement. Agile teams and individual members What makes design “good” can mean different things to different people.
should always be thinking about what they can do to improve how they One way for a team to pursue this and avoid many ongoing arguments
work. This can happen any time during an iteration. The retrospective is about what “good” means is to develop/adopt a set of coding standards
just to imbed such a focus as a formal part of the agile cycle. The idea of for the team. One aspect of what “good” might mean is that code is easy
continuous attention means always looking around, noticing what is go- to maintain over time — i.e., people can go into the code to make changes
ing on in the team, and considering how things could be better. and not have difficulty understanding how to do so because of its struc-
For example, at the end of each work day, members could take perhaps ture and how things are named. They will then be less worried about
five minutes to consider their day and ask themselves what they could do making such changes.
tomorrow to help the team work better. I would expect this kind of think- Another aspect of “good” might be adherence to certain object-oriented
ing on the part of the team’s facilitator (e.g., Scrum Master) and product design principles (the SOLID principles that Martin covers in his book).
owner, but it is something anyone on the team could consider. For example, there is the single-responsibility principle. As Wikipe-
dia puts it, “every module or class should have responsibility over a single
part of the functionality provided by the software, and that responsibil-
ity should be entirely encapsulated by the class.” Before object-oriented
Technical excellence design was popularized, we used to talk about this as concern for “cohe-
sion”. Cohesion would be high when every part of a module was related
One critical improvement to consider is how to grow the technical abil- to accomplishing one thing. (A related SOLID principle is dependency
ities of the team members. One team I worked with decided that they inversion, which we used to call “coupling”. Coupling was low when a
would like to get better at object-oriented development and decided to module did not depend on how other modules carried out their work.
use Robert Martin’s book Clean Code to do so. However, the book is 464 This allowed changes in modules that did not ripple through other parts
pages long. They were not going to do this in one sitting. They chose to of the system.)
have each person on the team individually take on a chapter during an
iteration and spend some time to prepare a presentation on the essence of Regardless of what the actual standards are, having the entire team agree
that chapter as part of their retrospective. The team would try to put that to them (and constantly look to see if improvements can be made in them)
idea into practice during the following iteration (while the next person in is important.
line tackled the next chapter of the book). It took them many sprints to
get through the book’s 17 chapters, but they did it and felt it was worth-
while to take the time to do so.

78 79
 UNDERSTANDING AGILE VALUES & PRINCIPLES

Enhances agility
How this all enhances agility is reflected in how such standards and ideas
improve the quality of the product and the ease with which it can be re-
liably changed. If you do not have to worry about whether changes can
be made safely, you are more likely to be willing to make more changes.
Thus, you can move quickly while maintaining your balance, i.e., your
system stability.

PART 16
Simplicity

80
 UNDERSTANDING AGILE VALUES & PRINCIPLES

“Simplicity — the art of maximizing the amount of work not done — is es-

sential.”
The principle is rather straightforward. All the engineers I’ve met believe
in this idea. The goal is not to over-engineer something. Ward Cunning-
ham speaks about working with Kent Beck. When they’d get stuck, Ward
said he’d ask, “Kent, what’s the simplest thing that could possibly work?”
Rather than sit and discuss for too long a time, the agile advice is to try
to make it work in the code, i.e., produce some form of working software

PART 17
and determine whether what you have will address the design goal.
My mother taught me some basic cooking ideas when I was a grade-
school kid. A key one was “you can always add more but it will usually be
impossible to take it out.” Incrementally determining if the combination
of ingredients is good allows you to test the mixture at some level. If you
go too far without such testing, you may end up either throwing it out
or adding more of some ingredients to balance out the excess of another,
producing more final product than you wanted, which may be wasted.
An incremental approach to a more complex design will make it easier to
Self-Organizing Teams
verify that where you are at any moment seems to be working. It will also
allow you to back up to a prior stable state more easily. It can also avoid
“goldplating”: the tendency to add more than was requested/needed.
Of course, just doing simple things all the time isn’t a commandment.
You’d ask this question “if you’re not sure what to do yet”, as stated in Cun-
ningham’s wiki notes. But thinking in simple terms whenever possible is
essential to good design practice.

82
 UNDERSTANDING AGILE VALUES & PRINCIPLES SELF-ORGANIZING TEAMS

“The best architectures, requirements, and designs emerge from self-or- is within the team’s scope is for the team to decide how to carry it out.
ganizing teams.” This means that teams do their own estimates, determine their own tasks,
work together and individually to perform the tasks, present their work
at the end of each iteration, and verify with those outside the develop-
ment team (e.g., product owner, other teams, management, customers)
that the work meets expectations.
The best
I hear the most controversy expressed about this principle because people It can take a while for a team to understand how to do this as many people
think it implies that a team of non-experts can presumably come up with are accustomed to following directions from others. That is, a manager of
better ideas/solutions than a skilled, experienced expert. The ideas of ex- some sort will have made (or at least been required to approve) many of
perts would certainly be included. Indeed, have the expert be a member the decisions that agile teams are expected to do for themselves. This does
of the team. This harkens back to the principle of giving the team the not mean managers have no place in an agile environment (though some
environment and support needed to do the work expected. early agile material sounded that way). However, the goal for managers
is to take a servant-leader approach concerned with providing the team
Regarding the prerequisites, about 14 years ago a book was published with whatever they need to be successful rather than to expect the team to
called The Wisdom of Crowds. It spoke about how a group could come up behave in a way that the manager is looked on as the success.
with a better decision than any individual member of the group, including
an expert. However, it wasn’t just any group that could do so. There were I had a manager once who knew very well what agile was about. He was,
some prerequisites (with my agile-related comments): however, very sharp and was used to being directive in how he approached
his teams. He came to me once and said, “I know I am not supposed to
• Everyone in the group would have individual perspectives and interrupt the team and tell them what to do, but I am worried this team
ideas — have a cross-functional team of people motivated to come up is not following the agile approach well. I don’t think they use the retro-
with a good solution. spective effectively.” That is a legitimate concern; a team should be trying
• People’s opinions would not be (unduly) influenced by others — avoid to use the retrospective effectively. What I told him was, “The next time
groupthink. the team is due to have a Retrospective, go up to the Scrum Master a short
• It’s possible to draw on diverse knowledge — information is not with- while after that and say, ‘Is there anything the team came up with at the
held from the group. Retrospective that I can help with?’” This does three things without being
directive or intrusive:
• There is a way for all the opinions to be aggregated in some way to ar-
rive at a collaborative decision — people can communicate with one • it makes clear the expectation that the team held the Retrospective;
another freely. • it makes clear the expectation that the team came up with some im-
The belief is that the collective decision, given these prerequisites, would provement item(s) to pursue;
end up better than if the expert were left alone to come up with the solu- • it offers to help them achieve the improvement(s) where possible.
tion.
If the manager got some sort of “deer caught in the headlights” response,
he could pursue the subject a bit further by asking, “Was there difficulty
in holding retrospective or settling on improvement items to pursue?”
Again, the manager would be asking, not telling, but expecting some rea-
Self-organizing teams sonable answer.
The phrase “self-managing, self-organizing teams” is used to indicate that Teams can still be encouraged to self-organize and manage with this ap-
teams both organize themselves as they see fit to accomplish work for proach, but it would be made clear that they are expected to do so.
each iteration and then manage themselves to do that work. Whatever

84 85
PART 18
Team Reflection
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

“At regular intervals, the team reflects on how to become more effective, and individually. The daily meeting may raise issues that the team should
then tunes and adjusts its behavior accordingly.” address immediately instead of adding them to a list for the end of the
iteration. At the end of each person’s day, they can ask themselves, “What
It is somehow appropriate that this is the last principle, given that the first can I do tomorrow to make our team more effective?” I would expect a
value is about individuals and interactions. I think this principle is sig- team’s facilitator, at least, to do this.
nificantly linked to that first value. Retrospectives are a key aspect of how
individuals interact in an agile context. Unfortunately, retrospectives, due
to schedule pressures, can be skipped when it is felt by (or communicated
to) a team that there is no time to hold the retrospective.
The team
This last chapter will be somewhat longer than any of the others because
I believe there are a lot of important things to say about retrospectives. Who should participate in the retrospective? The Scrum Guide states that
it’s for the Scrum team and defines that team as consisting of “a product
owner, the development team, and a Scrum Master”. The latter two are
rather universally seen as participating, but that is not always true for the
product owner. Sometimes, development teams look upon the product
Regular intervals owner as management. As managers are not included in the retrospective,
The point of the retrospective is continuous improvement. To be con- product owners frequently get excluded, too. This is unfortunate since
tinuous means improving with some frequency. The minimum frequen- they have direct connection to the work done and clearly have opinions
cy is at the end of every iteration. The classic “lessons learned” or “post like anyone else on the Scrum team about how things went during the
mortem” sessions would occur only after the end of an entire project or sprint.
release. There are several problems with this: I believe there can be approaches to involving a product owner in the
• At the end of a project/release, people are often dispersed to new retrospective that do not completely exclude them:
projects/releases, making it hard to get them together for such a ses- • They could attend the beginning of the retrospective, be heard and
sion. engage in some discussion, then leave.
• Since such sessions occur usually months after the start of the project, • They could offer their perspective to the Scrum Master before the
some people may not even be around to participate and those who retrospective and those ideas, at least, could be provided for consid-
are may not remember the things they thought of months ago, which eration in the retrospective.
could be mentioned at the session.
• A lot of what is discussed in such sessions is about the things that Neither of these are ideal, but they are better than total exclusion. In both
went wrong and how to fix them for the next project/release, so the cases, the product owner should receive feedback on what happened to
sessions don’t help the project that just ended. their ideas and what the development team came up with as improve-
ments.
• The sessions are often management-driven events at which some
people may not want to speak up because of concern for how they (I do realize that some teams may have some private issues they wish to
might be viewed if they raise an issue folks would rather not face. work on, but there should be some improvement(s) that can be shared
publicly.)
For reasons such as this, the frequency (and participants mentioned be-
low) are why retrospectives are expected to be held as they are.
On the other hand, reflection and adaptation does not have to wait until
the end of the iteration. There is an opportunity for this daily as a team

88 89
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

At the daily meetings in the next iteration, the team facilitator could ask
Become more effective about the items the team said they would try to pursue as improvements.
The idea of continual improvement goes back at least to the early lean This could help the team remember which items should get attention
work in Japan after World War II. It is known as kaizen in that context. during the iteration.
Improvement does not have to be some large change, just continuous
change for the better. Even something that seems to work well might At the next retrospective, these items should be part of the input to con-
work even better and can perhaps be improved upon. sider, i.e., how did the team do in working the items during the iteration?

Certainly, the retrospective is not just about “fixing” things that didn’t
go well. I have heard teams say they don’t need to hold a retrospective
because everything went fine in their iteration. This has always indicated
to me that they view the retrospective as a problem-fixing meeting. No
Retrospective “smells”
problems; no meeting. Since the goal is about improvement, unless a team Besides endless list making that goes nowhere, other things may discour-
thinks they are perfect at being predictable, being productive, and pro- age a team from conducting retrospectives or using them effectively:
ducing defect-free work, there is always something to improve.
• Boring/repetitive process — Conducting the retrospective the same
A typical focus of such meetings includes: way every time can become boring. The classic brainstorming ap-
proach of going around the room with each person offering up an
• What went well that a team would like to keep doing, i.e., make a part idea, having it noted down, and doing that until everyone thinks they
of their regular work process? have no more to say seems rather boring to me. At the very least, it
• What didn’t go so well and should be changed for the better (or per- does not engage the whole team right away as people have to wait for
haps dropped as not useful)? each person to say something (or pass) before anyone else speaks. If
• What could be tried that the team has not yet tried, i.e., learn some- someone has a lot of ideas, many people are going to sit there until
thing new or experiment with a new idea? that one person runs through their list. Also, hearing what one person
says may incline people not to repeat a similar idea as they do not
If a team feels that don’t have anything in that second category, they want to seem redundant, though the difference in how it is presented
should still consider the other two. would be useful to hear.
• Victim of others — Sometimes most of the things a team talks about
are problems that come from people outside the team, which, while
perhaps true, can result in the team feeling there isn’t much they can
Tune and adjust do to change things because it is others who must change/improve.
A facilitator, while acknowledging the truth of what is said, needs
One common problem that often inclines teams to abandon retrospec-
to ask, “What could we do about this? Who might help us with this
tives is that they make lists of improvement ideas but end up doing noth-
issue? How might we help ourselves?”
ing to improve. After doing this a few times, the team will wonder why
they should bother. • Blaming session — This occurs most often if there is not a sufficient-
ly trusting and collaborative spirit on the team. People will look for
It is imperative that teams move from list making to prioritizing their whose fault it was that they faced various problems. You want to ad-
ideas, selecting some (maybe one is enough), determining what it will take dress issues, but not so people are put on the defensive. Avoiding ac-
to pursue the improvements (e.g., tasks, effort estimates), and commit- cusative words like “you”, “they”, he”, or “she” and substituting “we”
ting to follow through on one or more. I have seen some teams create an helps a great deal. Handling this may require using some anonymous
improvement backlog where improvement ideas are treated like require- data collection (see below) as people may simply not raise the issues
ments.

90 91
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

to avoid the blaming, but the issues nevertheless probably need to be “People,” “Culture,” “Process,” “Environment,” and “Tools”. This begins the
heard. process of grouping ideas together (affinity) for further consideration. It
• Issues that are hard to talk about — People may avoid raising issues also makes it easy for people to step back, look at the overall patterns, and
that are specific to individuals on the team, while perhaps important reflect on those before diving into the details of each specific idea. When I
to address, because it is uncomfortable to do so. Issues may be raised have done this, I usually say the categories mean the following:
in a way that promotes defensiveness and destructive discussion, like
• People — interactions among individuals;
blaming.
• Culture — the organization’s beliefs about interactions;
While the retrospective is an important team activity, it may also be the • Process — the ways people work to get things done;
hardest one for a team to engage in effectively. The fundamental consid-
• Environment — the physical environment in which people work;
erations of communication, collaboration, commitment, continuous im-
provement, trust, and excellence discussed in Chapter 2 are particularly • Tools — the things people use (manual or electronic) to do their work.
important in the retrospective context. It is almost always the case that the volume of stickies skews toward the
first couple, then less for the third, and fewest for the last two. I think you
can guess the kind of discussion that ensues when people see this, regard-
less of how obvious it might be. Seeing the “obvious” presented physically
Some retrospective ideas just drives home the impression.

I have some strategies to try in retrospectives that I have used myself or I also used this approach and categories when a Scrum Master asked me
with teams. to run a retrospective because they felt it would turn a bit ugly due to what
had gone on during the sprint. I started the retrospective by acknowledg-
To allow the team’s facilitator/Scrum Master to participate as a Scrum ing that I had heard the team had a rough sprint. I asked that instead of
team member and not have to “switch hats” from that role to contrib- writing down ideas about the things that went badly, they should write
ute ideas, get an outside facilitator to run the session. This could be an- how they would have liked things to have happened and put them up un-
other team’s facilitator/Scrum Master; the two could agree to run one der these categories. Then I asked them to discuss how they thought they
another’s retrospectives, bringing in an otherwise uninvolved person to could make these things happen. This turned into a much more positive
facilitate the meeting. You could also go to your training (or perhaps HR) retrospective than the Scrum Master had (probably rightly) feared.
department and look for someone trained in facilitating meetings and
have them do it. This also serves a useful purpose in introducing people
outside the agile effort to a bit about the process. I’ve also had teams who Collecting Feedback
rotated facilitation among team members. Each iteration, a different team
One issue with collecting feedback can be doing this openly versus more
member prepared for facilitating, looking for new and different ways to
anonymously. If people are reluctant to raise issues for any reason, per-
possibly run it. This has the advantage of getting everyone to self-manage
haps some form of anonymous data collection could work. People could
this activity.
still write things down as noted above, but perhaps they’d all be handed in
As noted above, the traditional brainstorming approach has potential and shuffled before dealing with them further.
problems in collecting feedback. A simple way to overcome many of
I had a Scrum Master ask me to facilitate a retrospective because he want-
these is to ask people to write their ideas down on note cards or stickies.
ed to raise the issue of how people felt about teamwork, but he was not
This allows everyone to be busy at once and to be able to get out as many
sure if people would speak up and was concerned that the feelings were
ideas as they like without anyone having to wait for a turn to do so. When
somewhat negative. I asked people to rate their sense of teamwork/spirit
people seem to have exhausted their ideas, you can have everyone get up
on a 1–5 scale (worst to best) and write that number on an index card
and put their ideas up on a wall, board, etc. possibly under categories like

92 93
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

which they would hand to me to and I’d shuffle up. A “1” meant they felt Data “Tools”
the spirit was bad and a “5” meant they felt it was wonderful, etc..
There are also a variety of what can be called tools that help collect, orga-
nize, and visualize data. A book called The Quality Toolbox, published by
the American Society for Quality (ASQ) and also available on Amazon, is
filled with examples and explanations of such tools. I have used many of
the examples, which include traditional graph types like those in spread-
sheet programs and more sophisticated things such as statistical control
charts.

Bar chart.
As I would read out the numbers and the Scrum Master would create a
“bar chart” like this, putting an “x” whenever a specific number was read
out, stacking each “x” when the same number was read out again. I then
asked everyone what they thought of the Team’s overall data. Some folks
were surprised it was not more negative. Everyone could see perhaps
there was some work to do but it wasn’t as bad as many feared. Even one
of the most frequently disengaged members spoke up a lot.

The Five “Whys” Kiviat diagram.

One technique for dealing with the data collected is called the “5 Whys” One I like a lot is the Kiviat diagram, also called a spider chart or radar
and is a root cause analysis approach. You take an issue and ask why that chart. Topics for which feedback is desired are listed around the outside.
seemed to be true, then ask why that response might be true, and repeat The radial lines would usually have tick marks with those closer to the
this until you think you’ve hit the root cause rather than just symptoms of center being the low end of the scale and the outer end being higher. For
the root cause. For example, a team might say, “We have problems getting each topic, ask people to provide numeric values. In the example above,
stories done each sprint.” In response to why they think that happens, two such values are requested: where people would like to be (red line)
they could say, “Because other teams we depend upon don’t deliver what and where they feel they are (green line). Now you can average the data or
we need.” Asked why they think that happens, they may say, “Because co- plot each person’s two values, connecting the lines as shown. Again, step-
ordination with them is hard.” And this could continue until it was felt ping back allows all to see what the chart tells you about the areas where a
something was stated that could be changed, A solution would ripple up desired state is furthest from actual. Then you engage in discussion about
the line of issues to help the overall problem. what to do about what you see.
Another idea is something like the sailboat exercise originally created by
Luke Hohmann. (This specific diagram comes from Luis Gonçalves’ web-
site and can also be found in his and Ben Linders’ book Getting Value out of

94 95
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

Agile Retrospectives, which started as a mini book on InfoQ: https://www. Finally, there is what I call the “running retrospective”, which, as far as I
infoq.com/minibooks/agile-retrospectives-value). Besides this depiction, know, I invented. I certainly did not copy from anyone knowingly when I
I have also seen pictures of a sun and a shark added to such a diagram. came up with it several years ago. You take a piece of long, wide (“butch-
er”) paper and draw a horizontal line that represents the iteration. Each
tick mark on the line represents a day in the iteration.

Running retrospective.
Throughout the iteration, at any time, a person could write a note and
stick it on the mark for that day. I presented this to a workshop table at a
Scrum Gathering and Alistair Cockburn was part of the table. His won-
Sailboat diagram. derful suggestion was to have people put the stickies (a) above the line if
it was a positive experience (and the higher above the more positive), (b)
People write down their ideas on stickies then put them where they think below the line if negative (and the lower, the more negative), or (c) on the
they belong on the diagram. The meaning of the individual images could line if it was just an observation that the person wanted to make with no
be: strong feeling one way or the other.
Palm Trees — what the Team goal/vision was for the iteration; At the retrospective, there would already be a lot of data (to which more
could be added) and that might move the retrospective right into discus-
• Rocks — the risks the Team faced and may have hit (the stickie is on
sion and selection of worthwhile improvement ideas. Of course, people
the rocks) or avoided (so the stickie is not exactly on the rocks);
could see patterns forming throughout the iteration and might want to
• Anchor — something that held the Team back or “weighed them address something they see before the next scheduled retrospective (since
down”; the need/decision to improve need not wait to the end of the iteration).
• Wind — something that moved the Team forward; But the overall idea is that idea collection runs throughout the entire it-
• Shark — something that “bit” the Team during the iteration; eration.
• Sun — something that “brightened the day” for someone.
Again, after all the stickies are up, you stand back and get an overall sense
of what the image suggests with the stickies present. Then you can decide
where to begin your more detailed focus.

96 97
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

What next? Epilogue

There are certainly many more things that can be said about retrospec-
tives. Just type into your browser “agile retrospective exercises and games”
(or some combination of the words) to find plenty of ideas. There are also Hopefully, this book has offered some worthwhile perspectives on the
books such as Agile Retrospectives and Project Retrospectives that you can Agile Manifesto’s values and principles. The next step is yours: trying to
look into. put them into practice in your organization or situation. Use them to stop
and think rather than simply rush to do.
Whatever you do, do not allow people to give up on the retrospective.
If you have not had any formal training in these ideas and the basic agile
lifecycle (or people around you have not), I strongly encourage you to get
that training. I’d then encourage you to seek some initial coaching to help
you get moving in a successful direction. Neither of these must, or should,
cost a great deal.

One older and two recent

perspectives
As noted in Chapter 1, there have been a variety of proposals for updating
the manifesto. Kent Beck, in 2010, spoke of one evolution of the Agile
Manifesto’s value statements:
Team vision and discipline over individuals and interactions
Validated learning over working software
Customer discovery over customer collaboration
Initiating change over responding to change
This thinking seems to fit nicely with two recent perspectives.
Four values and 12 principles plus many methods, frameworks, and prac-
tices — that’s a lot to absorb. A common question is just what the essence
of being Agile is all about. A couple of people have come up with some
short and I believe easily understood ways to think about this that I have
found particularly interesting.

98 99
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

Modern agile or aren’t learning enough, we take it as a sign that we need to learn
more by running more experiments.
A few years ago, Joshua Kerievsky presented his ideas in a form he calls
• Deliver value continuously — Ask how valuable work could be deliv-
“modern agile” to address what he felt was “antiquated agility”. I will let
ered faster. Delivering value continuously requires us to divide larger
his words (with some editing) speak for themselves and suggest, if they
amounts of value into smaller pieces that may be delivered safely now
sound interesting, that you investigate this further.
rather than later.

Heart of agile
A few years before I encountered modern agile, I heard about Alistair
Cockburn’s proposed Heart of Agile as a succinct way to “get back to the
center of agile” after what he felt had been many years of “overly deco-
rated” ideas and practices. He feels that the four words in the associated
diagram “don’t need much explanation. They don’t need much teaching.
With the exception of ‘Reflect’, which is done all too little in our times, the
other three are known by most people. You know if you’re doing them or
not.”

Modern agile.
Kerievsky has said:
• Make people awesome — In modern agile, we ask how we can make
people in our ecosystem awesome. This includes the people who use,
make, buy, sell, or fund our products or services. We learn their con-
text and pain points, what holds them back, and what they aspire to
achieve.
• Make safety a prerequisite — We actively make safety a prerequisite
by establishing safety before engaging in any hazardous work. We
protect people’s time, information, reputation, money, health, and re-
lationships. And we endeavor to make our collaborations, products, Heart of Agile.
and services resilient and safe.
• Experiment and learn rapidly — You can’t make people awesome or These four words can be expanded as follows:
make safety a prerequisite if you aren’t learning. We learn rapidly by
experimenting frequently. We make our experiments safe to fail so
we are not afraid to conduct more experiments. When we get stuck

100 101
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

Over the years, I have always found Cockburn’s ideas and presentation of
those ideas significant. The first book of his I read, Agile Software Develop-
ment (revised in 2006), covers a wide scope of not just agile ideas but how
they relate and can blend with other ideas. Another of his books, Crystal
Clear, covers his own views on implementing an agile approach and con-
tains many interesting ideas.
One of those ideas is that there is more than one set of practices that a
project may need based on the perceived impact (loss) if a project is not
successful combined with the number of people who must be involved in
the project. Greater potential for loss would suggest more rigorous ver-
ification and validation practices make sense. Larger numbers of people
imply more formal communication considerations.
Another is that he advocates building up your approach rather than tai-
loring it down. That is, start with an approach that is the simplest thing
that could work and add rigor where it seems needed rather than start
Heart of Agile first-level expansion. with a very rigorous, complex approach and throw away things you feel
And even further into: you don’t need. It is better to encourage people to add rigor than to en-
courage the mindset of trying to get away with less.

Heart of Agile second-level expansion.

Cockburn reminds us that “the point of the Heart of Agile isn’t to pretend
that complexities and subtleties don’t exist; it is to remind us to scrape
away all the complexities from time to time, and restart from the begin-
ning.”

102 103
 UNDERSTANDING AGILE VALUES & PRINCIPLES TEAM REFLECTION

Agile Product Management with Scrum by Roman Pichler and Scrum Product
Further Reading Ownership: Balancing Value from the Inside Out by Bob Galen (Roman’s is
perhaps more frequently mentioned but Bob’s is good as well)

I hope the book has interested you enough to consider some of the ideas The Quality Toolbox by Nancy R. Tague (the ASQ publication mentioned
in it for your own practice of agile. Here are some books I think you after the Kiviat diagram example)
would find interesting to further explore Agile and Agile-related ideas: The Scrum Guide (free PDF) by Ken Schwaber and Jeff Sutherland (just
Extreme Programming Explained by Kent Beck (explains development type “The Scrum Guide” in your browser to find the site (scrum.org)
practices and the XP approach to “managing” a project by the team) where you can download the latest version of the “definitive” definition
of what Scrum is all about)
Balancing Agility and Discipline by Barry Boehm and Richard Turner (a
book addressing dealing with more traditional, more rigorous develop-
ment demands while pursuing Agile ideas)
Management 3.0 and Managing for Happiness, both by Jurgen Appelo (a
book addressing complexity and management in complex situations and
a book about techniques, exercises, etc. to use in working with people and
teams)
Coaching Agile Teams by Lyssa Adkins (which is just what it sounds like,
offering advice to coaches, Scrum Masters, managers, and anyone who
wants to help teams grow and develop, including team members them-
selves)
Succeeding with Agile by Mike Cohn (implementation advice when work-
ing in a Scrum approach)
Essential Scrum by Ken Rubin (another “guide” to implementing Scrum)
Kanban by David Andersen (a key book on applying Kanban, especially in
a software context)
Scrumban by Corey Ladas (combining Scrum and Kanban approaches to
managing work and workflow).
Lean Software Development, Implementing Lean Software Development and
Leading Lean Software Development by Mary and Tom Poppendieck (apply-
ing Lean concepts to software development)
The Software Project Manager’s Bridge to Agility by Michelle Sliger and Sta-
cia Broderick (Michelle was one of the people that advised PMI in the
creation of their PMP-ACP program)

104 105
 UNDERSTANDING AGILE VALUES & PRINCIPLES

About the Author

Scott Duncan has been in the software field for some 47 years as a de-
veloper, technology transfer researcher, process consultant, trainer, and
Agile coach. He has worked in fields such as book sales and distribution,
state government, mainframe database and natural language query prod-
ucts, telecom (14+ years in Bell Labs, Bellcore, Telcordia), credit card
transaction processing, and banking.
His most recent full-time role was as enterprise coach and trainer for an
organization that developed software for the design, construction, and
operation of power plants (including nuclear), processing plants (e.g., oil
refineries, chemicals), and ships. There, he helped grow the organization
to 144 Scrum teams in the US, India, Israel, UK, Germany, France, and
Canada.
Along the way he was trained as an ISO 9001 Auditor and CMM assessor,
was a member of ISO & IEEE Standards Committees for some 15 years,
and was a member of the Scrum Alliance Board of Directors for 2 years.
Currently, he does training and coaching as an ICAgile certified trainer
for Agile fundamentals, coaching, testing, business agility, and leadership
as well as a variety of non-certified scrum master, product owner, man-
ager, and team member courses.
Scott has a basic website at www.agilesoftwarequalities.com and can be
reached at [email protected].

106