(Note: This article is somewhat longer than usual, but I
didn't have the heart to reduce its scope…)
All over the world, Agile is the new darling. This
approach to work has caught the attention of most IT and
product development managers, who are now rethinking
their teams, tools, practices, programs, measurements,
reporting, and so on. Few of those managers, however,
question Agile’s fit to their situation, or begin
projects with the question, “Which approach should we use
For the longest time, nobody had to ask this question,
because there was a standard way to manage work: a
plan-driven, predictive approach such as Waterfall or
PRINCE2. The process was well-documented, ubiquitous, and
assumed to be right. In recent years, Agile emerged as a
viable, acceptable alternative to getting work done.
Where you work, are plan-driven and Agile approaches true
alternatives, or has Agile become the single new
standard? By my informal assessment, too many people are
inappropriately trying to force-fit their work into Agile
Excuse me? This from an Agile writer?
Many people think of Agile and Waterfall in terms of
right and wrong, new and old. I think the real question
is that of suitability.
When we work, we rely on principles that guide our
choices, decisions, and actions. If we apply Waterfall
practices — such as requirements analysis, Gantt charts,
code freeze, and user acceptance testing — it’s because
we’ve chosen to operate according to certain principles.
Some of the Waterfall principles are:
- Plan the work and work the plan
- Limit change
- People are resources
- Maximize worker utilization
- Hub and spokes
On the other hand, if we apply Agile practices — such as
daily standups, acceptance-test driven development, and
sprint demos — it’s because we’ve decided to operate by
the Agile principles, by which these practices were designed.
Some of the Agile principles are:
- Team self-organization
- Sustainable pace
- Continuous improvement
To be clear, more work principles exist beyond the
Waterfall and Agile ones. There’s Limit work in progress
(WIP), Eliminate waste, Don’t repeat yourself, and so on.
Principles are not the full story
Why do we pick some principles over others? We do so
because of what’s important to us: our values. We might
not make our values explicit, we might not share the same
values, and they might not be appropriate for our work —
but they’re still there, and they influence everything.
For instance, in millions of IT projects the important
things are usually these:
- Make early commitments (= promise what will be done by when and for how much)
- Get it right the first time (= there’s really only one go-live)
- Deliver on time and on budget (= that’s what success means and requires)
- Use standardized processes (= they should yield success as long as the workers are skilled)
When these are your values, the Waterfall principles are
the sensible way to approach work. You would want to make
a plan and follow it closely, and use proven practices
for managing the work and the workers.
In a different situation, other things might be more
important to you: putting people first, adaptation,
delivering value early and frequently, and continuous
collaboration with your customer. If these are paramount
for you, the “inspect and adapt”, empowered team, and
take-small-steps elements of the Agile approach follow
Choose your methods deliberately — every time
Always managing your work the same way cannot be a
winning strategy, because what you care about changes
with the work. For example, if you’re rebuilding my
city’s website, I hope you’d collaborate with city staff
and with citizens to discover changing needs and
expectations, adapt the site accordingly, and release it
gradually as more services are added. On the other hand,
if the City decides to replace a decrepit highway with a
tunnel (Toronto, I’m looking at you), I hope they get it
right the first time, use taxpayer money wisely, and
follow standard design and construction practices.
What if, instead, the city decided to use agile practices
for the highway project? Would short sprints, user
stories, product backlogs, and daily standups make a
useful difference? I think not. When long-term
predictability and promises matter, sprints add to
planning overhead, user stories are carved-out specs, the
product backlog is a weak representation of a project
plan, and the daily standup is merely a daily status
meeting. They do not increase agility — and indeed,
increased agility is not needed here.
It’s thus important to choose methods designed to
accomplish what’s valued. Some methods have been
prepackaged for you, such as Waterfall, Scrum, and SAFe.
But what if you have a hybrid – in other words, what you
care about is neither entirely Agile nor Waterfall?
Examples of that abound, for instance in contract
software development, legacy modernization, and HR policy
development. In those cases, no prepackaged set of
methods can be a perfect fit, and you’d have to roll your
own. (Facilitating the workshops in which staff and
management do their own process and team design happens
to be one of my favourite activities.)
Sometimes, the right methods still fail to yield the
results you’re after, and as the situation unfolds, your
values start changing. A common example is Waterfall
“project rescue”: when a project runs into schedule and
quality trouble late in the game, rescue efforts marshal
everyone around to finish at least a few useful, working
pieces. The values that dominated during inception —
predict, commit, economize — are still important, but
other ones — be flexible, satisfy the customer, don’t
look bad — eclipse them, and give rise to practices
reminiscent of Agile ones. Retrospectives (or
post-mortems) of such projects may yield a recommendation
to project leaders to be more critical of their values
and assumptions on the next project.
Beware the one-size-fits-all approach. In a given work
situation, before you ever plan, commit, design,
implement, improve, or otherwise do any work, be explicit
and deliberate about your values, principles, and
assumptions in order to increase your effectiveness.
Copyright © 2016, 3P Vantage, Inc. All rights reserved.