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.
DNRTFA, but I think this will be a fun thread.
Regardless of what Agile really is (a true scotsman?) the abuses perpetrated in the name of agile are appaling. I think a lot of people think agile means something like:
make bad developers good by not bothering to organise things properly
Which is really amazingly appealing if completely bogus.
SJW n. One who posts facts.
No, it's just no longer selling as many books and consulting hours as it once did--so it's time to invent a new scam.
There is no way to optimize the development process for software. Inserting terms such as "Agile" or "Waterfall" really just create bloat and waste time. The best software development process is to have no process and work in the way that fits you best. For instance when I write large software projects, I just start coding, I pick a place to start at and go. I wait until I have large testable blocks completed and then debug and integrate them. I don't follow and form of standard development process and yet have never been held up via a deadline of meeting request.
When developers try and add those stupid terms, they're basically saying that they can't self manage and instead of taking responsibility, they're going to throw silly management methods around in an attempt to streamline a task which is unique to each individual developer and situation.
The only things you need to write good code are the right language, the right platform and proper requirements. Once you have those, you can just start and work to completion.
That's not even close to enough time for a major cultural change to take place. The Agile Manifesto describes a culture of work that is so fundamentally different from how work was (and still is) performed, that I expect it will take another 15 to 30 years for organizations to really "get it". This is the same thing that happened with Lean manufacturing. Toyota developed it, other manufacturers adopted it as a fad over the course of about 15 years, and then it declined in popularity... but it never died out because it was "correct" and "good". Now, 40 years later, most manufacturers are still learning to be lean, but lean has fundamentally changed the culture of manufacturing. I have clients that will probably be working to adopt Agile methods over a 10 to 20 year period. Agile hasn't failed... Andy Hunt's patience has failed.
Helping with organizational effectiveness is our job.
No.
But it'll be yes again by the time of the next scrum.
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
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...
Skip QA/QC procedures? Then you're not Done. That means you've completed 0 stories and get to finish them on your next Sprint.
it's management. When you get a good project manager its like a breath of fresh air. The best PM I ever worked for was a guy that used to be a developer and just didn't understand object based programming, after an honest assessment, so he decided to go into project management. He shielded us from all the corporate BS and just let us code.
Most of the other PM's I have worked for have no background in programming. Some of them claimed to and didn't, which is much worse than someone that just tells you they don't. They would insist on idiotic exchanges like the following:
PM: How long will it take to code this?
Me: I'm not sure until I get all of the requirements
PM: Can you give it a guess?
Me: Sure but what's the point? It won't be a very good guess.
PM: That's OK I just need something to put on the project plan
Me: *Bullshit radar is now on full alert* So you just want me to pull something out of my ass so that you can finish up your project plan? Is that it?
PM: Umm, well, no...it's not like that
Me: OK, fine. I'll give you numbers but they are going to be grossly inflated to account for the unknowns. It covers my ass. Kind of like what you are doing, no?
PM: *Grunts and walks away*
Most of these people look at project management as if we were building widgets on an assembly line. As if we know exactly how long each task is going to take. Well, software development is not not like that. Not in the least. The ones that understand that - the ones that are truly "Agile" as it were - are the successful ones. The successful ones understand that any number of things can go wrong and plan accordingly.
Waterfall just cannot work.
You might want to talk to NASA and tell them all their missions have failed.
1. All the descions are taken at the time you know the least about the outcome, ie at the begining.
You know what that's a sign of? Failure to specify your requirements. (Something Agile people know so little of these days it's unsurprising they should be banned from programming)
2. By the time you get to the end your requirements are out of date, you get the product you wanted at the start of the project not the one you need now.
I need what I specified. If I need something else now, I should have added on more requirements. In fact, at the start of the project I should have added in an allowance that just maybe I will need to change something, or a dependency in the project may shift in time or not meet its capabilities. BTW, for you Agile people, this is where the Project Manager usually does his work. If they're managing which requirement you're coding and how, he's not doing his job.
If you try to support requirement change all you end up doing is replanning and pushing back delivery.,
If I was originally scheduled to make a simple sort in an adequate time period and then need to add in a complex multi-layered sort, um, yeah? What makes you think changed requirements wind up being deliverable in the same time frame? What vacuum do you live in? Are there pink ponies there too?
3. It was a failed methodology from the start, the original paper that started waterfall was an example of how not to write software
https://pragtob.wordpress.com/...
Again, I guess you better let all gov agencies know that all their projects involving software prior to 2005 or so failed. Guess that moon landing really was on a stage somewhere.
Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause. I've detailed some of those elsewhere, and the response from the believers is always "Oh, you're doing it wrong" which is hilarious, because in multiple cases they were following exactly what little is laid out by the Agile camp. The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states they are unless you're going LCD. In fact, if you estimate your "velocity" by your worst performing programmer on an Agile team, you may, just may, have a realistic estimate of when you'll supposedly get to the finish line as long as no one throws any new requirements your way. As soon as they do, everything you think you know just went away. Sorry, my next SCRUM is pulling me out of this one...
The cesspool just got a check and balance.