Perils and Pitfalls of Agile Adoption

Agile development sounds great; what could go wrong? Matt Heusser examines some of the myths, mysteries, and classic mistakes in Agile development, including some things to consider before jumping into Agile with both feet.

Like this article? We recommend

If your organization is trying to adopt (or considering) a more Agile
approach to software development, you are probably hearing plenty of rah-rah
stories of how great things will be. A rational response to those stories is to
ask, "What can go wrong?" To discuss some of the traps to avoid,
let’s consider what most companies are transitioning from: the waterfall
model.

The waterfall model is the most common way for large organizations to write
software today. It takes the complex, chaotic development process and turns it
into something simple and clean:

Figure out what needs to be done (requirements).

Determine how to do it (architecture and design).

Write the software (coding).

Make sure that the software works (testing).

Deploy the system.

The only problem is, it doesn’t work.

I should probably clarify that statement a bit: The waterfall model often
doesn’t work well. Companies try to turn the waterfall into an
assembly line, with requirements analysts, architects, coders, testers, and
project managers who oversee the assembly. Transferring information between
these people is difficult, so they tend to rely on documentation, which is often
vague and sometimes worthless. Worse, when the customer changes his mind after a
decision is made, costs go up vastly—therefore, waterfall advocates
suggest limiting or controlling change. So, when the software ships, it’s
late, buggy, and doesn’t really meet the customer’s need; it meets
what the customer thought his need was nine months ago...

Enter the Agile consultants. Instead of specialists, they suggest
generalists, who do all the work, implementing features in slices, end-to-end,
in very short timeframes. The customer can prioritize her features, getting the
most important features first, meeting after every release to plan the next
release. Productivity increases because problems aren’t falling through
the cracks. There are no inter-team arguments, such as architects versus coders
versus testers; everyone is on one team, focusing on delivering something of
value. Testing moves up front, changing from a verification activity to a
specification activity.

Immediate Risks

Implemented well, Agile methods truly can deliver. The customer sees working
progress periodically, can change her mind after every release, and sees the
most important features implemented first. But in my experience, Agile methods
have three major potential risks:

Agile methods are easy to misunderstand.

It’s easy to think you’re doing Agile right, and be wrong.

Agile methods make value visible.

Agile Methods Are Easy To Misunderstand

Agile philosophy
includes heavy customer involvement, responding to change versus following a
plan, releasing software early and often, and focusing on individuals and
interactions over processes and tools. Those Agile philosophies tie into Agile
methods such as pair programming, the planning game, time-boxed iterations,
test-driven development, and refactoring.
(XProgramming.com
is a wonderful resource on Agile methods.)

The methods exist in order to enable the philosophy. For example, test-driven
development combined with refactoring can make software malleable so it can
change more easily, allowing the plan to change. Automated testing combined with
continuous integration makes it possible to release often. Without automated
testing and continuous integration, frequent releases create a huge manual
testing burden that’s often unbearable.

Agile practices are like any other practices, though; they’re learned
through example, application, and training. If the practices are disconnected
from the philosophy, the result just won’t work.

For example, a few years back I worked with a company that wanted to be more
"agile," yet they still wanted to know exactly when projects would
start and stop, before the requirements were defined. That’s a fine
idea—in fact, Agile development can support this plan. Features are placed
in a priority order; the team works on the highest priority first, iterating
until time runs out. The problem was that the organization wanted an estimate
for all the work to be done—before they knew all the
requirements.

The example above isn’t Agile—it’s psychic. Agile
development specifically gives up on the psychic approach, instead choosing an
adaptive approach.

It’s Easy To Think You’re Doing Agile Right, and Be Wrong

It’s really easy to throw out the big, thick methodology binder and the
heavyweight requirements documents, but Agile development expects that something
will replace them. Many organizations move to iterative development
without automated testing—with the result that the testing burden grows
exponentially—or move to iterative development but keep the hard deadlines
and the expectation of full delivery on a ship date. Pair programming without
communication and feedback is just someone breathing over your shoulder. Without
testing skills, a developer won’t be able to do automated testing; worse,
he won’t even realize this as he wastes hours writing so-called
"tests."

In other words, Agile techniques require depth: the ability to know the right
techniques for the current project, and the ability to choose between them.
Without direction, a team told to throw away its waterfall method will simply
devolve into "code and fix."

That isn’t Agile: it’s chaos.

Agile Methods Make Value Visible

Yes, believe it or not, this is a potential risk of agile adoption.
It’s a political risk. In most large organizations, it’s possible to
not work very hard, not contribute, and get by on political savvy and power. I
refer to these folks as "roaches" because they’re essentially
scavengers that hide from the light.

Agile methods make progress visible. Unlike the complex, bureaucratic
waterfall organization, which is opaque, if someone in an Agile shop isn’t
contributing, the fact will become obvious—and fast. Think about the
consequences of this fact for a minute. The roaches, often the most influential
and politically savvy people in the group, are going to fight Agile methods
tooth and nail. The misinformation campaign that a roach leads can be
surprisingly effective, because Agile methods are easy to misunderstand and hard
to get right.