Perils and Pitfalls of Agile Adoption

By Matthew Heusser

Date: Feb 3, 2006

Return to the article

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.

"Any good idea can be implemented poorly."

—Author and consultant Esther Derby

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.

Two Cautionary Tales

A few years ago, I presented a seminar on test-driven development at a large testing conference. Many of the participants were "doing Agile." One in particular was having a very hard time. Her development group was rewriting a piece of core functionality from scratch in Java—a new language for them. They hired a group of Java coders and created a schedule with four-week iterations. Every four weeks, the developers were supposed to throw a chunk of code "over the wall" for the testers to test. The software was supposed to be developed in six iterations of four weeks each, with a final QA phase at the end.

The first iteration was two weeks late, and buggy. The second iteration was a week late (making the project now three weeks late), and completely buggy. The basic functionality didn’t even work, and it introduced a number of regression errors in the software, so the testers had to go rerun the original test plans for phase I. It didn’t take a crystal ball to foresee what the next five iterations would be like, and they weren’t good. Worse, the testing group was in trouble because they were the supposed bottleneck "holding up the Agile developers."

In other words, the organization tried the following:

"Big bang" style software scheduling with a new staff in a brand-new language. (But hey, they had iterations!)

Iterative development without automated tests.

"Iterations" that delivered incomplete work products (for instance, software that wasn’t ready to release to the customer).

Agile development while keeping the developers and the testers in separate buildings, with testing as an afterthought, verification activity.

You can probably guess the results; they weren’t pretty. That sad part is that Agile was blamed for the failure of the project. Here’s the real truth: New people, new processes, and new technologies throw realistic scheduling out of whack. By focusing on delivering working software early and comparing expected features completed to actual features delivered, Agile development provides feedback, which can allow a management team to make good decisions.

A second organization was having integration problems; specifically, problems with different versions of the same libraries on different products. When management heard the Agile pitch of "continuous integration," they were immediately sold, buying all of the developers copies of a famous book on Agile development. Management went to an iterative development standard, began daily standup meetings...and that was about it.

Without substance, the so-called Agile development conversion devolved into "work harder on tighter timeframes, with standup meetings." The developers still lacked direct contact with the customers and had requirements that were even more light, vague, and unverifiable.

Twelve months later and the team is basically back to square one. That’s not Agile; that’s "code and fix."

Avoiding the Pitfalls

Taking a careful look at some of the failures I’ve described shows a few similarities:

Massive, world-shaking change without experimentation.

Expecting to have your cake and eat it too: All features, on time, on budget, on schedule, regardless of how realistic that schedule is.

Implementation of Agile techniques without a belief in the core philosophies of responding to change and not planning everything up front.

When an organization implements Agile in a "big bang," all-or-nothing way...well, that is possible, but the results are unpredictable. They’re trying to develop in a new way on a project that’s never been done before, and the technical term for that is an experiment. Typically, you don’t want to use an experiment on a bet-the-company project, which is what many Agile projects end up becoming.

There is an alternative to declaring exactly how all development will be run, from this day forward, without ever trying it: Experiment on your existing projects. One place to start is with automated testing. If your team is constantly modifying the same codebase, automated testing can pay for itself very quickly by lowering the overall testing burden. With automated testing in place, the team has a safety net, which can enable true iterative development and quick releases.

Another way to be more Agile is to simply make decisions that conform more closely to the Agile manifesto—that is, decisions that value the following:

Individuals and interactions over processes and tools

over processes and tools Working software over comprehensive documentation

over comprehensive documentation Customer collaboration over contract negotiation

over contract negotiation Responding to change over following a plan

Add small, incremental changes to the way you develop software (your "methodology") that support these values. Agility is not yes-or-no; it’s more-or-less—and don’t let anyone tell you otherwise.

A Final Reminder

Agile methods won’t result in an ability to ship infinite code in zero time, they won’t create discipline without effort, and they are possible to perform badly. Implemented poorly, Agile methods can leave an organization in worse shape than when it started, with all the same problems, less documentation, and worse architecture.

Implemented well, Agile methods provide working software quickly; they give the customer the ability to change his mind routinely; and, most importantly, by comparing actual to expected delivery, they provide insight into the actual progress of the project.

Knowing the progress of the project makes realistic schedules with realistic end dates actually possible. Adjusting the schedule to reality, on the other hand, takes guts, integrity, courage, and self-discipline.

Welcome to real software management. Buckle up, and get ready for the ride of your career.

Matthew Heusser actively develops working software and also writes and speaks on systems improvement. You can email Matt at Matt.Heusser@gmail.com, or visit his web site, Excelon Development.