New Analyst Report Calls Agile a Scam, Says It's An Easy Out For Lazy Devs

msmoriarty writes "We recently got a copy of a new Voke analyst report on Agile, and the firm basically blasts the movement from top to bottom. Some highlights: 'The Agile movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Agile.' 'Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance. ... Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.' So did the analysts just talk to the wrong 200 people?"

Comments

You get what you pay/wait for

[elrous0]

Beware of hucksters selling a system that will give you everything you dream of, and fast and cheap to boot.

And be even more wary of those who promise a way to outsource everything on the cheap without taking any hit on quality.

There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick.

Re:You get what you pay/wait for

[NReitzel]

Yep. Fast. Cheap. Good.

Pick two.

Re:You get what you pay/wait for

[Anonymous Coward]

Not to mention the fact that the provider wants you to subscribe to their services at $999 per year, and even if you opt for the 3 month (free) trial, you don't get access to the report unless you purchase a "bundle" for $199... These are troll! and the fact that Slashdot has referenced them in such a provocative article is unconscionable!

Re:You get what you pay/wait for

[multi io]

Yep. Fast. Cheap. Good.

Pick two.

I think it would be hard to be slow and cheap.

Re:You get what you pay/wait for

[Gaygirlie]

Oh, I could point you to PLENTY of examples.

Re:You get what you pay/wait for

[PPH]

Beware of hucksters selling a system that will give you everything you dream of, and fast and cheap to boot.

Already this thread has gone off topic into politics.

Re:You get what you pay/wait for

[dkleinsc]

The one thing where I think agile might help is in reducing the impact of this scenario (which I watched really happen):
1. Marketing team presents a design of a web page to the development team, saying "This is exactly what we want".
2. Development team works night and day to make that web page completely functional, conforming perfectly to marketing team's every whim (burning out developers in the process).
3. Development team presents the design to marketing team, on time. Marketing team promptly announces that they hate it, ignoring all protests involving a side-by-side comparison between what the page does and what they asked for.

With more frequent iterations, there's a chance that the difference between what the marketing team asked for and what they actually wanted will be evident sooner.

For the most part, though, the basic deal with software developers is: 1. Hire competent developers. 2. Give them clear instructions about what you need. 3. Trust that they will do their best to get what you need done as quickly as they reasonably can.

Re:You get what you pay/wait for

[DCheesi]

The iterative development model is really the best thing to come out of Agile, IMHO. Multiple sprint cycles allow Marketing to shift their priorities without it turning into feature creep, since they're forced to decide what to cut from each cycle. And as in your example, it allows for change feedback once they've actually used the feature. All the rest of Agile can be tossed aside, but this orderly iteration is by far the best method I've seen for dealing with Marketing requirements issues.

...So of course it's the one thing that's expressly forbidden in the new formal development process imposed by upper management :-/

Re:You get what you pay/wait for

[petes_PoV]

"This is exactly what we want".

The example cited is just a textbook failure to consult properly. Every client *knows* exactly what they want - until you ask them "what about ...." in which case they'll think again, or challenge their conflicting desires: "you can't have it easy to use AND infinitely flexible". Repeat that loop until the end of time and you STILL won't get a hard set of requirements - let alone a sensible or possible set.

Every experienced designer knows that the customer always lies. They might not know they're lying (or they may well do) but they will NOT tell you the truth, simply because they don't know it yet. The job of a designer is not to write down all the wishes, hopes and dreams that exit the mouth of the client, it's to present them with a list of what's possible, what's necessary and what can be done within the constraints (time, money, skills) that exist.

In the end it doesn't matter what methodologies you use. Good, talented, motivated developers will get the job done no matter what processes or obstacles you put in their way. Lazy, stupid, demotivated or confused developers will never finish the work

Re:You get what you pay/wait for

[JWSmythe]

    Well sir, I have a nice Pentium 100 to sell you. And I have a team of developers ready to do your work. For only $20, they'll do any project. Don't ask how long it will take, I'm sure we* can have something** to show you by FY2015***.

    * "we" only indicates anyone who the work may or may not have been farmed out to.
    ** "something" may only be a photocopy of the printout of your original request.
    *** FY2015 is not a promised date, it simply indicates an arbitrary date in the future.

Re:You get what you pay/wait for

[dfetter]

Yep. Fast. Cheap. Good.

Pick two.

That's actually the optimistic perspective. Given skill, experience and good will, you could pick up to two. Frequently, the most you could have is one, or in sadly common cases, zero.

Re:You get what you pay/wait for

[mcmonkey]

Yep. Fast. Cheap. Good.

Pick two.

I've heard that many times before, and I have to disagree.

Where I work, we didn't pick two.

Our projects take twice as long as they should, cost three times as much as they should, and quality in the crapper.

Who says you can't have it all?

Re:You get what you pay/wait for

[turbidostato]

"There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick."

Exactly. But even then, there are ways and ways to reach to that.

"Agile" (in its various incarnations, but I'm specifically talking about Scrum) is not a project management methodology but a people expectations' management methodology. Most people have this wrong.

And it is a kind of people expectations' management methodology that leans *a lot* on giving power to the people that do the work -the pigs.

Just paying attention at the two observations above is the difference between a successful and a failed "agile" implantation:

1) "Chickens" that "forget" that agile is about empowering pigs: a lot of observations about that have already been cited here (i.e. "we do agile", which in fact means "we set your goals for each fortnight in stone and you'd better acomplish them by living in a permanent sprint or you are fired").

2) "Pigs" that are not up to the challenge: the Sturgeon's revelation works on every scenario but its results are even more wherever you depend on people more than in processes. With Scrum you are letting programers work like artisans or craftsmen (which, due our current state of the art is what they are no matter how much we'd want it to be consider an engineering); but once they are considered artisans, the difference between good and bad artisans is the more acute. And most (as in 90% of them per Sturgeon) are not up to the challenge. Here is where goes those "programmers want agile because it's the way they find to scape from whatever they don't like". It works the other way too: agile is most demanding for programmers but it increases demands for the business guys too: they forcibily need to understand what they are asking for and they won't be able to hide their responsibility pushing it towards the freakoids: *you* had the responsiblity to choose what was the best for the business and you failed; you can't hide the fact that it was *you* the one that wanted the "selling ice to the skimos" feature first.

3) And then, there are the "cargo cult guys". You find this kind very easy: they say "we are doing scrum" but then you learn that they interviewed the customer once on the kick-off meeting and they won't see him again till six months down the road (but, of course, they have their morning stand up meetings, their sprints, their cards, their pomodoros... even an internal manager -the one that sets the goals for next milestone in stone, acting as "internal customer" in lieu of the real one...).

So, just like always, you either take the work to stablish a high quality, commited, well imbricated team -and then methodologies doesn't mean so much, or you use the methodology in vogue to hide your lack of abilities and/or lack or commitment. And, just like always, it is the ones in command those that really have the greatest portion on the success of a project -and even a greater portion on its failure. But, hey, since they are in command they are in the best position too to make the successes to be theirs and the failures everybody else's.

Re:You get what you pay/wait for

[turbidostato]

"Every experienced designer knows [...] The job of a designer is not to write down all the wishes, hopes and dreams that exit the mouth of the client, it's to present them with a list of what's possible, what's necessary and what can be done within the constraints (time, money, skills) that exist."

Right.

"In the end it doesn't matter what methodologies you use."

Wrong. They may matter more or less, but they *do* matter. For instance, your approach to an "experienced designer" lacks a critical observation that the agile processes take into consideration even if the "experienced designer" forgets about it: the customer won't tell what they want because he doesn't know yet. Well, the designer won't get to what the customer really needs because he doesn't know it yet either: the iterative process with strong feedback between developers and customers with no people in the middle copes for the fact that neither the askers nor the doers know what's needed yet but by means of the strong feedback they maximize the chances to discover it on their way or, at least, to weight the highest responsibility to the ones that have the most chances and/or the most stakes to do it right (business to business and technology to techies) on a tighted loop.

So in the end: methodologies *do* matter. People *do* matter even more. Near, but not exactly the same thing you said.

Re:You get what you pay/wait for

[Guspaz]

I have. It didn't save money, because of the enormous amount of rework involved. It was a huge disaster that thankfully put the senior management off outsourcing for good.

They didn't do it to save money anyhow, they did it because a big customer wanted a new product, and we didn't have the development resources to pull it off. They hired an Indian outsourcing firm get the extra development resources required. It was a nightmare, both for those of us on the local side of the dev team working directly with them, and for the management, whose decision came back to bite them. Even years later, we're still finding bits of facepalm sprinkled in the code of that project...

Re:You get what you pay/wait for

[KingMotley]

As for as I'm concerned, Agile isn't a proven methodology. Not as far as being able to produce all the claims it makes for every project. In fact, I can say that it's proven to be false, time and time again.

That said, there are SOME projects that work well in an agile environment, and it works well in SOME environments using SOME teams. And on the other hand, there are SOME environments where it just doesn't fit at all, and SOME projects don't lend themselves very well to it, and SOME teams it's a hindrance.

I call that a huge success.

I call that one tool in a shed, not the golden swiss army/ginsu blade that does everything.

Companies would not use it if it did not provide benefit.

Companies use it MAINLY because they've hired program managers that are familiar with it, typically younger ones that want change. Change is good, as long as it provides a benefit. The company typically doesn't care so long as the work gets done in a reasonable amount of time.

Re:You get what you pay/wait for

[hawguy]

Agile is a proven methodology. In the old "waterfall" software industry, the famous "standard" was 7 lines of code per day per programmer.

Thanks largely to Agile methodologies, you can get up to as many as 1000 lines of code per day (though that's a bit on the high side), with even fewer bugs than the old 7-lines-per-day methods thanks in part to thorough, continuing testing being built-in to the process.

Using "waterfall" you could also get 1000 lines of code in a single day from a coder too - but whether the project is done using Agile or Waterfall, if you take the total project time (including requirements analysis, documentation, unit and system tests), the average LoC/day is much lower. And of course, LoC is completely meaningless - when using a modern library or framework a single line of code can replace what would have taken a thousand lines or code 5 or 10 years ago.

In my experience, Agile projects tend to run longer than they would have under waterfall, but the end product is usually closer to what the customer needs - few customers are willing to put in the time to spec out an entire project at the beginning (and are unwilling to freeze their business process during the project) and it takes too long to work changes through the waterfall process, but small changes can easily be rolled into the next iteration of an Agile process. (but some managers overestime the agility of Agile development and think that a major change that requires rearchitecting major pieces of the project can be incorporated into the next iteration)

Re:You get what you pay/wait for

[AVee]

Not to mention the fact that the provider wants you to subscribe to their services at $999 per year, and even if you opt for the 3 month (free) trial, you don't get access to the report unless you purchase a "bundle" for $199... These are troll! and the fact that Slashdot has referenced them in such a provocative article is unconscionable!

A report claiming Agile is just a scam to sell services will set you back $199,-. You just have to appreciate the irony there...

Who are these people again?

[JDG1980]

I'd never heard of Voke before today. What is this company? What credentials do their analysts have, that we should care what they say? (I don't mean academic credentials, I mean proven real-world success.) What are they trying to sell?

There needs to be more skepticism about statements coming from random "consultants", think tanks, etc.

Re:Who are these people again?

[ahem]

I took a look at their website. Seems like two ex-Gartners striking out on their own to build their own Gartner.

To that end, it certainly casts the alarmist report titles in the class of "generate buzz/subscriptions".

Both of the bios of the principals are fully buzzword compliant, not to mention cromulent.

Re:Who are these people again?

[dkleinsc]

What are they trying to sell?

Seems like the service they're intending to sell is a believable reason for manager A to blame the failure of a software project on manager B. In large companies, that's extremely valuable.

Re:Who are these people again?

[greg1104]

I don't know why this is modded Funny when it's the most Insightful description of the report yet.

Developer rebellion?

[Nursie]

It was forced on us by "hip and trendy" managers who saw it as a way to get more frequent status reports (i.e. pretty much daily) and try to get more work out of people (it's agile! Crunch time is every sprint!).

Not that I hate working that way, I like the morning meetings when they're conducted correctly, but it's not a panacea. Neither is it really anything new AFAICT, it's just waterfall with shorter iterations.

Re:Developer rebellion?

[Anonymous Coward]

That is so true that it's waterfall with shorter iterations. The process can still fail miserably if you don't have someone steering the process towards the deliverable goals. Also, just because you finished a piece of shitty code and decided to move on can still spell disaster for a project. One of the assumptions in Agile is that at almost any point you could go back and recode a significant amount of the work once you realize that you've been going down the wrong design path. Sounds nice on paper but in reality I doubt that ever happens. You rarely get a chance to redesign major code elements once they start getting leveraged and established throughout the codebase.

Re:Developer rebellion?

[Vanderhoth]

^ This is exactly what happened in my department. No training or understanding of the processes involved. We were told by our managers, who heard it used as some buzz word then read an article or something on it, we were going to use it.

After five years of practice and putting my own money up for training I finally have somewhat of a handle on it, and it works great in some situations. Specifically when a project is really short and only has maybe one or two cycles before it's complete.

The worst thing I find about Agile is scope creep. We were told we need to manage client expectations, which wouldn't be a problem except we're not allowed to say no, or that we can't do something, and we're not allowed to discuss cost. What I've ended up doing is putting all the request I get in a database then I let the client pick the most important features at the beginning of each cycle. After two or three cycles the clients usually forget about the, "oh, you know what would be really neat!!" features, or they confront me with, "Why hasn't such'n'such been done yet I asked for it two months ago", in which case I tell them it's in the queue. When projects go over budget we leave it to the managers to deal with. After all we're not allowed to discuss cost.

Re:Developer rebellion?

[Decameron81]

Agile works, as long as everyone involved has the balls to stand up for their own part of the process. If the client requests a feature that requires a big chunk of code to be rewritten / refactored, you just have to make sure you're upfront about it, and make it clear of how much effort and time will be required in the process.

The basic thing to keep in mind if that your boss, or the client don't trust your effort / time estimations, agile won't work.

And as a final note: the way to make sure you can trust someone is to hire the right people - have a good screening process when you hire.

Re:Developer rebellion?

[Immerman]

I've come to the decision that good up-front design is important at an architectural level - get a good, well though out "skeleton" in place and you can flesh it out all higgledy-piggledy while being confident that any major rewrites will be of a limited scope. Overall code and data structure, APIs between large modules, that sort of thing. Time spent on quality large-scale design up front tends to pay for itself many times over in the long haul since you can make sweeping changes at low cost. On the other hand any halfway-decent programmer is also at least an adequate designer - when you start designing the details of every module or function up front you're probably just wasting a lot of time, and it sucks all the creative joy out of actually programming. What fun is writing code when the only room for creativity is minor implementation details? If your design is detailed enough to be read as extra-high-level pseudo-code all that's left is the tedium of actually writing the corresponding code, and you've demoted your programmers to the position of sentient pre-compiler.

Right people, right results

[QuietLagoon]

The poll results correlate well with my experiences. I've still not seen a well-functioning agile implementation that has been working for more than three to five years. Once maintenance is required for the undocumented code, and the developers who worked on it have left, the problems with agile start snowballing.

Like any new method

[obarthelemy]

in any field: the early adopter are intelligent, motivated people who know what they're doing and understand how the new method is supposed to work. Later adopters are mediocre hacks who don't perform well to start with, and are probably looking for a way to obfuscate their lack of skill and motivation, or, at best, don't get how the new method is supposed to work.

Agile

[Stirling Newberry]

Is a way for managers to tell other managers that the features that no one really cares about will be delivered by a date that no one believes in.

Not lazy devs, just unrealistic deadlines

[gaygeek]

In my experience, agile is not about lazy developers not wanting to do the boring work, it's about the business owners and project managers wanting to force unrealistic deadlines on projects such that there is no time for those tasks because of the tight deadlines and quick release cycles. It is rare that they allow the principle that you deliver what you can by the release date, but rather they want everything they asked for and the devs need to make it happen.

Don't blame Agile for bad recruiting results

[ansak]

Agile is just a structure. Like anything else, it's only going to be as good as the people you put in place to execute it. A properly constituted agile team will put documentation (of designs, code, deployment, whatever) up as stories/tasks that need to be accomplished right alongside working features. Documentation is an end-product just as surely as working code and unit tests are.

If the team doesn't identify those tasks and sign up for them, you hired the wrong people. Reform your recruiting process before you blame a process that delivers a working solution at the end of every sprint. And if your so-called Agile doesn't pretty much do that, then you really are being scammed.

cheers...ank
(I've been a developer for 26 years; some form of Agile has covered the most productive and enjoyable parts of my careeer)

Agile is not the problem

[laffer1]

I'm the first to agree that Agile doesn't work for every company or every situation. However, if done correctly, it's a very useful process and I've personally seen it succeed. Most people ignore some of the rules and that's where they get into problems. I've seen craziness like project owners also be team leads or have direct hire/fire power. The second someone has to worry about their job, idiocy is not pointed out as it should be. Agile lets you change course, but it's not meant to make things 2000% faster to develop. Any failure of agile or the other extreme, waterfall, is always because someone didn't follow the rules and didn't implement the process correctly. I've never seen waterfall work correctly because it requires a lot more planning up front and everyone wants to change course in the middle of the process.

Business people don't want process. They want speed. That has to change. No one cares about quality or bugs until customers are complaining and sales are lost. Business people need to learn patience. Developers need to learn to stand up for process. I used to doubt it myself until I worked at a company with a functioning process. Today, I'm working for a company with no process again and it's a nightmare.

The best thing about agile is that you have clear deadlines and actually feel like you're making progress during the programming process. If done right, it can be a real morale booster.

Agreed and...

[LostMyBeaver]

I like the morning meetings, but I have found the concept of a sprint to have killed off most of the design and planning phase, especially as a group when needed. Most of the projects I work on should have all the developers/engineers/scientists locked in a room together for two months before a single line of code is written. We should have a project manager with better than entry level knowledge in all fields and as a bonus based on recent methods should have tests for every component written before and/or after implementation.

I think extreme programming combined with project management and morning scrums would be much more suitable than Agile which tends to make me see most projects get to the 90% mark muh faster, but fails drastically at the end since the lack of proper planning made integration of components extremely impractical. I still like it best when 1-2 guys spend some time to build the base product and then a team is assembled to evolve it... It avoids too many cooks.

Re:Agreed and...

[ATMAvatar]

One of the main things you should be doing when practicing agile is continuous integration. The point is that you should be able to release at the drop of a hat. It has been a long time since I have had to worry about long-delayed integration woes.

Re:Agreed and...

[IICV]

One of the main things you should be doing when practicing agile is continuous integration. The point is that you should be able to release at the drop of a hat.

That's one of the problems with these self-reported "Agile" failures - sure, it borders on a no true Scotsman argument, but if you're "doing agile" with five or six week "sprints", hour-long sit-down meetings instead of standups, no product manager, no backlog, no continuous integration - then can you really say that agile methodologies failed?

What really happened was you were trying to do waterfall faster, which just doesn't work. It's like saying baseball doesn't work because you made a few "tweaks".

Mod article 'flamebait'

[Tony Isaac]

The survey doesn't discredit Agile. What it does is show that there is wide misunderstanding of Agile, including by those who claim to practice it. I've worked in such a shop, where Waterfall was the methodology, but it was presented as Agile. I've also seen Agile work beautifully, and I've personally implemented it successfully.

What Agile really does is take into account the fact that it's not possible to fully anticipate and visualize all necessary features before a project begins. This is no different from any other physical product development, say, designing a new gadget. Lots of planning can and should be done up front, but once a prototype is complete, it will become evident that changes need to be made. Waterfall assumes that the product can be well understood from the beginning, like building a building. If you are building software that is nothing but data entry screens, maybe Waterfall can work. But for anything novel, it falls far short.

Re:Requirements do change

[dgatwood]

All the planning in the world can not assist with political changes in a business. Requirements are a moving target and agile is the best method formal framework available for integrating those new requirements into the workflow.

Maybe, maybe not. If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product. At some point, you have to step back and say, "Okay, we're never going to have a working building if we can't decide whether we're building a house or an office building." At some point, you simply must stop doing the agile stuff to just beat on the project for an arbitrarily long period of time until you have something that is functional for some fixed set of goals, and worry about dealing with the fallout later.

Also, Agile tends to assume that everything can be broken down into subtasks that take only a single iteration to complete. In practice, this is not always the case, particularly with complex software.

Finally, Agile has a tendency to fail in its goal of producing software that is actually usable by its intended consumer. Because the design work is done iteratively, it is very easy to go off on tangents and iterate on some part of the design, while failing to design the whole. This problem can also plague the architecture underneath if you aren't careful.

Flamed

[WilyCoder]

I realize I might get flamed for this, but I wanted to say it anyway: I think agile is a complete waste of time. Its micro management wrapped up in a fancy, marketable term.

I've been a senior developer for about 8 years now. Never used Agile, never had a need to. Hire the right people and there is no need for agile.

Ok, my flame suit is on.

All software methodologies are snake oil

[pauljlucas]

If you have a group of talented developers, all they really need to do is programming, motherfucker. (It helps if you read it in Samuel L. Jackson's voice.)

I have issues with the TFA

[thinkingsites]

From the TFA:

* Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.
- I'd like to see the number for success in waterfall.

* Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
- How is 40% overwhelming? I though overwhelming meant much larger than a simple majority. What about the other 60%?

* We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
- Having not met them, I can't vouch for the Agile leaders. However, we're using their product, not their personality.

* Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.
- Sure, it's another developer rebellion... against bad practices. Agile does not mean you get to avoid the necessary tasks like documentation. And who doesn't want to make money? If that's what they do fulltime and it's valuable they should be able to earn a living. That's the pot calling the kettle black with them pushing their $150 report.

I'm not an agile fan boy but it's a better alternative than A) bad managers thinking they're managing a project correctly or B) planning a massive project and having it shift underneath you.

This just sounds like a smear to get attention.

Re:I love it when XP/scrum practictioners defend i

[ATMAvatar]

Yes, no methodology is going to be a magic bullet that turns a loser team into a superstar team. Agile was never intended to do so.

What agile processes attempt to address is the transient nature of requirements. Large, monolithic processes do not respond well in cases where the client doesn't know exactly what they want up front.

The reality is that clients often times add things during the process, and just as often as not, they do not realize that what they said they wanted wasn't really what they wanted. Providing continuous feedback and re-adjustment helps to mitigate this problem.

Re:Agile works - My experience

[fotoguzzi]

"I was trained in Scum/Agile/Design for Lean Six Sigma to the green belt level and have over 4 years experience."

No buzzwords here, thankfully. Is Scum that super-stripped-down version of Agile that I have heard about?

Took the words

[Giant Electronic Bra]

Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.

Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now", so yes, you will refactor, but that refactoring is an ongoing part of the process that is informed by 2 things, continuous integration and user acceptance testing.

IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process. If you actually PAY ATTENTION to the things that Agile is telling you to do (personally I find XP type process to be the most effective) then you can make it work. Everyone needs to understand the value of the parts, and as any Agile expert will tell you ALL the pieces are important. It is not at all interesting news for someone to tell me that if you fuck up and ignore half the pieces of the process that the other half don't magically just work.

No one development methodology is a panacea of course, but this report seems to be meaningless criticism based on not actually understanding how and why to use Agile.

Re:Took the words

[greg1104]

I don't think the report is even addressing whether Agile *can* be used effectively nor not. Its scope seems to be whether it *is* being effective or not for companies, and the answer they present is that it isn't. Whether or not there is a One True Agile that really does work isn't the point; that doesn't matter if people can't figure out how to adopt the approach for their own work (or with consulting help in implementing process, which is also being commented on). You can't prove a software development approach works by presenting examples of it working; the amount of variation among development teams means you could have just been working with a good one. The reason companies try to adopt methologies is to try and get useful work out of *any* development team. A really good software process should work as a filter, only letting things of good quality through as output.

Now, I would turn that conversation not toward Agile--it's no better or worse than the alternatives--and instead ask "is there any process that gets good software even from bad developers?" That's what managers want, and every new softtware development approach that comes along includes some people who claim such magic exists in the process that this will happen. The alternative--accepting there is no silver bullet and focusing on how to get good developers working productively instead--that idea is just fundamentally repugnant to many businesses.