Over the years, we’ve thrown a considerable amount of nouns, verbs and adjectives at the topic of development methodologies. We’ve focused mainly on that of agile and waterfall, as they are not only the most popular, but they are (in my opinion) the two most polarizing approaches.
We’ve examined and listened to arguments in favor of one versus the another – agile is more fluid and responsive, waterfall is more practical, agile people are flakes, waterfall people are dinosaurs, etc. etc. etc. We tried to be neutral, giving equal weight to the arguments of both sides. Our aim was to educate you – dear reader – in the hopes that we could help you make the right decision when it came to choosing a methodology.
What a waste of time that was! Well, only if you believe that the war of methodologies are over - an idea that was raised in a recent article on PCadvisor.com, and one that I felt was worthy of further consideration. Here’s the gist:
The wars over development methodologies — agile, XP (extreme programming), waterfall, and so on — are fast giving way to a more fluid and flexible approach to producing and refining a product. Telerik’s Semeniuk is one of many in the modern development world who sees development methodologies not as dogmas to be followed to the letter, but toolkits to be raided for what’s useful. Confining a development team to one methodology is becoming a thing of the past.
In other words, if you are a methodology fundamentalist – that is to say you never waver from the playbook – then you are likely missing out on a number of tactics that can improve the development (and testing) process. Case in point:
Some, however, caution that agile can’t simply be sprayed onto an existing development process. A former program manager who has declined to be named but has five years of experience as a Scrum master has time and again seen agile used in development, but with no corresponding changes in other facets of bringing software to market.
“There’s no intermittent QA; instead, there’s old-school ‘toss it over the wall to QA’-style QA,” he says. “Instead of regular releases, they’re using agile to get a release out, then having the schedule disrupted by support.” In his purview, there has been a battle between traditional software releases and agile, with a lot of people simply using agile merely to drive old-school models.
So what now? On the one hand, you can continue to stick to the rigid rules of the methodology of your choice. Or you can accept the notion that every methodology has something of value, and to borrow those elements as they are needed.
What are your thoughts? Do you believe the methodology wars are coming to an end?
Please sound off in the comments section below.