BEING AGILE WITH AGILE
Jesse Fewell, CST, PMI-ACP, PMP, is a founder of the
PMI Agile Community of Practice and participated on
the core team of the Software Extension to the PMBOK®
Guide. He can be reached at email@example.com.
willing to get a head start on projects. A key benefit
of agile is that projects can begin with a less-than-
complete plan. For example:
n Instead of waiting for a dedicated facility, ask
if some of the project setup can be performed
n Instead of waiting for the project team to be fully
staffed, assess whether the current team mem-
bers can begin working on certain tasks.
n Instead of crafting every requirement at the very
beginning, prioritize, assign and work on the
high-level capabilities first, then develop the
remaining tasks as time goes on.
Agile author Jim Highsmith probably said it best.
When asked for advice about how to stop having
consistently late projects, he replied, “Start them
sooner.” The longer you wait for everything to be
just right, the later your project delivery may be.
ALWAYS BE PREPARED
Starting a project aggressively also means being
ready to solve issues as the team executes the proj-
ect. Use each issue as an opportunity to find a solu-
tion that improves the project process. For example:
n If the product owner is too busy to engage in the
project, ask him or her to authorize an analyst to
manage stakeholders and offer tactical guidance
n If an expert on the team is needed across several
projects, a solution might be training one person
from each project to assist him or her.
n If team members are located across several
time zones, limit meetings to fixed “collabo-
ration hours,” which will help work get pri-
oritized and focused.
Being rigid with agile could undermine all
the benefits you’re trying to get. Remember that
remaining flexible—and tailoring agile to the proj-
ect’s needs—can help move things forward. PM
If you’ve tried using agile approaches and it’s not
going well, it might be time to break out of the
box. While agile provides many fixes for project
problems, it still requires a project manager’s dis-
cerning eye to sift between rules and principles.
Take a look at these three situations where a project might fare better by bending some agile rules.
PECULIARITIES VS. PRINCIPLES
When working in change management, details are
very important. People crave details. To navigate
the transition from the old to the new, project
managers wisely make checklists, policies and
guidelines. However, when using agile to guide
these details, keep in mind that it’s just that: a
guide. For instance:
n If you hear, “Agile says 9 a.m. is the best time for
the daily standup,” know that is only one pos-
sible way to encourage consistent, reliable daily
n If you hear, “Agile says all requirements must be
expressed as user stories,” know that is one of
several ways to represent the customer.
n If you hear, “Agile says we deliver an increment
to operations every month,” know that is but
one particular project’s approach to delivering
business value early and often.
Every agile technique is designed to have a fixed
principle with room for customization and flexibility.
Adapt agile so it works best for the project at hand.
NO NEED TO WAIT
Spending valuable time figuring out the perfect
way to roll out agile could wind up costing you the
competitive advantage, as other organizations are
An iterative approach like agile has
certain rules. But the beauty is that
flexibility is built into the structure.
BY JESSE FEWELL, CS T, PMI-ACP, PMP, CONTRIBUTING EDITOR
being ready to
as the team