Why “Agile” is complete and utter bollocks. (Part 1)
“Agile” has become received wisdom. It’s THE standard way of building software products. “Agile” is more gospel than the Gospels.
But why? Is there anything to it, really? The Agile Manifesto was , after all, the result of a (boozy?) weekend away in Utah.
Now I’m sorry, but I’ve had lots of wonderful insights on a weekend away that didn’t stand up very well in the cold light of actually getting things done.
Is “Agile” even what you think it is? Is it anything at all? Or is it just horseshit, and not even wrapped up nice?
(see Part 2 here if you’ve already read Part 1, and Part 3 here if you’re feeling really enthusiastic. There’s even a “Reactions” piece here. )
First off, let’s be clear. I’m not arguing for methods that are not agile or responsive or efficient. That’s part of the genius of the whole “Agile” manifesto. Who’d argue against being agile?
Problem is, there’s really no evidence that “Agile” is actually agile. Funny, that. So, let’s look at what’s in the “Agile Manifesto”.
This is important….I’m going to have a go at “Agile” so I need you to come with me and look at what “Agile” actually is….what it says it is in its own words.