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

You get what you pay/wait for by elrous0 · 2012-07-14 02:30 · Score: 5, Insightful

Beware of hucksters selling a system that will give you everything you dream of, and fast and cheap to boot.

And be even more wary of those who promise a way to outsource everything on the cheap without taking any hit on quality.

There is no secret formula. It takes hard work, time, and skill to produce quality work. That's the only trick.

--
SJW: Someone who has run out of real oppression, and has to fake it.

Re:You get what you pay/wait for by NReitzel · 2012-07-14 02:37 · Score: 4, Insightful

Yep. Fast. Cheap. Good.
Pick two.

--
Don't take life too seriously; it isn't permanent.
Re:You get what you pay/wait for by Anonymous Coward · 2012-07-14 02:44 · Score: 5, Insightful

Not to mention the fact that the provider wants you to subscribe to their services at $999 per year, and even if you opt for the 3 month (free) trial, you don't get access to the report unless you purchase a "bundle" for $199... These are troll! and the fact that Slashdot has referenced them in such a provocative article is unconscionable!
Re:You get what you pay/wait for by multi+io · 2012-07-14 02:50 · Score: 4, Funny

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 by Gaygirlie · 2012-07-14 02:55 · Score: 4, Funny

Oh, I could point you to PLENTY of examples.
Re:You get what you pay/wait for by PPH · 2012-07-14 03:11 · Score: 5, Funny

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.

--
Have gnu, will travel.
Re:You get what you pay/wait for by dkleinsc · 2012-07-14 03:27 · 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.

--
I am officially gone from /. Long live http://www.soylentnews.com/
Re:You get what you pay/wait for by jythie · 2012-07-14 04:00 · Score: 3, Interesting

True, but this is what splits 'iterative' or 'spiral' development from 'agile'. Actually, this kinda gets into the murky waters of 'what does person X actually mean when they say 'agile'?'......

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:You get what you pay/wait for by Ryanrule · 2012-07-14 04:09 · Score: 2

In software development, pick one.
Re:You get what you pay/wait for by DCheesi · 2012-07-14 04:22 · Score: 5, Insightful

The iterative development model is really the best thing to come out of Agile, IMHO. Multiple sprint cycles allow Marketing to shift their priorities without it turning into feature creep, since they're forced to decide what to cut from each cycle. And as in your example, it allows for change feedback once they've actually used the feature. All the rest of Agile can be tossed aside, but this orderly iteration is by far the best method I've seen for dealing with Marketing requirements issues.
...So of course it's the one thing that's expressly forbidden in the new formal development process imposed by upper management :-/
Re:You get what you pay/wait for by petes_PoV · 2012-07-14 04:40 · Score: 4, Insightful

"This is exactly what we want".
The example cited is just a textbook failure to consult properly. Every client *knows* exactly what they want - until you ask them "what about ...." in which case they'll think again, or challenge their conflicting desires: "you can't have it easy to use AND infinitely flexible". Repeat that loop until the end of time and you STILL won't get a hard set of requirements - let alone a sensible or possible set.
Every experienced designer knows that the customer always lies. They might not know they're lying (or they may well do) but they will NOT tell you the truth, simply because they don't know it yet. The job of a designer is not to write down all the wishes, hopes and dreams that exit the mouth of the client, it's to present them with a list of what's possible, what's necessary and what can be done within the constraints (time, money, skills) that exist.
In the end it doesn't matter what methodologies you use. Good, talented, motivated developers will get the job done no matter what processes or obstacles you put in their way. Lazy, stupid, demotivated or confused developers will never finish the work

--
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Re:You get what you pay/wait for by JWSmythe · 2012-07-14 04:59 · Score: 5, Funny

Well sir, I have a nice Pentium 100 to sell you. And I have a team of developers ready to do your work. For only $20, they'll do any project. Don't ask how long it will take, I'm sure we* can have something** to show you by FY2015***.
* "we" only indicates anyone who the work may or may not have been farmed out to.
** "something" may only be a photocopy of the printout of your original request.
*** FY2015 is not a promised date, it simply indicates an arbitrary date in the future.

--
Serious? Seriousness is well above my pay grade.
Re:You get what you pay/wait for by dfetter · 2012-07-14 05:06 · Score: 5, Insightful

Yep. Fast. Cheap. Good.
Pick two.
That's actually the optimistic perspective. Given skill, experience and good will, you could pick up to two. Frequently, the most you could have is one, or in sadly common cases, zero.

--
What part of "A well regulated militia" do you not understand?
Re:You get what you pay/wait for by biodata · 2012-07-14 05:22 · Score: 3, Informative

We were doing the iterative development model explicitly in the mid 90s. Do you think this model really came from something called 'Agile' or the other way round?

--
Korma: Good
Re:You get what you pay/wait for by mcmonkey · 2012-07-14 05:25 · Score: 5, Funny

Yep. Fast. Cheap. Good.
Pick two.
I've heard that many times before, and I have to disagree.
Where I work, we didn't pick two.
Our projects take twice as long as they should, cost three times as much as they should, and quality in the crapper.
Who says you can't have it all?
Re:You get what you pay/wait for by macson_g · 2012-07-14 05:29 · Score: 3, Funny

Yep. Fast. Cheap. Good. Pick two.

My choice: Yep & Good
Re:You get what you pay/wait for by turbidostato · 2012-07-14 05:29 · 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 by turbidostato · 2012-07-14 05:42 · Score: 4, 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 by greg1104 · 2012-07-14 06:00 · Score: 2

Like most software methdology, iterative development dates back to the 50's. All of these "new" software approaches are just different mash-ups of existing development techniques; it's inappropriate to credit any of them with real innovation.
Re:You get what you pay/wait for by Guspaz · 2012-07-14 06:50 · Score: 4, 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 by KingMotley · 2012-07-14 07:25 · Score: 4, Insightful

As for as I'm concerned, Agile isn't a proven methodology. Not as far as being able to produce all the claims it makes for every project. In fact, I can say that it's proven to be false, time and time again.
That said, there are SOME projects that work well in an agile environment, and it works well in SOME environments using SOME teams. And on the other hand, there are SOME environments where it just doesn't fit at all, and SOME projects don't lend themselves very well to it, and SOME teams it's a hindrance.

I call that a huge success.
I call that one tool in a shed, not the golden swiss army/ginsu blade that does everything.

Companies would not use it if it did not provide benefit.
Companies use it MAINLY because they've hired program managers that are familiar with it, typically younger ones that want change. Change is good, as long as it provides a benefit. The company typically doesn't care so long as the work gets done in a reasonable amount of time.
Re:You get what you pay/wait for by hawguy · 2012-07-14 07:26 · Score: 5, Insightful

Agile is a proven methodology. In the old "waterfall" software industry, the famous "standard" was 7 lines of code per day per programmer.
Thanks largely to Agile methodologies, you can get up to as many as 1000 lines of code per day (though that's a bit on the high side), with even fewer bugs than the old 7-lines-per-day methods thanks in part to thorough, continuing testing being built-in to the process.
Using "waterfall" you could also get 1000 lines of code in a single day from a coder too - but whether the project is done using Agile or Waterfall, if you take the total project time (including requirements analysis, documentation, unit and system tests), the average LoC/day is much lower. And of course, LoC is completely meaningless - when using a modern library or framework a single line of code can replace what would have taken a thousand lines or code 5 or 10 years ago.
In my experience, Agile projects tend to run longer than they would have under waterfall, but the end product is usually closer to what the customer needs - few customers are willing to put in the time to spec out an entire project at the beginning (and are unwilling to freeze their business process during the project) and it takes too long to work changes through the waterfall process, but small changes can easily be rolled into the next iteration of an Agile process. (but some managers overestime the agility of Agile development and think that a major change that requires rearchitecting major pieces of the project can be incorporated into the next iteration)
Re:You get what you pay/wait for by next_ghost · 2012-07-14 07:49 · Score: 2

Development can make exactly what was requested, and regardless, they will want something different.
The main cause of this problem is that what the client wants and what he needs are two completely separate things. Pay no attention to what the client says he wants. Make him teach you the process as it is done at the moment without the software and then design the software around what you've learned. Chances are the process itself will need some serious rethinking.
Re:You get what you pay/wait for by AVee · 2012-07-14 07:51 · Score: 4, 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:You get what you pay/wait for by Altrag · 2012-07-14 10:00 · Score: 2

Something slow and expensive, most likely.
Re:You get what you pay/wait for by IICV · 2012-07-14 13:08 · Score: 2

... few customers are willing to put in the time to spec out an entire project at the beginning (and are unwilling to freeze their business process during the project) ...
Actually, even if they spec out exactly what they think they want and you implement it perfectly, on delivery you're still going to realize that 90% of the time what they said they wanted in the spec isn't what they needed.
Asking someone to spec out an application sight unseen is essentially asking them to commit the planning fallacy, except for feature estimation instead of time estimation. Humans seem to be largely incapable of making detailed plans more than a few "units" in advance, no matter whether or not those units are time, feature or cost based.
That's why Agile projects can "take longer" than equivalent Waterfall projects - if the client had somehow managed to spec out exactly what they really needed in the first place for the Waterfall project, I bet you it would have ended up taking about as long as the Agile version; the Waterfall project was only "completed" faster because nobody could foresee some of the features that would end up being required.
Further, there's a whole heck of a lot less risk with the Agile project; if some feature isn't quite what you wanted, you'll find out in a couple of weeks, not a several months.
Re:You get what you pay/wait for by hawguy · 2012-07-14 13:39 · Score: 2

"Using "waterfall" you could also get 1000 lines of code in a single day from a coder too..."
Repeat: the oft-quoted "average" in a large waterfall project has often been reported at 7 usable (i.e., non-comment) lines of code a day.
The average for Agile is commonly reported to be somewhere around 300 to 500 lines. That's a pretty significant difference.
I'm going to have to call bullshit on those numbers. Unless you're saying that an Agile project is bloated with unnecessary lines of code because a developer continuously rewrites code over and over. I'm sure you can find the stats to back up 7 LoC for a Waterfall project and several hundrend LoC/day for an Agile project, but I can't believe it's an apples-to-apples comparison for an equivalent project.
If those numbers were true a project that would have taken 60 months under the Waterfall methodology would take a month or two under Agile (assuming the same number of resources were assigned to the project). I haven't heard anyone claiming that a project could be completed 40 to 70 times faster under Agile.

"(but some managers overestime the agility of Agile development and think that a major change that requires rearchitecting major pieces of the project can be incorporated into the next iteration)"
I agree, but that's a problem with the manager, not with the process.
Well, sometimes the adaptability of Agile is oversold. It's not a weakness with the process, but it is sometimes presented as a magic bullet that will let a project adapt to changing requirements, and not everyone understands that a fundamental change in the requirements may require a major overhaul of the project. Whereas waterfall makes that assumption explicit - what you write down is what you're going to get.

Who are these people again? by JDG1980 · 2012-07-14 02:37 · Score: 5, Insightful

I'd never heard of Voke before today. What is this company? What credentials do their analysts have, that we should care what they say? (I don't mean academic credentials, I mean proven real-world success.) What are they trying to sell?

There needs to be more skepticism about statements coming from random "consultants", think tanks, etc.

Re:Who are these people again? by neiljt · 2012-07-14 02:41 · Score: 3, Insightful

There needs to be skepticism. Doesn't really matter who suggests it.
Re:Who are these people again? by ahem · 2012-07-14 02:42 · Score: 5, Insightful

I took a look at their website. Seems like two ex-Gartners striking out on their own to build their own Gartner.
To that end, it certainly casts the alarmist report titles in the class of "generate buzz/subscriptions".
Both of the bios of the principals are fully buzzword compliant, not to mention cromulent.

--
Not A Sig
Re:Who are these people again? by dkleinsc · 2012-07-14 03:32 · Score: 5, Insightful

What are they trying to sell?
Seems like the service they're intending to sell is a believable reason for manager A to blame the failure of a software project on manager B. In large companies, that's extremely valuable.

--
I am officially gone from /. Long live http://www.soylentnews.com/
Re:Who are these people again? by RabidReindeer · 2012-07-14 04:57 · Score: 3, Funny

I took a look at their website. Seems like two ex-Gartners striking out on their own to build their own Gartner.
Dogbert & Ratbert?
Re:Who are these people again? by greg1104 · 2012-07-14 06:01 · Score: 4, Insightful

I don't know why this is modded Funny when it's the most Insightful description of the report yet.

Developer rebellion? by Nursie · 2012-07-14 02:37 · 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.

Re:Developer rebellion? by Anonymous Coward · 2012-07-14 02:52 · 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.
Re:Developer rebellion? by Vanderhoth · 2012-07-14 03:07 · Score: 5, Interesting

^ 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? by mwvdlee · 2012-07-14 03:34 · Score: 3, Insightful

I've seen this in practice, it works really bad.
The problem is that "really cool new features" pretty much always win from all but the most annoying bugs.
If you rely on a feature that only a minority uses and that feature is bugridden, a customer-controller priority system will ensure that it'll never get fixed.
Unless they make an exception for bugs (bugs have priority over everything else), it won't work.

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Re:Developer rebellion? by cmat · 2012-07-14 03:37 · Score: 2

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.

--
-- Humans, because the hardware IS the software.
Re:Developer rebellion? by Surt · 2012-07-14 04:21 · Score: 3, Interesting

You asked wrong. You don't ask for the priorities, you ask for the order he'd like them resolved in.

--
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Re:Developer rebellion? by mothlos · 2012-07-14 05:02 · Score: 2

This isn't a problem with Agile as much as it is a problem with organizational management. It seems that every new idea is simply a way to rebrand management's desires for more work and more control over the process. I can't tell you how many stories I have heard (omitting my personal experience) of shops which implemented structural paradigm 'X' (e.g. Agile, ITIL, Six Sigma) only to cherry-pick and misimplement and then later call the paradigm a failure when in reality the paradigm wasn't even attempted in anything like a reasonable way.
That said, Agile doesn't solve every problem and for many projects it isn't particularly appropriate. Agile works best when stakeholders are not dependable and you, developing something fairly straightforward, and your team has sufficient maturity and buy-in. That said, Agile does encourage practices which are applicable in almost every project, particularly writing smaller functions which work and saving optimization for later.
Re:Developer rebellion? by Decameron81 · 2012-07-14 05:08 · Score: 4, Insightful

Agile works, as long as everyone involved has the balls to stand up for their own part of the process. If the client requests a feature that requires a big chunk of code to be rewritten / refactored, you just have to make sure you're upfront about it, and make it clear of how much effort and time will be required in the process.

The basic thing to keep in mind if that your boss, or the client don't trust your effort / time estimations, agile won't work.

And as a final note: the way to make sure you can trust someone is to hire the right people - have a good screening process when you hire.

--
diegoT
Re:Developer rebellion? by Immerman · 2012-07-14 05:17 · Score: 4, Insightful

I've come to the decision that good up-front design is important at an architectural level - get a good, well though out "skeleton" in place and you can flesh it out all higgledy-piggledy while being confident that any major rewrites will be of a limited scope. Overall code and data structure, APIs between large modules, that sort of thing. Time spent on quality large-scale design up front tends to pay for itself many times over in the long haul since you can make sweeping changes at low cost. On the other hand any halfway-decent programmer is also at least an adequate designer - when you start designing the details of every module or function up front you're probably just wasting a lot of time, and it sucks all the creative joy out of actually programming. What fun is writing code when the only room for creativity is minor implementation details? If your design is detailed enough to be read as extra-high-level pseudo-code all that's left is the tedium of actually writing the corresponding code, and you've demoted your programmers to the position of sentient pre-compiler.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:Developer rebellion? by turbidostato · 2012-07-14 06:13 · Score: 2

"You asked wrong. You don't ask for the priorities, you ask for the order he'd like them resolved in."
"all of them by the end of this week, or yesterday, whatever is sooner".
There.
Re:Developer rebellion? by overnight_failure · 2012-07-14 06:14 · Score: 2

If you think it's waterfall with shorter iterations you may be missing the point. I'd also say 'agile' covers many different methodologies so your generalisation isn't really applicable.
Re:Developer rebellion? by CyberLife · 2012-07-14 06:40 · Score: 2

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.
Happens in my company all the time, but it requires competent management and lots of discipline. The software design has to support such changes, as does the work environment. If you've got a jumble of spaghetti and a boss who just wants it done, you've got management problems. No system is going to be very effective.
Re:Developer rebellion? by asdf7890 · 2012-07-14 12:28 · Score: 3, 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.
Re:Developer rebellion? by complete+loony · 2012-07-14 14:01 · Score: 2

I thought that one of the points of agile / scrum, is that you only give an estimate in hours when you have broken down a piece of work into smaller tasks, each of which should only take a day at most to complete. ie, when you have almost finished designing the solution and now just have to implement it.
Are you giving estimates in hours before that process has been completed? Is your task breakdown insufficiently detailed? Do some of your tasks have big unknowns?
At the time a task goes over, or the discovery of an unknown or additional piece of work that your task breakdown didn't cover. Create a new task, give it an estimate, and quickly document why it was required. Before the next iteration, review all of these extra tasks and try to learn something from them.

--
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Re:Developer rebellion? by pijokela · 2012-07-14 18:15 · Score: 2

Your situation is probably very common - good luck. Just a f
- It's a real problem if you estimate all the stories/use cases/features. The team is supposed to do that so that they can commit to doing the work in the estimated time. Maybe you should stop doing estimates at all? That would force someone else to do them.
- If you're the lead designer (and while scrum does not have that role the team usually has someone the others trust), you are not the scrum master. This is important. Go ahead with the tackling, or better yet, point out that you just cannot be the scrum master. IMHO it's better to make a project manager or junior dev the scrum master.
- Do not make estimates in hours or days. Make estimates in points. Pick out some example features and decide that feature X is 5 points and feature Y is 10 points. Then estimate all the other features with points. Now, all your devs are not as productive, but hopefully they can agree that Y = 2 * X in size. After some sprints you will know how many points you get done in a sprint and it will provide you with quite accurate calendar estimates.
So, the short version is: you are not doing agile, but maybe it'll work great for you guys? Good luck.

use your Brain cells... if you got some left by fluffythedestroyer · 2012-07-14 02:39 · Score: 2

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.

Right people, right results by QuietLagoon · 2012-07-14 02:39 · Score: 4, Interesting

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 by Gorobei · 2012-07-14 03:43 · Score: 3, Informative

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 by Surt · 2012-07-14 04:39 · Score: 2

I'm currently in my personal year 8 with a company that has been doing agile for the last 11. We've had most of the original team leave at this point, so that there are only a couple of people left more senior than I am.
Undocumented code isn't a fault of agile, that's a fault of the team. Documentation should be part of your work product, and it should be scheduled right along with the other work, or an acceptance criterion for the other work.

--
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking

Like any new method by obarthelemy · 2012-07-14 02:40 · Score: 5, Insightful

in any field: the early adopter are intelligent, motivated people who know what they're doing and understand how the new method is supposed to work. Later adopters are mediocre hacks who don't perform well to start with, and are probably looking for a way to obfuscate their lack of skill and motivation, or, at best, don't get how the new method is supposed to work.

--
The Cloud - because you don't care if your apps and data are up in the air.

Re:Like any new method by devforhire · 2012-07-14 03:21 · Score: 2

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 by Stirling+Newberry · 2012-07-14 02:45 · Score: 5, Insightful

Is a way for managers to tell other managers that the features that no one really cares about will be delivered by a date that no one believes in.

--
Fugue for Aaron Swartz

As others have said, not a panacea by Just+Brew+It! · 2012-07-14 02:46 · Score: 2

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.

Not lazy devs, just unrealistic deadlines by gaygeek · 2012-07-14 02:46 · Score: 5, Insightful

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 by Stirling+Newberry · 2012-07-14 02:50 · Score: 3, Insightful

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.

--
Fugue for Aaron Swartz
Re:Not lazy devs, just unrealistic deadlines by dkleinsc · 2012-07-14 03:51 · Score: 3, Insightful

One thing that I've learned, working in a bit of a project management capacity, is that for a lot of businesspeople, the only time frame they actually understand is "I NEED IT RIGHT NOW!"
In fact, I only really remember 1 project where there wasn't an issue. End result: We finished what we had originally set out to do 2 weeks ahead of schedule, added some polish for a week, and released it a week early. All because the smart business manager and project managers had done everything they could to allow the development team to succeed: (1) Determined their project schedule from the development teams' estimates rather than the business manager's enthusiasm, (2) left appropriate time for mistakes to happen, (3) fought any attempt at scope creep, and (4) ensured that people who weren't on the project kept out of the hair of those working on the project.

--
I am officially gone from /. Long live http://www.soylentnews.com/

Don't blame Agile for bad recruiting results by ansak · 2012-07-14 02:56 · Score: 4, 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)

--
Still hoping for Gentle Treatment...

Re:Don't blame Agile for bad recruiting results by buddyglass · 2012-07-14 03:10 · Score: 2

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.

It's just good business by Anonymous Coward · 2012-07-14 02:57 · 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.

Re:What is Agile? by kestasjk · 2012-07-14 02:57 · Score: 3, Funny

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?

--
// MD_Update(&m,buf,j);

Agile is not the problem by laffer1 · 2012-07-14 02:58 · 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.

--
MidnightBSD: The BSD for Everyone

Agreed and... by LostMyBeaver · 2012-07-14 02:59 · Score: 5, Interesting

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... by ATMAvatar · 2012-07-14 03:23 · Score: 5, Informative

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.

--
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Re:Agreed and... by IICV · 2012-07-14 04:19 · Score: 4, Insightful

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.
That's one of the problems with these self-reported "Agile" failures - sure, it borders on a no true Scotsman argument, but if you're "doing agile" with five or six week "sprints", hour-long sit-down meetings instead of standups, no product manager, no backlog, no continuous integration - then can you really say that agile methodologies failed?
What really happened was you were trying to do waterfall faster, which just doesn't work. It's like saying baseball doesn't work because you made a few "tweaks".

Mod article 'flamebait' by Tony+Isaac · 2012-07-14 03:00 · Score: 4, 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.

Re:Requirements do change by dgatwood · 2012-07-14 03:02 · Score: 5, Insightful

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.

--

Check out my sci-fi/humor trilogy at PatriotsBooks.

Flamed by WilyCoder · 2012-07-14 03:05 · Score: 4, Insightful

I realize I might get flamed for this, but I wanted to say it anyway: I think agile is a complete waste of time. Its micro management wrapped up in a fancy, marketable term.

I've been a senior developer for about 8 years now. Never used Agile, never had a need to. Hire the right people and there is no need for agile.

Ok, my flame suit is on.

Re:Flamed by mattpalmer1086 · 2012-07-14 07:00 · Score: 2

It's a huge and arrogant mistake to think that stakeholders aren't talented people (well, they may or may not be, like anyone else). It is true that they almost always aren't talented at software development, and often not great abstract thinkers. From their perspective, you are not talented at retail, or industrial processes, or finance, or... well, whatever they actually know about and you don't.
I'm actually quite appalled at your derogatory attitude to your customers and development partners. Were you just trying to make a point, or do you really believe what you said?

Everyone knew Agile was a scam. by Anonymous Coward · 2012-07-14 03:07 · 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].

All software methodologies are snake oil by pauljlucas · 2012-07-14 03:08 · Score: 5, Insightful

If you have a group of talented developers, all they really need to do is programming, motherfucker. (It helps if you read it in Samuel L. Jackson's voice.)

--
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.

The reality... by Junta · 2012-07-14 03:08 · Score: 2

*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'.

--
XML is like violence. If it doesn't solve the problem, use more.

What are they trying to sell? by goombah99 · 2012-07-14 03:09 · Score: 2

Anti-agile services.

--
Some drink at the fountain of knowledge. Others just gargle.

It's a myth that agile is undisciplined by Anonymous Coward · 2012-07-14 03:10 · Score: 2, Informative

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.

I have issues with the TFA by thinkingsites · 2012-07-14 03:16 · 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:I have issues with the TFA by IICV · 2012-07-14 04:09 · Score: 2

We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
I loved this line, it sounds so much like "what the hell, Agile encourages developers to talk back? This is bullshit, slaves do what they're told".

Re:Requirements do change by SpzToid · 2012-07-14 03:19 · Score: 3, Informative

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.

https://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

--
You can't be ahead of the curve, if you're stuck in a loop.

The metaphor of Agile by ddtstudio · 2012-07-14 03:21 · Score: 2

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 works - My experience by turgid · 2012-07-14 03:28 · Score: 2

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.

--
Stick Men

Re:Agile works - My experience by fotoguzzi · 2012-07-14 03:51 · Score: 5, Funny

"I was trained in Scum/Agile/Design for Lean Six Sigma to the green belt level and have over 4 years experience."

No buzzwords here, thankfully. Is Scum that super-stripped-down version of Agile that I have heard about?

--
Their they're doing there hair.

Re:I love it when XP/scrum practictioners defend i by ATMAvatar · 2012-07-14 03:29 · Score: 5, Insightful

Yes, no methodology is going to be a magic bullet that turns a loser team into a superstar team. Agile was never intended to do so.

What agile processes attempt to address is the transient nature of requirements. Large, monolithic processes do not respond well in cases where the client doesn't know exactly what they want up front.

The reality is that clients often times add things during the process, and just as often as not, they do not realize that what they said they wanted wasn't really what they wanted. Providing continuous feedback and re-adjustment helps to mitigate this problem.

--
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."

Re:Agile is not Easy by st0nerhat · 2012-07-14 03:30 · Score: 3, Interesting

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.

PMP Backlash by tomhath · 2012-07-14 03:30 · Score: 3, 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:PMP Backlash by urusan · 2012-07-14 05:44 · Score: 2

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.
This is true most of the time, but there are a few shockingly old systems in places where high reliability is required. They tend to show up as controllers for things that last a long time (like nuclear power plants or airplanes), in work environments with a highly conservative culture (hospitals), or in places where uptime trumps many other concerns (financial backend or power grid calculations). In these cases, it's critical to treat software similarly to building a bridge you expect to last 50+ years, because you really have no idea how long someone is going to keep using it (and anyway, you really don't want it to fail even if it is new).
Of course, this kind of software represents a tiny percentage of all software. In most cases today, you're right. It certainly doesn't make sense to ensure that a new video game or office productivity feature is perfect if by cutting down on quality a bit we can get it to market faster. That said, you never know when your non-critical software might be used to make this kind of critical software. OSes and libraries are particularly likely to be pulled into such a project. Furthermore, the amount of critical software is likely to expand in the near future. A good example from the recent past is that back in the really olden days there weren't computers small, light, and cheap enough to put into aircraft to control their flight, but nowadays fly-by-wire is common. There aren't any 50 year old fly-by-wire aircraft because the first ones were built 40 years ago. How long will some people hold on to their early model self-driving cars? As computers become more cheap and ubiquitous, these issues will become more widespread.
Durability and reliability requirements are important to consider early in any project, and different answers will lead to the need for totally different approaches to developing the software.

I've got a mixed opinion of Agile by NotSoHeavyD3 · 2012-07-14 04:00 · Score: 2

Since we did that officially at one place we worked.(Agile/Scrum to be specific) So I've ranted before how I think the second dogma is just wrong. (You don't need to encourage developers to not document, they'll do that quite happily.) There are other issues however. So for one we had an issue where our "Scrum Master" basically just took over the group and started having us report to him, giving us tasks, etc. We did complain to management but they did the whole "You're doing Agile, you manage yourselves, work it out for yourselves." Then of course there's this whole agile thing that you have to produce software every day that shows visible changes. The problem that those of us in dev have with that are 2 fold. For one depending on what you're working on it might be weeks before you can shows anything that works at all. Also some bug fixes arn't really visible. (For example I fixed a race condition that in production only happened once every 6 months. It took QA and myself basically a week to write up a "test" to get this accepted since Agile is "Visiblity-Crazy") Actually more recently i was doing agile which would have been nice since the product manager could tell me how it's supposed to work. The problem? He didn't actually know how the product is supposed to work (I mean basic functionality) so I'd work on it and put some functionality and then we'd find out oh wait, nobody asked for that and nobody wanted it.(Which was annoying since I kind of mentioned I didn't think it'd be that useful.) Of course the big bad thing about agile is since you work daily with the product manager(who is simply my manager in this case) it ends up just being an excuse to micromanage me. (So that's twice I ended up getting micromanaged under Agile.)

--
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.

Took the words by Giant+Electronic+Bra · 2012-07-14 04:05 · Score: 5, Informative

Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.

Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now", so yes, you will refactor, but that refactoring is an ongoing part of the process that is informed by 2 things, continuous integration and user acceptance testing.

IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process. If you actually PAY ATTENTION to the things that Agile is telling you to do (personally I find XP type process to be the most effective) then you can make it work. Everyone needs to understand the value of the parts, and as any Agile expert will tell you ALL the pieces are important. It is not at all interesting news for someone to tell me that if you fuck up and ignore half the pieces of the process that the other half don't magically just work.

No one development methodology is a panacea of course, but this report seems to be meaningless criticism based on not actually understanding how and why to use Agile.

--
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson

Re:Took the words by greg1104 · 2012-07-14 06:23 · Score: 5, Insightful

I don't think the report is even addressing whether Agile *can* be used effectively nor not. Its scope seems to be whether it *is* being effective or not for companies, and the answer they present is that it isn't. Whether or not there is a One True Agile that really does work isn't the point; that doesn't matter if people can't figure out how to adopt the approach for their own work (or with consulting help in implementing process, which is also being commented on). You can't prove a software development approach works by presenting examples of it working; the amount of variation among development teams means you could have just been working with a good one. The reason companies try to adopt methologies is to try and get useful work out of *any* development team. A really good software process should work as a filter, only letting things of good quality through as output.
Now, I would turn that conversation not toward Agile--it's no better or worse than the alternatives--and instead ask "is there any process that gets good software even from bad developers?" That's what managers want, and every new softtware development approach that comes along includes some people who claim such magic exists in the process that this will happen. The alternative--accepting there is no silver bullet and focusing on how to get good developers working productively instead--that idea is just fundamentally repugnant to many businesses.
Re:Took the words by _xeno_ · 2012-07-14 08:31 · Score: 2

IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process.
That reminds me of an "Agile" project I was on. The top-level project leader declared we were going to do Agile.
He then refused to answer requests for clarification on design requirements and refused to allow any of the developers to talk to the actual users, insisting that all user communication go through him. (While refusing to actually pass on questions to users or, really, answer any question we asked.)
So we had a continuous integration system updating the demo system with every commit - a demo that no one ever used. But, hey, if anyone ever checked in a commit that failed to compile, we knew that at least.
In the end, the system didn't quite do whatever it was it was supposed to do. Imagine that.

--
You are in a maze of twisty little relative jumps, all alike.
Re:Took the words by Giant+Electronic+Bra · 2012-07-14 08:38 · Score: 2

I think the thing is that really good crackerjack developers are hard to keep around. There's very high demand and high prices. Many businesses cannot or will not pay what they need to pay to get them, and in fact a lot of businesses really aren't doing something sexy enough that someone who could work on cutting edge stuff is going to stick with, at least not unless they're handled quite well.
So, yeah, most teams are going to be made up of some mix of good, bad, and ugly. I agree that there's no silver bullet, etc. The thing is lots of places just don't have the choice of "get good developers working productively" because they might have one or two good developers and ten bad/ugly ones. You need to bring those up to usable status. Frankly my answer is get in a good process consultant, but it is also pretty hard to find one of those... lol.
Frankly software and humans don't mix well. I think we'll have bad software until we invent some AI to write it for us (but that AI will be bad human-written software...). lol. Best you can do is if something is REALLY important, like flight control software (or for instance the self-destruct device for a large commercial booster, which I once wrote some of the firmware for) then you can get pretty decent quality, but it is hugely expensive. That box had about 6k lines of code in it and the software cost was well into the millions...

--
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson

Agile Manifesto by rockmuelle · 2012-07-14 04:07 · Score: 2

In reading the comments, it's clear that many people don't know the roots of agile software development. In short, agile (note the lower case) development is basically a set of of principles laid out by a group of very talented developers in the late nineties in their agile manifesto:

http://agilemanifesto.org/

Note that the manifesto makes no mention of Extreme Programming, Scrum, or any of the other capital-A Agile methods. Instead, it focuses on observations about what made their software projects successful. Itpecifically doesn't prescribe any specific methodology, but rather encourages communication, iteration, and excellence in design and engineering. The last two points come from this section of the manifesto:

"Continuous attention to technical excellence
and good design enhances agility."

The manifesto very much allows for, and even encourages, design. It also assumes that the practitioners are already experienced developers who know how do design software and know how much design is needed before coding. Unfortunately, the most Agile methods traded experience for certified training and the 'technical excellence' portion was lost.

I've worked with many talented teams and have seen agile work time and again. Of course, all of those projects did have design, documentation, and tests. But, all those artifacts were developed using the same principles in the manifesto.

-Chris

This finding does not match my experience by jjohn · 2012-07-14 04:39 · Score: 3, Informative

Agile is not a product. It is a mindset. Each team needs to workout what that means for them. I have been in teams for two companies that used Agile methods heavily and it has worked out very well for business units (predictable deliveries), developers (predictable work hours) and customers (higher quality releases).

I am positive Agile is not a silver bullet for every project. Software engineering is still a hard problem to generalize.

Re:I disagree .... by Immerman · 2012-07-14 04:51 · Score: 3, Insightful

Oh, I don't know - given N methodologies of approximately equal effectiveness, it seems to me the one that the workers find most enjoyable/rewarding is highly preferable as it will allow you attract better people and/or pay them less.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.

Re:I love it when XP/scrum practictioners defend i by h2oliu · 2012-07-14 04:55 · Score: 2

That is nice in theory, but I have found all to often in practice, when people see what they ask for, they realize that they didn't really want that. When you have a multi-year process, requirements change (heck I've seen it in multi-week!). Even ignoring the issues of human nature which induce this type of event, there are so many external forces that can drive a change that being able to re-evaluate is key.

My take on agile, and the "developer rebellion" is that developers got fed up with 18 different "Number 1" priorities, and wanted to force management to actually do their job and prioritize.

--
Ok, I give up, why you?

Pretty much agree, agile isn't. by SmallFurryCreature · 2012-07-14 04:58 · Score: 2

The whole issue is that agile isn't. Isn't what? AGILE! That word causes customers/managers to think flexible meaning "I don't have to plan anymore, I can get what I want, when I want it".

In reality Agile is extremely rigid. There is nothing in the method to deal with issues that crop up NOW and have to be fixed YESTERDAY. Instead, the manager/customer now has to plan ahead for what he wants, get it approved for inclusion in a sprint and then wait for that sprint to be finished. That could take DAYS if not weeks!

Not that a sprint itself has to take that long but before YOUR new wish is included in the next sprint might mean you have to wait your turn.

Agile needs a lot of discipline and commitment across the entire production line, from customers to managers to developers. But if you got discipline and commitment, ANY methodology will work. And if you don't. None will.

Dysfunctional companies are dysfunctional regardless of the label they put on their method for screwing up.

Agile is particularly bad since it doesn't enforce any fixes. It is often introduced as the solution itself, go Agile and all the unrealistic planning and louse development and under staffing will just fix itself.

--

MMO Quests are like orgasms:

You may solo them, I prefer them in a group.

Find and replace works pretty well! by sootman · 2012-07-14 05:43 · Score: 2

sed s/Agile/Analyst

'The Analyst movement is designed to sell services. ... Out of over 200 survey participants, we received only four detailed comments describing success with Analysts.' 'Survey participants report that developers use the guise of Analyst to avoid planning...'

--
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.

Did RTA. It doesn't sound too dismissive by Gimbal · 2012-07-14 06:13 · Score: 2

"[...] Agile, which may not be appropriate for all organizations or projects"

That's fair.

Never understood agile by WaffleMonster · 2012-07-14 08:52 · Score: 2

I never understood the benefit of Agile or why anyone would want to go there. If your working on boring small projects which only take time and a lot of typing to complete I guess Agile works. I could see this working with shops dedicated to small scale custom projects.

For anything non-trivial you really need to invest in infustructure and design or you will end up with a patchwork of shit.

Agile seeks to exert pressure away from thinking and design rewarding instead the brainless zombie which makes shit up as they go along. It also encourages use of more modern and exotic language features to cover for the underlying system being a piece of shit.

A good development process will exert no artifical pressure detremental to the overall project lifecycle. Agile fails this test in a great number of domains.

Laziness is actually a virtue the entire point should be to reward those doing the least with least amount of effort to get the job done.

The catch is laziness must be evaluated in the context of the entire lifecycle of the system. Being lazy up front and having to work 10 times harder later as a result means you suck. Being lazy up front and having to hire more people just to support your POS when the complaints come filing in means you suck. Agile encourages people to suck in my not so particularly humble opinion.

Agile Programming by Anarchduke · 2012-07-14 09:15 · Score: 2

Personally, I dislike Agile Programming. Its sloppy. There is a place for it, such as if you need to rapidly develop an app that needs to work, but doesn't need to work well. Its programming in chaos. I prefer an ordered approach to application development.
You need a working utlity as soon as possible to analyze, detect, or whatever you want it to do? Fine, use an Agile appoach. Just accept that what you produce is going to be buggy, and probably with shoddy documentation. Sure Agile can be handled in an orderly fashion, but then it loses the flexibility that makes it worthwhile.
I prefer a slow and steady approach. Its not sexy, but I want my code done well, rather than quickly.

--
who prays for Satan? Who in 18 centuries has had the humanity to pray for the 1 sinner that needed it most? ~Mark Twain

Re:slow and cheap by TaoPhoenix · 2012-07-14 09:56 · Score: 3, 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

The other more harmless example is US Mail's Bulk Rate shipping.

--
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine

I've heard the legends by chicago_scott · 2012-07-14 10:07 · Score: 2

Some people say that Agile is awesome when fully implemented, but I've never seen that done. Or met anyone that seen that done. It's kind of like Big Foot.

Slashdot Mirror

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

102 of 491 comments (clear)