Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why do some developers consider Agile development to be nonsense?

agileoverflow.com

Post reply on HN
Print view View original

121–130 of 147 posts

Re: Why do some developers consider Agile development to be nonsense?

#121

Post by davidgerard »

wilsynet wrote: post #68
zimpenfish wrote: post #53

Earlier quoted context omitted.

I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.

They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me? There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". The standup is 10-15 minutes. If it is longer, it needs to be sto…

So, have you ever said "Anyone going over sixty seconds will be shot" and there's that one guy - or two, or three - who nevertheless always take five minutes? Yeah, turns out you probably can't actually shoot them.

Re: Why do some developers consider Agile development to be nonsense?

#122

Post by davidgerard »

jacquesm wrote: post #30
mklim wrote: post #24

Earlier quoted context omitted.

What was your company doing before switching to Agile?

Getting stuff done, but in the eyes of management not fast enough. Just guessing but this seems to be the rule. If you really need agile it will not help and if your team already rocks agile won't improve it, likely you'll already be doing something like it but customized to your needs. I've seen a couple of fairly efficient teams utterly ruined by switching to 'agile' and I've yet to see an inefficient team become m…

"No Silver Bullet" was written in 1986. https://en.wikipedia.org/wiki/No_Silver_Bullet One day someone in The Mgt. will read it.

Re: Why do some developers consider Agile development to be nonsense?

#123

Post by dragonwriter »

chillingeffect wrote: post #23

An eager beaver at one of my client's is introducing Agile as a "Waterfall silver bullet." I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture. Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration? Why write "gdb" when "gcc with printfs" will work fine, even if it simply requ…

> I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture.

Neither the Agile Manifesto nor even the far more specific Scrum Guide even refers to user stories.

A particular organization using Scrum may decide that architecture-related concerns are not important in the definition of "done" for items in their product backlog, and focus only on "user story success", but, to the extent that that's a problem, that's not a Scrum (and much less, Agile) problem, its an organization problem.

Agile is about what concerns you favor in figuring out how to get work done, Scrum is about how a team gets work done and defines the work it is to do within the framework provided by the wider organization, but the specific definition of quality standards for work is not directly addresses by either.

> Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration?

Why wouldn't an organization have maintaining (or improving) the overall architectural standards of the work a priority for every iteration -- in Scrum terms, part of the Sprint Goal -- unless there is a conscious decision to take on technical debt to meet some other goal? Agile, or even Scrum, doesn't tell you what goals to set, and you shouldn't blame them for you choosing to set the wrong goals.

Re: Why do some developers consider Agile development to be nonsense?

#124

Post by davidgerard »

notacoward wrote: post #82

I've seen many criticism of agile/scrum as they (don't) apply to long-term or systems-software environments, but another disconnect I think people need to know about is with open source. Here's the "upstream first" development model typically used by Red Hat (my employer) and others. (1) Company decides to devote resources to a feature. (2) Developer writes code and submits patches upstream (e.g. to the Linux kernel)…

And the hilarious (fsvo) thing there is that "agile" was an attempt to port open source at its best to corporate development.

Re: Why do some developers consider Agile development to be nonsense?

#125

Post by kabdib »

cmdkeen wrote: post #46
kabdib wrote: post #19

Earlier quoted context omitted.

Yeah. Scrum doesn't make management disappear, it amplifies it. I saw meetings with middle managers (people who hadn't shipped anything significant in a decade) in daily meetings, going over burn-down rates of individual engineers and "expressing concern" through channels that someone was off their schedule by a couple of days. The daily scrums were just half-hour status-in-a-ring and some public shaming if you could…

Intriguingly you've not mentioned 2/3rds of the people in a Scrum team - the Product Owner and the Scrum Master - both of whom are supposed to be the ones who handle many of the problems you list. Build servers being on fire feels like a perfect example of an impediment. People who aren't actually developing anything feel like the perfect example of people who shouldn't be at standups, and certainly shouldn't be spea…

Well, 2/3rds of the people in a Scrum team were essentially dead weight, in my experience. They made work.

In one org, the devs were excluded from the planning meetings, which is pretty much all you need to know about how badly Scrum went off the rails.

"Okay, you're signed up for X, Y and Z, it'll take you two weeks, and tell us every morning about your progress."

"This is day 15 of the build system being totally broken, and I haven't been able to run my code in a week."

"So, you're late. Is that what you're saying?"

(sound of door slamming shut)

Re: Why do some developers consider Agile development to be nonsense?

#126

Post by kabdib »

depr wrote: post #93
dbg31415 wrote: post #56

So instead of Agile we should use, what? Fully understand that process is a technology. If Agile is so bad, what's better?

I am interested in this as well. Who's using a different process?

Why do you need a capital-P Process? Does it need to have a name?

Best teams I've been on have been self-organizing, with a few senior engineers who did heavy-lifting and some less experienced engineers learning new stuff. Management was minimal (the more we had, the more things sucked).

- Minimize management. Minimize management. Minimize management. Management exists to set very high level directions and to remove obstacles.

- Make sure that different teams talk. A lot.

- Get real. Don't blow smoke up people's asses. Making a schedule with a granularity of a day on a six month project is fucking bullshit. Just stop it, okay? You might be able to do this a week out, but not much more than that. If that deadline is important, be clear on why. (I've been on projects that have been absolutely killed because someone felt they had to ship on magic date X, when shipping a few months later would have saved the product).

- If you are working steady 60+ hour weeks, you are doing it wrong. If you are doing regular 80+ hour weeks then you will burn out and leave.

- It's done when it's done. Ship it, and iterate.

Re: Why do some developers consider Agile development to be nonsense?

#127

Post by fsloth »

walterbell wrote: post #75
fsloth wrote: post #57

Earlier quoted context omitted.

"Here's the secret: software development isn't really about making computers work, it's about organizing knowledge. If your process focuses more on making the computers work than your institutional knowledge you're making a critical mistake." That's a fantastic quote, thanks.

You may like Philip Armour's Five Orders of Ignorance , http://www-plan.cs.colorado.edu/diwan/3308-07/p17-armour.pdf " 0th Order Ignorance: Lack of Ignorance. I have 0OI when I (probably) know something. 1st Order Ignorance: Lack of Knowledge. I have 1OI when I don't know something. With 1OI we have the question in a well-factored form. 2nd Order Ignorance: Lack of Awareness. I have 2OI when I don't know that I don't…

Thanks! That was a new one. But now I am perplexed is Dunning-Kruger effect the result of 4OI or "just" 3OI :)

Re: Why do some developers consider Agile development to be nonsense?

#128

Post by wilsynet »

jackmaney wrote: post #90
lostcolony wrote: post #89

Earlier quoted context omitted.

They don't, however, involve everyone. The standup does. That's key. If person A needs to talk to person B about an issue, and it's done in standup, it wastes person C, D, etc's, time, even though they don't need to be involved. Doing it with just the required people is, obviously, required anyway, and the problem a lot of people doing agile have is they end up wasting everyone's time by bringing it up during standup…

A 45 minute meeting that spawns off of a 15 minute meeting is still a total of 60 minutes of meeting time. And yes, while that 45 minutes involved fewer total people, that doesn't mean that others won't have spin-off meetings of their own.

If you want to say that 2 people resolving an issue is a meeting, sure, go ahead and call it that. But I would suggest that the meeting needed to happen anyway.

Scrum doesn't imply that unneeded meetings need to be created for no purpose.

It is perfectly okay to also say during the standup "I'll follow up with you over email later" or "Let's resolve this over Slack".

Re: Why do some developers consider Agile development to be nonsense?

#130

Post by geebee »

outsidetheparty wrote: post #12

This matches my experience. We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-softwar…

Your analogy to estimating 23 across is pretty amusing. I like it a bit more than the claim that software estimates are like asking how long it will take to detect dark matter (another one I've heard), because honestly, I really shouldn't try to equate my work with something on that scale. That said, I actually think your analogy is, if anything, a bit too optimistic about estimates. In some ways, I'd stretch it to "you're good at puzzles. how long will it take to solve next week's puzzle". You know that puzzles are usually crosswords, sudokus, word scrambles, or chess problems, and you can usually get them, even the hard ones. There's variance, and sometimes you do get stumped, so it's a bit stressful, but at least you have some kind of prior history as a guide. But surprisingly often, it turns out to be something like encountering a rubik's cube for the first time. How long does it take to solve a rubik's cube? Well, once you know how to solve one, it takes less than 5 minutes. How long does it take to figure out how to solve one when you've never encountered it? Well, for some, never. For others, a month? For a few people, a day?

But the answer is, it will take me anywhere from 30 minutes to a month to tell you how long it will take me to solve this problem (over 1 month, I give up). Then, my answer will be: 5 minutes.

Post reply on HN