Live data from Hacker News

Agile Ruined My Life

whattofix.com

121–130 of 137 posts

Re: Agile Ruined My Life

#121
post #48

Earlier quoted context omitted.

...if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile If there is no way to tell, does it matter? I mean, if Agile requires a perfect implementation, support from everybody, very smart people and luck, is it any good? If I have all that, I can do whatever with any methodology.

Agile does not require perfect implementation. I have yet to see an "unsuccessful" project using agile, as in the customer and team was not happy with the conclusion (I've been involved with > 10). Usually things change before that point is reached. If the team cannot change when things start sucking, then things will continue to suck, regardless of methodology or lack of. Most teams can adjust (at least the ones I w…

I have yet to see an "unsuccessful" project using agile

The question I was responding to was if all the problems were caused by Agile or by deficiencies in its implementation.

If all you've seen is succesful projects, you can only guess why failed ones fail.

Re: Agile Ruined My Life

#122
post #48

Earlier quoted context omitted.

...if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile If there is no way to tell, does it matter? I mean, if Agile requires a perfect implementation, support from everybody, very smart people and luck, is it any good? If I have all that, I can do whatever with any methodology.

If there is no way to tell, does it matter? It's easy to see the flaw in many failed implementations: they don't manage their schedules, they don't have successful iterations, they don't manage their technical investments, and the only thing they don't do that agile suggests isn't usually worth doing is writing lots of specifications and documentation beforehand.

It's easy to see the flaw in many failed implementations

Is it also also easy to correct the flaw? I don't mean to blame Agile practices. It could be the case that Agile is a bad fit to some "corporate cultures" or certain project type and the result of someone pushing hard its adoption is to have some practices really used and other only in appearance. This could be what people hates.

OK. that would not be "True Agile", but what difference makes for the poor guy that's forced to play a part?

Edit: I've had Scrum in mind all the time when writting "Agile". Sorry.

Re: Agile Ruined My Life

#123
post #21
post #2

Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally…

Being Agile has become a fad off late. This has led to team adopting agile blindly doing things without understanding the reason or need behind it. This could lead to frustration mentioned by you involving a lot of long ass meetings standing. I believe as mentioned in the article that Agile is a set of best practices followed by a ever adaptive team. I completely agree there is in no ONE TRUE WAY.

We implemented it because one of the teams we work with implemented it. The big difference no one cared to notice was that they work in terms of iterative builds of a huge application that they determine the timescales of, and we work on learning products that have prescribed deadlines, sometimes down to "this needs to be done this afternoon for tomorrow morning".

We were still forced to estimate the effort of something that we knew had to be done the same day, and it was to be done by the person who had free time, no the person who it would be the least effort for.

No surprise it was a completely hollow experience.

Re: Agile Ruined My Life

#124
post #102
post #62

Earlier quoted context omitted.

The marketing speak is often useful when one needs to sell ideas to management who might otherwise default to waterfall. I can tell not many here have been in that situation or there would be more appreciation for the utility of branded ideas.

Has anyone ever used the waterfall model in any other capacity than to blame it?

Of course. Most software was developed using that model. I think most software is still developed that way, actually, but most people on HN are more likely to be using new techniques.

I also think this is the model that is still taught in most Universities.

Re: Agile Ruined My Life

#125

As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away. I don't want to be sold a product. The fact that it led people to t…

But you can't call it "Good practices for software developement". Over the years, that term has shifted. 30 years ago it meant the Waterfall method of analysis, 20 years ago it meant OOP, and 10 years ago it started to mean Agile.

Hopefully, we actually are getting better at developing software. But don't think for a minute that what you call "Good practices for software developement" is something trivial, that was known all along, and that you'd have to be an idiot not to do anyway.

Re: Agile Ruined My Life

#126
post #2

Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally…

there is a lot of anger towards the agile movement because it was sold as a tool to pointy haired bosses to impose, rather than a grassroots movement among engineers that embraced flexibility.

the interesting thing is that the agile movement started as exactly the reverse of what you said: as a grassroots movement among engineers that embraced flexibility, not a tool to pointy haired bosses to impose.

If your experience is the opposite, you've been had by someone, and you're blaming agile.

whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true

The reverse would be "anyone doing unit tests in incompetent", which is not a defendable statement. What are you trying to say?

Re: Agile Ruined My Life

#127
post #57

Earlier quoted context omitted.

No, discovering that is market research. I don't see how McMethodologies help there.

That sounds like an assumption that everyone's in the business of selling software. I'm certainly not.

Are you in the business of writing software that never gets used? I have, and I hated it. Quick feedback means quickly finding out if you're building the right thing.

Re: Agile Ruined My Life

#128
One thing I've noticed with Agile projects at $work is that the processes better suit a "contractor" mindset, than a "fulltime employee" one. NOTE: I'm a fulltime employee, so view things from that mindset.

As a contractor (in theory), you're bought in to do a specific job, and then you leave - get done, get paid, get gone. This works well with Agile, where you can devote your entire attention to the project, and not get caught up in other things.

However, fulltime developers will find it more difficult to devote all their time to a project, as they're likely to still be maintaining some of their previous projects as well. In smaller organisations, you often end up being the go-to person for part of the system, and the rest of the business may struggle with these people being out of reach for weeks or months.

Another factor is that contractors have less reason to care about existing code and its design principles when designing and implementing a new project, and well as less reason to care about the maintainability of it. This leads to the software platform having a melange of different styles, further complicating the lives of those who have to support it later on.

To me, Agile just seems like contractor culture converted to religion.

Re: Agile Ruined My Life

#129
post #2

Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally…

Wow, it's pretty surprising to see such a rant get so many upvotes. Your rant is about a bad company (good on you for quitting) but it has nothing to do with Scrum.

You're right that there is for sure no "one true way". For me, I like (the parts I use of) Scrum because (a) it puts a low limit on how long a project can veer off track without anyone noticing (i.e. you can only lose SCRUM_LENGTH time at once, not years) and (b) it puts up a wall that stops business from just coming over interrupting me everything some bright idea pops in their head (they can do this if they wish but it means canceling the current scrum. Usually this is enough to make sure they don't do this for trivial stuff).

Maybe one reason I like it is because I'm the kind of person who always sees "rules" as guidelines, not things to be followed rigorously in all cases.

Re: Agile Ruined My Life

#130
post #39

Earlier quoted context omitted.

The gaping vulnerability in the traditional ad-hoc waterfall approach is management is constantly interrupting work in progress and changing the priorities, then wondering aloud why nothing ever seems to get done. Agile is certainly worth the bureaucratic hassles it adds because agile protects developers from the tyranny of ever-changing priorities. At the start of each iteration (every 4 weeks or so) the management…

This can be solved simply by explaining to your management that Change == Things Will Be Late. If your management can't understand this, then it's unlikely that they'll be able to commit to Agile, anyway.

But using Agile allows you to show this in concrete terms. Waterfall uses the "man hours/months/years" metric which is useless given the difference in productivity between developers. Agile, on the other hand, shows the output that is occurring on average, i.e. what you're realistically going to get.

What I tell people is: what do you want? Do you want to never be told no, but never get what you were promised? Then use waterfall. Do you want to usually get what was promised, but be told you can't have what ever you want? Then use Scrum.

Post reply on HN