Slashdot Mirror
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?"
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.
SJW: Someone who has run out of real oppression, and has to fake it.
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.
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.
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.
The Cloud - because you don't care if your apps and data are up in the air.
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.
Fugue for Aaron Swartz
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.
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.
MidnightBSD: The BSD for Everyone
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.
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.)
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
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.
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.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
"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?
Their they're doing there hair.
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.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson