Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about 2 years ago | from the but-i-just-revamped-my-entire-lexicon dept.

Programming 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?"

cancel ×


You get what you pay/wait for (5, Insightful)

elrous0 (869638) | about 2 years ago | (#40648303)

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 (4, Insightful)

NReitzel (77941) | about 2 years ago | (#40648355)

Yep. Fast. Cheap. Good.

Pick two.

Re:You get what you pay/wait for (4, Funny)

multi io (640409) | about 2 years ago | (#40648457)

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 (4, Funny)

Gaygirlie (1657131) | about 2 years ago | (#40648501)

Oh, I could point you to PLENTY of examples.

Re:You get what you pay/wait for (-1, Flamebait)

Anonymous Coward | about 2 years ago | (#40648581)

Never worked with outsourced Indian programmers, eh?

Re:You get what you pay/wait for (0)

Anonymous Coward | about 2 years ago | (#40648913)

cheap per time unit, presumably

Re:You get what you pay/wait for (5, Insightful)

Anonymous Coward | about 2 years ago | (#40648417)

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 (-1)

Anonymous Coward | about 2 years ago | (#40648531)

kinda like cloud services. They're all scams. 12 cents a GB? When it costs like less than 0.02 of a cent?

I've never heard of Agile

Re:You get what you pay/wait for (0)

Anonymous Coward | about 2 years ago | (#40648879)

1 GB of unduplicated space costs something like 6 cents on consumer level (1 TB disks can be found for as little as $60). Cloud storage is fault-proof (relatively), so your stuff isn't lost if one disk breaks (or your NAS blows up). At 10 cents/GB, cloud storage profit margins are probably pretty slim, even if the providers get HDDs cheaper than the average consumer.

Re:You get what you pay/wait for (5, Funny)

PPH (736903) | about 2 years ago | (#40648631)

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 (0)

Anonymous Coward | about 2 years ago | (#40648667)

Yep, thanks for taking it there. /sarc

Re:You get what you pay/wait for (5, Interesting)

dkleinsc (563838) | about 2 years ago | (#40648733)

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 disagree .... (0)

Anonymous Coward | about 2 years ago | (#40648341)

While Agile shouldn't replace good practice of project management, when working on smaller scale issues, products, features, in my (humble yet practical) experience Agile has proven very rewarding and efficient. But I can only imagine it mixed with more traditional project management tools/practices.

Re:I disagree .... (0)

Anonymous Coward | about 2 years ago | (#40648369)

[addition from the same author] what is a scam though is those so claimed consultants who come in promising miracles ...

Re:I disagree .... (0)

Anonymous Coward | about 2 years ago | (#40648765)

While Agile shouldn't replace good practice of project management

Which means Agile, at best, is only as good as any other methodology with less documentation.

Honestly, Agile is a crock. I've never bought into it because I've always seen it for what it is - just a hipster's counter culture movement to project planning.

Who are these people again? (5, Insightful)

JDG1980 (2438906) | about 2 years ago | (#40648359)

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? (3, Insightful)

neiljt (238527) | about 2 years ago | (#40648399)

There needs to be skepticism. Doesn't really matter who suggests it.

Re:Who are these people again? (5, Insightful)

ahem (174666) | about 2 years ago | (#40648401)

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.

What are they trying to sell? (2)

goombah99 (560566) | about 2 years ago | (#40648613)

Anti-agile services.

Re:Who are these people again? (5, Insightful)

dkleinsc (563838) | about 2 years ago | (#40648771)

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.

Developer rebellion? (5, Interesting)

Nursie (632944) | about 2 years ago | (#40648361)

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? (5, Interesting)

Anonymous Coward | about 2 years ago | (#40648475)

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.

Agreed and... (5, Interesting)

LostMyBeaver (1226054) | about 2 years ago | (#40648535)

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... (5, Informative)

ATMAvatar (648864) | about 2 years ago | (#40648705)

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... (1)

dgatwood (11270) | about 2 years ago | (#40648835)

Failure to integrate is an avoidable problem; you should have been doing that all along. What I've seen is that you get 90% of the way very quickly, but then because of the lack of sufficient design and architecture planning up front, you end up with a design in which the remaining 10% takes 90% of the time.

In other words, it's an interesting way to build a prototype that you never intend to ship, so long as you understand that the next thing you should do is throw it away, design a proper architecture based on the lessons you learned along the way, and borrow only fragments of the code from the prototype as you build the final design using a more traditional process. If you try to evolve the prototype into the final design, you're in for a world of hurt.

Re:Developer rebellion? (5, Interesting)

Vanderhoth (1582661) | about 2 years ago | (#40648603)

^ 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? (1)

modmans2ndcoming (929661) | about 2 years ago | (#40648643)

That is actually a really cool way to make the customer feel like they are in control... they can request many changes, and choose the priority for the next release....not bad.

Re:Developer rebellion? (3, Insightful)

mwvdlee (775178) | about 2 years ago | (#40648779)

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:Developer rebellion? (2)

cmat (152027) | about 2 years ago | (#40648795)

In fact, the customer really must always be in control... of the features. As developers, we are good at what, how, when and where. It is however, the "why" that will hang us ever time. And the "why" is driven by and only by the stakeholders of the software being developed (i.e. typically the "client" or "customer"). So they must (imho) ALWAYS have control over the features, and be given input as to how their choice of features impacts the other variables: cost and delivery time (which we are supposed to be the experts in providing them).

I don't think it makes any difference on the development methodology used, but this one golden rule will, must always be obeyed in successful projects: the clients choose the features, the developers provide the estimates and recommendations on implementation and delivery time. Then the client is free to make an informed decision based on what's the most important features for them at the time frame that developers feel is achievable.

Re:Developer rebellion? (1)

donscarletti (569232) | about 2 years ago | (#40648931)

If I had asked people what they wanted, they would have said faster horses - Henry Ford

One can make an effort to understand the business practices and requirements of the client well enough to give them what they need, rather that what they ask for. It's a riskier proposition because you can't just throw it back saying "well, this is what you said", but if you really want to make a something more efficient, especially if it is internal and will impact you in the future, you've got to tackle the whys with the what, whens, wheres and hows and deliver the solution that is needed, rather than what someone with questionable understanding of the problem has asked for.

Re:Developer rebellion? (1)

Anonymous Coward | about 2 years ago | (#40648881)

I once asked my boss to prioritize the requests I had for a project. He said all the requests were priority 1.

Re:Developer rebellion? (1)

modmans2ndcoming (929661) | about 2 years ago | (#40648633)

Waterfall is the basis of all engineering....the difference is you can not use it in its classic sense in a software engineering project. Iterative is the modification you are talking about and takes smaller chunks and applies the waterfall to each...what separates basic iterative from Agile is the methodologies used to decide what belongs in the iterations.

Re:Developer rebellion? (0)

Anonymous Coward | about 2 years ago | (#40648791)

You are doing it wrong.

What do you mean by managers getting more frequent status reports in agile? In my experience agile removes the need for status reports. If a manager needs a status report they can just have a look at the backlog or listen to what is going on in a daily scrum. Also at the end of each sprint they get to see demo of what is working. During the sprints the team doesn't need to do any status reporting other than marking their tasks as done. In one team that I was in we actually could stop making stupid power point status reports that no one reads because of Scrum.

Also some time ago I worked in a team that used Scrum or actually managers had forced them to use Scrum. They were basically using Scrum terms, but doing everything wrong. The team didn't perform that well and of course they partly blamed agile/scrum. I have had great experiences of Scrum in other teams that are more experienced and know what they are doing.

This quote actually quite nicely proves that they are not doing Agile correctly:

Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance

Requirements do change (1)

Anonymous Coward | about 2 years ago | (#40648367)

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.

Traditional waterfall does not provide such flexibility and having to repeat analyses due to changes is both time consuming and a waste of financial resources.

I delivered some of the largest systems available using this framework and it works well. It all depends on the people involved.

Re:Requirements do change (5, Insightful)

dgatwood (11270) | about 2 years ago | (#40648553)

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.

Re:Requirements do change (3, Informative)

SpzToid (869795) | about 2 years ago | (#40648673)

Thank you for describing Agile so I could understand it better, however I try to see The Point, aside from causing me deadline stress with regularity.

I always try to point folks to this wikipedia page that describes RUP; especially the graphic. In fact I have found on every single project whenever I have any say on the matter, all the stakeholders adore planning based off of this instructional page-as-a-plan. I wish I could say this happened to me a lot.

Usually discussing the graphic in an important stage is enough to set the pace of the project, in my experience on more informal projects. []

Re:Requirements do change (1)

mwvdlee (775178) | about 2 years ago | (#40648799)

It is my understanding that ever with things like Agile, you still have overarching phases. You still need to have an overal design, you still need to test the product as a whole, you still need an architecture. It's more about subdivision than simply splitting a task.

Re:Requirements do change (1)

ninetyninebottles (2174630) | about 2 years ago | (#40648875)

Maybe, maybe not. If the requirements really are constantly changing, Agile poses a very real risk of never producing a working product.

I'm not really sure that is any worse than not producing the product needed.

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.

If the goals are never firmed up, all projects fail, even if you abandon Agile. In my experience, Agile is just a good way to make it very, very visible to all the stakeholders that this is what is going on so they can do something about it. When managers are constantly telling you to change things, they often don't understand the costs. With Agile, everyone sees the forecast for completion growing or shrinking as they change it each iteration.

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.

It does? I agree breaking things up into too many subtasks can be a common failing of agile implementations, but I see things estimated at 2+ iterations all the time.

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.

I've seen this and I've worked in situations where all the design has to go through the designers before the developers, so when a customer requests a change in scope or purpose, they have to write a card for the UI specialists to design that change and write cards for the developers to implement it. This works fairly well in most cases and prevents the problems you're talking about.

This problem can also plague the architecture underneath if you aren't careful.

Agreed, this requires a significant number of competent engineers in a team and developers that remember to include architectural refactors into estimates by default. It also requires a culture of building solid, maintainable code and not relying on your fellow coders to go back in and fix your lousy hacks. (I've seen that happen as well, but the team was also collectively in charge of hiring and firing, so offending coders did not last.)

The wrong 200 people? (0)

Anonymous Coward | about 2 years ago | (#40648371)

Shouldn't it be the wrong 196 people?

use your Brain cells... if you got some left (2)

fluffythedestroyer (2586259) | about 2 years ago | (#40648373)

If devs and other people that use Agile don't documents their work for future use and maintenance I think it's clear that its a failure right at the start...Anyone with a brain cell will know that.

Don't blame Agile for bad recruiting results (4, Interesting)

ansak (80421) | about 2 years ago | (#40648505)

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.

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

Re:Don't blame Agile for bad recruiting results (2)

buddyglass (925859) | about 2 years ago | (#40648621)

Good systems can look bad with bad actors and bad systems can look good with good actors, but that doesn't mean there aren't still differences between systems.

Re:use your Brain cells... if you got some left (1)

modmans2ndcoming (929661) | about 2 years ago | (#40648665)

yeah...they miss the part where you are suppose to design tests, document what feature is being tested and build against those test and comment the crap out of your code so you can run a nice utility to generate documentation automatically for you.

Right people, right results (4, Interesting)

QuietLagoon (813062) | about 2 years ago | (#40648379)

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.

Re:Right people, right results (1)

Anonymous Coward | about 2 years ago | (#40648485)

It works well with a small team and low budget where the final design is in flux. Software development is a learning process and agile can give you solid learning cycles when you have a tight feedback loop between the users & developers. Where I've seen it fall apart most is on large teams that are spread out around the globe - which is more and more common. If the team isn't physically and socially "close", agile can be counter-productive. Make no mistake though, waterfall has built-in costs that add little value to the development cycle but can pay dividends on systems with a long life and frequent updates & maintenance. Teams need to be willing to adapt to whatever processes is needed for their problem/project.

Re:Right people, right results (1)

Anonymous Coward | about 2 years ago | (#40648625)

Even the part about being spread out across the globe doesn't have to apply. I work on a team that is in England, Poland and the US and I communicate with these co-workers much better than all other teams that I've worked on before. We do Scrumban and it works very well! I agree about the size of the team though, smaller is better. Many large companies like to throw people at a problem. Throw fewer, more competent people at a problem who are well motivated.

Re:Right people, right results (0)

Anonymous Coward | about 2 years ago | (#40648575)

Where's the tests?

The article also goes on about that there's no documentation, no process etc. From my experience agile projects are better documented via tests than other projects via "documentation". And because of this maintenance is easier in the long run.

Agile is not an excuse to lower quality and neglect software engineering.

Re:Right people, right results (3, Informative)

Gorobei (127755) | about 2 years ago | (#40648819)

Where's the tests?

The article also goes on about that there's no documentation, no process etc. From my experience agile projects are better documented via tests than other projects via "documentation". And because of this maintenance is easier in the long run.

Agile is not an excuse to lower quality and neglect software engineering.

Exactly right. Tests are requirements are documentation.

Want a new feature? Add a test.
Want to report a bug? Add a test.
Want to understand the system? Read the tests.

My current project has >1K devs, and >1M LOC. The doc is under a hundred pages, and that is mostly "how-to" stuff. There are also hours of "why we did X" videos to explain the design. Almost no comments in the code: if the code is unclear or poor, we just reject it: no one is allowed to use comments to explain how something works.

One critical module (approx 20K LOC) has >1K tests. Its release cycle is essentially daily, numerous devs in various teams have contributed to it, and it almost never breaks. The test pack is what allows it to be agile and replace >1M LOC of legacy system code.

Re:Right people, right results (-1)

Anonymous Coward | about 2 years ago | (#40648893)

the developers who worked on it have left

Two years ago I developed a database and wrote several dozen SQL queries to facilitate settlement derivation for the Minneapolis Grain Exchange, Inc. Most of the code-base for the back office web-apps I did using any combination of PHP/JSON/AJAX when applicable. As I am the sole author and copyright holder, I granted my employer an implied license to run my system. I should note that my full-time salaried position of Sr. System Administrator compensated me at ~$50,000 which isn't terrible for a 10+ year veteran.

Jan 7, 2011 my best friend and fellow programmer died from complications related to liver and renal failure. He had been contracted by MGEX to develop their UDP reader to decode and deliver data to my database.

Jan 14, 2011 the Director of IT, Market Operations, and Clearing terminated my position of "Sr. Systems Administrator" after failing to extort me to write some stupid program sans compensation/bonus pay.

Anyway, for what they now call the "MGEX Data Warehouse"... I didn't write a single fucking comment. I didn't write a single character of documentation. I'm sincerely hoping that somehow fucked the Director in the ass and cost MGEX hundreds more (if not thousands) of hours to document/support/maintain/upgrade.

I sincerely hope the Agile approach taken by that Director continues to fuck him in the ass for as long as MGEX let's him hold that position :)

Like any new method (5, Insightful)

obarthelemy (160321) | about 2 years ago | (#40648385)

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:Like any new method (2)

devforhire (2658537) | about 2 years ago | (#40648691)

In the last 8 years as a developer, I've seen 2 types of "agile."

Agile Fail:
      This is by far the most common type, where a trendy word is used to defend lack of project structure/discipline/planning. IMHO this is not too much better than waterfall in the end.

Agile Succeed:
        I've seen this once. This requires an intelligent, experienced, and disciplined team the whole way through (devs, managers, sys admins, and yes client too.) This works because you have people with the intelligence to understand the core principles of "agile" and apply them correctly to the individual project; the experience to know what "just enough" means in terms of docs, structure, managing, etc; and discipline to strictly follow agreed upon (within the team) best practices and standards. This is an incredible way to work and we did amazing things; I do not expect I will see it again because one bad person on the team and it falls apart.

Agile (5, Insightful)

Stirling Newberry (848268) | about 2 years ago | (#40648425)

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.

All methodologies are hokum (0)

Anonymous Coward | about 2 years ago | (#40648429)

Management likes to pretend that they have a plan, because it's their raison d'etre, but in reality everybody just makes it up as they go along, complete with supporting statistics. If you have no documentation, at least it isn't misleading. Agile doesn't prevent you from writing documentation though, so if you can and do write good documentation, that's not an advantage of the methodology, it's you. Certification is a way of selecting for a willingness to do what's necessary. It doesn't prove anything else.

I love it when XP/scrum practictioners defend it (1)

Anonymous Coward | about 2 years ago | (#40648431)

By saying, you need experienced developers in charge to prevent the architecture from going to hell, or from changes being introduced just to close a bug without addressing the underlying issue, or introducing more issues than they fix, or thrashing between competing ideas of how the code should be implemented etc.

Yes, but if you had those guys in charge then you'd probably get good results with any methodology.

Re:I love it when XP/scrum practictioners defend i (5, Insightful)

ATMAvatar (648864) | about 2 years ago | (#40648747)

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.

As others have said, not a panacea (2)

Just Brew It! (636086) | about 2 years ago | (#40648433)

IMO agile methodologies can work phenomenally well if you have a development team where everyone is technically solid and works well with others. Take either of those factors away and it is a recipe for chaos; with an "average" development team you're probably better off with something more structured.

Re:As others have said, not a panacea (0)

Anonymous Coward | about 2 years ago | (#40648669)


I work on a prominently agile consulting company, and things only work out for us because we are very strict on hiring. You may be the best dev in the universe, but if you can't communicate or share knowledge with the rest of the team, your going to be a drag.

Re:As others have said, not a panacea (1)

GreyWolf3000 (468618) | about 2 years ago | (#40648903)

Most methodologies work well in a "development team where everyone is technically solid and works well with others."

Regular 2-4 week iterations, mandatory automated testing, replacing boring waterfall meetings with short 10 minute scrums, and keeping the stakeholders involved at all times are things that every solid developer should welcome.

That's about as far in to "Capital A" Agile I've ever cared to go. Any more than that and we're too focused on process, IMO.

Not lazy devs, just unrealistic deadlines (5, Insightful)

gaygeek (843167) | about 2 years ago | (#40648437)

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.

Re:Not lazy devs, just unrealistic deadlines (3, Insightful)

Stirling Newberry (848268) | about 2 years ago | (#40648461)

Exactly, crucial to agile is the concept that features are pushed to backlog if they can't be delivered, and that programming teams have the ability to negotiate over delivery. However, as with almost any system, give one side all of the power, and it fails to work.

Re:Not lazy devs, just unrealistic deadlines (3, Insightful)

dkleinsc (563838) | about 2 years ago | (#40648885)

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.

What is Agile? (0, Flamebait)

ObsessiveMathsFreak (773371) | about 2 years ago | (#40648445)

Sorry. I'm just getting up to speed on "The Cloud", and Web 3.0. I haven't had time to to and understand the latest development buzzwords.

Am I supposed to know what "Agile" is before I read an article rubbishing it, or can I just skip over the concept entirely now?

Re:What is Agile? (3, Funny)

kestasjk (933987) | about 2 years ago | (#40648515)

Am I supposed to know what "Agile" is before I read an article rubbishing it, or can I just skip over the concept entirely now?

Whoa whoa whoa.. "Article"? What the hell is an "article"? Am I supposed to be some kind of psychic wizard in charge of marketing at Forbes or something to know what an "article" is? How about an explanation?

Re:What is Agile? (1)

malakai (136531) | about 2 years ago | (#40648543)

<Waves his hands in front of your face> This is not the news site you are looking for.

Re:What is Agile? (0)

Anonymous Coward | about 2 years ago | (#40648545)

I take it you're not a programmer. If so, you can ignore it.

Agile has been around for a long time and you can take the five minutes to read wikipedia if you choose. Lookup scrum as it's one of the more popular methods and there are many books on the subject.

Re:What is Agile? (1)

mwvdlee (775178) | about 2 years ago | (#40648907)

Since you have no clue what Agile is, let me be the first to explain, so you don't look foolish when a collegue want to discuss the topic.

Agile is a development methodoloy that radically changes the way software developers work. Instead of the typical role of "manager", "designer", "programmer" and "tester", these are split into "chief", "baker", "garbargeman", "clerk" and "monkey". You can probably imagine what each role is responsible for". Typically you work in subteams of three of these disciplines, unless ofcourse you have three "bakers", in which case a "chief" must be added to the subteam. These subteams are further divided in a "major" and "minor" roles, where the majors are responsible for all typing work and the minors documents progress. Every 2-3 hours these minors meet in a decentralized location and synchronize progress, so all subteams keep working at the same pace. At the end of the day all subteams commit their current state of development to a centralized repository and automated builds compile everything overnight. At the last day of the week, all these daily bugreports are filtered by the minors and relayed back to their majors for fixing. Iterate this for however long it takes to complete the project and you're done.

Hope this'll help you join in discussions on the topic!

ObXtraNormal link (0)

Anonymous Coward | about 2 years ago | (#40648477)

It's not far off - as always, it's about the implementation of the idea and not the idea itself.

It's just good business (2, Interesting)

Anonymous Coward | about 2 years ago | (#40648511)

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 (5, Interesting)

laffer1 (701823) | about 2 years ago | (#40648527)

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.

Re:Agile is not the problem (1)

cpscotti (1032676) | about 2 years ago | (#40648815)

Not the problem but is neither the "golden solution".

I work on an Agile team that because they are agile they believe they can change things, requirements & focus every two weeks. Plus, anyone that says waterfall doesn't work is ignoring ALL *critical* software we depend on. Do you think airplane control systems are developed using agile? Bankin systems? Stock exchange? Power grid... your OS for fuck sake (be it linux, MacOS or the other one).. none of them were fully developed using Agile.

Agile ADDs a lot of good stuff on top of waterfall and is more transparent and flaws/problems become apparent earlier - that's all. It doesn't solve *the problem of sw development*.

I bet you that in 10 years there'll be another *agile* with a different name and book that will promise that THEY are solving the problems. Smart people take agile and try to make it better, dumb people follow it like religion (and like any religious one, they sin).

Mod article 'flamebait' (4, Interesting)

Tony Isaac (1301187) | about 2 years ago | (#40648539)

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.

Trolling? (1)

ausrob (864993) | about 2 years ago | (#40648541)

The thing smells of trolling. I'm happy for people to 'call BS' on some of the garbage people say (by way of promoting) Agile practices, but honestly, who thinks 200 people is a wide enough sample range to denounce an entire methodlogy/ideology? Reads like a cheap shot.

Agile as a last gasp answer to offshoring ? (1)

CalcuttaWala (765227) | about 2 years ago | (#40648549)

This whole concept of Agile was dreamt up as a last gasp response to the offshoring of development work to inexpensive developers in India. Nothing more.

Agile is what you make it (0)

Anonymous Coward | about 2 years ago | (#40648567)

I would agree there are teams who use the Agile guise to create lazy, slapped together, products with very little forethought into the lifespan of the product. However, I would also like to point out there are plenty of teams who take a very long time to put together the same garbage software with traditional methods.

My teams work every day using an Agile methodology and I would actually argue the opposite. We still do a heavy amount of "global" planning at the beginning of each product, assemble a feature outline, create a cycle map, and establish a deliverable schedule. The main difference is that it lets us adapt to real world outcomes. When we have an iteration we analyze the prototype and there are countless times where we find a feature that we spent days initially planning simply does not work in the real world; at this point we go back to the drawing board and come up with a new solution. This iterate and check methodology leads to a far superior product at the end of the day but in some cases it can drastically increase the development time of a product. The added ability of involving the client in each of these iterations to get their feedback and apply their suggestions guarantees a product which meets their needs.

Flamed (4, Insightful)

WilyCoder (736280) | about 2 years ago | (#40648587)

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.

Re:Flamed (0)

Anonymous Coward | about 2 years ago | (#40648741)

I will not be trolled!!!!!!

oops I think I just was.

Re:Flamed (1)

Anonymous Coward | about 2 years ago | (#40648777)

I've been an Object Oriented developer for 23 years and Agile development for 15 years. It beats the HELL out of the "Waterfall model" of software development.

But like any other process, it can be abused

Everyone knew Agile was a scam. (3, Interesting)

Anonymous Coward | about 2 years ago | (#40648599)

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.

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 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].

All software methodologies are snake oil (5, Insightful)

pauljlucas (529435) | about 2 years ago | (#40648607)

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.)

The reality... (2)

Junta (36770) | about 2 years ago | (#40648609)

*Anything* that becomes the most popular 'brand' will become distorted to the point it's hard to say precisely how meaningful the application of the name in a given circumstance is. Agile and Cloud are the two terms in the computing industry the most afflicted by this phenomenon.

In fact, I would say an organization getting very picky about using every little piece of 'Agile' terminology is more likely than not in a scenario where they really aren't doing 'Agile'. Many just rename their 'product requirements' to 'user stories', 'milestones' to 'sprints', and 'status meetings' to 'scrum' without actually changing anything about the way they do things other than renaming (well, and putting the exact same project management data they had before into new software tools that advertise 'Agile').

It's just like how anything that has network connectivity now is advertised as 'cloud enabled', without regard for anything but the ability to transmit and receive IP as a qualifiaction for 'cloud'.

It's a myth that agile is undisciplined (2, Informative)

Anonymous Coward | about 2 years ago | (#40648619)

We have to practice planning and create documentation like everyone else, we just do it on rapid iterations. Agile done right will force discipline on developers and they will hold each other accountable for deliverables.

In our company there's really no alternative to agile, because our customers never know what they want. We've tried various "waterfall" methods over and over, with the same results each time--the initial requirements are vague and/or poorly understood, leading to a lot of wasteful development and missed expectations that cause the project to be late, sometimes cancelled, or if it ships it doesn't work the way the customer wants it to.

Agile works (0)

Anonymous Coward | about 2 years ago | (#40648635)

I've been using agile, mostly based on scrum for 4 or 5 years now and it works. If documentation is listed as important put it as a task on the backlog and board remember prioritization is the business owners responsibility and their responsible for making sure we work on the tasks that will generate the most customer value.

CCP (0)

Anonymous Coward | about 2 years ago | (#40648645)

CCP(EVE Online) uses agile development. I guess they're not successful.

I have issues with the TFA (5, Interesting)

thinkingsites (1903190) | about 2 years ago | (#40648661)

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.

Agile is not Easy (1)

Moe Taxes (304424) | about 2 years ago | (#40648685)

Just because you're fit doesn't mean you can tear up the parkour course.

If you've done agile right the code is the documentation, and it reads like documentation.

Agile is not developer centric, it's user centric. If what you are doing is developer centric, it's not agile.

The toughest thing in Agile is getting a good person in the user role. That's why it works great for consultancies where the user pays for the privilege of guiding their project every day, and not so much for the enterprise where nobody wants the responsibility. It is a better career move to wait and throw bombs at a failed project then to get involved and make decisions everyday.

Re:Agile is not Easy (3, Interesting)

st0nerhat (2540360) | about 2 years ago | (#40648755)

Agreed. Agile really was designed for frontend applications where the majority of the work is in the user interface. Games, web sites, iPhone apps are great candidates for Agile/Scrum. But I would never Scrum a prison door controller or a missile guidance package. Some things you have to get right once or not at all. Secondarily, Agile is not a one-size-fits-all. A consultant cannot set up the process for an existing team. Every company takes the form and modifies it to produce better outcomes. Sure the book-Agile is bad, but I love the Agile we run in my shop.

The metaphor of Agile (2)

ddtstudio (61065) | about 2 years ago | (#40648689)

First off, I'll say that I have little to no direct experience working in this system, as I am not a developer. But as has been pointed out to me by many Agile-experienced managers and developers, what I have done -- worked at monthly, weekly, and daily newspapers and news sites -- is very similar in structure. That is, we have daily meetings about what we're working on and where that is, the editorial goals, checking in on longer-form projects, and then going off and working our asses off.

Of course any snake-oil consultant can come in, propose a "just-add-water" buzzworld-compliant solution, and screw up any endeavor. See also: metaphors about having only hammers.

But I think the key is that at least in journalism, we had an existing superstructure and larger mission, and regular content that we delivered, so that kept us on track and gave us regular learning feedback. Think of it as daily iteration based on user research.

Do software/hardware projects have that sort of thing? Is the superstructure in place, and does Agile fit into that, rather than imposing Agile because... well, it's Agile?

agile solves analysis paralysis (1)

systemsplanet (1332511) | about 2 years ago | (#40648737)

agile can be summarized as "just do it". it works well,in my experience, at cranking out code and a semi usable product. after a few years of bolting on enhancements you may wish you spent more time designing. however, it's easy to design something that don't work. at least with agile you get something working fast. as fast as the web changes, we really need fast solutions to current problems.

Agile works - My experience (2)

turgid (580780) | about 2 years ago | (#40648743)

Agile does work, and it works well provided that you have cooperative managers and good developers (or at least good lead developers).

Agile fails when management dictates what the developers do, management doesn't trust the developers, the developers are clueless or the developers are lazy.

Clueless, ignorant, lazy people cause projects to fail no matter what methodology they follow.

You don't need to spend money to "do Agile." If you want the official training, you can pay for it. There has recently been a break-away movement by the originators of Agile/Scrum to go back to basics and to provide much lower cost certification.

I was trained in Scum/Agile/Design for Lean Six Sigma to the green belt level and have over 4 years experience. I went to a new job and initiated Scum in my new team. I gave a presentation to all of the engineering staff, got their buy-in and my software team started working in sprints. I was the scrum master for the first few cycles and now we're taking it in turns to get experience.

I've tried to start with the basics and to avoid it turning into a "cargo cult." It's working very well. The PHBs love it because they know what's going on at all times without many frequent boring meetings and they get a demo once a fortnight of the new "value" that we've created in line with our sprint goals.

The developers like it because the work is in bite-size chunks, management can see progress (and so we get credit and praise), interruptions and emergent work are monitored (the effect on progress can be seen) and we are delivering working incremental pieces of the product and integrating and testing them early.

Progress and quality have never been so good at this place, and the developers are enjoying being seen to be delivering and having things that work.

The engineering director is so impressed that he wants the other teams to adopt Agile/Scrum too. I'm getting moved to another team temporarily to get them started on scum.

I also use Test Driven Development to write my code and have implemented a test stub mechanism of my own. My colleagues have seen how successful it is and are starting to learn how to do it as well.

Re:Agile works - My experience (5, Funny)

fotoguzzi (230256) | about 2 years ago | (#40648889)

"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?

Agile is mind control for programmers (1)

ToasterTester (95180) | about 2 years ago | (#40648749)

I work in a Agile shop, but lucky for me in DevOps. All the SCRUMs, Code Sprints, developer trying to play QA is just a way to be cheap and to the "Suits" with OCD be controlling. The last big product rollout they got all their constants to come in and create code sprints and try to whip everyone up. A week in all the developers were ticked off and burnt and told the "suits" can hit the targets with all time wasted on writing test cases and not code. So the drop the Agile crap and got the rollout done. Think the "suits" would learn, no development is back to Agile suckage. Where I'm at Agile is all about control and trying to make 60 seconds of every minute work.

PMP Backlash (3, Interesting)

tomhath (637240) | about 2 years ago | (#40648757)

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.

CCP games really likes it (1)

emagery (914122) | about 2 years ago | (#40648769)

The developers of EVE online adore agile and have noted a dramatic uptick in productivity, reliability, and content delivery since adopting it... and even went so far as to do a presentation about the whole thing. So I guess it CAN work... it just doesn't necessarily work by default

Re:CCP games really likes it (1)

gweihir (88907) | about 2 years ago | (#40648873)

If you have really good developers that do all the planning, structuring and documenting on their own, then Agile can remove problems caused by dysfunctional processes. It can never turn bad developers into good ones.

Re:CCP games really likes it (1)

emagery (914122) | about 2 years ago | (#40648919)

I've no basis for arguing with that =3

Agile vs. Agile-speak (1)

DaveAtFraud (460127) | about 2 years ago | (#40648803)

I have yet to see a development group that says they are doing some form of agile development that actually implements the claimed methodology. What I have seen is full implementation of "agilr-speak" where agile terminology is applied to what is esentially just yet another death march development effort. Re-writes become refactorings and milestones become sprints but only the terminology changes. I don't see this as something the developers do so much as something management does since it's a way to supposedly get all three of "good, fast, cheap" without actually defining a product goal, creating a realistic project schedule and then staffing the project with enough people to accomplish the effort.

Although I have yet to actually see such a development effort, my guess is that agile really works when correctly implemented. Several other commenters say they have been part of successful agile development efforts. I've just never actually seen it done.


Agile VS Traditional (0)

Anonymous Coward | about 2 years ago | (#40648849)

I am a game developer who has worked for years doing Agile and non-Agile projects. From my experience, when done correctly Agile projects go much smoother and produce a higher quality product. They may not have the amount of features, but the overall product is better, the team moral is better, and the client is usually happier. The problem with traditional development is that in many cases scope, timeline, and resources are fixed. This is a recipe for disaster because based on the cone of uncertainty (, the original estimate could be off by as much as 100% and trying to cram the work into an unrealistic schedule forces developers to cut corners and not create a solid framework. This in turn creates more bugs and the project tends to take longer than if quality (rather than quantity) was the focus from the beginning. I have seen well functioning Agile teams. In fact, the art director in my last Agile team said that that team was the most efficient he had ever been on (he had worked with something like 27 other non-Agile teams prior). I think many people have been on poorly implemented Agile teams and therefore get a bad impression of Agile. Some of these poor implementations include very long daily stand-ups (they shouldn't take more than 15 min), zero documentation (you should do as much documentation as is needed), trying to force developers to complete every task in a sprint (team velocity should be calculated not dictated), poor negotiation of scope by management (scope should be adjusted based on the product burn-down chart), and forced overtime for more than two weeks (The average person will be less productive working long hours after two weeks than they would at a continuous 40 hours per week. The number 40 is not arbitrary. Based on multiple studies, it is produces the highest productivity for the average person. Management doesn't usually take this into account because it's hard for them to track the time it takes to fix the bugs that long hours tend to generate). If you just look at the amount of features that get completed, then yes traditional will probably look better in a study, but these studies don't take into account the time it takes to train new developers as a result of others that have quit because of poor process and they don't take into account the true quality of the product.

Makes sense to me (1)

gweihir (88907) | about 2 years ago | (#40648851)

While initially, Agile may actually deliver a working prototype faster if you are are lucky, this prototype will be all you get, because the system will be unmaintainable and non-scalable. It will also be unreliable and insecure. If that fits your needs, fine. If not, there is no replacement for a classical approach and, more important, for competent, motivated and experienced engineers to architect, design and implement it. Unfortunately, these competent engineers are quite scarce and quite expensive. But they cannot be replaced under any circumstances. Business people often try to compensate with processes, but while that may work in the area of business (I doubt it), it is unsuitable to any technological area requiring genuine understanding and skills.

My take is that basically Agile in practice is people trying to make do with incompetent developers instead of telling management that the people available do not cut it and that competing for talent and experience (which drives cost up massively) is the only way that will cut it. Somehow business people still fail to see the blatantly obvious: Good engineers are essential to any technological undertaking and these engineers are far more important than anybody from the business side.

The founders of the agile movement seem pretty blameless though. They already knew this. After all, "People over processes" (the "including agile processes is implied") is at the top of their list. And good people will plan, document, structure well, regardless of the processes they are working with. Bad people will always be bad people, regardless of processes, management, border conditions, etc.


Designed to sell services? (0)

Anonymous Coward | about 2 years ago | (#40648867)

TFA greeted me with "Close this Advertisement", and so I did: I closed the tab.

Pilot/copilot anyone? (0)

Anonymous Coward | about 2 years ago | (#40648869)

I have 25 years of development experience. agree with the headline completely; Agile is a "methodology" that pampers developers. It basically codifies chaos. I've been pretty happy with the classic Waterfall (with 4-to-10-month release cycles).

At the same, I have rarely seen planning and design documentation that is really useful for maintenance and tech transfer. Almost without fail, they are process-induced write-only documents that lose their relevance a few days into the project. At best, they are internal sales brochures that create an impression on the feasibility of the project even if ultimately a completely different design is implemented. Unfortunately, there never seems to be motivation to document the actual design after the release for maintenance.

What intrigues me is the pilot-copilot model proposed by the Mythical Man Month: a 10-member core team with one coder (the pilot) and a spare coder (the copilot) in case the pilot dies or quits plus eight bureaucrats to make it possible for the pilot to concentrate on his job. I believe that model would work really well, but I haven't ever seen it in practice. Does anybody else have experiences with it?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account