Out of curiosity I recently reviewed articles critical of Agile Methodologies. I had expected agile-versus-waterfall arguments and attacks from vendors selling new alternatives, but even given the reputation that advocates have for flaming well-intentioned critics, I wasn’t prepared for the level of emotion I found.

My opening position was that Agile techniques are great, but like any other tool there are limits and prerequisites. The critical articles I read strengthened that view. Let’s review three examples that stood out, in reverse order:

The Ugly

Perhaps the strangest of Agile dismissals is this 20 page 2008 screed by David Longstreet.  To summarize, Mr Longstreet pits Agile versus Waterfall and finds the former undisciplined, unstructured, and unproductive.

I’ll spare you a point-by-point rebuttal (here’s one), but perhaps the most instructive of Mr. Longstreet’s many analogies is the one about music. He compares a software project with a classical orchestra. He’s correct in asserting that no effective Agile team is 100 members strong. However, he somehow overlooks one of America’s greatest cultural contributions by only reviewing western classical music. Just as Agile works best in small teams and “values individuals and interactions over processes and tools” jazz, for example, favors small groups and values individual originality over “measurement, rules, and structure”. As is clear in the Agile Manifesto, in these statements both sides of the “over” are valued, it is just that the left side is valued more highly than the right.

The Bad 

In late 2011 Mike Gualtieri of Forrester Research posted a piece with a tone not unlike Mr Longstreet’s. He leads off by saying that Agile “annoys” him more than any other new trend. I guess that gives me license to say that I’m annoyed by arguments that criticize a technique by taking carefully selected points to logical absurdity. Calling out “the rush to write code” and the “lazy” inclusion of business reps in software development, Mr Gualtieri sets up a cartoon target with a big soft bulls eye to shoot his cardboard arrows into. Sorry Mike, effective Agile teams do value documentation and requirements, and business people are on effective Agile teams when needed, but absent when not.

After drawing readers in with polemics, he follows with a “better approach” that is really interesting, doesn’t preclude Agile techniques, and needs tons of work to get past the platitude stage.

The Good

On the other hand, Alex Bell’s delightful “Death by Agile Fever” discusses ways that a trendy new method can be misused to the detriment of an organization. He details 14 varieties of Agile Fever, starting with Lemming Fever, in which “one [with decision making authority] knows about Agile simply based upon what he or she has been told”, to Cook the Books Fever, hiding real results to show success.

I particularly liked Mr Bell’s reference to Phillippe Kruchten’s “Agile Sweet Spot”, a model that considers factors including business domain, system size and criticality, maturity of organization, and more, to predict Agile project success:

“The “agile sweet spot” tends to be for collocated team, of less than 15 people, doing greenfield development for non-safety-critical system, in rather volatile environment; the system architecture is defined and stable, and the governance rules straightforward.”

On the other hand, projects outside the sweet spot that apply Agile techniques tend to be “challenged”.

Know the Limitations

Let’s face it, Agile Methods are sitting ducks for criticism. Excluding sports like hockey, basketball, and soccer, there aren’t many analogous models in life that feature team improvisation/evolution. Few of us play jazz. If an Agile contractor sent you a bid to add an addition to your house it would be absurd.  (“I’m not sure what it will end up looking like, but we’ll make sure we deliver a section you can use every six weeks.  You’ll have to meet us every morning at 9:00 for a brief standup”.)

Furthermore, the Agile movement sports a slightly subversive element. Mr Longstreet hints at it when he dismisses Agile for eliminating division of labor. He quotes Adam Smith in a section bemoaning Agile’s reunification of craft and engineering, in his view throwing away the benefits of specialization. Agile practitioners, by valuing developer and product most highly, remind me of Karl Marx, who saw division of labor as one of the roots of alienation of the worker from his product, in part a source of the evils of capitalism. And they have a “Manifesto” for crying out loud!

But even if it sounds crazy, and even if it touches subliminal red scare nerves, my experience squares with Kruchten’s sweet spot. For example, among the Agile projects I’ve participated in and observed are two successful Scrum efforts for unrelated organizations in Business Intelligence and data warehousing extract, transform, and load. In both cases the technical environment was stable, requirements were volatile, and governance was well established. The reporting project featured a full time business representative, and the ETL project didn’t. Both delighted the customer.

Hopefully the industry will soon get past the emotional reactions and method “fevers”, and be able to objectively assess a situation and apply the right management approach for the job at hand.

That’d make my day.