Live data from Hacker News

Why do some developers consider Agile development to be nonsense?

agileoverflow.com

31–40 of 147 posts

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

#31

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…

"'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass." . I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is so…

Some or several of the points you raised probably fit more into the "chance to look into the puzzle" phase so that doesn't really stand to reason against his point 100%.

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

#32

Earlier quoted context omitted.

I've been in a lot of standups and that's never come up. (Yes, I know, the plural of anecdote is not data.)

OT, but I'm stealing that quote! Made my morning :)

http://freakonomics.com/2010/04/29/quotes-uncovered-whats-th...

(I prefer "The plural of anecdote is Gladwell" but that's because I can't stand his lame books.)

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

#33
post #4

The title is completely mangled. The original (rather long) title is "Why do some developers at strong companies like Google consider Agile development to be nonsense?", and it seems it was shortened. There's a spurious "at" left in there now which breaks it.

This happens when people try to shorten their titles to fit 80 characters.

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

#34
post #6

IF teams are using Agile like that there doing it wrong. It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. If your goal is to use Agile to push developers to their limits, you've already failed the Agile Test. You can twist Agile, based on your vision of good team is. So you have to get the right people to implement it. You have to approach it from the idea of it bei…

> It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. The vast majority of work environments cannot be described as relaxed and friendly (hell, most of them probably aren't all that collaborative). Far more could be described as pressured hot houses.

That's the point. Managers often use management techniques that encourage that. It works if your on simple assembly tasks. I.E Worried if you gonna be fired if you don't make 200 widgets.

Doesn't work if you're on knowledge work.

A lot of people approach agile as its an extension of those approaches. When in fact it was a reaction to it, by trying the opposite approach.

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

#35

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…

Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward. Most of my experience with agile…

> The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do.

That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").

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

#37
The free e-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though.

Scrum-English Dictionary:

* "sprint": artificial crisis

* "end of sprint": abandonware

* "Scrum master": resume credit for my planned escape to a new company

* "stakeholder": someone you can't get away with externalising your costs onto

* "simplified": doesn't implement any of the actual business requirements

* "lightweight": doesn't implement any of the actual business requirements, but does so much more elegantly than the version that works

* "easy": project was born circling the drain (and doesn't implement any of the actual business requirements)

* "legacy": the version that works and implements the actual business requirements, even if no sane human wants to touch it

* "velocity": a speed with a direction, so skittering about following marketing's random hairpin turns counts

* "retrospective": blamestorm incoming!

* "stand-up": getting the blamestorming in early

* "We'll put that on the backlog": hahaha fuck you

I do enjoy some of the jargon. "empowered": do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that yourself."

Seriously: every good idea is turned into a bad one by the relentless management quest to Taylorise clue.

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

#38

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…

"'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass." . I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is so…

To be sure. And if we were doing routine maintenance on a longstanding codebase things might be a bit more predictable than they are. But we're trying to do new feature development on a new product, and my experience has been that beyond a very general sense of "this is going to be a big one" vs "this shouldn't take too long, unless I run into something unexpected" -- which is the same level of detail you get with or without Agile -- sizing isn't meaningful enough to be worth the time it takes to do.

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

#39
Experienced engineers have seen a lot of "magic bullets" both on the process side and the product side. Generally they turn out to not be a substitute for hiring good people and getting good leaders to define a quality product and focus the team on what is important both short and long term.

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

#40

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…

Well there is an interesting concept - you're talking about jargon like "sprints" yet referring to "Agile" which is a very, very broad church.

I like Scrum for the power of the retrospective, if people actually talk about issues, the the team really is empowered you can change those problems: a) Talk through how to handle bugs. There is no prescriptive answer, if you have a problem with defects then fix it, or develop a system to deal with them. You don't have to bring a bug into sprint after all, and if you do then get your Project Owner to drop an equivalent bit of work out. b) Refinement is a crucial part of the process, if you can't break up the task into 1/2 weeks worth of work for a team odds are you don't fully understand the task, which means you can't provide forward estimation, which means management can't trust you're numbers. c) "Project Managers" don't exist in Scrum, so a PM consultant guiding you on agile feels very, very wrong.

If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction then odds are Scrum isn't going to work for you.

Scrum is very clear that there are certain things you need to do in order to say you're doing Scrum. Doing "Agile" screams following no particular sub methodology but cobbling something together. There's nothing wrong with that evolving, but it helps to be able to describe why you've gone in that direction. In your case it seems like you've had something foisted on you by external people talking out of their rear.

Post reply on HN