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.
Yes.
SJW n. One who posts facts.
Sales / Management are on strict Waterfall and dev is on Agile
Until those concepts align in a company they will always be at odds with each other
From where I've sat Agile just looks like 'weekly iterative waterfall; skimp on testing'.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Are we going to go back to Waterfall?
In my experience, that would be greatly preferable to Agile.
But Agile works better than any other methodology that I have used, even when implemented piecemeal, by mediocre programmers, rather than in its "ideal form".
My experience is just the opposite: agile is very nearly the worst of the methodologies I've used. The one great thing about it is something that can be done in any methodology: increased communications. We can throw out the bathwater and keep that baby.
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...
Thank Heaven for wifi and laptops
Sigh. That's why my company banned laptops from sprint planning and sprint retrospective meetings. With forty devs, it takes about six hours to score enough stories to keep all of us busy for two weeks. The retrospective, aka bitch sessions that really hurt morale, take a couple of hours. That's an entire day wasted every two weeks with nothing done. Add-in the JIRA-induced overhead, preplanning meetings, creating user stories, etc., and I think I only get to write code about ten hours a week. Agile is just too heavy of a process.
DING!
If by saying QA/QC isn't completed you mean that unit and functional testing is missing, then the developer is not done. If you have problems with the developer not writing these tests, then be sure that "Definition of Done" includes some acceptable target level of unit/functional testing.
If on the other hand you get to the end of a story and accept it only to find out that it doesn't meet your QA standards, then you as a product manager haven't done your job in properly validating the story prior to acceptance; add to your own procedures the time required to properly validate the story for acceptance. Maybe you need a testing resource to do this if you are overworked as a product manager - an assistant product manager, even.
Agile is as good as you make it.
Let us live so that when we come to die, even the undertaker will be sorry -- Mark Twain
None of those are failings of waterfall at all. There is nothing about waterfall that requires you to make ironclad decisions at the very start, and there is nothing that prevents you from adapting the course of development as the project proceeds.
In other words, you aren't describing waterfall in your comment. Yes, I'm invoking the "No True Scotsman" fallacy, since that is usually what is invoked when Agile is criticized.
The real truth is that all methodologies can be done well or poorly, including waterfall and agile. The difference that I've seen in practice is that it's incredibly hard to implement Agile correctly (such that I've never seen it done), but implementing waterfall correctly is not a huge chore.
At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.
So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?
For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.
My organization accounts for QA/QC with the definition of "done"; QA is not a second class citizen of the organization, but rather a crucial part of the development team/process - and the story is not DONE until QA says it is. Therefore it rolls over across iteration boundaries as needed, and is only demo'ed when it is done.
The problem we have had with Agile thus far seems to be our inability to produce accurate estimates without doing Big Design Up Front which ultimately means spiking every story before we can get started. Nearly every time we try to shoot from the hip on story estimation for anything moderately complex (or worse), we have missed by several multiples the actual amount of work needed.
This is mainly due to the product being very complex (think enterprise scale SaaS, tens of millions of users, terabytes of data, complex data modeling, and numerous technologies being adapted with a variety of API/interfacing solutions) with many interconnected systems across multiple data centers and cloud services... you just can't stare at a story in the backlog and come up with a meaningful estimate off the top of your head no matter how well defined the acceptance criteria are because no one person knows what the potential impact is to all those systems.
But we're committed to working on improving our processes, cross-training, and reduction of overall system complexity to eventually be able to do just that and are sticking with Agile because it has forced us to take smaller bites which has really been a challenge for our sales/marketing and product owner teams because they want the world and they want it yesterday... and Agile empowers the scrum team to give them a reality check and say no.
I apologize for the run-on sentences... too lazy to edit at the moment.
A lot of companies actually sit down during their stand ups, because they last too long to stand the whole time.
I've tried to point out the stupidity of this situation to some of these people (at least change the name!), but the irony escapes them.
"First they came for the slanderers and i said nothing."