New Analyst Report Calls Agile a Scam, Says It's An Easy Out For Lazy Devs 491
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?"
You get what you pay/wait for (Score:5, Insightful)
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 (Score:5, Insightful)
Yep. Fast. Cheap. Good.
Pick two.
Who are these people again? (Score:5, Insightful)
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.
Like any new method (Score:5, Insightful)
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.
Re:Who are these people again? (Score:3, Insightful)
Re:Who are these people again? (Score:5, Insightful)
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:You get what you pay/wait for (Score:5, Insightful)
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!
Agile (Score:5, Insightful)
Not lazy devs, just unrealistic deadlines (Score:5, Insightful)
Re:Not lazy devs, just unrealistic deadlines (Score:4, Insightful)
Re:Requirements do change (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
Re:I love it when XP/scrum practictioners defend i (Score:5, Insightful)
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:Who are these people again? (Score:5, Insightful)
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:Developer rebellion? (Score:4, Insightful)
I've seen this in practice, it works really bad.
The problem is that "really cool new features" pretty much always win from all but the most annoying bugs.
If you rely on a feature that only a minority uses and that feature is bugridden, a customer-controller priority system will ensure that it'll never get fixed.
Unless they make an exception for bugs (bugs have priority over everything else), it won't work.
Re:Not lazy devs, just unrealistic deadlines (Score:4, Insightful)
One thing that I've learned, working in a bit of a project management capacity, is that for a lot of businesspeople, the only time frame they actually understand is "I NEED IT RIGHT NOW!"
In fact, I only really remember 1 project where there wasn't an issue. End result: We finished what we had originally set out to do 2 weeks ahead of schedule, added some polish for a week, and released it a week early. All because the smart business manager and project managers had done everything they could to allow the development team to succeed: (1) Determined their project schedule from the development teams' estimates rather than the business manager's enthusiasm, (2) left appropriate time for mistakes to happen, (3) fought any attempt at scope creep, and (4) ensured that people who weren't on the project kept out of the hair of those working on the project.
Re:Agreed and... (Score:5, Insightful)
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 [xprogramming.com] because you made a few "tweaks".
Re:You get what you pay/wait for (Score:5, Insightful)
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 (Score:5, Insightful)
"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:I disagree .... (Score:4, Insightful)
Oh, I don't know - given N methodologies of approximately equal effectiveness, it seems to me the one that the workers find most enjoyable/rewarding is highly preferable as it will allow you attract better people and/or pay them less.
Re:You get what you pay/wait for (Score:5, Insightful)
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:Developer rebellion? (Score:5, Insightful)
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? (Score:5, Insightful)
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.
Re:Who are these people again? (Score:5, Insightful)
I don't know why this is modded Funny when it's the most Insightful description of the report yet.
Re:Took the words (Score:5, Insightful)
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 [wikipedia.org] and focusing on how to get good developers working productively instead--that idea is just fundamentally repugnant to many businesses.
Re:You get what you pay/wait for (Score:5, Insightful)
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 (Score:5, Insightful)
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)