Jesse Fewell, CST, PMI-ACP, PMP, has served on the core
team of the Software Extension to the PMBOK® Guide
and the steering committee for the PMI-ACP® certification. He can be reached at email@example.com.
Iwas recently on the phone with a project management office director whose orga- nization was in the middle of a merger. “We’ve been hitting dates for a while,” she said. “But the chief technology officer of the
new company says we have to add more prototyping
to our agile process, because that’s how he does it.”
Ugh. This is a classic example of what I call
victory bias: What worked for me last time will
always solve my problem this time. Unfortunately,
your favorite agile approach isn’t a panacea. Here’s
a better way to build your agile strategy.
First, name the problems. When someone says,
“We need to be more agile,” the first question
should be: Why? Then go deeper: What is the pain
point we should tackle first? Is our delivery slow
enough to cause a reputation problem? Are we
building solutions people only use grudgingly? As
in medicine, we need to know where the pain lives
in order to know which techniques to use.
Second, choose the right kind of agile. Most
project problems fall into two broad categories:
exploration (on the front end) or execution (on
the back end). You need to choose the appropriate
agile techniques to solve issues in each area.
Exploration. Many projects venture into
uncharted territory where there is great risk of
building the wrong thing. In these cases, we want
agile approaches that help explore
whether a good idea is viable and
valuable. Techniques such as
personas, customer site visits, collaboration games and storyboarding help identify the “minimum
viable product.” The alternative is
to waste money on initiatives that
haven’t been properly vetted.
Execution. Once we minimize
the business risk of an idea, the
question becomes: Can we build
this proven idea with sufficient
quality and speed to maximize
potential value? We want agile
techniques for maximizing momentum, such as fully
allocated staff, automation and frequent testing.
Finally, seek a balance. The temptation is to
draw a line in the sand and use certain techniques
only for exploration and others only for execution.
Indeed, you may have seen this pattern reflected
in an organizational chart that divides staff into
“requirements teams” versus “delivery teams.” But
any successful initiative will have some amount
of both exploration and execution. So don’t be a
knee-jerk agilist. Instead, assess the situation and
seek out the right techniques to solve the problem
at hand. PM
No Size Fits All
What worked last time probably won’t this time. So be
sure to take a balanced agile approach.
By Jesse Fewell, CS T, PMI-ACP, PMP, Contributing Editor
Voices THE AGILE PROJECT MANAGER
is to draw
a line in the