Slashdot Mirror
A Decade of Agile Programming — Has It Delivered?
snydeq writes "InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, 'heavyweight' software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban — a trend some see benefiting software development overall."
"You are doing it wrong" is the perpetual excuse of Agilists when you say that agile methods have not worked for you. They are hiding behind a certain impossible to define or explain "something" that you supposedly are not doing or not doing right that causes your project to fail, because if you were Doing Agile Right (tm) (whatever that means) your project would have been a resounding success.
In the end Fred Brooks got it right decades ago: "there is no silver bullet". Software development is just hard. Anything promising massive gains in success or effectiveness is snake oil.
Well, they are doing it wrong.
The something is possible to define and explain but is typically different in different cases.
In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.
In this case it seems that the problem is changing requirements. That will kill any project no matter what the methodology.
This is exactly one of the key points that the Agile community keep trying to drill into us! The Agile Manifesto explicitly states "Responding to change over following a plan", which is translated into the principle "Welcome changing requirements, even late in development."
Agile principle #2 (from http://agilemanifesto.org/principles.html): "Welcome changing requirements, even late in
development." Other methodologies typically draw a line in the sand to recognize the costs of changing requirements late in development. They don't often forbid crossing that line, but they encourage people to honestly evaluate the trade-offs involved in changing requirements.
To take a car analogy - using Agile is like using a GPS: it is a methodology that tells you were you are, and can adapt if you take a wrong turn or if you change the destination. Like the GPS, if you cannot make up your mind where you are going (or do follow the indication of the GPS gives - been there, ...) you will not get anywhere.
Your post reminds me of a Muslim friend who told me once (dead seriously) that Muslims didn't attack the World Trade Center. They weren't REAL Muslims, you see.
SJW: Someone who has run out of real oppression, and has to fake it.