Live data from Hacker News

Coconut Headphones: Why Agile Has Failed

mikehadlow.blogspot.co.uk

31–40 of 133 posts

Re: Coconut Headphones: Why Agile Has Failed

#31

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who ar…

Agile is the new RUP.

The main audience is shifting toward the shitties. It's the circle of life for cultural movements. Nothing wrong with Agile. It's just not my thing anymore.

Re: Coconut Headphones: Why Agile Has Failed

#32
He just vaguely blames everything on "non-technical management" without really offering a cogent argument why.

When he does get to concrete points, one of them is "Short feedback loops to measurable outcomes create good software." And yet "two week iterations" he calls "agile nonsense".

The overal tone is kind of "technical macho" to me.. like, Real Developers don't need management and if you slipped then it's because your programmers suck and you should just hire better ones.

Re: Coconut Headphones: Why Agile Has Failed

#33
post #32

He just vaguely blames everything on "non-technical management" without really offering a cogent argument why. When he does get to concrete points, one of them is "Short feedback loops to measurable outcomes create good software." And yet "two week iterations" he calls "agile nonsense". The overal tone is kind of "technical macho" to me.. like, Real Developers don't need management and if you slipped then it's becaus…

Non-technical agile management usually gets in the way. They get in the way with rigid prioritization. Prioritization means less gets done because you are optimizing sequential outcomes instead of a solid development process. Good engineers will evolve the architecture toward where the product is heading.

Non-technical agile management uses points to measure the work that gets done because they don't know any better and they "need" to measure something.

The technical architecture starts to go downhill over this never ending treadmill of the prioritized backlog with the non-technical task masters whipping their developers to get more points done.

Sure, we can educate the non-technical management over keeping a low standard deviation of points. We can bargain to get technical cleanup time (marked as chores). We may even have a debt cleanup week out of the month.

However, the spirit of the engineering endeavor is lost to the marketers, or their henchmen, running the project. It's too bad because subpar products and subpar code are the result.

Re: Coconut Headphones: Why Agile Has Failed

#34

The demotivation poster (we'll ask for estimates, but then treat them as deadlines) really strikes a chord because that is one of my major 'gripes' with the agile planning process. Particularly when a manager is heavily involved in that process. It may be no coincidence that the best projects I have been on are the ones where the manager deliberately stepped out of the room or was not a part of those phases of the pl…

I think the correct way to do it is to do the old 'pick two' method - quality, features, timeline, pick two. (I'd say you never want low quality but... situationally.)

Re: Coconut Headphones: Why Agile Has Failed

#36

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who ar…

Agile is the new RUP. The main audience is shifting toward the shitties. It's the circle of life for cultural movements. Nothing wrong with Agile. It's just not my thing anymore.

By definition most companies, most teams and most individuals are average. There are very few really good developers and managers. What suits those few does not really matter. They will do great things not matter what. Agile works for most better than the alternatives.

Re: Coconut Headphones: Why Agile Has Failed

#37

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who ar…

"No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need."

Depends what you class as "good software". My colleague left some code which "worked" and "met the needs" (at the time). I made a small change to the database it interacted with and it fell over. I had to go in a debug it, but it was so badly written I had to completely refactor it just to debug it properly.

So her software met the needs, my rewrite of it met the needs, and has been far more reliable and maintainable. I would say that is better software.

Re: Coconut Headphones: Why Agile Has Failed

#38
post #37

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who ar…

"No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need." Depends what you class as "good software". My colleague left some code which "worked" and "met the needs" (at the time). I made a small change to the database it interacted with and it fell over. I had to go in a…

Of course technically better implementation is better if the only thing that changes is the technical quality of the implementation.

But it does not follow that doing good software is a technical challenge. It does not matter how fast your algorithm is if nobody wants the results that it spits out.

Defining good software is really hard task, but in general what I mean by it is that good software increases the well-being of its users. Yes, one aspect of that is the technical quality of the implementation.

Re: Coconut Headphones: Why Agile Has Failed

#39

I worked for a large corporation which used a hard core water fall method to produce software. And yet it called it Agile. Why? Because why not.

I have noticed this. Every one claims to be doing agile, even though they pick and choose the parts they decide are "agile".

I just continue to write software the way I always have. Kind of disciplined version of cowboy coding I would say. Sometimes I have design documents - when I feel it helps. Other times the problem might be less clear, built a prototype, and iterate from there. It really depends on the problem you are trying to solve and the time frame you need to do it in.

I get software working, usually in a decent time frame. Is that not what agile is supposed to be about?

Re: Coconut Headphones: Why Agile Has Failed

#40
post #10

Has it really failed? It seems like at least some of the principles of agile are just a given now. 10-15 years ago that wasn't the case. People actually believed in waterfall. Of course many individual teams fail at agile but those teams would probably fail no matter what approach they were using.

It's a good question. But personally, I think that people would have stopped believing in waterfall approaches anyhow. Anybody sticking with 18-month release cycles today would seem like an idiot whether or not anybody had heard of Agile. And really, what a lot of supposed Agile teams are doing is really mini-waterfall: all the ceremony, shorter cycles, but just as much horseshit and self-delusion.

I got taught waterfall at university. Nowhere did it specify 18 month release cycles, just iterations, and going "back up the waterfall" if need be (critics of waterfall never seem to acknowledge that you can go back the way). To be honest I don't see how it actually differs from agile that much. Just less emphasis on documents up front.
Post reply on HN