Imagine that you knew nothing about Agile. One day, a friend
tells you, “We’ve implemented Agile practices at my
company and they’ve done wonders to our development
efforts. You should try them. Wanna visit us and take a
Intrigued about the potential for improving your own
team’s results, you visit your friend’s office. His team
is working in a noisy open space. You notice a wall
covered with stickies and duct tape, and upon close
examination you realize that it is their work plan. You
ask your friend where they store project artifacts, and
he points to the wall, saying, “That’s most of them, right
Before you can decide whether these Agile practices are
promising or crazy, you’re invited to the team’s sprint
planning. That meeting doesn’t feel like anything you
recognize. You’re a bit uneasy when you realize you can’t
tell who the project manager is. And then you wonder, why
are so many people getting together just to plan for a
couple of weeks? Don’t they care for efficiency? Why do
they keep asking to simplify, split, remove, or defer
work items? Why do they avoid making large commitments?
Where is the accountability?
Such scenes could well give you the impression that Agile
is not a responsible way to work. A quick Internet
search, however, would put your mind at ease: There are
established Agile process frameworks and solid practices.
If you just followed them, you would produce better,
cheaper, faster results. And you could be formally
trained to do that. Trust us, this stuff works.
The trouble is, it wouldn’t — not if you merely followed
someone’s recipe or practices...even if those practices
applied perfectly to your unique context. Your friend and
his team are getting their results not from the practices
you observed, but rather from three invisible elements that
guide their application of the practices.
The first element: principles
Consider a ubiquitous Agile practice: the daily standup
meeting. In its popular format, every team member answers
the same three questions about their progress.
If a team lives by the principles of Time-Boxing and
Outcome, they will give answers that move them closer to
their iteration goal and to a delighted customer. If the
principles of Transparency, Focus, and Self-Organization
also guide them, their answers and the ensuing dialogue
would strengthen the team. These are only five of the
On the other hand, if the meeting leader has Waterfall
principles in mind, the exact same format will yield
other outcomes. For instance, the answers might be used
for holding team members accountable for individual
micro-progress. In that case, the outcome will not be a
stronger team that’s closer to their goal; the daily
meeting will be more likely to amplify individualistic
and self-preserving behaviours.
The second element: beliefs
Beliefs are convictions that people hold to be true in
their situation. Let’s see how they play out in iteration
(sprint) planning. It’s a simple practice: the delivery
team and the product owner choose from among the most
valuable work items the ones that will fit in the
These practitioners may hold Agile beliefs: Being human,
they might make mistakes; valuable opportunities for
changes in direction could present themselves anytime;
and requirements could go stale. Given these beliefs,
both the delivery team and the product owner would prefer
short iterations and a focus on current needs, and thus
could increase their chance of creating truly valuable
With Waterfall beliefs in mind, however, the same
planning practice would produce different outcomes.
Believing — correctly or incorrectly — that the product
owner knows what she wants, and that her ideas would
remain valuable and mostly unchanged once baked into
product, the team would work with a bigger backlog,
longer iterations, and big designs up front. That would
limit everyone’s flexibility and increase the cost of
The third element: values
People’s values are what they hold most important. For an
example, think about the well-documented and partially
automated practice of code refactoring. It improves the
code’s design without altering its behaviour, thus making
the code easier to work with.
Teams and managers who value “getting it right the first
time” — a Waterfall value — consider refactoring a
penalty for poor execution or bad decisions. They
refactor code grudgingly and superficially.
By contrast, other teams and managers who subscribe to
the Agile value of adaptation consider refactoring a
deliberate and desirable practice. Wanting to get to
“Done” without delay, they develop simple, sufficient,
and safe code for their increments. Once that code needs
to grow, they’ll refactor it to make room for whatever
that growth happens to be. They rely on this technical
practice to support business decisions.
Values, beliefs, and principles are the three elements of
a mind-set. If you like the promise of Agile, executing
the practices without adjusting your mind-set will not
get you that promise. So, before you adopt Agile
practices, examine how the principles, values, and
beliefs behind them fit your current mind-set about the
work. If they don’t fit well, start by adjusting your
mind-set — otherwise the practices won’t stick, and may
even do harm.
For years, Agile coaches and bloggers have been saying,
“Don’t just do Agile (go through the motions), be
Agile (have the mind-set).” Yet few went beyond the
super-brief Agile Manifesto to explain what that meant.
So last year I took on the challenge to explain Agile
thinking in simple, concrete terms without prescribing
specific practices or frameworks.
The result is my new book, The Agile Mind-Set:
Making Agile Processes Work. Apparently the need is real, and the book's reception has been heartwarming. I invite you to check it out (click the image of the book's cover, on the left).
Copyright © 2015, 3P Vantage, Inc. All rights reserved.