Over at SD Times, Andrew Binstock has a bone to pick with agile evangelism. In some ways, I sympathize. I’ve certainly read enough testimonials from born-again agilistas to know that their views aren’t always realistic. As Binstock points out, agile is not the “one true path.” In fact, there are several methods by which one could successfully manage a complex project—and one of them is waterfall. If your company is meeting its deadlines and staying within budget while using a waterfall approach to development, don’t change a thing. After all, there’s no point in messing with a winning formula.

Agile can be an indispensible asset to an organization, however, when that formula isn’t winning. If a team is missing deadlines and burning through budget, delivering a product that disappoints the customer, or generally doing a poor job of behaving like a team (i.e. communicating, pairing on work, etc.), then it might be time to turn to agile. And even then—it’s not a quick fix. Agile tends to push team members to think and behave differently, which can be a real shock to the system. Factor in the critical importance of following—really following—the principles and processes of agile and it can seem like a very disruptive change, indeed. However, it’s the sort of pain that hurts a lot at first, but goes away altogether over time. (You could call it “healing.”) Once a team has adopted and internalized the agile paradigm, its familiarity will provide the team with a grounding set of practices and a roadmap for iterating their way out of challenging scenarios.

By the way, Binstock’s assessment of Winston Royce’s presentation of waterfall as a “stuffed man” is exactly right. At the time of his presentation, he warned that his design would need to go through at least a second iteration before it would have much chance of succeeding. So, really, Royce presented a kind of phased version of waterfall, which lacked agile’s cross-functional teams, but anticipated its use of multiple iterations.