Agile Anti-Patterns

© 2016 Stellman and Greene Consulting LLC http://www.stellman-greene.com/slides/agile-antipatterns.pdf
Agile Anti-Patterns
Understanding “better-than-not-doing-it” results

About Andrew Stellman
• Author and international speaker, with top-selling books
in software development and project management
• Referred to as one of “the industry’s best and brightest”
by Dr. Dobb’s Journal (2006)
• World-recognized expert in transforming and improving
software organizations, teams, and code
• Agile coach and team lead (Scrum, XP, Lean/Kanban)
• PMP certified project manager and trainer, PMI-ACP and
CSM certified Scrum Master and agile practitioner
• Built, managed, and lead teams of (up to 80+)
programmers, business analysts, project managers
• Architected, designed, and programmed large-scale
front-end and back-end systems

About Jennifer Greene
• Author of top-selling books in software
development and project management
• Agile coach and team lead (Scrum, XP, Lean/
Kanban)
• PMP certified project manager and trainer,
PMI-ACP certified agile practitioner
• Currently building and managing
geographically distributed teams building
large-scale enterprise software using agile
practices
• Built and managed large development and
test teams across many different industries

In this presentation, we’ll examine a
few of the most common antipatterns
that agile teams run into.
We’ll use those antipatterns to explore
how agile practices are driven by
values, and learn how understanding
that relationship can help us achieve
better results for our own projects.

Let’s start with a few examples
of antipatterns and a quick
review of what agile is.

Brooks’ Law is a very common
project management antipattern
“Adding manpower to a late project makes it later.”
– Fred Brooks, The Mythical Man-Month (1975)
“Brooks’ Law” describes a bad
situation that a lot of teams
find themselves in. It’s one of
the most common project
management antipatterns.
Even though it’s called a “law,”
it doesn’t really apply to every
project. But we recognize the
basic truth in it from our own
project experiences—that’s
what makes it an antipattern.
an • ti • pat • tern, noun
An approach to a problem that is frequently used but usually ineffective

Other common project
management antipatterns
“Work expands so as to fill the time available for its completion.”
– C. Northcote Parkinson (“Parkinson’s law”)
“Failure is not an option (that we’re comfortable planning for).”
Optimism bias: ignoring risks because of a project’s importance
“The first 90% of the code accounts for the first 90% of the development time. The
remaining 10% of the code accounts for the other 90% of the development time.”
– “The ninety-ninety rule” (Tom Cargill, Bell Labs, 1985)
“It’ll take about three weeks.”
Said by every software developer at some point in his or her career

What is agile?
(a quick review)
Agile is a set of methods and methodologies
• Scrum is an agile methodology focused on project management
• XP is a methodology that’s centered around software development
• Kanban is a method for process improvement
Agile is also a mindset
• The mindset of agile is driven by the values of the Agile Manifesto
• Agile methodologies like Scrum and XP come with their own values
• Kanban is rooted in the values of Lean thinking

Agile methods and methodologies
use effective and simple practices
Scrum practices are focused on project management
sprint
product backlog
Daily Scrum
retrospective
sprint backlog
sprint review
XP practices are focused on software development
Kanban practices are focused on process improvement

Agile values drive the team’s mindset
Agile teams value processes and
tools. But they value even more
the people on the team and the
way that they interact with
each other to solve problems.
A contract negotiation mindset
is one where hard-and-fast
agreements are defined between
the customer and the team. True
collaboration is more effective.
The Agile Manifesto
Individuals and interactions
over processes and tools
Working software over
comprehensive documentation
Customer collaboration over
contract negotiation
Responding to change over
following a plan
It’s easy for a hyper-focused team
to lose track of what the users
actually need. This value makes
sure that the users’ perspectives
and ideas are genuinely represented.
...because working
the wrong plan
causes the team
to build the wrong
software.

When the team “gets” the values,
they get more out of the practices
Many of these slides
use illustrations
from our book
“Learning Agile”
Like the fable of the blind men and the elephant, the
agile “elephant” is more than the sum of its practices.

Antipatterns can cause your team
to work much less effectively. The
daily standup is the most
common* agile practice, and a
very common antipattern that
affects agile teams is directly
related to it. A better mindset can
fix that antipattern and make
your team much more effective.
* Source: 2016 VersionOne State of Agile Report – http://stateofagile.versionone.com

Antipattern: a daily standup devolves
into an ordinary status meeting
Let’s hold a daily standup
meeting so I can get status from you
every day. That’s a great practice that
we can all get behind.
We already have too
many meetings! If you don’t
trust me to do my job, find
someone else to do it.
Project Manager
Developer
This is one of the most common agile antipatterns.
It’s so common that most teams think it’s normal.

They miss the point... but the
meeting still produces results
The project manager uses the
daily standup to get status
updates on his plan and give
team members their next
assignments.
I only find
out about a
problem when
it’s too late
for me to do
something
about it.
The developer wants to get back
to coding, so he gives his update
and spends the rest of the
meeting looking at his phone.
Project Manager
when you keep
dragging me
to meetings, I
don’t have
time to write
any code.
Developer
The daily standup is less effective than it could be,
but it’s still effective enough that it’s worth doing.
We call this “better-than-not-doing-it” results.

Most team members focus on practices that
directly help them do their jobs, but rarely
think about the big picture
If each team
member only pays
attention to the
practices that he
or she is using, the
project will still
get results, but the
people on the team
aren’t really
working together.
But the practices
are still effective
and worth adopting.

When everyone on the team understands
the principles behind the daily standup
practice, they get more effective results
What if the developer and project
manager had a different mindset?
With shared values, the project
manager doesn't think of it as
his plan, he thinks of it as the
plan everyone on the team
worked together to create.
So the
daily standup
means You’ll listen
to me and actually
change the way the
project runs?
And the developer does more
than just give status. He has (and
shares!) opinions on the whole
project, and the daily standup
becomes important to him.
When everyone values communication and shared
commitment, the daily standup is much more effective.

We’ll concentrate on antipatterns
that Scrum teams encounter
because it’s by far the most
common agile methodology.*
* Source: 2016 VersionOne State of Agile Report – http://stateofagile.versionone.com

What is Scrum?
(a quick review)
• There are three main roles on a Scrum project: product owner,
Scrum Master, and team member
• The Product Owner maintains a backlog of features and
stories that need to be built, organized by value and difficulty
• The software is built using timeboxed iterations called sprints
• At the start of each sprint, the team plans together to
determine which features from the backlog to build
• Every day, the team holds a short face-to-face meeting called
a Daily Scrum to update each other on the progress they’ve
made, and the roadblocks ahead
• The Scrum Master keeps the project rolling by helping the
team identify and remove roadblocks
• Working software is demonstrated at the sprint review, then
the team holds a retrospective to figure out lessons they’ve
learned so they can improve

What better-than-not-doing-it
results feel like to a Scrum team
• It was worth adopting Scrum, but you’re not seeing the
“astonishing” results that books and trainers promised
• The practices somehow feel “empty” — like everyone is going
through the motions, but projects are only marginally improving
• Things went well for the first few sprints, but they’re starting to
slow down and you’re not sure why
• You’re getting second-guessed by management about what
features to include in the software, and it’s not clear exactly
who’s supposed to make decisions about what features to build

Antipattern:
Command-and-control Scrum
• Command-and-Control project
managers feel like they create and
“own” the schedule by themselves
• They get estimates from the team
and create the plan on their own
• Team Leads assign work to the
team members to do exactly what’s
required by the plan
• This can lead to “water-Scrum-fall”:
the project is planned up front, and
iterations are just project phases
This is a better-than-not-doing-it result. It gets the
job done, but the team could be much more effective.

Antipattern: Product Owner
without authority
You want to
include that feature in the sprint? Wow,
that decision’s way above my pay grade. I’ll
have to check with my boss, and maybe his
boss, and…
Product Owner
If the Product Owner doesn’t have
the authority to make product
decisions, the team can’t plan
effectively. The better-than-notdoing-it
result is that the team
still produces some work, but users
and managers aren’t happy and team
has to tear out and redo features.
The Product Owner decides what items go into the product
backlog, and which of those items the team will work on
during each sprint. At the end of the sprint, the Product
Owner accepts the completed items on behalf of the
company. This depends on the Product Owner having the
authority to make those decisions. That authority is
compromised if:
• The team elects a Product Owner from within their own
ranks who does not have any special authority
• Senior management chooses a Product Owner but
doesn’t stand behind his or her decisions
• The Product Owner role is replaced with a committee

Antipattern:
Sprints aren’t really iterations
Iteration #1
Iteration #2
Iteration #3
Scrum is an iterative methodology because it uses iterations
called sprints. The team demonstrates working software to the
users at the end of each iteration. Iterations are timeboxed,
which means the deadline does not change. Work that isn’t
completely “Done” done at the end of the sprint is put back in
the product backlog and resumed in a later iteration.
But a lot of Scrum teams use sprints that aren’t really iterations:
• The deadline moves to accommodate unfinished work
• The team will demo work that isn’t really “Done” done
• Features move in and out of the sprint seemingly at random
• People aren’t working together towards a shared sprint goal
When sprints aren’t iterations, it feels like the
team’s not really able to make or meet commitments.

Antipattern:
CYA culture
It’s
not my fault that
the developers made
mistakes and blew
the deadline.
Agile teams work best when they have a
culture that gives them freedom to make
mistakes. But that only happens when
everyone feels a collective commitment to
deliver the most valuable product they can.
Project Manager
How were we
supposed to know the
project manager made bad
assumptions when he
planned the project?
Scrum is still worth doing, even with
a team that has a CYA culture. It’s
just not as effective as it could be.
Developer

Scrum has more than practices
and roles: it has values, too
Commitment: Each person is committed to the project's goals
Respect: Team members respect each other
Focus: Each team member is focused on the work
Openness: Everyone is aware of their teammates’ work
Courage: Team members are willing to stand up for the project
A lot of teams overlook the Scrum values, but they’re
the key to getting past better-than-not-doing-it
results and becoming a more effective team.

The values of Scrum and the Agile
Manifesto help you to counter these
antipatterns
Use openness and commitment to
counter the “command-andcontrol
Scrum” antipattern
Responding to change over
following a plan
Use focus to counter the “sprints
aren’t iterations” antipattern
Working software over
comprehensive documentation
Use courage to counter the
“Product Owner without authority”
antipattern
Customer collaboration over
contract negotiation
Use respect to counter the “CYA
culture” antipattern
Individuals and interactions
over processes and tools
Countering these antipatterns helps you and your
team do better than better-than-not-doing-it results.

How do you do better than
better-than-not-doing-it results?
Choose a methodology with values that match your team and company
culture, and practices that address real problems.
There are many paths to becoming agile, but there is no single, canonical agile
implementation that your team can simply follow without thinking or learning.
Find a great agile coach! There might already be one in your organization.
Start with the practices, because a great way to learn a new way of thinking is
to start acting differently—but keep a focus on learning the values as you go.
A practice that works really well for one team can utterly fail for another
because they have a different attitude and mindset.