Over at SD Times (http://www.sdtimes.com/INTEGRATION_WATCH_THE_ZEALOTS_OF_AGILE/About_AGILE/33300), 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.
Posted under Agile Methodology
This post was written by admin on March 5, 2009