Perils and Pitfalls of Agile Adoption
- Immediate Risks
- Two Cautionary Tales
- Avoiding the Pitfalls
- A Final Reminder
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
"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.