As the
saying goes, the best laid plans are bound to go astray. When it comes down to
it, project
management is all about managing the twists and turns of collaborative
development. The ability to adapt and respond to these inevitable changes will
determine whether the project in question will be successful.

In his
book, Managing Agile Projects, Sanjiv Augustine
explains how projects can benefit from a change in philosophy and approach
known as agile project management (APM). APM is based on the idea that
management should revolve around enabling project teams to create and respond
to change. A sample chapter from his book is available as a TechRepublic
download.

In the
following, interview Sanjiv Augustine discusses the
benefits of APM and how a transition to this management philosophy can be
accomplished especially with regard to modifications to the organization
culture and the elusion of management control.

Managing Agile Projects
BySanjiv
Augustine
Published by Prentice Hall PTR
Chapter 8: Light Touch
ISBN: 0131240714; Published: May 12,
2005; Copyright 2005
Web site

Interview

[TechRepublic] In chapter 1 of your book you go to
great lengths to define the concept of agile management. Could you take a
moment to summarize your definition of agile management for the TechRepublic
audience and the benefits derived from it when compared to conventional project
management techniques?

[Augustine] In the book, I present this general
definition for Agile Project Management (APM): “the work of energizing,
empowering and enabling project teams to rapidly and reliably deliver business
value by engaging customers and continuously learning and adapting to their
changing needs and environments.” Another concise definition is this:
enabling project teams to create and respond to change. 

Here are
the some benefits of agile management:

  • Iterative and incremental
    delivery for rapid business results
  • Increased teamwork and
    collaboration for reduced waste; and increased productivity and team
    morale
  • Learning and adaptation for
    increased quality and flexibility to change

[TechRepublic] Traditional project management is
not agile management. However, that fact also means that project managers will
have to alter their behavior in very significant ways before the
advantages of agile management can be realized. What steps should a traditional
project manager take if he/she is attempting to migrate to an agile management
style? What changes in philosophy will he/she need to make personally to adjust
to an agile management environment?

[Augustine] Chapter 10, Transitioning from the Familiar, of the book covers several
transitions that I feel that managers need to make in order to alter their
behavior to realize the benefits of APM. Some of these are:

  • Recognize that people are the
    longer-term project
  • Use Features Breakdown
    Structures instead of Work Breakdown Structures
  • Acknowledge that the Perfect
    Plan is a Myth
  • Replace Predictive Planning
    with Adaptive Planning
  • Stress Execution Over Planning
  • Respond to Change with
    Adaptive, not Corrective Action

The biggest
change in philosophy that s/he needs to make (if they haven’t already) is to
give up on the idea of command-and-control.
Good, experienced managers know that control is only an illusion and
people do what they want to do.  So, APM
accepts this and presents simple ways to work with this reality.

That said, many traditional management tools can find application on
agile projects. The difference lies not in the tools, but in the way they are
applied: with different assumptions about uncertainty, risk and control; and
with a different, evolutionary approach to planning and execution.

[TechRepublic] Many large corporations have made
attempts at changing their culture to foster the common principles you espouse
for agile management: alignment and cooperation, emergence and
self-organization, and learning and collaboration. Unfortunately, many of us on
the front lines look upon these proposed changes with jaded, cynical eyes
because management almost always reverts to their previous, non-agile,
behavior. How do you suggest organizations approach changes in management
culture, like agile management, that can make the principles a lasting part of
the environment rather than a nice thought that gets thrown out because there
is “work” to be done?

[Augustine] Any organization contemplating
changing to agile management needs to make the change incrementally, and with
the full participation of those affected: managers, team members and executives
alike. The reasons that change initiatives fail are quite well known: top-down
imposition of change, a “big-bang” rollout that tries to do too much too soon,
and a lack of awareness of how people are supposed to accommodate change. Also,
we must remember, people change only what they want to change. So the answer
lies in making managers want APM.

Another key
factor is time. Changes do not happen overnight, and everyone involved needs to
be prepared to commit to several months or even a couple of years to effect
lasting change in organizational culture.

As for
reverting to “work to be done,” the best motivation to sustain agile and APM
comes from business partners and customers on agile projects—they love the new
way of operation and simply don’t want to go back.

[TechRepublic] Are there certain projects where
agile management would not be the best choice? Are there famous problem or
failed projects that could have been saved with the principles of agile
management? How would agile management change the outcome?

[Augustine] Projects that do not have the
commitment of a business customer are not good choices for agile management.
Also, if we take this up a level, there are organizations that have difficulty
adopting APM. See Chapter 6, Simple Rules, for a tool that helps identifying
and classifying organizational culture.

I’m not
familiar with famous failures that might have benefited from agile management.
The only comment I would make here is to say that large projects have the odds
against them (I think something like an 80% failure rate). So, small is
beautiful: if you’re managing a large project, start breaking it into many
small projects today!