Being in the business of helping development teams and
organizations become more effective, I get to see very
diverse starting points. The clients of the last few
months, however, had a lot in common:
- They use one of the popular ALM (lifecycle management) tools.
- They use Scrum, doing their best to fulfill its expectations for meetings, artifacts, and roles.
- They’ve picked up many of the “best practices” associated with Scrum.
- Despite the framework’s built-in continuous improvement loop, their process improves little.
People’s approach to work consists of many elements.
Think about each element as being on a spectrum, from
rigid to flexible. Most teams I meet place too many of
their elements — especially the Scrum parts and those
“best practices” — on the rigid side.
These teams’ rigidity is due to two beliefs they share:
that the mechanics of Agile have to look a certain way,
and that they should perform certain mechanics because
they are good. I think neither belief is helpful: you
cannot be agile if you’re being rigid about its
implementation. Rather, you’ll be agile if you apply its
mind-set. Here is my take on the most ubiquitous examples
of haves and shoulds, and what the mind-set would guide
you to do instead.
You do not have to have a daily recital of answers to
three questions. You do, however, have to coordinate team
activities to maximize their likelihood of finishing and
delivering by the end of the iteration.
You do not have to have a demo meeting if it’s not worth
having. A common example of that is when the only
non-delivery person to show up is the product owner, and
he’s already seen everything. Another scenario is when
the meeting yields no meaningful feedback about the
product, making the meeting just an expensive
You do not have to diligently write down “What Worked
Well?” and “What Needs Improvement?” in every
retrospective. You do, however, need to reflect regularly
(and frequently) on the team’s work and methods in order
to make them better.
You do not have to spend one hour in planning per week of
iteration length. Some teams do that usefully, others go
mental with boredom. You do, however, have to identify
enough meaningful work that can fit in the next
iteration, and not make that determination too early so
it stifles adaptation.
You do not have to have a single person own a story or a
task. The ALM tool you use might lead you to think that,
but that’s just a tool limitation. What you want to have
is the team finishing valuable stuff. If work has to flow
between people (and not just between roles such as dev
and test), that’s not a problem; in fact, it’s often
You do not have to put hours on tasks and do iteration
burndowns. Especially in software development, where it’s
devilishly hard to get the tasks and numbers right. You
do, however, need to have a decent sense of your ability
to finish valuable stuff when the iteration timer dings.
You do not have to pick a ScrumMaster and a product owner
who are different from the delivery team. You do,
however, need to have someone look after the backlog from
a business standpoint, and someone to help the team grow
as a team. Yes, they need to be competent, empowered,
knowledgeable, available, and effective. But if you’ve
run out of appropriate and non-conflicted options, they
can be the same person, or a manager, or a consultant.
And you certainly do not have to write each and every
backlog item in the “As a ... I want ... so that ...”
template. I have yet to see a team where the exclusive
(or merely frequent) use of this template helps. You do,
however, want to have every backlog item address,
implicitly or explicitly, these questions: So what? Who
cares? How will we know we’re done?
So, on the spectrum of rigid to flexible, what do you put
closer to the rigid end? Not the roles, artifacts,
meetings, and definitely not context-free practices.
Closer to the rigid side, you put values and principles:
stuff to take a stand for, to emphasize, to permeate
every action. For example, the Agile principles of “defer
decisions to the last responsible moment”, “seek feedback
assiduously”, “fail fast and cheap and maximize the
learning from that”, and “people collaborate in
cross-functional, semi-autonomous, self-organizing
teams”. That’s the stuff that makes Agile agile and
yields its benefits.
I feel so strongly about pragmatic, principle- and
value-driven Agile that it’s the subject of my upcoming
book, “The Agile Mind-set”, now in second draft (register
for early availability announcements at TheAgileMindsetBook.info). It’s also the subject of a new
talk I’ll be giving at various user groups and
conferences in 2015.
ONE LAST THING: Pragmatic leadership, as well as
coaching and influencing others to act pragmatically in an Agile
context, are a central theme in my upcoming event “The
Influential Agile Leader.” If you see your teams
reflected in my words above and would like to learn tools
for increasing their Agility, sign up at
InfluentialAgileLeader.com. There’s one session in San Francisco
and one in London, but it’s not a local event; in both
sessions, half the participants are from elsewhere in the
Copyright © 2015, 3P Vantage, Inc. All rights reserved.