Slashdot Mirror
Is Agile Development a Failing Concept?
Nerval's Lobster writes: Many development teams have embraced Agile as the ideal method for software development, relying on cross-functional teams and adaptive planning to see their product through to the finish line. Agile has its roots in the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods. And now one of those developers, Andy Hunt, has taken to his blog to argue that Agile has some serious issues. Specifically, Hunt thinks a lot of developers out there simply aren't adaptable and curious enough to enact Agile in its ideal form. 'Agile methods ask practitioners to think, and frankly, that's a hard sell,' Hunt wrote. 'It is far more comfortable to simply follow what rules are given and claim you're 'doing it by the book.'' The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In broad strokes, GROWS sounds a lot like Agile in its most fundamental form; presumably Hunt's future postings, which promise to go into more detail, will show how it differs. If Hunt wants the new model to catch on, he may face something of an uphill battle, given Agile's popularity.
I've got to agree with JohnFen. As a Program Manager, while Waterfall techniques could frequently end up with late or over budget, or both, projects, at the end of every project (I oversaw 5 multimillion dollar projects using Waterfall methods) we at least had a working application that met the original specifications.
Now, after two similarly sized Agile projects, all I can say is it seems to be an excuse for developers to skip QA/QC procedures "because we're already into the next scrum" and end up with a mess that doesn't come close to matching the original specification at the end blaming changing requirements and "developmental issues" during the scrum process. I just turned down a contract that explicitly required Agile coding because I don't have any confidence that the end user will be satisfied with the results.
"Unheard of means only it's undreamed of yet,
Impossible means not yet done." ~~ Julia Ecklar
But you know, development isn't about making developers 100% happy. It's about product.
I spent around 15 years as a developer, and now I'm closer to a PM.
Development has to have actual goals, clear targets, and measurable outputs -- because you're either writing something specific which has to work as designed, or you're releasing a version of a product which has to fix a set of things and add a set of features. Both of these will probably have deadlines.
The problem is when we see it as "we must keep the developers happy" or "we must keep the middle management happy".
You're all, in theory, on the same team. If the developers have no measurable yardstick to judge their progress, or middle management collects a bunch of meaningless metrics which don't help the development process ... you're doing it wrong.
It has long been observed that managing developers is like herding cats.
Fundamentally what is happening is you need to ensure all of the cats get to the same place at the same time. Some cats, once they understand the goal, will plan their own route and get there in plenty of time, and will assist in getting some of the other cats there ... others need to be dragged hissing and mewling to make sure they don't go off in random directions and not show up.
In my experience, some teams will organically manage their stuff, and others need a good swift kick in the ass.
I've met a few developers who need to have a little friction foisted on them, or they drift a little. And some of the best managers I've known are ex coders who understand this.
The trick is to fool the cats into forming a self organizing collective, as well as implementing ways to keep tabs on all of the cats to ensure none have gone chasing butterflies.
The specific methodology is as dependent on which cats you have as anything else.
Lost at C:>. Found at C.
Funny thing is that the original 'AGILE Manifesto' wasn't 'theory' or even a methodology: it was really a set of observations on what did and didn't work for them.
I think the 'universal solution' aspect of AGILE is let your smartest people work the way that they find most efficient - trust your (best) people. Many of the core concepts are not revolutionary: don't get bogged down in planning, work in small teams, prepare to adapt rapidly when your spec cannot be fixed.
The AGILE guys were inspired by the obvious wastefulness and inefficiency of the big enterprise software projects they had been on, so to that extent their observations were dead accurate. But now people are acting as though the *specific methodology* that's grown up around it is precious, holy and applies to everything, everywhere.
It's exactly like the scene in 'The Life of Brian; where Brian loses his shoe running from the crowd: one guy argues that they should all hold one shoe in the air, and the other guy wants to gather shoes together. The shoe is not the point (SCRUMS, Pair programming, backlogs), it is the idea of working intelligently.
'This writing business. Pencils and what-not. Over-rated if you ask me. Silly stuff. Nothing in it' - Eeyore
I also have to agree but for different reasons. What I've experienced is Agile as excuse for micromanagement. Projects take much longer than they used to because we now agonize in meeting after meeting over details that used to be left to the developer to decide. Agile is a recipe for managing programmers fresh out of college perhaps, but most I work with aren't those, and they work better when you trust them with more of the detais and have management worry about the bigger pictures instead...