Beta
×

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!

Why Your Users Hate Agile

Soulskill posted about a year ago | from the they-prefer-strength-or-charisma dept.

IT 597

Esther Schindler writes "What developers see as iterative and flexible, users see as disorganized and never-ending. This article discusses how some experienced developers have changed that perception. '... She's been frustrated by her Agile experiences — and so have her clients. "There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.' The premise here is not that Agile sucks — quite to the contrary — but that developers have to understand how Agile processes can make users anxious, and learn to respond to those fears. Not all those answers are foolproof. For example: 'Detailed designs and planning done prior to a project seems to provide a "safety net" to business sponsors, says Semeniuk. "By providing a Big Design Up Front you are pacifying this request by giving them a best guess based on what you know at that time — which is at best partial or incorrect in the first place." The danger, he cautions, is when Big Design becomes Big Commitment — as sometimes business sponsors see this plan as something that needs to be tracked against. "The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"

cancel ×

597 comments

Sorry! There are no comments related to the filter you selected.

I tell them I feel the same way! (1)

Anonymous Coward | about a year ago | (#43909833)

But the alternatives are worse, so... there's that.

Re:I tell them I feel the same way! (4, Insightful)

Anonymous Coward | about a year ago | (#43909953)

Agile taken to an extreme can be a PITA. If a customer orders a car, they want what comes out of the factory to have four wheels and a steering wheel. Agile development means that who knows what the end product will be... will it be a bicycle, will it be a lorry, will it be a motorcycle, or perhaps it might be a unicycle. The only person who knows is the one with the loudest voice.

This isn't to say that waterfall is the best dev model, but there should be a balance, so one at least has a vision of what the end product will look like.

Re:I tell them I feel the same way! (5, Insightful)

Entrope (68843) | about a year ago | (#43910197)

If you're not doing Xtreme Agile, you're not doing Agile right.

Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.

Re:I tell them I feel the same way! (5, Interesting)

ebno-10db (1459097) | about a year ago | (#43910405)

If you're not doing Xtreme Agile, you're not doing Agile right.

That is correct comrade. Failure is always caused by insufficient ideological zeal and purity.

Agile Hitler said it best (2, Funny)

Anonymous Coward | about a year ago | (#43909837)

"Why weren't you at the fucking stand up meeting???"

According to MS, agile does have a process. (0)

Anonymous Coward | about a year ago | (#43909849)

And you can do the in depth planning for the plan-less agile method , right in foundation team server-ices ( New word! For all the servers and all the services on top!)
http://blogs.msdn.com/b/bharry/archive/2013/06/03/visual-studio-2013.aspx [msdn.com]

I mean, how can you not have enterprise agile capabilities in your devops team?

Attack of the pseudo technological acronyms (2)

dgharmon (2564621) | about a year ago | (#43910433)

key words: Agile Portfolio Management, ALM blog, Application Lifecycle Management, Application Lifecycle workflows, backlog of business initiatives, backlog of scenarios, backlog of user stories, Build conference, configuring any infrastructure, enterprise agile, enterprise agile capabilities, granularity, higher-level backlog, in-flight releases, Kanban support, lightweight code commenting, multiple Scrum teams, nifty Git innovation, pending changes, Project Server integration, Release Management, sprint after sprint, sprint management, Team Foundation Server, TFS 2012, trace the relationships, version control solution, VS 2013, VS Premium, web based test case management solution, work breakdown ...

Agile summed up (5, Funny)

Shinobi (19308) | about a year ago | (#43909855)

Agile is to proper software engineering what Red Bull Flugtag is to proper aeronautic engineering....

Re:Agile summed up (1)

Narcocide (102829) | about a year ago | (#43909867)

This is inaccurate. Red Bull Flugtag generates a huge amount of publicity for Red Bull. Agile makes everyone who touches it quickly fade into obscurity.

Re:Agile summed up (0)

Anonymous Coward | about a year ago | (#43909887)

Agile and SVN? Gimmie a break.

Re:Agile summed up (1)

MichaelSmith (789609) | about a year ago | (#43910343)

Why not? If anything the problem is the branching strategy.

Re:Agile summed up (0)

Anonymous Coward | about a year ago | (#43909929)

This is inaccurate. Red Bull Flugtag generates a huge amount of publicity for Red Bull. Agile makes everyone who touches it quickly fade into obscurity.

I wish!

Re:Agile summed up (0)

Anonymous Coward | about a year ago | (#43909905)

Bingo

doesn't work (0, Flamebait)

nten (709128) | about a year ago | (#43909983)

"Proper software engineering" doesn't work. Code that actually does work is invariably ugly and violates any best practices you can possibly imagine. Code that follows those best practices and whatever the current paradigm fad is, are over budget, over schedule, and even though they incorporate all the correct patterns for abstraction and maintainability, this results in such a huge volume of excess sloc, that it is less maintainable as a function of sheer size. You don't need process or patterns, or even documentation (though it would be nice). The only thing you need are good engineers that actually communicate with each other, and if you don't have that, then no amount of process or patterns or paradigms or practices can save you. I should note however, that if you just want to generate billable hours then you absolutely want every last one of those Ps and mediocre (but not bad) engineers.

Re:doesn't work (5, Interesting)

Anonymous Coward | about a year ago | (#43910097)

"Proper software engineering" does work, its called "Systems Engineering", is well established and successfully used for large-scale mission-critical projects in almost every industry outside of IT - which seems to be blind to anything invented outside of IT.

Systems engineering has its own professional accreditation organization: http://www.incose.org/practice/whatissystemseng.aspx

Re:doesn't work (4, Insightful)

Nerdfest (867930) | about a year ago | (#43910143)

As TFA points out, that always works fine when your requirements are *all* known an are completely static. That rarely happens in most fields. Even in the ones where it does it's usually just management having the balls to say "No, you can give us the next bunch of additions and changes when this is delivered, we agreed on that". It frequently ends up delivering something less than useful.

Re:doesn't work (5, Insightful)

MichaelSmith (789609) | about a year ago | (#43910363)

The problem with Agile is that it gives too much freedom to the customer to change their mind late in the project and make the developers do it all over again.

Re:doesn't work (1)

ebno-10db (1459097) | about a year ago | (#43910301)

"Proper software engineering" does work, its called "Systems Engineering", is well established and successfully used for large-scale mission-critical projects in almost every industry outside of IT - which seems to be blind to anything invented outside of IT.

Systems engineering has its own professional accreditation organization: http://www.incose.org/practice/whatissystemseng.aspx [incose.org]

True, but the problem is when the Great Plan becomes too rigid. It's necessary to change it as warranted. This actually seems to be easier in hardware, when you say "sure I could get that last 1dB of dynamic range you wanted, but it'll double the price and power consumption", or "yes we could put that function in module X as planned, but it'd be half the cost and complexity if we move it to module Y". Good systems engineers know this. Of course the headache of being a systems engineer is fighting with the implementers - half the changes or spec relaxations they ask for make sense, and the other half are about laziness or incompetence.

I do hardware and software in a 50/50 split, so I see both sides. Hardware is more easily understood to have physical constraints, but every thing in software that isn't exactly as planned is seen as a failure of the implementers.

Re:doesn't work (5, Interesting)

ebno-10db (1459097) | about a year ago | (#43910203)

"Proper software engineering" doesn't work.

You're right, but you're going to the other extreme. The problem with all methodologies, or processes, or whatever today's buzzword is, is that too many people want to practice them in their purest form. Excessive zeal in using any one approach is the enemy of getting things done.

On a sufficiently large project, some kind of upfront design is necessary. Spending too much time on it or going into too much detail is a waste though. Once you start to implement things, you'll see what was overlooked or why some things won't work as planned. If you insist on spinning back every little change to a monstrously detailed Master Design Document, you'll move at a snail's pace. As much as I hate the buzzword "design patterns", some pattern is highly desirable. Don't get bent out of shape though when someone has a good reason for occasionally breaking that pattern or, as you say, you'll wind up with 500 SLOC's to add 2+2 in the approved manner.

Lastly, I agree that there is no substitute for good engineers who actually talk to and work with each other. Also don't require that every 2 bit decision they make amongst themselves has to be cleared, or even communicated, to the highest levels. If you don't trust those people to make intelligent decisions (including about when things do have to be passed up) then you've either got the wrong people or a micromanagement fetish. Without good people you'll never get anything decent done, but with good people you still need some kind of organization.

The problem the article refers to about an upfront design being ironclad promises is tough. Some customers will work with you, and others will get their lawyers and "systems" people to waste your time complaining about every discrepancy, without regard to how important it is. Admittedly bad vendors will try and screw their customers with "that doesn't matter" to excuse every screw-up and bit of laziness. For that reason I much prefer working on in-house projects, where "sure we could do exactly what we planned" gets balanced with the cost and other tradeoffs.

The worst example of those problems is defense projects. As someone I used to work with said: In defense everything has to meet spec, but it doesn't have to work. In the commercial world specs are flexible, but it has to work.

If you've ever worked in that atmosphere you'll understand why every defense project costs a trillion dollars. There is absolutely no willingness to make tradeoffs as the design progresses and you find out what's practical and necessary and what's not. I'm not talking about meeting difficult requirements if they serve a purpose (that's what you're paid for) but being unwilling to compromise on any spec that somebody at the beginning of the project pulled out of their posterior and obviously doesn't need to be so stringent. An elephant is a mouse built to government specifications. Ok, you can get such things changed, but it requires 10 hours from program managers for every hour of engineering. Conversely, don't even think about offering a feature or capability that will be useful and easy to implement but is not in the spec. They'll just start writing additional specs to define it and screw you by insisting you meet those.

As you might imagine, I'm very happy to be back in the commercial world.

Re:doesn't work (4, Interesting)

Dantu (840928) | about a year ago | (#43910241)

"Proper software engineering" doesn't work.

As a Software Engineer in the formal sense (Engineering is regulated profession here in Canada) I can assure you that "proper software engineering" works great - and it's often Agile. Software Engineering is just like any other type of engineering, you have to pick the right tool for the job. That said, a lot of under-qualified people go around claiming to be Software Engineers and think that generating piles of paperwork will make their crap code (and crappier designs) smell better. They are just as bad as these people [youtube.com]

Re:doesn't work (1)

dbIII (701233) | about a year ago | (#43910257)

Then your "best practices" are probably wrong and just a poor analogy of what software developers think physical engineering is about. Engineers didn't leap onto CAD like a drowning man onto a liferaft when it emerged because it was a better way to draw, we did it because it was a better way to handle changes. When one portion of a design changes others often have to change to fit, which is very different from the illusion that portions of a design have to be set in stone and later portions warped to fit them no matter the consequences. Until the thing is built or the software is shipped there are many options and care should be taken that artificial administrative constraints don't remove too many of them.

Re:doesn't work (0)

Anonymous Coward | about a year ago | (#43910321)

http://www.fastcompany.com/28121/they-write-right-stuff

This is my evidence that "proper software engineering" *can* work. The fact that most businesses (and their customers) are willing to save money by accepting less from their software is not the fault of software engineering. We could and did build buildings much faster than we do today, if you are willing to make more mistakes and pay more in human lives. If established industries and their customers began demanding software at that higher standard and were willing to pay for it like it was real engineering, then maybe it would happen more often.

Re:Agile summed up (1)

Anonymous Coward | about a year ago | (#43910019)

If you know what you are doing more than 50% of the time then you are not doing true agile.

Re:Agile summed up (2)

perry64 (1324755) | about a year ago | (#43910079)

Academics with degrees in software engineering describing how to write code is like a horny virgin describing how to have sex:

They've thought about it an awful lot, have lots of "great" ideas on how to make it better, and maybe have even been nearby a few times when someone else was doing it .

But they have never done it themselves and the thought of actually DOING it scares the crap out of them.

Re:Agile summed up (0)

fuzzyfuzzyfungus (1223518) | about a year ago | (#43910237)

Don't forget the gigabytes of 'example code' stashed on their computers, and how you always seem to see an IDE being frantically closed if you open a door behind them when they aren't expecting it...

UI/Process Stability (1)

Mystakaphoros (2664209) | about a year ago | (#43909877)

There is some value to UI/process stability. Even if the overall operation is optimized, the time it takes to retrain users still counts for something...

Re:UI/Process Stability (2)

judoguy (534886) | about a year ago | (#43910297)

It's because of incompetent management, or at least incompetently managing the development process, that most of the problems occur. I worked in construction before going into software development almost 30 years ago.

You can't build a chicken coop properly, much less a modern house, much less a skyscraper without *really detailed* specs, the bigger the project, the more detail. And everyone buying the building or building it is supposed to realize that any changes are really expensive. How can you tell the client what even a simple structure will cost without knowing a whole lot about what's being built? Even then, with literally thousands of years of practice, construction often has cost overruns or worse, structural problems.

But for software, we almost always pull numbers/timelines from our backsides and almost all software projects just flail on until it's good enough or collapses. Just making shit up as you go and calling it a methodology is sad.

Why do developers hate agile (1)

Anonymous Coward | about a year ago | (#43909907)

The more appropriate question is why your developers hate agile? And the most important question why is management pushing agile down the throat of developers?

Re:Why do developers hate agile (1)

Mystakaphoros (2664209) | about a year ago | (#43909943)

And the most important question why is management pushing agile down the throat of developers?

Much easier to fire developers, sub in new and unprepared ones, and then blame delays on the "agile" programming.

Re:Why do developers hate agile (2, Insightful)

Anonymous Coward | about a year ago | (#43910133)

Because, as every good manager knows, all problems can be fixed by making them more agile!

Is your well oiled development team on schedule, and the producers are twiddling their thumbs with little to do? You need to be more agile!

Have recent changes to the way your dev team works caused an on track project to go off the rails? You need to be more agile!

Have your senior developers got so fed up with the piss poor management team behind your project, that they've all just quit? You need to be more agile!

Has your company just gone bankrupt due to a lack of developers, and a lack a product? Have you considered becoming an agile consultant?

Re:Why do developers hate agile (2, Insightful)

Anonymous Coward | about a year ago | (#43910221)

The more appropriate question is why your developers hate agile? And the most important question why is management pushing agile down the throat of developers?

Easy ...

Developers hate Agile because it, when combined with incomplete/inadequate specifications, is quicksand for developers.

Management loves it because it allows them to commit to anything. The mindset management has is the developers can throw together an "Agile" solution without management having to do their part of the job.

obligatory non-xkcd (4, Insightful)

mrvan (973822) | about a year ago | (#43909919)

http://programming-motherfucker.com/ [programmin...fucker.com] , do you speak it?

Re:obligatory non-xkcd (1)

bunhed (208100) | about a year ago | (#43910245)

Bah, I was all down with that until I saw that blow hole Zed was behind it

Agile is not a golden bullet (5, Interesting)

bhetrick (1812392) | about a year ago | (#43909927)

The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development. Agile has a specific application: development of experimental software, where the project sponsors know they need something in a particular area but do not know exactly what. Agile (and iterative development in general) lets the target change over time as knowledge is gained. Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework," and there is a great deal of this in iterative development. Agile in practice is typically waterfall without a project plan: the project sponsor knows what is desired, and when, and is trying to get it for cheap. Iterative development fixes the time taken ("timeboxing") and the cost (level of effort); what is unknown is how long it will take (or alternately how much you can put into a sprint). Starving Agile has the same result as starving typical development: you only get the 1/3 of the software that is apparent, not the 2/3 that makes that 1/3 truly functional, reliable, and maintainable.

Re:Agile is not a golden bullet (0)

Anonymous Coward | about a year ago | (#43910065)

One odd thing about "agile" (or "extreme programming") is that I agree it's a software development buzzword, yet the term has been widespread for over ten years now. I've been working solo for the past five years, so I'm somewhat out of the loop in terms of fads and buzzwords, but I'd think at this point there'd be a general consensus on the good and the bad of it. I'm left wondering if the articles about it are purposely behind the times, if people still don't get it, or maybe it attracts lots of new programmers that don't bother to read anything critical about it.

Re:Agile is not a golden bullet (3, Insightful)

Entrope (68843) | about a year ago | (#43910289)

Journals and conferences don't want to publish negative results, so you very seldom hear about all the people who try a process and find that it sucks for them.

Process success stories in the software field have always been driven more by special circumstances than science. Nobody has yet figured out how to (or at least bothered to) control for variations in sample-group productivity well enough to generate reproducible results for most process changes, and all the practitioners want to optimize their processes for different things. For example, CMMI and its ancestors are good if you have a load of time, good requirements control, and a few good leaders mixed with a bunch of more ordinary workers; Agile is good if your customers value whims over checking all the boxes and having really robust software; etc.

Finally, software changes can have chaotic effects, which makes it hard to apply a lot of the control, prediction and robustness methods used in other engineering fields. This makes me think that there will always be a large element of individual skill and domain expertise in building and delivering successful software, and that processes will always need to be carefully chosen based on the team and the project.

Developers hate Agile too (5, Interesting)

pauljlucas (529435) | about a year ago | (#43909939)

I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.

Re:Developers hate Agile too (2, Informative)

Typical Slashdotter (2848579) | about a year ago | (#43909979)

I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.

You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.

Re:Developers hate Agile too (5, Insightful)

Jaime2 (824950) | about a year ago | (#43910027)

Almost everyone's doing it wrong, that's why it doesn't seem to work in practice. 99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.

Re:Developers hate Agile too (3, Insightful)

Crazy Taco (1083423) | about a year ago | (#43910193)

99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.

This is totally true. And I think the main part of the SDLC they try to avoid is planning. I've both been a developer and had developers writing automation code as projects for me as an infrastructure engineer, and the most frequent abuse is zero planning. And that's the thing that makes agile seem endless to users like me. The developers keep having to rewrite everything every dang sprint because they didn't put enough planning into the architecture to make it flexible enough to meet the requirements. And speaking of requirements gathering, that consisted of getting a bunch of user stories and then diving straight into coding, rather than taking the time to get into the true details and really flesh what the users needed. Which is another agile abuse.

I'm honestly getting pretty darn sick of agile, because even with the defects in other paradigms, I think better software was developed more quickly. It's amazing what a little up front thought (which most other paradigms call for) will get you. And again, a lot of people will argue that it's not agile that is the problem, but the abuse of agile. I agree in theory that abuse of agile is the problem, but since 99% of projects seem to do agile wrong in practice, it might be time to throw the baby out with the bath water and get a new paradigm that isn't so easily misinterpreted.

Re:Developers hate Agile too (2)

chrismcb (983081) | about a year ago | (#43910215)

I'm not saying I know how to do Agile wrong, but every team I've been on that did "agile" did it wrong, and pretty much every story I heard I can recognize areas that did it wrong. The first team I was on that did "agile" had 30 minutes daily conference room meetings! They are stand up/water cooler meetings for a reason. To keep them short.

Re:Developers hate Agile too (2)

Entrope (68843) | about a year ago | (#43910391)

One of the hardest things for process designers to do is to fit their processes to the people who will use them.

Most hard-core proponents of Agile don't understand this. This shows up in the small number of places that do stand-up meetings right, that do automated *and* thorough testing right, that elicit useful input and direction from the customer, and so forth. Once you throw all the Agile processes together, few places can do most of it right, and that's one of the biggest reasons that Agile ends up being a poor fit so often.

When projects inevitably fail in those circumstances, it is just annoying human behavior that makes the Agilistas claim the failure is due to not doing Agile hard enough rather than doing Agile in the first place, and that's one of the biggest reasons that Agilistas end up being obnoxious blowhards so often.

Re:Developers hate Agile too (0)

Anonymous Coward | about a year ago | (#43910061)

This is the same BS that all Agile apologists say, "you're doing it wrong, its not agile its you!".

Much more effective than a daily stand up: manager spending at least 5 minutes with each team member to review, inspect, and evaluate their progress (you know, actually checking people's work) + more meets as a deadline approaches (beginng of project doesn't need daily meetings, near end might need 2-3 meetings per day).

You can't do right doing wrong. (0)

Anonymous Coward | about a year ago | (#43910069)

There are many more efficient tools for communicating. If none of those are working, all the meetings in the world aren't going to work either. The difference is that physically moving people into the same area takes more time. It also makes whatever is communicated harder to recall unless you expend that much more effort recording the proceedings.

Re:Developers hate Agile too (4, Insightful)

pauljlucas (529435) | about a year ago | (#43910077)

You're doing it wrong. The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any.

As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care). And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.

If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.

Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.

Re:Developers hate Agile too (-1)

Anonymous Coward | about a year ago | (#43910087)

If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.

No one who advocates Agile says that you should just ignore that you have issues until your next standup. Obviously if during the day you have issues you should tell someone. Nice strawman though.

Re:Developers hate Agile too (2)

pclminion (145572) | about a year ago | (#43910121)

As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care).

So you're saying if a fellow team member is doing something in a way you think could be done better, you just stay silent? If a team member is planning to do something that you think isn't actually necessary because of something you're doing, you just stay silent? If a team member is struggling with a problem you have the skill set to help out with, you just stay silent?

It's true, for Agile to work, you need to have a team. The group you are a part of doesn't seem to fit the definition (or at least you don't).

Re:Developers hate Agile too (0)

Anonymous Coward | about a year ago | (#43910235)

So you're saying if a fellow team member is doing something in a way you think could be done better, you just stay silent?

The best way anyone can do something is in a way that makes sense to them and they can achieve efficiently. Give them a clear spec to adhere to and then let them do the job they were tasked with.

If a team member is planning to do something that you think isn't actually necessary because of something you're doing, you just stay silent?

Again, a clear spec!

Re:Developers hate Agile too (0)

Anonymous Coward | about a year ago | (#43910375)

A "clear" "specification" isn't a single thing. Nor has it EVER resulted in higher quality software (unless you can show a study to the contrary).

Re:Developers hate Agile too (1)

ebno-10db (1459097) | about a year ago | (#43910387)

So you're saying if a fellow team member is doing something in a way you think could be done better, you just stay silent? If a team member is planning to do something that you think isn't actually necessary because of something you're doing, you just stay silent? If a team member is struggling with a problem you have the skill set to help out with, you just stay silent?

It's true, for Agile to work, you need to have a team.

There is a difference between a team and trying to create a hive mind. If everybody has to talk about this crap every day, I fall asleep. We have a 0.5-1 hour meeting every week where everyone talks about what they've done, will do, what problems they face, and how they think they can fix it. That seems about right. It isn't necessary for everyone to go into excruciating detail about everything they do. Good people generally know when they've got things under control by themselves and when they have a big worries or need multiple people working on an issue. The daily confessionals seem like something out of 1984. In addition to the weeklies we have either impromptu or sometimes official meetings whenthings come up. We're also trying a new technology called "email".

Re:Developers hate Agile too (0)

dfghjk (711126) | about a year ago | (#43910113)

"The daily standups should be about 5 minutes and are mainly for communicating problems encountered, if any."

You are incorrect, though "You're doing it wrong" is the standard comeback for anyone who criticizes Agile.

http://en.wikipedia.org/wiki/Stand-up_meeting [wikipedia.org]
http://www.mountaingoatsoftware.com/scrum/daily-scrum/ [mountaingoatsoftware.com]
http://agile.dzone.com/articles/agile-health-check-daily-stand [dzone.com]

There are three things that each Scrum team member is expected to relate in turn:
- What they have done since the last standup
- What they are working on now
- Any impediments that are getting in their way

Of course, such meetings aren't unique to Agile and aren't what makes Agile suck. There are other, far worse, problems.

Re:Developers hate Agile too (1)

Nerdfest (867930) | about a year ago | (#43910181)

Admittedly that's because most do Agile quite wrong. I saw a study somewhere that showed that those that the more Agile processes were followed, the better the success rate. Doing half-assed Agile doesn't work well and burns out developers.

Re:Developers hate Agile too (2)

Anonymous Brave Guy (457657) | about a year ago | (#43910357)

I'd love to see a citation for that study. I've been waiting a decade for someone to show me actual data that supports a claim that various Agile practices cause a measurable improvement in some useful way, and so far I've yet to find a paper where the methodology and/or conclusions couldn't be debunked literally in a few seconds.

Re:Developers hate Agile too (0)

Anonymous Coward | about a year ago | (#43910435)

I just started working as an intern at a programming shop, and we're using Agile with five minute daily standups. I can honestly say it's incredibly helpful for the new guy, as you see what everyone is doing and how to think about certain kinds of problems.

A new Highway by my house (0)

Anonymous Coward | about a year ago | (#43909945)

A new highway was constructed by my house and most of the exits existed but they were not open because there was still work to be done to finish the ramp. Lots of drivers were anxious to have the ramps completed and have the highway open. I guess all engineering projects frustrate users and make them anxious.

The problem I have with Agile (0)

Anonymous Coward | about a year ago | (#43909957)

Is getting any work at all out of the devs that use it. They seem to spend 50% of their time in meetings - scrum meetings, planning meetings, grooming meetings and that's just internally. The other 50% of the time seems to be finding how long they can spend to spread one simple thing out over the sprint, and of course once that's out the way _nothing_ else happens until the next one begins. The upshot of all this is that actually getting anything done is like steering a supertanker from the next planet.

So I've come to understand "agile" as meaning "waste nearly all of your time doing meta-work instead of actual work" - the sooner this management fad is replaced by the next one, the better.

I'm sure its proponents will now immediately wheel out the old "no true Scotsman" argument.

Re:The problem I have with Agile (0)

Lunix Nutcase (1092239) | about a year ago | (#43910001)

Sounds like you simply have lazy people who would do the same regardless of the methodology they use. They just use Agile as a convenient excuse to be even more lazy than they normally would be. Maybe you need to fire them and hire people with a decent work ethic?

Re:The problem I have with Agile (1)

Anonymous Coward | about a year ago | (#43910137)

From what I have seen they're not lazy, the amount of meta-work is high, and no developer likes doing that kind of paperwork when they could be programming instead. What happened is that they made an earnest attempt to properly follow the methodologies that were mandated by upper management, and this is the result we got. Not the brightest bunch, really.

Re:The problem I have with Agile (4, Insightful)

Anonymous Coward | about a year ago | (#43910247)

What you're failing to recognise is that there is little incentive to work beyond what you're told to do. I once worked on a product that always hit its dev targets on time, every release contained additional features that were not asked for (but were gratefully received by the clients), and every developer knew what they were doing now, and what they'd be doing in the near future. We had pride in what we were creating, and then it went agile.

Suddenly long term planning went out the window, and the dev team was forced into working in a reactive fashion, rather than a proactive one. Code became buggy, mainly due to the product owner not wanting to expend effort on things like 'testing' and 'documentation'. Any developer problems that needed to be fixed (you know, those important architectural refactors that are needed every so often), would be put into tickets, and would then be buried by the product owner so far down the backlog that they'd never be found again. In the end, if you had some spare time at the end of the sprint, you'd spend that time looking for a new job, rather than worrying about the complete and total mess the codebase had become.

Agile f**king sucks big time. You have a single point of failure, and that point of failure is the product owner. If your product owner is the best software engineer that has ever existed, then agile might work for you. If however your product owner is human, then it's likely your dev team would do better by actually making the decisions as a team. Agile does not promote teamwork, it pays lip service to it, and in the process, it removes any incentive for the team to work as a team.

The real truth... (2)

Junta (36770) | about a year ago | (#43910095)

It doesn't matter what you call your process, many development teams will devolve into this behavior. The fact of the matter is that 'agile' has the distinct honor of being the most 'hip' thing, and as such it is the set of labels of choice used to hide behind.

Of course. most of the terminology about agile stems from a host of BS that seems more infomercial than useful. The original 'manifesto' was a collection of straightforward statements that are pretty sensible, though mind numbingly obvious. It has mutated to be a large set of vocabulary generally hijacked at will.

christianity, and most religious organi (0)

Anonymous Coward | about a year ago | (#43909981)

Communism is awesome, but there just hasn't been a real Communist state....
Christianity is awesome, but the church isn't true Christianity
Democracy is awesome, but we just need more to be a true democracy...

Huh (0)

Anonymous Coward | about a year ago | (#43909987)

Since when does Agile mean overwriting people's changes at random in your version control system? I can't say I've ever encountered such a bizarre thing anywhere I've worked and done Agile.

Re:Huh (1)

Anonymous Coward | about a year ago | (#43910389)

With agile you're supposed to work on isolated 'features', and that kind of implies you'll be using feature branches. Now, let's talk about branching in SVN. With SVN, when you create a branch, you are actually creating a fork. The two forks will quickly diverge, and so you have to synchronise your fork with the trunk every so often. If you're working in a team of say 30, then you may have 30 separate product forks active at the same time. At the end of a sprint, the developers will enter a race to see who can jab their fork into the product first. If you're the first person, the meat is nice and tender, and the fork will stick firmly into the product without a problems. If you're the last developer, you'll find that the product is nothing more than a pulverised mush of meat scattered around the trunk, and your fork wont stick no matter what you try. I call this developer the 'spoon'. The spoon's job is to scrape up the remnants of the product, roughly form it into something that looks edible, and then commit the resulting mess, before pissing off down the pub. During this process, there is a good chance that the spoon will have missed a couple of forks that have fallen behind the table, still with a bit of meat attached. Branching in SVN is only slightly better than a nervous breakdown, but the end results are more or less the same.

M. Folwer said it best: Don't do scrum w/o XP (5, Insightful)

bADlOGIN (133391) | about a year ago | (#43910007)

He says it quite nicely:

http://martinfowler.com/bliki/FlaccidScrum.html [martinfowler.com]

Of course that was in 2009. Nothing has changed, and I've long past the point of being fed up with the non-technical fuck-tards that think they can sprinkle Scrum-dust on a mountain of technical debt and it'll go away. This is usually done in the presence of a stable of bad developers who lack the discipline to do the actual hard work of the XP practices that deliver good products in the first place.

The parent article author can STFU already. It just reeks of, "Wah! My agile hurts me because I won't do the hard stuff".

Oh, and while your at it agile wimps: stop fucking trying to do "distributed agile" with fucking China and fucking India in order to save 30% on what's already a crap-pile due to communication problems. It's not going to help one bit.

Also, get off my lawn...

Re:M. Folwer said it best: Don't do scrum w/o XP (1)

ImperialSardaukar (2904421) | about a year ago | (#43910043)

The FlaccidScrum article made me worry that we had a spy in the room documenting how my company works.. Sorry, "works" :)

Re:M. Folwer said it best: Don't do scrum w/o XP (5, Insightful)

bADlOGIN (133391) | about a year ago | (#43910089)

Exactly. Part of the reason XP never took off is that it forces business people to confront reality. You can't PowerPoint your way out of a pair of developers standing in front of you explaining that you're the one who needs to decide what the fuck in going to be built right here, right now, and to accept the consequences of supporting it.

Re:M. Folwer said it best: Don't do scrum w/o XP (0)

Anonymous Coward | about a year ago | (#43910351)

Exactly. Part of the reason XP never took off is that it forces business people to confront reality. You can't PowerPoint your way out of a pair of developers standing in front of you explaining that you're the one who needs to decide what the fuck in going to be built right here, right now, and to accept the consequences of supporting it.

+1

Re:M. Folwer said it best: Don't do scrum w/o XP (2)

bunhed (208100) | about a year ago | (#43910085)

Goddam I wish I had me some mod right about now

Re:M. Folwer said it best: Don't do scrum w/o XP (0)

Anonymous Coward | about a year ago | (#43910187)

*standing ovation*

This is the problem. We believe that we can change process to avoid refactoring and you just can't avoid refactoring. You're only delaying the inevitable, and by the time you get to it you're sitting on the biggest pile of shit that civilization could ever imagine.

I'm starting to think that a combination of open source and more programmers in the world might actually recognize some of the crap the industry keeps churning out. As long as no one is looking they'll keep cranking crap and more crap, and a healthy massive dollop of bullshit and chips.

this or that --you pick (1)

Anonymous Coward | about a year ago | (#43910017)

Dear user: you can have a Big Upfront Crystallized Waterfall Development and we'll all pretend that nothing will ever change and what you get is what you get -- or we can try and make it better along the way as we develop better understanding of the lame incompetent efforts you have half-heartedly made when laying what you asked for.

Users are agile in changing what they asked for into what they wanted; developers have to agile to match those changes.

Are you nuts? Don't talk agile with the customer (5, Insightful)

bunhed (208100) | about a year ago | (#43910025)

The customer thinks they are ordering a building, metaphorically speaking. They can walk around it in their heads, see the color of the drapes, measure the windows, there are quantifiable costs. You don't build things using agile techniques however. "Well, we'll put this skyscraper about here. Start digging and we'll see how she goes."

"The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"

How? Don't even talk about agile to the customer. Can you imagine a surgeon... "Well we'll just start cutting and figure it from there" no no, talk about outcome, not process. Agile talk is for the operating room, not the waiting room.

Re:Are you nuts? Don't talk agile with the custome (2)

dfghjk (711126) | about a year ago | (#43910169)

"...talk about outcome, not process."

But with Agile there is no outcome, just process. Agile does not work toward an end nor does it invest in understanding when there might be one. It is optimized for projects for which the intent is a continuous stream of incremental deliverables of little or no value and no completion. Great for sustainable billing and the pretense of interchangeable man-months, bullshit for anything worth doing.

Re:Are you nuts? Don't talk agile with the custome (1)

bunhed (208100) | about a year ago | (#43910211)

That's kinda what I'm saying actually. In the real world, agile talk is idiotic.

Re:Are you nuts? Don't talk agile with the custome (3, Funny)

ebno-10db (1459097) | about a year ago | (#43910229)

So you've worked at Google? Beta is the goal.

Re:Are you nuts? Don't talk agile with the custome (1)

Typical Slashdotter (2848579) | about a year ago | (#43910269)

I disagree. If you can't get your customer to go along with agile, then agile might not be right for you. One of the key observations behind agile is that customers often don't really know what they want up-front, and that they're better at pointing out the differences between an intermediate solution and something workable. As I understand it, that's one of the driving forces behind the short sprints: start with the bare bones, and work on what the customer perceives to be the biggest missing feature. Keep doing that until the customer likes it.

I understand that not all customers can do this, however.

Re:Are you nuts? Don't talk agile with the custome (1)

bunhed (208100) | about a year ago | (#43910293)

"I understand that not all customers can do this, however."

A very fortunate few in my experience.

Re:Are you nuts? Don't talk agile with the custome (1)

sphealey (2855) | about a year ago | (#43910421)

- - - - - I understand that not all customers can do this, however.

Whereas my experience is more with a bewildered business unit representative being handing a 200 page "spec" in dense type and bizarre, technical language and told he has until Thursday to approve it (with all the time invested, it is understood that no spec can ever be rejected); then being equally bewildered when the mods delivered (which do in fact match the spec, modulo interpretation) don't do anything like what he needs them to do or thinks he asked for. Similarly with dozens of business unit reps sitting in a room reading laboriously through aforementioned spec line by line and being told to "sign off" on each page; when it doesn't work they are contemptously asked 'why didn't you speak up in the review meeting?'.

sPh

Re:Are you nuts? Don't talk agile with the custome (1)

Entrope (68843) | about a year ago | (#43910315)

Agile dictates that you have practically continuous customer input to the development process. How do you propose to get that -- and to communicate your expectations about those interactions with the customer -- without telling them about the methodology?

Re:Are you nuts? Don't talk agile with the custome (5, Interesting)

sphealey (2855) | about a year ago | (#43910401)

If anyone thinks that there is complete, 100%, nailed down design for a 75-story skyscraper before any digging starts, and that the design for the 69th floor is similarly nailed down before the 3rd floor is finished, they need to spend some time on a construction site. The overall shape of the building, the structural design, the very bottom and top floors, and the allowable parameters for design of the later floors, sure. But the exact design of floors 50-72? No. Plan for what happens when the selected elevator supplier goes bankrupt, the ship carrying a key delivery of structural steel sinks, the developer finally signs a tenant for 68-70 and he wants an internal staircase and private elevator for his offices? No. Look up "fast-track" in a construction dictionary.

sPh

Groupon (0)

Anonymous Coward | about a year ago | (#43910047)

Here's how to sell Agile : It's like Groupon. Maybe you won't have what you want, but you will end up with something and it will be cheap.

Mumbo jumbo marketing (0)

Anonymous Coward | about a year ago | (#43910051)

"What developers see as iterative and flexible"

Really? Because I think its the latest in a long line of mumbo jumbo project leadership tools for managers that don't know what they're doing, so they seek out a guru to tell them. Usually with a lot of nice sounding [Barnum statements] for weak minded managers to cite as evidence.

Re:Mumbo jumbo marketing (1)

Junta (36770) | about a year ago | (#43910175)

Don't forget the consulting and speaking fees! Those are critical.

Customers get some of their own medicine (0)

Anonymous Coward | about a year ago | (#43910131)

Gee customer, this is how it feels when you change the spec, add features, demand arbitrary and contradictory changes with no notice.

Sorry, will reply... (0)

Anonymous Coward | about a year ago | (#43910155)

once my Chrome finished updating to version 244...

Feelings - nothing more than feelings (1)

Anonymous Coward | about a year ago | (#43910163)

developers have to understand how Agile processes can make users anxious, and learn to respond to those fears

Soo.... To make Agile work developers have to understand user 'feelings' and respond considerately. Is it just me or did this whole Agile thing just turn from a fun one night stand into a committed relationship with cards and anniversaries and stuff?

I think I'd rather just stick with Agile sucks.

Agile definitely has a place (3, Insightful)

GodfatherofSoul (174979) | about a year ago | (#43910167)

But, it's like every other tool; it was made for a certain job. You try working in screws with the claw end of a hammer, and you can expect your results to suck. If you don't have a staff of above-average, disciplined developers and small or well-understood project goal odds are you're applying the wrong path. Agile isn't for project managers who just want to save money and speed up development.

Big designs are bad, be good (0)

Anonymous Coward | about a year ago | (#43910223)

At some level agile is agile. At its core it encourages doing more of less rather than less of more. If your a software sweatshop please tune out now.

I think encouraging people to make piecemeal changes rather than investing in hard creative designs to better address the application domain is great advice for all of our competitors.

You guys go do that thing...add your widgets and features in low level codes while we configure the same in a RAD framework before you can say uncle. Be disruptive release little shit updates to production customers all the time...I'm sure they will be thrilled at your responsiveness to their needs. Place no bounds on global complexity and just let all the shit pile up because well features are worth it and using your brain is a bad thing (tm). I love agile and I hope our competition does too.

Agile isn't what I hoped it would be. (3, Interesting)

Maltheus (248271) | about a year ago | (#43910231)

I've done agile for the past few years and always waterfall before that. Was looking forward to agile because it sounded more flexible, but that's not what I've observed in practice. Everybody is so touchy about finishing up all of the sprint tasks by the end of the two week period, that there is a strong disincentive to bring anything new in, when you're finished up. No one wants to skew the metrics.

Between the aribtrary development cycle and the constant meetings, I find it far less productive than waterfall. Especially since so much waterfall is implemented in an interative fashion anyway.

No process? (3, Insightful)

phantomfive (622387) | about a year ago | (#43910243)

She's been frustrated by her Agile experiences — and so have her clients. "There is no process.

If there is no process, it's not Agile. It's laziness with a name as its excuse.

Agile has a very different process than Big Design Up Front, but it definitely has processes. Frequent releases are a process. Scrum meetings are part of a process.

Agile means you always hit final release date (1)

ferret4 (459105) | about a year ago | (#43910275)

The way I've used agile is not to have multiple iterative launches of a product, but to have multiple iterative points where you *have* a launchable product. The advantage of Agile isn't constantly churning out crumb-like updates to freaked-out users, it's being able to say on any given week "we could launch with X feature set now if we had to, and have Y feature set still to build" rather than the non-agile alternative which is "it doesn't work but we are 30% towards completing it".

This enables you to be able to set a firm launch date and be able to meet it with a working product. You can either chose to launch iterative updates afterwards, or just stick with what you launched and move onto a different project - whatever the business decides.

In reference to the summary: if there is no process, you are doing Agile wrong. If your developers are overwriting each others work, you are using SVN wrong. Neither of these are inherent problems with Agile, you're just being incompetent - and there is no methodology to overcome incompetence.

Agile is fundamentally flawed (0)

Anonymous Coward | about a year ago | (#43910283)

Quality and re-usability aren't even on the radar, so in the long run, code is more expensive, buggier, and harder to extend and maintain. In practice the mindset almost always becomes, "just get something done, somehow, so we can move on..."

In the real word, comprises need to be made, but Agile doesn't consider software to be a valuable asset, it is a disposable tissue suitable for wiping your nose and never using again. Later, when you have to maintain or enhance it, it is an undocumented mess with poor design, ragged interfaces, and often without even a clear understanding of what it is supposed to do.

In other words, it expresses perfectly the general opinion of what we now expect.

Re:Agile is fundamentally flawed (1)

Jack9 (11421) | about a year ago | (#43910403)

> Later, when you have to maintain or enhance it, it is an undocumented mess with poor design, ragged interfaces, and often without even a clear understanding of what it is supposed to do.

The resulting mess has nothing to do with Agile. If your process doesn't require testing, that's often the result. Testing is the most effective way to document specifications and is a common requirement that product owners choose to throw away. That's a choice made to improve the process. The fact the PO can't understand the result, is not the fault of the process.

Simple answers. (2)

neoshroom (324937) | about a year ago | (#43910295)

"Clients ask, 'How much will it cost?'" says Hecker. An Agile-style answer is frustratingly ambiguous, he points out, along the lines of, "We think we can do it as described in about two months plus one month of bug-fixing so that's about three months unless we choose to make refinements and improve the product along the way, in which case it will be longer." "Then the client responds, 'Umm but, how much will it cost?' and I begin to hear the anxiety in their voice," says Hecker. "They wanted a crystal clear answer to a seemingly simple question, but it's hard to supply that answer because Agile projects are always a shifting sand."

This is just silly. As an agile developer you just write to a spec and the spec contains features and milestones. You ask "What do you want it to do?" They tell you. You write a spec for them with everything they asked. They ask "How much will it cost?" You tell them. Then if they want evolutionary developments you add those on as a fair fee later for the extra work beyond what was in the original spec. This isn't a problem with an agile development philosophy.

Agile programming is like evolving a species. Just because you might end up with a giraffe, doesn't mean your first spec can't be a very clear one for an antelope. If the client wants to make the neck longer and add some spots later, it is good that you choose a flexible and agile basis, but there is no need to give the client a primer on selective breeding and evolutionary genetics before you even begin and get them concerned with all the details. Details are the programmer's job.

We had an odd experience with Agile.. (0)

Anonymous Coward | about a year ago | (#43910325)

It was sort of Agile - all of the Agile-buzzwords and all that. But there was *TONS* of process wrapped around it. You couldn't commit anything unless the sprint was in the right state and you had a story in the right state, and the tasks were in the right state. Part of the explanation is that they needed to accommodate customers who were in highly regulated industries, where everything you do needed to be traceable and documented.

You really had no motivation to do much of anything above and beyond. Even fixing trivial "no-brainer" bugs got deferred simply because there was too much process involved to actually check in the fix.

But from one who actually had to do it, I would describe it as "soul-sucking".

Not all projects are amenable to Agile (1)

non-e-moose (994576) | about a year ago | (#43910331)

Yup. A Troll-bait comment subject. But not every project is one where it can be afforded to "fix it" next month/next quarter. Device drivers. Compilers. Mainframe OS's. I heard a figure recently (from in-person discussion with a Mainframe SW person) that downtime costs them upwards of US$10,000 PER SECOND of downtime. Agile focuses on fast responses to customer bugs, not on ensuring that the number of bugs experienced by the customer is virtually zero. The point is that Mission Critical content has to have a correctness level which is an order of magnitude (or more) than a game or a less-than-wonderful UI. A bad case scenario: Oh, I'm sorry, Miss/Mr. medical patient of Therac25 (http://en.wikipedia.org/wiki/Therac-25) - we'll fix that in two revisions by using our Agile process (its a tough bug to fix), and we're sorry that you will contract a horrible form of cancer in the meantime.

Roadmap! (1)

chrismcb (983081) | about a year ago | (#43910333)

If you are working for a customer, you still need a roadmap, some sort of over design. Your customer needs to know where you are going. You can't just say "we'll give you an iterative version with a new feature or two in two weeks" and say that every two weeks. Because then you'll do exactly what you described, leave the customers and programmers confused. You don't need to design every last thing out, but you still need a roadmap.

Features in search of an architecture (1)

Animats (122034) | about a year ago | (#43910367)

"Agile" techniques are useful when the problem can be treated as a large number of decoupled features. This is the case for many web-based systems. (Especially since the database system does most of the the stuff that really needs to work right.). It's not too useful if the problem isn't like that.

This is part of the curse of open source, which tends to turn into a set of features in search of an architecture. Some open source projects have a strong architecture, but they tend to have a "little tin god" problem.

Not Worth. (0)

Anonymous Coward | about a year ago | (#43910377)

I have been work in software development accounting sector.
1.Will exhaust Developer because of time constraint.
2.User tend to bypass normal accounting procedure,making development agile faster but inconsistent software.
3.Software love by user. No the user think differently.User also exhaust numerous of testing and blaming the vendor because inexperince while the the vendor much confuse since they follow the new and fast agile development.
4.Hardly to get break even.
**
Now i'm moving to non customize accounting software.It had to because customer usually don't understand how software and accounting works.
More report on excel,make user itself tend to do agile reporting rather then forcing developer to agile reporting.
BI tools->unsure it will help or not.

Seriously.. (1)

houbou (1097327) | about a year ago | (#43910431)

Agile or Not, users should NOT care, which means, if you can't satisfy 66% of your users with your product and/or your services, then you are doing bad business, it's that simple.

If you have no process then you are doing it WRONG (0)

Anonymous Coward | about a year ago | (#43910441)

Agile, has process, lots of process, it is just different. If you are doing Agile with process then the problem is not Agile it is your teams lack of understanding of Agile development methodology.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?