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?"
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.
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.
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.
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.
I am officially gone from
"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.