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?"
Developer rebellion? (Score:5, Interesting)
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.
Right people, right results (Score:5, Interesting)
Re:Developer rebellion? (Score:5, Interesting)
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.
Don't blame Agile for bad recruiting results (Score:5, Interesting)
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)
It's just good business (Score:2, Interesting)
The goal of development is to produce and deliver working software that aligns with the business objectives in a cost effective manner.
Agile is an attempt to achieve these goals and was conceived as a response to the failings percieved in waterfall. This is achieved by ensuring that, on a frequent basis, developments goals are focusing on businesses needs. Now this isn't to say that you can't screw up with agile. You can consistently deliver the wrong product or fail your iterations. But the business now knows it after a few weeks and can adjust. This compares with failing at the end of a 12 month Dev cycle. Both fail but it costs a lot less to fail with agile.
As for documentation, agile does not necessarily preclude documentation. Instead it says if it doesn't provide a net positive value don't do it.
Agile is not the problem (Score:5, Interesting)
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... (Score:5, Interesting)
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.
Mod article 'flamebait' (Score:5, Interesting)
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.
Everyone knew Agile was a scam. (Score:3, Interesting)
Agile was meant for producing disposable code with few people. Such as MS Access documents that tell you the amount of wood a house is going to need, or a quick and dirty C# program that reports to you on how your web-servers are doing so you don't have to spend $10,000 per server for a whatsupgold license, or....*insert "If we could do X for Z Cash that'd save me Y money" statement".
Check out this picture.
http://en.wikipedia.org/wiki/File:Agile_Software_Development_methodology.svg
Someone thought that was a GREAT way to build complex enterprise systems. Afterall, there's a lot of movement in there, and execs with high blood pressure love seeing Chinese fire drills.
The end result is burnt out developers produce a large amount of bug ridden code which gets stacked ontop of each other in a process known as fudgepacking. A Fudgepacker is someone who builds the integration layer between the pieces of fudgey goodness which usually results in Enterprise systems with operating procedures which state "If the software gives an error, that is normal, click OK", and because management pushed it, even though the numbers LOOK wrong they are actually right which leads the entire org off a cliff. After-all, no developer knew what numbers should look correct.
If caught just before going over the cliff, two things happen. First, the lemmings argue about who's got to jump off the cliff first. Second, after the appropriate blood sacrifice upon the alter, management asks to get it fixed. Problem; the fudgepack..er..integration specialist costs $250k/year and jim says it's jacks code, so they blame jack and jack is tasked with fixing it. Well....
Cost inevitably gets out of hand in such a world which leads to outsourcing as a "risk" instead of looking for an actual solution because choosing the wrong solution makes it look like you're doing work to investors and the investors know, while it's likely you'll fail, if you do, and you look like you tried hard, some other sucker may buy your work thinking it just needs a tweak.
Everyone who does software development just wants to build indisposable code; systems that are rock solid and work well for decades. This requires a lot of work, planning and a lot of research by the business to build a [i]design document[/i].
Re:Developer rebellion? (Score:5, Interesting)
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.
I have issues with the TFA (Score:5, Interesting)
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:You get what you pay/wait for (Score:5, Interesting)
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:Agile is not Easy (Score:3, Interesting)
PMP Backlash (Score:4, Interesting)
Anyone who has been forced to work with certified Project Management Professional project managers will understand why organizations have looked at agile. PMP is the worse of waterfall with a bunch of useless buzzwords. Agile breaks that cycle but does introduce some other problems.
The biggest problem with developing software is that any non-trivial system takes time to deliver regardless of the methodology, You can take time to properly spec out and design a bridge over a river because it'll be good for 50 years. But the world of software changes so fast that any system is obsolescent by the time it's done, and if you spend a few months specing/designing it's time for a redesign before you even start writing the code.
Re:You get what you pay/wait for (Score:4, Interesting)
I think the real problems come from pure forms of agile, or the agile services sector. Like any technique it tends to work well when hybridized with others in order to best suit the situation, and sucks in its pure inflexible form.
Re:Developer rebellion? (Score:4, Interesting)
You asked wrong. You don't ask for the priorities, you ask for the order he'd like them resolved in.
Re:You get what you pay/wait for (Score:5, Interesting)
"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 (Score:5, Interesting)
"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 (Score:5, Interesting)
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 (Score:5, Interesting)
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...
Re:slow and cheap (Score:4, Interesting)
You're getting +Funnies, but it's a legit part of the equation.
A thundering famous example is cargo shipping stuff from China. China, as we all know, is the poster country for Non-Expensive, and just to amuse the /. crowd, I'll use the example where a businessman lost $100,000 because his shipment of Justin Bieber dolls took too long to arrive and then they had a haircut that was no longer good.
http://www.dailymail.co.uk/tvshowbiz/article-2046881/Justin-Bieber-haircut-cost-doll-company-100-000.html [dailymail.co.uk]
The other more harmless example is US Mail's Bulk Rate shipping.
Re:Developer rebellion? (Score:4, Interesting)
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.
Herein lies one of my problems with what my people are calling Agile (everyone I talk to seems to have a slightly different, sometimes wildly different, idea of exactly what "agile" means - ATM it seems to me to be "what we've always done to an extent, but more formalized and with responsibility more evenly spread"). Our company/group is going through a very fast change at the moment (most of it for the better: resource for things we've been begging for resource for for years, better coordination/sharing between parts of the group, commitment to proper planning, and just general investment from up high to refresh+grow our people and equipment) and "agile" is one the BigThings.
I'm liking parts of it, but some of it grates (the terminology for a start: the next person who calls me a "scrum master" is getting rugby tackled or, if I'm having a bad day, pushed down the stairs).
One of the issues I'm having is that people are trusting my estimates too much IMO which pushes me out of my comfort zone quite a bit as I know that tracking and estimating time is very much not my forté. Though I think part of the problem is one step above my line manager, where there are a couple of people taking estimates too literally which seems to me to go against the methodology they are asking us to follow: they ask for a ball-park estimate, but then expect a detailed report if things take more or less time than that "guess" (and preparing that report, or just having meetings about it, eats into the next period's hours for someone). As it happens I've surprised myself by being fairly close to the mark most of the time thus far, when estimating my ability to get X done in a given timeframe, and other peoples' abilities to do the same, and including "coordination time", but I fully expect at some point soon there will be a massive underestimate (there have been some underestimates already, but some overestimates too and they've more-or-less cancelled out and where they didn't I pulled extra hours and made them look like they did) and excrement will be introduced to the air circulation device...
One of the things I'm not getting out of the change that I've been nagging about wanting for years is time to adequately document work so that later maintenance is less arduous. Tasks like that are considered and get the own "card", but those work items don't seem to gather any priority.
Though as I've expressed my concerns more than once I'm filing it under "things I can say 'I told you so' about when the time comes" for the time being. Having said that, the things that look much more positive in the future as a result of the investment/expansion/improvement are outweighing my concerns at the moment - I'll take a long look at the situation again when I can see where some more of the many balls that are up int he air right now are likely to land.