well,” he says. “Whereas if you’re impacting the bottom line or there are big
public relations implications or security issues, it’s dangerous to proceed in that
off-and-running agile way.”
At one organization he worked at, taking a pure agile approach on a project could
only be approved at the portfolio level, and only by meeting certain criteria. (Criteria
included a method for tracking spending and a one-page summary of the project’s
goals.) But there’s a payoff. “You save time and money doing that, because you’re not
applying unnecessary governance to projects that don’t need it,” Mr. Moores says.
At organizations where agile approaches are less widespread or tend to meet
resistance, however, project leaders should embrace as much upfront planning
and governance as the project can reasonably bear. “Doing traditional design
documents might not feel like pure agile, but it has an upside: Taking the best
bits of agile and traditional project management, from the project through portfolio level, gives you that agility you need,” Mr. Moores says.
From an organizational perspective, of course, the approach taken doesn’t
matter—delivering results aligned to strategy does. In that sense, the debate over
whether and how to effectively scale up agile project management practices connects directly to the larger conversation about how to achieve organizational agility.
“While we’re scaling agile, why don’t we also work to descale the organizational
structure?” Mr. Sudame asks. That would mean less bureaucratic tape, fewer layers
of middle management and less redundancy in planning and oversight. “I’m seeing
more debate recently over how we can get rid of the fat of extra layers and make sure
teams are better aligned with the organization’s strategy and used optimally. With
less layers, you’d have a better, leaner organization—and stronger project teams.” PM
was anarchy, paid big money to experts and brand
owners who would give them a playbook—rules and
procedures to follow so they could “do agile.” No
one seemed to realize that rules and procedures are
poisonous to a team exercising agility.
All truths are contextual—no rules are universal.
You can’t pin something down with rules, constrain
it with processes, cripple it with hierarchies and
then expect it to exhibit any trace of agility.
Instead, you embrace the fact that the world our
systems live in is rapidly changing and ultimately
unknowable. Writing systems that work in this
world is not a science—it’s an exploration. We set
off in a direction but rapidly use feedback to guide
us. We make mistakes. We backtrack. But if we
move closer to our goal each day, eventually we’ll
get there, even if “there” isn’t where we initially
thought it was.
You don’t need consultants to become agile. You
don’t need expensive frameworks.
It’s tougher than that.
You need courage and curiosity.
The Manifesto: A
Call for Change
In 2001, 17 software programmers interested
in improving then-dominant development
processes gathered at the Snowbird ski resort
in Utah, USA to relax and find common
ground. They ended up writing the “
Manifesto for Agile Software Development.” It’s
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes
Working software over comprehensive
Customer collaboration over contract
Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more.
Dave Thomas is
He’s also an
Elixir) and a