CHAPTER

The Agile
Principles
Welcome to the fourth industrial revolution
When I was in grade school, I read books about what could be expected to
happen in the twenty-first century. It was predicted that things like flying cars,
one-piece suits that looked like they were made of aluminum foil, and vaca-
tions on Mars would be commonplace by now. None of that stuff has come
to pass yet, but there are some amazing things happening. Nobody is happier
than me that cars can now parallel park by themselves. Cell phones now pack
more computing power than early mainframes. In fact, the primary function of
a smartphone is no longer making or receiving phone calls. People are using
3D printers to print robotic, prosthetic limbs.
And software runs it all.
We live in an age where software literally touches everything. It is the great
equalizer. Software is not built just by traditional software companies, but by
companies like banks, insurance companies, car manufacturers—you name it
and software is an integral part of it.
Welcome to the fourth Industrial Revolution…
Time for a little history lesson. The Agricultural Revolution occurred when
human beings started planting crops and domesticating animals. They became
less nomadic. In other words, people stopped wandering around and stayed in
one place. They worked the land and herded animals.

© CA 2016
D. McKenna, The Art of Scrum, DOI 10.1007/978-1-4842-2277-5_1
4 Chapter 1 | The Agile Principles

The Industrial Revolution caused people to leave their farms. Humans started
working with machines in factories. Villages were abandoned for big cities.
Factory work was structured, measured, and steeped in command and control.
The Information Revolution relies on knowledge workers. The term
knowledge worker does not just refer to software developers. Anybody who
handles or uses information can be classified as a knowledge worker——
folks like doctors, teachers, and scientists. Knowledge work is different. For
example, the emphasis is more on changing things than running things. Less
structure and continuous innovation is required as the work is constantly
changing and evolving.
The fourth Industrial Revolution refers to quickly emerging, disruptive tech-
nologies that fundamentally will not only change the way we live and work,
but how we relate to each other. The ability to collaborate, pivot, and adapt
to change is critical to survival in the age in which we now find ourselves.
Technology is everywhere and is impacting both business and society. The
lines between physical and digital are being blurred—requiring, dare I say, agil-
ity to survive and thrive.

What Animal do You Think of When I Say the

Word “Agile”?
When I ask that question, most folks pick the cheetah. On the surface, that is
a great choice; however, I think that what the furry speed merchant is trying to
chase down may actually be the best example of agility in the animal kingdom.
The cheetah is the fastest animal on land. No doubt about that. The cheetah’s
favorite meal, the Impala antelope, is almost as fast but can run at top speed
for a longer time. A cheetah can only run all-out for around twelve seconds
or so. To keep from becoming dinner, the antelope needs to hold the cat off
until it cannot sustain the effort required to keep up the frantic pace. The
impala will jump and change direction quickly and force the cheetah not to
pursue in a straight line, where its superior speed would enable a quick kill.
The antelope tries to tire out the sleek cat by using superior agility. In the
animal kingdom, agility is vital for survival.
 The Art of Scrum 5

Agility is About Moving and Adjusting Quickly

In my freshman year, I believe it was 1981, I had fractured my ankle on the first
day of practice in pads during the first play I tried to run as a quarterback. As
I learned, the weakness of a four-four defense was either up the middle or
around the end. I took the ball around the right of the defense for a 30-yard
gain. I focused on the air whistling through my helmet. Running like the wind…
until I stepped in a gopher hole. As the defense caught up to me, I hear the
head coach yell, “If that was a good quarterback he would have scored!”
It took a long time for my ankle to heal, so I did not play during my sophomore
year, On top of that, I wasn’t exactly what you would call graceful. I would say
that I was gangly, not used to my six-foot frame. My Uncle Frank, who played
for the University of Nebraska and was trying to help me with my ill-fated high
school football career, had a different term he used to describe my movement
patterns:
Heavy Footed.
“What do you see boxers doing all of the time?" My uncle asked.
“Jumping rope,” I replied.
“That’s right!” he said. “Every chance they get, those guys jump rope. That is
because footwork is important to a boxer. Same thing with football. You need
to do a lot of agility drills like jumping rope because you can’t move your feet.”
I jumped rope, lifted weights, and ran, but the football thing never panned out
for me. I find it somewhat ironic that the person who could not get out of his
own way now coaches Agility.
No, not that kind of agility…
If you challenged me to describe the Agile framework in one sentence, I would
say this:
Agile is about adapting to change, not planning everything out up front.
Agile is many things. Iterating often, freeing development up to do what they
do best, aligning the business with software, trying to produce stuff that our
customers really want to buy, and developing a culture of continuous improve-
ment——All great stuff that is part of Agile. However, to me it is all about
responding to change.
6 Chapter 1 | The Agile Principles

In my early days on a development team, change was a disruptive force that

was about as welcome as a rabid raccoon in your garage. Since all the planning
was done at the beginning of a project, any type of change created problems.
A team needed to avoid change at all cost.
However, in reality the change we were avoiding was a customer that needed
help. It was a flaw with a design that needed addressed, it was harnessing a new
technology to make a product better. The requirements change so quickly
that it is foolish to try to plan out a large-scale release up front.
Teams need to embrace change. They need to shift the way they work. Change
is going to happen. Agile teams need to crave change. Sticking to the plan is
not going to cut it anymore. The power is in the ability to pivot and adapt
quickly. That is how we create delighted customers.

Who Doesn’t Like Waterfalls?

When I started working for a software vendor, I did not know that we were
using the Waterfall methodology; I just thought it was the way we did things.
The Waterfall methodology has goals for each phase of development. Once
a phase of development is completed, you move on to the next phase. You
cannot turn back once you have passed through a phase. Since we are talk-
ing about waterfalls, let us look at probably the most famous waterfall in the
world, Niagara Falls. When you go there, the beauty and majesty of the place
makes an impact. The sheer volume of water that passes over the falls every
day is amazing. One thing that is obvious is that once water goes over the cliff
you cannot get it back up the mountain. The same with Waterfall develop-
ment. As you see in Figure 1-1, you cannot turn back.
 The Art of Scrum 7

Figure 1-1. Once water goes over the falls, there is no going back

When you think about how you build software, the Waterfall model describes
a method that is linear, gated, and sequential. You take a development project
and you break it up into stages or phases of development. Each one of these
phases has a goal. You move onto the next phase once you achieve the goal.
I have seen Waterfall described as resembling a track and field relay race. A
runner takes a baton, runs his leg of the race, and passes the baton to the next
runner.
Figure 1-2 shows the phases of the Waterfall method.
8 Chapter 1 | The Agile Principles

Figure 1-2. Waterfall phases

The Requirements Phase

A team will start with the requirements phase, as shown in Figure 1-3. This is
where business analysts or product marketing define the requirements.

Figure 1-3. The Waterfall Requirements phase

In other words, they would figure out what we were going to build, and what
both customers and the business require out of this project. The goal for
the requirements phase is usually some kind of requirements document that
details the team’s findings.
 The Art of Scrum 9

As shown in Figure 1-4, the team did all planning in the design phase. Design
work consists of stuff like deciding how the team will write the code. They
would figure out the languages and techniques to use, to best deliver func-
tionality and value, and even who would work on what. The result of all this
work would be the development staff producing an internal requirements
document, as shown in Figure 1-5.

Figure 1-4. The Waterfall Design phase

Figure 1-5. The Waterfall requirements document

10 Chapter 1 | The Agile Principles

The Implementation Phase

The Implementation phase, as shown in Figure 1-6, is where developers do
what they do best. They write the code and transform ideas into functional
product. Developers take the requirements as defined in the Requirements
phase and create value for customers. At the end of the implementation
phase, software is produced, and that software resembles a viable product.

Figure 1-6. The Waterfall Implementation phase

The Verification Phase

We have software at this point, and that is a good thing. However, software
needs to be in good working order. Figure 1-7 shows the Verification phase,
where the Quality Assurance engineers test the software. They work to
ensure that the team delivers a high-quality product to the customers. The
QA engineers take the design document produced during the design phase
and create test plans from it. They execute the test plans against the software
produced in the Implementation phase. The development staff addresses any
defects found. The quality assurance engineers work as a separate team. They
are not considered part of development.
 The Art of Scrum 11

Figure 1-7. The Waterfall Verification phase

Once the software is thoroughly tested and everybody agrees that it is in a

stable state. The release enters a beta period. This could be considered a
phase of Waterfall; however,I see it as part of the verification phase. During
Beta testing, the release is packaged and given to a specific subset of custom-
ers to try in their environment.

The Maintenance Phase

Once everybody agreed that the product is ready, it is released, or deemed
Generally Available (GA). Once the product is “out the door,” the release
is in the Maintenance phase, as shown in Figure 1-8. Sustaining engineers or
developers address any defects discovered by customers, and business people
decide whether another release of the product is needed.
12 Chapter 1 | The Agile Principles

Figure 1-8. The Waterfall Maintenance phase

Makes sense, right? At first glance, Waterfall looks like a sound way to pro-
duce quality software. Truth be told, I was involved in the creation of some
best-of-breed products using Waterfall.
However, there are some major flaws with Waterfall that are severely prob-
lematic here in the application-driven economy of the twenty-first century.
If requirements change in a Waterfall project after the requirements phase,
everything has to stop and the new requirements need to be evaluated. This
causes a domino effect where all of the other phases get “pushed out.” This
adds cost to the project, and it makes the GA date a whole lot harder to hit.
As you can probably imagine, management would not be happy about this
turn of events. We now live and work in a world where requirements change
rapidly, so there is ample opportunity for requirements to change quite a bit
during a twelve or eighteen month release.
You may be asking yourself “Why does Waterfall take so long? Twelve to
eighteen months is a long time.” One of the biggest reasons I can think of is
that customers were used to that cadence. They would try to get as many
requirements as possible into the next release because it took a long time to
get releases out. That was a big pile of requirements that may or may not be
relevant when the functionality is delivered.
It is also problematic that the Quality Assurance folks do not get their hands
on anything until the code is finished. Look, I like developers. I really do, but
everybody needs to understand that every new line of code is a potential
defect. I am not accusing anybody of writing bad code. That being said, we are
 The Art of Scrum 13

all human. Mistakes are made. Couple that with the fact that teams are work-
ing on incredibly complex products, and you are going to have some bugs. The
earlier you find a bug in the development process, the easier it is to fix. It also
costs a lot less to fix. In Waterfall, the bugs did not show up until the very end
of the project, in the verification phase. Think about that for a second. How
do you predict how many defects were going to be found? How do you plan
for that?
In my experience, the verification phase always threatened to push out the
GA date because of the amount of time required to fix all of the defects. This
resulted in a stress-filled mad scramble to make the GA date. The quality
assurance engineers and developers were also two separate teams. This led
to an “us versus them” attitude——especially when stress levels were high.
Most importantly, customers and stakeholders did not get to see the new
product until Beta or GA. The customer would make their requirements
known, and a year later, we would produce a shiny, new thing.
However, how do we know we built the correct shiny, new thing?
Allow me to give you an example. I play bass guitar at my church. I am by no
means anywhere near a musician, but I can play in the correct key, most of the
time. Figure 1-9 shows the instrument that I play is an old Peavey Foundation
four-string rig. It stays in tune, and fits me well.

Figure 1-9. My bass guitar is not flashy; however, I can move furniture when I hit an open
E string
14 Chapter 1 | The Agile Principles

I found out that my daughter Bailey was going to buy me a new bass guitar for
Christmas, and I stopped her. I was touched by the fact that she would put that
much thought into a present for me, but there is no way she would be able
to buy an instrument that I would be happy with. I am very particular about
how my bass plays. The action, the feel of the fretboard, how the pickups are
situated on the body. There is no way I can tell if I am going to like a particular
bass guitar until I play it.
Same thing with our customers. The team tries to build something that satis-
fied what was asked for, but more often than not, this was not the case. Sure,
we had a Beta period, but that was to make sure the software worked, not to
change functionality.
Waterfall development was impacted by changing requirements, unrealistic
deadlines, and bad estimating. The biggest impact was on the people. Notice I
said people, not resources. A resource is something you use up, like toilet paper.
People are amazing and talented. Waterfall caused low morale, burnout, and
even health problems. Something had to be done…

Enter the Agile Manifesto

Personally, I am not overly comfortable with the word manifesto. Since I am a
child of the Cold War, whenever somebody starts throwing the word mani-
festo around I start thinking of the great workers’ paradise that was the for-
mer Soviet Union…or the Gulag.
Karl Marx and Friedrich Engels wrote The Communist Manifesto to declare
their thoughts on what the perfect society would look like. It was a document
that changed the world, but it was not the only one. As I see it, a manifesto is
a proclamation of ideals and intentions. The Declaration of Independence was
a manifesto. President Kennedy’s Land a Man on the Moon speech is another
example.
When I was a teenager, I wanted nothing more than to be a monster. No, not
like Godzilla or Frankenstein. I was the kid who was picked on. As I saw it
muscles and strength were my armor, and I desperately wanted them both. In
my mind, a person who could rip a door off the hinges and then have to turn
sideways to fit though the door was automatically respected by his peers and
feared by bullies. There was a secret… a way to this muscular Nirvana, and I
was going to find it.
Mind you, these were the days when the internet only existed in Al Gore’s
imagination, and training information was nowhere to be found. As a result,
my friends and I wasted countless hours flailing away on our plastic Sears and
Roebuck weight sets while dumping our hard-earned paper route money into
worthless supplements.
 The Art of Scrum 15

Then it happened. I do not know if it was divine intervention, serendipity,

or just dumb luck, but a friend’s uncle took us under his wing and showed
us the secret. We took what he gave us and made a manifesto, of sorts.
We wrote it out and taped to the wall of his garage. Right in front of the
squat rack.
• Lift heavy. Challenge yourself to set a personal record
every workout in something.
• Never miss a repetition. We were introduced to some-
thing called rest/pause training, which I will detail later.
• You grow when you rest. Working out for two hours
a day, every day will make you small and weak.
• Eat real food. A lot of real food. No supplement or drug
in the world can take the place of actual food.
As I said before, a manifesto is a public declaration. It is a statement of how
we intend to carry out what we do from this point forward. It may not have
changed the world, but it changed my world.
In 2001, a bunch of really smart people got together at a ski resort. As I
understand things, most of them were lean, or extreme programming (XP)
pundits who were coming together to talk about lightweight methodologies.
They came up with what we now know as the Agile Manifesto.

Individuals and Interactions over Processes and

Tools
As the old joke goes—if you put a bunch of monkeys in a room with type-
writers, eventually….by luck you will end up with the complete works of
Shakespeare. Supposedly, this is a mathematical possibility…
I doubt it. Mathematically possible or not…
Same idea here. A super well-defined process, the top-of-the-line tools, the
best facility in which to work, catered lunches every day, a ping pong table…
none of it matters if the team can’t work together.
However, if any of my management chain is reading this, catered lunches are a
great idea. Just sayin’.
A better bet would be to throw the team in a room and let them figure out
the best way to do the job. The idea is that the team needs to talk to each
other. When I say talk to each other, I mean everybody talks to each other. I
have had the pleasure of working in the software business for over 20 years.
That means that I have taken part in many meetings. In those meetings, I have
16 Chapter 1 | The Agile Principles

heard a lot of talking by the senior developers, architects, development man-

agers, directors, and so on. Not a whole lot of input from the junior staff, the
QA team, or User Experience engineers. My guess is that they were afraid to
speak out of turn because they felt they would be dismissed or made to feel
less than adequate.
It is much healthier to engage in collaborative team meetings. The idea is to
get everybody on the team to talk to each other, and to understand the per-
spective they are coming from. For example, I have always said that I could say
the dumbest thing you ever heard in a meeting, but still provide valuable input.
That is, what I say is not at all that valuable in itself, but it lets you see where
I am coming from. In other words, you understand my perspective, and have
a pretty good idea of what my thought process looks like. It is the interac-
tion between people that builds great software, solves problems, and delivers
value. People need to be able to communicate and work together. If you do
not get that right, you are not going to be successful.
Tools and process can still provide value, but neither is the magic bullet. Take
the smartphone, for example. For some reason, the more connected we seem
to be in the twenty-first century, the less connected we really are. We seem
to want to hide behind our phones and not interact with the person standing
next to us. When my daughter and I are at the mall and she sees somebody
she does not want to talk to, she pulls out her phone and starts texting or
tweeting or whatever the cool kids do these days. I do not understand it. If
you leave me by myself at the mall for a half hour, I will have spoken to at least
three people and know everything about them. I even make it a point to try
to strike up a conversation with folks when they are in the elevator with me.
Sometimes, I think I scare them. I guess that whole monster thing backfires on
me in this case. Most of the time, folks act somewhat pleasantly surprised that
another inhabitant of planet Earth is acknowledging their existence.
I guess I am a people person.

Working Software over Comprehensive

Documentation
If you are having problems sleeping, start reading some technical documenta-
tion. Think about it—when do you read the documentation that comes with
something you buy? Is the first thing you do when you buy a car is to find a
comfortable chair and read the owner’s manual? I don’t even know where the
owner’s manual for my car currently is.
Most of the really good developers that I know are detail-driven and heavily
steeped in process. A developer benefits from these characteristics, no ques-
tion about it, but it also means they can be easily distracted from what they
should be focused on:
 The Art of Scrum 17

Writing software that produces customer value

Teams need to consider the user’s perspective when building software.
Remember, the goal is to build something that customers actually want.
Documentation is still needed, just not on a grand scale. When generating
documentation becomes a priority over generating value, things are out of
whack. I am not saying that we stop generating documentation. The key is to
have just enough documentation to support the working software. Notice
that it says working software. This means zero defects. When bugs are found,
they are addressed as soon as possible—even if it means the team stops
working on new features to do it.

Customer Collaboration over Contract Negotiation

Customers use our software in ways we never thought of to solve problems
we never heard of. The truth of the matter is that developers are not users.
The scrum team needs to collaborate with the customer to get a solid under-
standing of what they are looking for. In order for a team to create software
that customers want, you kind of need to know what they, you know … want.
A contract does not take the place of communication. I have been a part of
projects that management loved but that never saw the light of day in the
datacenter because the people who actually do the job did not see the value
in it. Not only must the team collaborate with the customer, they must col-
laborate with the folks who are “closest to the glass,” the people who use the
product.
Remember, requirements change rapidly. The customer may not know what
they want at first. They will change their minds. They may not do a good job
of communicating. Constant collaboration allows the team to overcome these
obstacles and deliver something truly valuable to the customer. It allows the
team to focus continuously on the end goal, and not anything else.

Responding to Change Over Following a Plan

Change is disruptive. Change is messy. Avoid change at all cost. That is how
change was viewed before the Agile Manifesto. That was then. This is now.
The application economy is disrupting how customers go about their business,
and how that changes what they require from the products they buy. These
days, requirements change so quickly that it is foolish to try to plan out a
large-scale release up front.
Agile teams need to embrace change. This means that they need to shift how
work is done. We know change is going to happen. We should be expect-
ing it. Part of our release plan should be to adapt to change. Instead of saying
“Look at what I built for you—Isn’t it cool?” we should be thinking about how
18 Chapter 1 | The Agile Principles

to deliver small slices of what we plan to build at regular intervals. This way
customers can get their hands on what we are building. They get to try the
new functionality and give us feedback.
And expect disruptive change to come from the customer feedback we get.
That means that we do not plan 10 months ahead in intricate detail. A team’s
release plan and Backlog priority should be constantly changing and evolving
due to changing requirements and feedback.
The power is in the ability to pivot and adapt quickly. This ensures that what
the team builds is what the customer wants. Even if it isn’t what was originally
planned.

Wait, There’s More

In addition to the manifesto, the authors defined 12 principles. Most folks do
not refer to the guiding principles when they talk about the Agile Manifesto. I
am not sure why. I think the guiding principles are just as important as what is
contained in the Agile manifesto itself, if not more. These principles are simple
enough to understand, they but also have a deeper complexity that brings out
the deeper meaning of Agile.

1. Our highest priority is to satisfy the customer

early and continuously deliver valuable software
Back when I was working in customer support, we used the phrase “delight
the customer.” Think about that for a second. When you are satisfied with
something, it is a good thing. There is nothing wrong with satisfied, but when
you are delighted, that is taking it to a completely new level. If I am finished
with a big meal at a fine dining establishment, I am probably satisfied. I will be
smiling, patting my belly, and generally happy with what I just ate. If the meal
delighted me, I cannot wait to tell all my friends about the awesome meal I had
at this establishment. I am on social media as fast as possible, telling everybody
about my experience. This became a mantra of sorts——do not just satisfy
the customer, delight them. That is what we should be all about——delighting
the customer—Not delighting management. Delighting our customers. If the
teams focus on anything else but the customer, then the focus is in the wrong
place. The goal is not just to produce something that the customer wants, but
something that the customer cannot wait to get their hands on.
This requires developers to change the way they work. It is necessary to
rework the way code is written. It may require the team to change the way
they work together. This can be a struggle, especially if not everyone on the
 The Art of Scrum 19

team is comfortable with this idea. The team needs to understand that it is
better to get something wrong upfront and have time to pivot and deliver
what the customer really wants.
Think of it like a wedding cake. Let us say that you are paying for a wedding.
Yes, that is extremely frightening. Trust me, I have two daughters.
I think everybody would agree that next to the bride’s dress, the wedding cake
is the most important decision to be made. Knowing this, as the person buying
the cake, you want it to be perfect. I am sure that the pastry chef making the
cake wants to delight you.
However, if a huge, seven-tier cake shows up the day of the wedding and
the bride does not like it, there is a good chance we have a living, breathing
Bridezilla on our hands.
Trust me; nobody wants that, so we have a tasting. We get to taste the cake
and see what it is going to look like. I would not expect to see the huge cake
here. I would expect a Minimally Viable Product. A smaller version of the fin-
ished product that stands on its own. We get to taste the cake, icing, filling,
and whatever. We could also possibly see some of the decorating techniques
that are planned, but we are not seeing the finished cake. This way, we can give
feedback and let the pastry chef know what we want.
Maybe we wanted strawberry filling between the layers, but now we do not
like the idea, or we like flowers instead of birds, or fondant instead of butter
cream icing.
The idea is that we get an idea of what the final product will be by working with
a small prototype. We can then give feedback and get exactly what we want. In
the wedding cake example, we might only do this one or twice. When develop-
ing software, the team delivers early and frequently so that there is plenty of
opportunity for feedback from the people who are going to use the software.
That ensures that what you are building is not the wrong thing but the right thing.
Which brings us to the most important point. In the end, all the customer
cares about is that what you have produced is something valuable to them.
That is what the team needs to focus on.

2. Welcome changing requirements even late in

development
Agile is about adapting to change, not planning everything out up front. If you
have not noticed yet, I have been talking about change quite a bit. Change
is the reason teams need to change the way work is done, but it is more
than that. Customers cannot make their requirements known, because those
requirements are constantly changing.
20 Chapter 1 | The Agile Principles

Agile teams work in a manner that expects and embraces change. This way,
customer requirements can be satisfied—even if they change late in the
project.

3. Deliver working software frequently, from a

couple of weeks to a couple of months, with a
preference to the shorter timescale
I remember when I challenged my team to deliver what we were building
in small increments. “We can’t deliver all of that functionality in that short
amount of time.” they said.
“What if you work on some of the functionality and mock up the rest?” I
suggested.
The look on their faces was priceless. It was as if I suggested that we all cut off
a finger and try to sell them. Seriously, they were horrified.
It is human nature to not want to show something off until it’s done. But it
does not make sense to hold stuff back until we think it is, well… good. A
team needs feedback as early in the project as possible, and then at regular
intervals. The absolute best way for a customer to give useful feedback is to
try out what has been built. A team can produce slideshows, technical dia-
grams, and even demos of the functionality they plan to produce, but nothing
is better than working software. A team works in iterations, or Sprints, that
last from two to four weeks. The goal of the Sprint is to produce a minimally
viable product (MVP) that the customer can take “for a test drive.” After play-
ing with the software, the customer can provide the team with the feedback
they so desperately crave. An added bonus is that the status of the project
is as transparent as can be. The customer knows exactly what the team is
producing as well as how long it is taking.
Speaking of that, a team should strive to make Sprints as short as possible.
That makes sense if you think about it. The shorter the Sprint, the more feed-
back the customer can provide.

4. Business people and developers must work

together daily throughout the project
The idea behind a software project is to satisfy the business. In other words,
to make money. It is easy for a team to focus on the wrong thing. When you
keep the team focused on the business, they have the proper perspective.
The team learns much more about the business this way than by going over
lists of requirements. The team needs to be encouraged to interact with the
 The Art of Scrum 21

customer as much as possible. It may not be possible for the team and cus-
tomer to interact every day, but contact should be as often as possible.

5. Build projects around motivated individuals. Give

them the environment and support they need, and
trust them to get the job done
The team is the most important entity. It may not be possible to build a
“dream team,” but to be honest it really does not matter as much as you
think. That being said, management cannot throw a bunch of junior program-
mers together and expect miracles to happen. The key is to form a team that
can work together, and then let them do the work.
In the Waterfall days, the development manager would tell the team what to
do and how to do it. Customers took every opportunity to try to get the
team to put the functionality they wanted into the product. Salespeople would
bother the team to drop everything and provide functionality that would help
to close a sale. Teams were also asked to provide demos, help support, and a
bunch of stuff I am forgetting.
An Agile team is insulated from all of this. Instead of a development manager,
the team has a Product Owner that is responsible for talking to customers,
understanding how they work and what value they would gain from the proj-
ect, and building a prioritized Backlog of work. The team uses the Backlog
to build what the customer wants. The Scrum Master (another Agile role) is
responsible for protecting the team. All of the distractions are gone, allowing
the team to focus.

6. The most efficient and effective method of

conveying information to and within a Development
Team is face-to-face conversation
Face-to-face communication is most effective because all facets of commu-
nication are in play. You have facial expressions, tone, body language, and the
actual words being spoken.
One of my favorite coaching experiences was when the mother of a player
marched up to the head coach and me. I could tell by the look on her face
that she was upset about something. Actually, mad as a wet hen is probably a
better description. She got uncomfortably close to the head coach and said “I
didn’t appreciate the tone of your email.” She then pivoted and walked away.
“How do you get tone from an email?” said the head coach with a quizzical
look on his face…
22 Chapter 1 | The Agile Principles

Communication is vitally important. Agile won’t work without it, so we should

be striving to use the most effective method possible. If you try to commu-
nicate using email or some type of Instant Messenger, you are losing one or
more facets of the communicative process.
And it’s faster. If we were communicating via email, you would need to wait
until I read the original email and respond to find out if I even understand
what you are trying to say, let alone my feelings on the subject. Face to face,
that happens immediately. As a result, understanding flows easily.

7. Working software is the primary measure of

progress
Working software needs to be where the team is focused. Not on documen-
tation, or design, or anything else. Development Teams seem to want to focus
on completing development. Completed development and working software
are not necessarily the same thing.
In other words, software is not done if it compiles or assembles. It has to
“work,” meaning it can be tested and is demonstrable.
Let’s go back to the wedding cake example. If the pastry chef shows up at the
cake tasting with a recipe in his hand and tells you that he’s perfected it for
your wedding but has no cake for you to test, would you be happy?
I think not…
To be successful, the pastry chef needs to focus on tasty cake. The team needs
to focus on working software.

8. Agile processes promote sustainable development.

The sponsors, developers, and users should be able to
maintain a constant pace indefinitely
The mad rush to get projects to the GA date required long hours. The teams
that I was involved with pulled together and got the work done, but it was
not fun. I am sure that the pace wasn’t sustainable for more than a few weeks.
Look at it this way. The fastest marathon runners in the world run the 26.2
mile course at a six-minute mile pace. That pace is sustainable for them, but
it is far from an all-out sprint. Nobody in their right mind would try to sprint
for the entire length of a marathon.
Neither should a Development Team.
 The Art of Scrum 23

When I was in basic training, the drill sergeant was fond of saying that if we
were supposed to have a family, it would have been issued to us and grounded
at the right side of our foot locker. This should not be the prevailing attitude
of the people you work with. Work-life balance is important. A sustainable
pace supports a healthy work-life balance.

9. Continuous attention to technical excellence and

good design enhances agility
Clean code is easier to work with than spaghetti code. That should be obvi-
ous. I doubt that any person who ever worked as a developer woke up one
day and said “Today I will write code that is complex, convoluted, and hard
to understand.” It happens because of the pressure required to get projects
complete and make dates. An Agile team needs to be constantly mindful of
the code they write. Once the code becomes a mess, you lose the opportu-
nity to pivot quickly and respond to feedback. In other words, you lose agility.
The same with design. Why go off and spend a great deal of time coming up
with a complex design for the entire project when you are expecting change?
Design must be clean, efficient, and done in a way that embraces change. I like
to say that coding and design must accept change gracefully.

10. Simplicity—the art of maximizing the amount of

work not done—is essential
This seems counterintuitive. After all, a Development Team exists primarily
to write software.
Yes, that is the idea. The team should be all about building awesome stuff——
just as long as they are building the right stuff.
This requires development to reframe the way they think about writing code.
If a developer writes a simple function, they will assume they need to look at
all possible scenarios and do all kinds of work that really isn’t necessary.
“Well, this might happen, so I better build something into the function for it.”
“While I’m at it, I might as well call this other routine to make sure the data is
good… And I guess I should prepare for this other thing as well.”
An Agile team should create the function as simply as possible. Get in, do
the work as simply as possible, and get out. I’m being simplistic here (while
discussing simplicity, no less), but this is the way teams need to look at devel-
opment. All of the other stuff you think you “might” need is a waste of time. If
you need to add it in the future, add it then. I’ve heard it said that the majority
of features built are hardly ever used. Complexity leads to unreliability. Agile
teams strive for simplicity by building only what is needed at the time.
24 Chapter 1 | The Agile Principles

11. The best architectures, requirements, and

designs emerge from self-organizing teams
I coached cross-country for 5 years when my daughters ran. The sport of
cross-country is exactly what it sounds like. You run in the woods. My coach-
ing style would normally consist of me showing the runners the course and
saying “get after it.” I would then stand at the finish line with a stopwatch and
wait for them.
Parents would always ask me if I was going to run with the kids or give them
pointers on how to race. My answer was always the same:
“They will figure it out themselves.”
The truth is that I would do more to screw things up than fix them if I got
too involved. Running is simple; we all can do it. Racing requires dedication
and desire. Somebody like me yelling at you to run faster isn’t the proper
motivation. Wanting to beat the kid in the different-colored shirt is. I always
found it amazing that after the first race the team stopped walking and started
running—hard. The proverbial light bulb went on.
It’s the same thing with an Agile team. They don’t need a development man-
ager who tells them how to do everything. Just like the runners, the team fig-
ures it out as they go. Instead of trying to design everything up front, the team
allows the design to emerge as they are building the functionality. Give them
a goal and get out of the way. They will figure out the best way to get there.

12. At regular intervals, the team reflects on how to

become more effective, then tunes and adjusts
Agile is about inspect and adapt with a focus on experimentation.
—Bob Carpenter, CSM, ICP-ACC, CSP

Agile is all about continuous improvement. An Agile team inspects everything

that it does and routinely makes changes in an effort to try to get better.
Doing a post-mortem after a project is great, but the project is over. That
ship has sailed, and the lessons learned can only be applied to a future project.
By contrast, an Agile team takes the time to do regular retrospectives during
the project. In these retrospectives, the team identifies ways to improve and
tries to incorporate them into the way they work. The team gets to try new
things, keep what works, and throw out what doesn’t. By focusing on constant
improvement, the team can’t help but improve.
 The Art of Scrum 25

That constant improvement creates high-performing teams.

This chapter provided an overview of Waterfall software development, the
Agile manifesto, and the twelve principles of Agile software. The next chapter
will examine Scrum, a lightweight framework that promotes iterative develop-
ment as described in the Agile Manifesto.