1. I.

Improving Agility

2. 1. What Is Agile?
1. Agile’s Genesis

2. Born Out of Crisis

3. The Agile Manifesto

4. The Essence of Agile

1. Adaptive rather than predictive

2. People-oriented rather than process-oriented

5. Why Agile Won

6. Cargo Cult Agile

3. 2. Choose Your Agility

1. Let’s Talk Success

2. Enter Agility
1. Organizational Success

2. Technical Success

3. Personal Success

3. The Agile Fluency™ Model

1. Focusing Zone
 2. Delivering Zone

3. Optimizing Zone

4. Strengthening Zone

4. Choose Your Zones

The Art of Agile Development
SECOND EDITION

With Early Release ebooks, you get books in their earliest form—the author’s raw and
unedited content as they write—so you can take advantage of these technologies long
before the official release of these titles.

James Shore and Shane Warden

The Art of Agile Development

by James Shore and Shane Warden

Copyright © 2021 James Shore and Big Blue Marble LLC. All rights
reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway

North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales

promotional use. Online editions are also available for most titles
(http://oreilly.com). For more information, contact our
corporate/institutional sales department: 800-998-9938 or
[email protected].

Acquisitions Editor: Melissa Duffield

Development Editor: Gary O’Brien

Production Editor: Deborah Baker

Interior Designer: David Futato

Cover Designer: Karen Montgomery

Illustrator: O’Reilly Media, Inc.

August 2021: First Edition

Revision History for the Early Release
2020-08-27: First Release

See http://oreilly.com/catalog/errata.csp?isbn=9781492080695 for

release details.

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc.

The Art of Agile Development, the cover image, and related trade
dress are trademarks of O’Reilly Media, Inc.

While the publisher and the authors have used good faith efforts to
ensure that the information and instructions contained in this work
are accurate, the publisher and the authors disclaim all responsibility
for errors or omissions, including without limitation responsibility for
damages resulting from the use of or reliance on this work. Use of the
information and instructions contained in this work is at your own
risk. If any code samples or other technology this work contains or
describes is subject to open source licenses or the intellectual
property rights of others, it is your responsibility to ensure that your
use thereof complies with such licenses and/or rights.

978-1-492-08069-5

[LSI]
Part I. Improving Agility
 CHAPTER ONE

What Is Agile?
<aside data-type="sidebar"><h5>A note for Early Release
readers</h5> <p>With Early Release ebooks, you get books in their
earliest form—the author’s raw and unedited content as they write—
so you can take advantage of this content long before the official
release of these titles.</p>

<p>This will be Chapter 1 of the final book.</p>

<p>If you have comments about how we might improve the content
and/or examples in this book, or if you notice missing material within
this chapter, please reach out to the editor at [email protected].
</p> </aside>

Agile is everywhere. And, paradoxically, nowhere.

In the 20 years after the Agile freight train roared into software
developers’ conscious, the number of companies calling themselves
“Agile” increased by orders of magnitude. The number of teams
actually taking an agile approach to their work? Not so much.
”Agile,” the easily-repeated name, is enormously successful. The
ideas behind Agile—well, most of them are ignored.

Let’s fix that.

Agile’s Genesis
In the 1990s, software development was believed to be in crisis. They
actually called it that: “The Software Crisis.” Software projects were
over-budget, late, didn’t meet requirements, and—according to the
oft-quoted and ominously named “CHAOS Report”—a third of them
failed outright.

Agile wasn’t a response to this crisis. Far from it. Agile was a
response to the response.

To bring software development under control, big organizations

created highly detailed processes that defined exactly how software
was to be created. Everything was tightly controlled so that no
mistakes could be made. (In theory, anyway.)

First, business analysts would interview stakeholders and document

the system requirements. Next, software architects would read the
requirements documents and create detailed design documents
specifying every component of the system and how they related to
each other. Then programmers would convert the design documents
to code. In some organizations, this was considered low-skill work—
1
just a mechanical translation exercise. Meanwhile, test leads would
use the same documents to generate test plans, and when coding was
done, armies of QA personnel would manually follow those test plans
and report variances as defects. After each phase, everything would
be carefully documented, reviewed, and signed off.
This approach was called “waterfall development” or “phase-gate
development.” If it sounds like a ridiculous straw-man, well, consider
yourself fortunate. Not every company used a heavyweight process in
the ’90s, but it was widely recognized as a logical and sensible way
to work. Of course you needed to define requirements, then design,
then implement, then test. Of course you needed to document every
phase. This was discipline. This was engineering. How else could
you possibly succeed?

Born Out of Crisis

Big companies defined their processes in excruciating detail. Roles,
responsibilities, document templates, change control boards… every
aspect of development was defined and controlled. If a project didn’t
succeed—and according to the CHAOS Report, two-thirds of them
didn’t [xxx check]—it was because the process needed more detail,
more documents, more sign-offs. It resulted in a massive amount of
2
documentation. Martin Fowler called it “The Almighty Thud.”

This wasn’t a great way to work. It was bureaucratic and

dehumanizing. Skill didn’t seem to matter as much as adherence to
process. Programmers felt they were interchangeable cogs in an
impersonal machine. It didn’t even work all that well.

So several people independently developed simpler, slimmer, and less

prescriptive methods for developing software. They were called
”lightweight methods” in contrast to the heavyweight methods used
by big companies. These new methods had names like “Adaptive
Software Development,” “Crystal,” “Feature-Driven Development,”
“Dynamic Systems Development Method,” “Extreme Programming,”
and “Scrum.”

By the late ’90s, these methods were attracting serious attention.

Extreme Programming, in particular, saw an explosion of grass-roots
interest among programmers. In 2001, 17 of the lightweight
methodology proponents met at a ski resort in Utah to discuss
unifying their efforts.

The Agile Manifesto

“I personally didn’t expect this particular group of [people] to ever
3
agree on anything substantive,” Alistair Cockburn said later.

And, in fact, after two days, they only accomplished two things: the
name “Agile,” and a statement of four values (see Figure 1-1). Over
the following months, over email, they hashed out twelve
accompanying principles (see Figure 1-2).

This was the Agile Manifesto. It changed the world. So, as Alistair
said, they did agree on something substantive after all.
Figure 1-1. Agile Values
Figure 1-2. Agile Principles
But there was no unified Agile method. There never has been, and
never will be. Agile is three things: the name, the values, and the
principles. That’s it. It’s not something you can do. It’s a philosophy.
A way of thinking about software development. You can’t “use”
Agile or “do” Agile… you can only be Agile. Or not. If your teams
embody the Agile philosophy, then they’re Agile. If they don’t,
they’re not.

The Essence of Agile

Martin Fowler has made a career out of turning complicated software
topics into well-considered, even-handed explanations. His
4
explanation of “The Essence of Agile Software Development” is one
of the best:

Agile Development is adaptive rather than predictive; people-

oriented rather than process-oriented.
Martin Fowler

Adaptive rather than predictive

Remember the CHAOS Report, which said that only one-third of
software projects were successful? It had a very specific definition of
success:

Successful
“Completed on time, on budget, with all features and functions as
originally specified.”
Challenged
“Completed and operational but over budget, over the time
estimate, [with] fewer features and functions than originally
specified.”

Impaired
“Cancelled at some point during the development cycle.”

These definitions illustrate the predictive mindset perfectly. They’re

all about conformance to plan. If you did what you said you were
going to do, you were successful. If you didn’t, you weren’t! Easy.

It makes sense at first. But look closer. There’s something missing.

5
As Ryan Nelson commented in CIO Magazine:

Projects that were found to meet all of the traditional criteria for
success—time, budget, and specifications—may still be failures in
the end because they fail to appeal to the intended users or
because they ultimately fail to add much value to the business.
... Similarly, projects considered failures according to traditional
IT metrics may wind up being successes because despite cost, time
or specification problems, the system is loved by its target audience
or provides unexpected value. For example, at a financial services
company, a new system… was six months late and cost more than
twice the original estimate (final cost was $5.7 million). But the
project ultimately created a more adaptive organization (after 13
months) and was judged to be a great success—the company had a
$33 million reduction in write-off accounts, and the reduced time-
to-value and increased capacity resulted in a 50 percent incresae
in the number of concurrent collection strategy tests in production.
Agile teams define success as delivering value, not conforming to a
plan. In fact, truly Agile teams actively look for opportunities to
increase value by changing their plans.

Take a second look at the Manifesto (see Figure 1-1 and Figure 1-2).
“Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.”
How many of its values and principles relate to delivering valuable
software and adapting to feedback?

People-oriented rather than process-oriented

Heavyweight processes tried to prevent errors by carefully defining
every aspect of software development. By putting the “smarts” in the
process, individual skill became less important. In theory, you could
apply the same process over and over, with different people, and get
the same results. (Come to think of it, they kind of did. Just not the
results they wanted.)

Agile says people are the most important factor in software

development success. Not just their skills, but all aspects of their
humanity. How well team members work together. How many
distractions they encounter. How safe they feel. Whether they’re
comfortable voicing dissent, and whether they feel motivated by their
work.

Agile teams have a process—every team does, even if it’s implicit—

but the process is in service of the humans, not the other way around.
And Agile teams are in charge of their own process. When they think
of a better way of working, they change it.

Look back at the Manifesto (see Figure 1-1 and Figure 1-2). “Build
projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.” Which
values and principles relate to putting people first?

Why Agile Won

In the first ten years after the Manifesto, Agile faced enormous
criticism. It was “undisciplined,” critics said. “It could never work.”
Another ten years after that, the critics were silent. Agile was
everywhere, at least in name. Heavyweight waterfall methods were
effectively dead. Some younger programmers had trouble believing
anybody ever could have worked that way.

There’s actually nothing inherently wrong with the basic waterfall

process. If you keep it slim and operate in a well-understood domain,
waterfall can work well. The problem was the heavyweight processes
big companies used. Ironically, the processes designed to prevent
problems actually caused many of the problems organizations were
seeing.

With software, it’s very difficult to imagine how it will work before
you actually use it, and it’s even harder to think of absolutely
everything your software needs to do. This is doubly true for people
who aren’t actively involved with software development. As a result,
it’s critically important to get working software in front of people as
soon as possible. You need to get feedback about what’s missing or
wrong, then change your plans based on what you learn. As the
Manifesto says, “working software is the primary measure of
progress.” Learning and responding to change are at the heart of what
Agile is all about.

Those heavyweight processes put so much emphasis on process

controls and documentation and sign-offs that they incurred a huge
amount of delay and overhead. They took years to produce working
software, and they had nothing concrete to show until near the end.
Instead of welcoming change, they actively worked to prevent
change. They actually had a dedicated part of the process, the Change
Control Board, whose primary purpose was to say “no” to change
requests. (Or, more accurately, “yes, but it will cost you.”)

All of this added up to projects that spent years in development

before they had anything to show. When they did, it was too late and
too expensive to make changes. They ultimately shipped software
that didn’t do what customers needed.
 A TYPICAL HEAVYWEIGHT FAILURE

On February 3rd, 2005, Robert S. Mueller III, director of the Federal Bureau of
Investigation (later famous for his role investigating Donald Trump), appeared
before a Senate subcommittee to explain how the FBI had managed to waste
6
$104.5 million.

This couldn’t have been a comfortable position to be in. In June 2001, the FBI
had launched VCF, a project designed to replace the Bureau’s case
management software. Four years later, it was cancelled, at a total cost of $170
million, $104.5 million of which were completely unrecoverable.

The timeline for VCF tells an all-too-familiar story. The project launched in June
2001. Seventeen months later, in November 2002, “solid requirements” had
been established. The software was delivered a year after that, in December
2003, but the FBI “immediately discovered a number of deficiencies in VCF that
made it unusable.” The contractor building VCF agreed to fix the problems, but
only at the cost of an additional $56 million and another year of development.

Ultimately, the FBI declined to fix the problems, scrapping years of work. “In
many ways,” Mueller said during his testimony, “the pace of technical
innovation has overtaken our initial vision for VCF, and there are now products
to suit our purposes that did not exist when [VCF] began.”

Although there are a variety of approaches to Agile—and some of

them are more about co-opting a popular name than following the
actual philosophy—one thing they all have in common is a focus on
making progress visible and allowing stakeholders make course
corrections as they go. This seems like a small thing, but it’s
incredibly powerful. It’s why we no longer hear about a Software
Crisis. Software is still late. It’s still over budget. But Agile teams
don’t spend years building failures. And that’s huge.
There’s more to Agile than just providing visibility. But this one
thing? This was enough. It’s why everybody wanted Agile.

Cargo Cult Agile

At first, Agile was a grassroots movement. It was largely driven by
programmers seeking better results and better quality of life. As it
became more successful, Agile’s momentum shifted from the
underlying ideas to hype. Rather than saying, “let’s get better results
by adapting our plans and putting people first,” organization leaders
started saying, “Everybody’s talking about Agile. Get me some
Agile.”

The thing is, there is no “Agile” to go get. It’s just a set of values and
principles. There are specific Agile approaches, such as Extreme
Programming and Scrum, that will tell you how to be Agile, but you
still have to be on board with the underlying philosophy.

And for a lot of organizations, that underlying philosophy—adapting

plans and putting people first—is really, really foreign.
 THE CARGO CULTS
7
Back in the 1940s, the story goes, American troops landed on a remote island.
The natives of the island had never seen modern civilization before, and were
amazed by the men and materials Allied forces brought to the island. They
watched the troops set up an airstrip and a tower, don headphones, and call
great metal birds filled with valuable Cargo down from the heavens. When the
birds landed, shares of the Cargo were distributed to all the islanders, bringing
prosperity and comfort.

One day, the troops left, and the great metal birds stopped arriving. Missing
their Cargo, the islanders made their own airstrip out of woven bamboo. They
constructed a tall platform, placed their chief on the platform, and had him don
coconuts carved to look like headphones. But no matter how hard they tried,
the great metal birds never returned.

The tragedy of the cargo cult is its adherence to the superficial,

outward signs of some idea combined with ignorance of how that
idea actually works. In the story, the islanders replicated all the
elements of cargo drops—the airstrip, the tower, the headphones—
but didn’t understand the vast infrastructure that enabled airplanes to
arrive.

The same tragedy occurs with Agile. People want Agile’s Cargo:
better results, more visibility, fewer business failures. But they don’t
understand the underlying philosophy, and often wouldn’t agree with
it even if they did. They want to buy Agile, but you can’t buy an idea.

What they can buy is the outward signs of Agile. Stand-up meetings!
User stories! Tools! Consultants! There’s lots of stuff labelled Agile,
and plenty of people eager to sell it to you. It’s often labelled as
“enterprise-grade,” which is a way of saying “don’t worry, you won’t
have to change.” Uncomfortable ideas like “adaptive planning” and
“people-centric” are ignored.

And that’s how you get a cargo cult. All the activity; none of the
results. The Agile part is missing.

“At my old company they wasted a huge number of man hours in

meetings.”
“[Agile] cost an entire team (30+) people their jobs as they
produced almost nothing for almost a year.”
“All [Agile] means is developers get shafted when the project
changes… the day before delivery.”
“Its because of Agile there are sh—ty developers and sh—ty
products being shipped.”
“I can’t take this Agile crap any more. It’s lunacy.”
comments about Agile from around the Web

The name Agile is everywhere. The ideas of Agile aren’t. It’s become
self-perpetuating; for many, the only Agile they know is Cargo Cult
Agile.

It’s time to fix that. In the rest of this book, I’ll show you how to
apply Agile ideas for real. Keep an eye out for the Cargo Cult Agilists
shown in the margin. [XXX icon in margin here] They’ll show you
what not to do.

Ready? Let’s go.

In fact, programming was considered such a mechanical activity that, for a while, there
1
was a movement called CASE—Computer Aided Software Engineering—to
 automatically convert architectural diagrams into code.

Fowler, https://www.martinfowler.com/distributedComputing/thud.html
2

Alistair Cockburn, quoted by Jim Highsmith at https://agilemanifesto.org/history.html.

3
He went on to say, “Speaking for myself, I am delighted by the final phrasing. I was
surprised that the others appeared equally delighted by the final phrasing, so we did agree
on something substantive.”

Fowler, https://martinfowler.com/agile.html https://www.youtube.com/watch?

4
v=URlnxbaHhTs

Nelson http://www.cio.com/archive/090106/applied.html
5

Sources: Mueller’s February 3, 2005 testimony to Congress, found at

6
https://archives.fbi.gov/archives/news/testimony/fbis-virtual-case-file-system, and
Inspector General Glenn Fine’s May 2, 2005 testimony to Congress, found at
https://oig.justice.gov/testimony/0502/final.pdf.

I first saw this story in the writings of Richard Feynman. Wikipedia says it’s based in
7
reality: http://en.wikipedia.org/wiki/Cargo_cult
 CHAPTER TWO

Choose Your Agility

<aside data-type="sidebar"><h5>A note for Early Release
readers</h5> <p>With Early Release ebooks, you get books in their
earliest form—the author’s raw and unedited content as they write—
so you can take advantage of this content long before the official
release of these titles.</p>

<p>This will be Chapter 1 of the final book.</p>

<p>If you have comments about how we might improve the content
and/or examples in this book, or if you notice missing material within
this chapter, please reach out to the editor at [email protected].
</p> </aside>

Real talk: There’s no point in Agile for the sake of Agile. The only
reason you should be Agile is if it gets you better results than you’re
seeing now. So, what results will you get?

Let’s Talk Success

When I was a kid, I was happy to just play around with computers. I
loved the challenge of programming. When I got a program to work,
it was a major victory. Back then, even a program that didn’t work
was a success of some sort, so long as I had fun writing it. My
definition of success centered on personal rewards.

As I gained experience, my software became more complicated. I

often lost track of how my programs worked, and I had to abandon
some programs before they were finished. I began to believe that
maintainability was the key to success—an idea that was confirmed
as I entered the workforce and began working with teams of other
programmers. I prided myself on producing elegant, maintainable
code. Success meant technical excellence.

Despite good code, some projects flopped. Even impeccably executed

projects could elicit yawns. I came to realize that my project teams
were part of a larger ecosystem involving dozens, hundreds, or even
thousands of people. My projects needed to satisfy those people…
particularly the ones signing my paycheck. In fact, for the people
funding the work, the value of the software had to exceed its cost.
Success meant delivering value to the organization.

At each step along my journey, my understanding of the world

expanded. For a while, I found myself perplexed by the companies
that achieved massive organizational success despite creating
technical messes and treating their people terribly. Now I’ve come to
realize that my previous conclusions weren’t wrong. They were just
incomplete.

Organizational success makes a company;

Lack of technical success breaks a company;

 And personal success glues it together.

Organizational success is crucial. Without it, the money will

eventually run out. Organizational success doesn’t just mean dollars
and cents, though. There are many sources of value for an
organization—see “WHAT DO ORGANIZATIONS VALUE?”.

Technical success is more subtle. Technical success is the ability to

cost-effectively enhance and maintain your software. Without
technical success, your costs rise and your ability to make changes
plummets. Eventually, you have to throw your software away and
rewrite it. It can take years for the replacement to achieve feature
1
parity with the old code. Meanwhile, you’re spending buckets of
money just to catch up with where you used to be, all while your
customers become increasingly frustrated with your lack of progress.

Personal success is more subtle still. If people aren’t seeing personal

benefits—typically, that means more than just a paycheck—they
don’t always complain. In the best case, they’ll find a new job, taking
their accumulated organizational knowledge with them. In the worst
case, they’ll quietly sabotage the company’s efforts as they agitate for
work that’s more satisfying.
 WHAT DO ORGANIZATIONS VALUE?

Although some products’ value comes directly from sales, there’s more to
organizational success than revenue. Products provide value in many ways,
and you can’t always measure that value in dollars.
2
Sources of value include:

Revenue

Cost savings

Competitive differentiation

Brand projection

Enhanced customer loyalty

Satisfying regulatory requirements

Original research

Strategic information

Enter Agility
Will Agile help you be more successful? It might. I don’t want to
over-promise. Agile’s just a philosophy, and your success depends on
how well you apply the ideas.

Applied well, though, Agile can improve your success.

Organizational Success
Agile teams achieve organizational success by focusing on delivering
value and decreasing costs. This directly translates to increased return
on investment. Agile teams also validate expectations early, so if an
effort won’t be an organizational success, you’ll find out early
enough to cancel it before your organization has spent much money.

Specifically, Agile teams increase value by seeking out business

expertise and focusing development on the core value that their
products provide. Agile teams release their most valuable features
first and release updates frequently. When business needs change,
Agile teams change direction to match. In fact, the best Agile teams
will actively seek out opportunities to improve their plans.

Agile teams decrease costs as well. They do this partly by technical

excellence; the best Agile teams generate only a few bugs per month.
They also eliminate waste by cancelling bad projects early and
replacing expensive development practices with simpler ones. Agile
teams communicate quickly and accurately, and they make progress
even when key individuals are unavailable. They regularly improve
their process and code, making their software easier to maintain and
enhance over time.

Technical Success
Agile teams work closely together, which helps them keep track of
the nit-picky details necessary for great work. They streamline
complex processes like release deployment, giving them the ability to
release features exactly at the moment that makes the most business
sense. The whole team focuses on finishing each feature before
starting the next, which prevents unexpected delays and allows the
team to change direction without waste. They create simple,
continuously evolving code that’s easy to modify when plans change.
They include team members with expertise in the whole production
pipeline, preventing hand-off errors and delays.

Personal Success
Personal success is, well, personal. Agile development won’t satisfy
everyone’s desires. It’s different enough that it can be uncomfortable
at first. However, once they get used to it, people find a lot to like, no
matter who they are:

Executives and senior management

They appreciate Agile teams’ focus on providing visibility, a solid
return on investment, and long-lived code.

Users, stakeholders, domain experts, and product managers

They appreciate their ability to influence the direction of
development; their teams’ focus on delivering useful and valuable
software; and increased delivery frequency.

Product and project managers

They appreciate their ability to change direction as business needs
change; their teams’ ability to make and meet commitments; and
improved stakeholder satisfaction.

UX and graphic designers

They appreciate their ability to influence development plans; their
teams’ willingness to iterate on ideas; and faster, more accurate
implementation of design ideas.
Developers
They appreciate the improved quality of life that results from
technical excellence; their improved influence over estimates and
schedules; and their teams’ autonomy.

Testers
They appreciate being integrated as first-class members of their
teams; their ability to influence quality at all stages of
development; and more challenging, less repetitive work.

Operations
They appreciate being included in development discussions;
having operational requirements integrated into development
plans; developers’ focus on providing actionable telemetry and
logging; and teams taking responsibility for post-release quality
and up-time.

Working on Agile teams has provided some of the most enjoyable

moments in my career. Imagine the camaraderie of a team that works
together to identify and deliver products of lasting value, with each
team member enthusiastically contributing to a smooth-running
whole. Imagine how it feels to take responsibility for your area of
expertise, whether technical, business, or management, with the rest
of the team trusting your professional judgment and ability. Imagine
how pleasant it is to address the frustrations of your project and see
quality improve over time.

Agile development changes the game. Developing and delivering

software in a new way takes a lot of work and thought. Yet if you do
it consistently and rigorously, you’ll experience amazing things:
you’ll ship truly valuable software on a regular basis. You’ll
demonstrate progress on a weekly basis. You’ll have the most fun
you’ve ever had in software development.

The Agile Fluency™ Model

That’s what will happen if you apply Agile well. This book shows
you how. But will you actually be able to do everything in this book?

At first…probably not. It depends on your company. Diana Larsen

and I (James Shore) have been working with agile teams from the
beginning, and, over the years, we’ve noticed that Agile teams tend to
cluster in different “zones” of capability. Their capability corresponds
to how their companies have invested in Agile ideas. We captured
3
these observations in the Agile Fluency Model.

The results you get from Agile depends on how much your company
buys in to the Agile philosophy. Not just lip service; their willingness
to make actual, meaningful changes. Changes that cost time, money,
and political capital. Each zone has its own set of investments, and
you probably won’t be able to convince your company to invest in
every zone. But that’s okay. Each zone also has its own set of
benefits, and as long as you can fully invest in at least one zone,
you’ll be able to see improvements.

Which zones should you choose? It’s a matter of picking the right
cost/benefit tradeoffs. Let’s take a look.
 IT’S NOT A MATURITY MODEL

It’s common in software development to come up with “maturity models,” which

show a progression of stages required to develop to “maturity,” or the desired
end result. Early stages on the journey represent poor practice and lead to poor
results. Later stages represent expert skill and lead to good results.

Our findings were different. We saw multiple sets of skills, which we call zones.
So long as teams practiced each zone’s skills with rigor and discipline, every
zone had benefits. It wasn’t a progression from bad to good, but rather a group
of four different choices, each with their own costs and benefits. We chose the
ordering we did because later zones take longer, not because they represent
increased skill or maturity.

The ability to perform a skill with rigor and discipline is called proficiency. Being
able to do so unconsciously, even when under pressure, is fluent proficiency.
Because we saw multiple sets of skills to invest in, rather than a progression
from bad to good, we didn’t want to call our model a maturity model. Instead,
we call it a fluency model.

Focusing Zone
Although the Focusing zone is only the first zone in the Agile
Fluency Model, the model isn’t a maturity model, as “IT’S NOT A
MATURITY MODEL” describes. The core Agile philosophy is fully
realized by the Focusing zone. That means that your organization will
need to buy into the Agile philosophy in order for your teams to be
successful.

What is that core philosophy? As we saw in “The Essence of Agile”:

Agile is adaptive rather than predictive, and people-oriented rather
than process-oriented (Fowler).
In practice, this means that Focusing teams regularly review and
change their plans. They work as a tightly knit team to define their
own work processes and self-organize around completing the work.
All the while, they’re Focusing on providing value to their
organization.

For most teams and organizations, this requires a shift in how they
think about teams. Pre-Agile organizations make plans in advance,
ask teams for estimates, and expect reports about how work is
progressing relative to those estimates. Focusing teams revise their
plans frequently—at least every month—and report progress by
showing what they’ve completed.

Pre-Agile organizations break their plans into tasks, assign those

tasks to individuals on the team, and judge individuals based on how
well they complete their tasks. Focusing teams do their own task
breakdown, decide for themselves who will work on each task, and
expect to be judged on their ability to work as a team.

Can your organization buy into this core Agile philosophy? Again, lip
service isn’t enough. Here are the concrete investments they’ll need
to make for each Focusing team:™

Create long-lived, cross-functional teams. Compose each team of

people who can work well together and who have all the skills and
background needed to accomplish the team’s work. Allocate them
100% to their team. (See [Link to Come] for details.)

Create a productivity-focused workspace for each team. Unless

your company has a tradition of remote-first work, this will
 probably need to be a physical team room. It’s best if each team
has their own room. (See [Link to Come] for details.)

Ensure that each team has access to someone with business value
expertise who’s responsible for setting product direction and
goals. They don’t need to be a team member, but they do need to
participate in every planning session. (See [Link to Come].)

Ensure that each team includes at least one full-time team member
who’s responsible for determining the details of what the team’s
software will do. (See [Link to Come].)

Remove or revise HR policies that impede effective teamwork,

such as competitive ranking and individually-focused rewards.
(See [Link to Come].)

Train managers how to manage the work system rather than

individual contributions. (See [Link to Come].)

Obtain buy-in from managers and key stakeholders that, rather

than working to deadlines, teams are going to focus on delivering
value in order of priority.

Obtain buy-in from managers and key stakeholders that, until they
reach Delivering fluency, teams won’t be able to provide useful
estimates or forecasts. (See [Link to Come].)

Coach and train team members in the Focusing practices

described in Part 2.

These investments are a “good news, bad news” situation. The bad
news is that, when the rubber meets the road, some organizations
won’t be willing to make all these investments. The good news is
that, if they refuse, you’ve discovered early that they’re not really on
board with the Agile philosophy. You just saved yourself years of
frustration and heartache chasing Cargo Cult Agile.

If your organization refuses to make these investments, that’s great.

Now you know: Don’t try to be Agile. Choose another approach to
software development, one that properly fits your organization’s
culture. Waterfall is a fine choice! Keep your documentation
lightweight and your delivery horizons down to 3-6 months, and
you’ll avoid its most common failure modes. (If you’d really like to
be Agile anyway, there is a bit of wiggle room. We talk about options
in the next chapter.)

If you are able to get buy-in, that’s even better. With dedicated effort,
fluency will take about 2-6 months to achieve. [Link to Come] shows
how.

In exchange for these investments, once your team has achieved

fluency, expect to see the value-related organizational success factors
described in “Organizational Success”. Some aspects of personal
success will also improve (see “Personal Success”). Specifically,
senior management, product managers, and project managers will
like their improved visibility into the team’s work and their ability to
change direction as needed.

Here are the biggest benefits to expect from investing in Focusing

fluency:™
 Fluent teams plan their work in terms of business value, not
technical tasks, and they align their work to your company’s
business priorities.

Fluent teams demonstrate progress at least every month, and they

discuss their progress in terms of business value, not technical
tasks.

When business priorities change, fluent teams change direction to

match.

Management knows when fluent teams are building the wrong

thing, or aren’t making progress, and they’re able to intervene
early.

Fluent teams regularly improve their work habits, reducing costs

and improving their effectiveness.

Fluent teams’ team members collaborate well, which reduces

misunderstandings and hand-off delays within each team.

You aren’t likely to see improved technical success (see “Technical

Success”), though. In fact, technical quality could get worse.
Traditional approaches to design rely on careful up-front work based
on firm plans. That doesn’t mesh well with Agile’s emphasis on
flexible, frequently changing plans. As a result, Focusing teams often
end up with an ad-hoc approach to design, which isn’t sustainable.

Poor technical quality can be frustrating for team members, lowering

their feelings of personal success. It usually prevents the team from
making useful estimates and forecasts, which can be frustrating for
stakeholders.
To improve technical success and make useful forecasts, you’ll also
need fluency in the Delivering zone.

Delivering Zone
Companies who invest in the Focusing zone have taken an important
first step: they’ve aligned themselves with the core Agile philosophy.
This is critical! It’s the secret to Agile success.

But it’s not enough for long-term success. Although organizational

success makes a company, and Focusing fluency will help you get it,
lack of technical success breaks a company. Software built by
Focusing teams becomes unmaintainable over time. Over the course
of several years, costs will rise. The team wil eventually lose their
ability to make cost-effective changes. They’ll tell you they need to
throw away the software and rewrite. That’s a dangerous place to be.

Delivering teams prevent this problem by investing in technical

success. They design their code so that it can absorb frequent
changes. They keep code quality high, so they don’t waste time
hunting bugs. They refine their production lifecycle so releases are
painless and operations are manageable. They’re capable of
Delivering reliable, low-defect software whenever it makes the most
business sense.

This requires a shift in team members’ skills, and that takes

investment. Specifically, for each Delivering team, your organization
needs to make the following investments:

Make all the Focusing zone investments (see “Focusing Zone”).

 Provide time for lowered productivity while team members learn
new skills.

Integrate all needed technical disciplines into the team, not just
programming, such as QA and Ops (see [Link to Come]).

Provide training and mentoring in the technical practices described

in [Link to Come].

The first three investments are critical. The last one—training and
mentoring—isn’t strictly necessary. Teams can be self-taught. It’s a
cost/time tradeoff: Do you want to spend extra money on mentoring,
or extra productivity on self-directed learning?

Either way, as long as you have the first three investments, fluency
will take 3-24 months achieve, in addition to the time needed for
Focusing fluency. Part 3 describes how. The exact amount of time
each team will need depends on the quality of their existing code and
how much coaching they receive.

In exchange, expect to see the technical success factors described in

“Technical Success”, the cost reductions described in “Organizational
Success”, and the team member success factors described in
“Personal Success”. Combined with Focusing fluency, that’s all the
success factors described at the beginning of this chapter.

Here are the biggest benefits to expect from investing in fluent

Delivering teams:{footnote_1_2_afm_copyright}

Fluent teams release their latest work, at minimal risk and cost,
whenever their business partners desire.
 Fluent teams discover and fix flaws in your production lifecycle
early, before they can do damage.

Fluent teams provide useful predictions upon request (with some

caveats; see [Link to Come]).

Fluent teams have low defect rates. They spend less time fixing
bugs and more time building features.

Fluent teams’ codebases have low technical debt, which means

changes are cheaper and faster.

Low defect rates and technical debt are good for job satisfaction
and morale, which improves fluent teams’ retention and
productivity.

Optimizing Zone
The vast majority of companies would be satisfied with Focusing and
Delivering fluency. But Agile imagines more. In its full glory, Agile
is a world in which teams twirl and dance in response to changing
market conditions. They experiment and learn; develop new markets;
outmaneuver the competition.

Optimizing teams achieve this level of agility. They understand what

their market wants, what your business needs, and how to bridge the
two. Or, as in a startup environment, they know what they need to
learn and how to go about learning it. They not only have the ability
to deliver reliable software, they also know what to deliver. They’re
constantly Optimizing their product plans to achieve the most value
possible.
This requires a shift in organizational structure. Optimizing plans
requires deep business and product expertise, and that means having
product and market experts join development teams full-time. For
each Optimizing team, your organization needs to make the following
investments:{footnote_1_2_afm_copyright}

Make all the Focusing zone investments (see “Focusing Zone”).

Ensure that each team includes at least one full-time team member
with expertise in determining how the team’s software fits into its
market and how to achieve maximum value. They will be
responsible for setting product direction and goals. (This is similar
to the “access to someone with business value expertise” Focusing
investment, but now they’re part of the team full-time. See [Link
to Come].)

Give each team full responsibility over a particular product(s) or

market segment(s).

Give each team responsibility for their budget, plans, and results.
Judge them on their results, not their adherence to plans.

Enable and expect managers to work collaboratively across the

organization to remove obstacles to team performance.

Provide coaching to managers about how high-performance, self-

organizing Agile teams change the nature of management work.

These structural changes require high-level permission in the

organization. It can be difficult to obtain. It typically takes teams at
least a year of building trust via Delivering fluency before they get
permission for these investments. Once that happens, Optimizing
fluency takes another 3-9 months to achieve. That said, Optimizing is
a never-ending process of experimentation, learning, and discovery.
Part 4 describes how to begin.

These are the biggest benefits to expect from investing in fluent

Optimizing teams:™

Fluent teams deliver products that meet business objectives and

market needs. They include broad-based expertise that promotes
optimal cost/value decisions.

When discussing progress with leadership, fluent teams describe

where their products stand in their market and how they’ll
improve their position.

Mutual trust between fluent teams and their organizations leads to

rapid, effective negotiation.

Fluent teams coordinate with leadership to cancel or pivot low-

value projects early.

Fluent teams learn from market feedback to anticipate customer

needs and create new business opportunities.

Strengthening Zone
There’s one final zone in the Agile Fluency Model. It’s largely
speculative: a possible future for Agile. It’s also only appropriate for
organizations on the bleeding edge of management theory and
practice. That puts it out of scope for this book. Briefly, it involves
distilling teams’ collective insights and channeling them into
organizational improvements. If you’d like to learn more, start with
Shore & Larsen.

Choose Your Zones

Will Agile get you better results than you’re seeing now? It depends
on your organization. In a vacuum, all three zones together provide
the best results and the purest realization of Agile ideas. But this also
takes the most investment. Investing in more than you need could
incur backlash, and could even poison people’s perception of Agile
ideas in general.

Similarly, don’t choose zones that are beyond your organization’s

ability to invest. Without sufficient investment, teams’ skills will
develop slowly, if at all, and full fluency will probably be out of
reach. You’ll incur the costs of learning without getting all the
benefits, and you might even see worse results than now if teams
don’t have the expertise they need.

So which zones should you choose? As you’ll see in the next chapter,
it starts with a conversation with management. But here’s a handy
guide.

1. Every Agile team needs Focusing fluency. It’s fundamental. If

you can’t invest in Focusing fluency, Agile isn’t a good fit for
you. You can pick and choose from the practices in this book—
[Link to Come] has suggestions—but you’ll need a different
underlying philosophy of development.
 2. Unless your teams produce code that is short-lived—less than a
year of development, with no ongoing maintenance afterwards
—Delivering fluency will pay for itself. In fact, you’ll notice
benefits within 3-6 months. Without it, your code will
eventually succumb to technical debt. That said, some
organizations aren’t ready to make such big investments. It’s
okay to start with Focusing fluency, demonstrate success, and
then use that to make the case for further investment.

3. Optimizing fluency is where Agile shines brightest. It’s also a

lot to ask. For most organizations, it’s best to build trust by
demonstrating fluency in the Delivering zone first, then
gradually take on more responsibility. But if your organization
already has a culture of delegating decision-making authority to
cross-functional teams, as is often seen in startups, Optimizing
fluency will give you great results.

Whichever zones you choose, invest in learning all of them

simultaneously. It’s easier and faster to learn Agile ideas if you
practice everything together, because the techniques in the later zones
make the earlier zones work better. If you can’t get the investments,
though, that’s okay. It takes longer, but as long as you can at least
invest in Focusing, you can build up to the later zones over time.

Once you’ve chosen your zones, you’re ready to get started. That’s
the topic of our next chapter.

Larmen says a rewrite project takes 25-50% of the time of all person-years invested to
1
date on both initial development and maintenance.

Based partly on Denne & Cleland Huang

2

“Agile Fluency” is a registered trademark of Agile Fluency Project LLC, founded by

3
Diana Larsen and James Shore. Adapted from Shore & Larsen. Used with permission.
About the Authors

James Shore has been leading teams in practicing Agile

development since 1999. He combines a deep understanding of Agile
ideas with decades of in-the-trenches practical development
experience. He uses this experience to help people understand how all
aspects of Agile fit together to create outstanding results. James is a
recipient of the Agile Alliance’s Gordon Pask Award for
Contributions to Agile Practice, host of Let’s Code: Test-Driven
JavaScript, and co-creator of the Agile Fluency Model.

Shane Warden is an engineering leader and writer, notably the

coauthor of The Art of Agile Development and Masterminds of
Programming. When he’s not working, he helps to give animals good
homes.