[kylnew]

Do devs really hate agile? I’ve really enjoyed it in workplaces despite it not always being perfect. I’ve never felt micro managed either, just regularly managed. I understand that maybe some want more free will to pursue problems the way they feel is right, but it’s a job at the end of the day and you are a human resource being paid to deliver results. Make sure you’re being compensated enough, at least to not feel like you’re being exploited.

[randomdata]

Absolutely. We adopted 'Agile' a little over a year ago and the perverse incentives carried with it brought a markable decline to the quality of the software being produced. We've made strides in righting that ship by returning to proper software development planning methodologies to build good software again (the results we're being paid for), but at the expense of angry PMs who don't see it as fitting their Agile system, which makes for an unhappy work environment.

Shame too, as this used to be a really great workplace.

[dudul]

The part I really hate about Agile is how it almost encourages "sloppiness" in requirements (execution too sometimes, but requirements is the part that really drives me crazy).

You need to always be "sprinting". There is no time to take a step back and think deeply about the product you are trying to build. No time to think through what a new feature means for your customer and for your existing system.

How often do you work on tickets that are completely ironed out? All the actors of the feature are described, all the interactions with their outcomes, all the things to test for, all the new metrics to add to the system?

And don't hear me wrong. It's probably the right MO for small companies/products. But once you've reached a certain size for the company, the system and the user base, it's not gonna work. People often laugh at how long it takes for Twitter to introduce a minuscule change in their product, but seriously, I wish a lot of "agile" companies would apply this extreme instead of the completely opposite side of the spectrum: "just start coding this shit, and we'll figure it out later".

[mathieuh]

I hate it. Constantly being pressured to move some stupid card or add some stupid tag so people’s graphs look nice. I just want to get work done, Scrum just adds overhead.

[cc81]

How much overhead is it really? 15 minutes a day at most?

[pjmlp]

Not if you have the misfortune to be a single developer project or having a lead role on a team.

Someone needs to convert those Jira/Trello/Wall/... items into nice Excel sheets because upper management won't look at anything else.

While you are at it including some nice Powerpoints for the weekly/monthly updates.

And on the remaining time do those development tasks, while coaching junior devs at the same time.

[mdorazio]

If you have a lead role on a team the large majority of your time should be leading the team by doing all those non-development tasks. If you're trying to also cram in mission critical development you're trying to do too much or your company's leadership sucks. If it's a single developer project, 1) Agile might not be the best approach, and 2) updates to management should take very little time since you just need to sum up what you personally have accomplished and are planning to accomplish vs. whatever deadlines exist.

[pjmlp]

That's the nice theory and then there are the actual real life projects, hence why we reached the point discussed on the linked article.

[mdorazio]

Yes, that is the nice theory and also the nice real world. And yes, I've been on and managed dozens of projects at 10+ companies over the last decade so I feel confident saying that. Sounds to me like your company's leadership just sucks. That's not a problem with the methodology.

[rawoke083600]

yup ! just let me solve interesting problems... stupid tickets ! lol and then you get plugins like "everyhour" so you know.. they can track... EVERYHOUR !!

[devonkim]

The advantage I do see for Agile is in shops where management is justified in their belief that developers are being over-cautious as well as too relaxed - this is exactly the atmosphere in many low-throughout software organizations I’ve seen in lots of old, non-software companies. If management is fine with lowering quality in favor of more shinies, Agile is pretty alright - it is Worse is Better codified and institutionalized. If the codebase is so bad it is impeding your ability to deliver business results, you do have justification, but time boxing efforts is important to avoid going down rabbit holes of endless refactoring.

I think most of the developers that are hating Agile are probably more disgruntled with their organizations and their culture (usually hostile to high quality engineering in most places fundamentally) than Agile itself. In a way, I think Agile (similar to a lot of automation efforts in infrastructure / IT processes I’ve worked on) simply brings out the true nature and culture of who is driving, who pretends to drive, and where things are falling apart in team dynamics. The software is usually a casualty of bad dynamics is the implication, not bad team members, but we all know this is not true.

I think the #1 thing that is missed is that the implementing team should have more control over what they work on. Someone writing a bunch of tickets and pointing them out alone reduces team ownership / responsibility and is pretty much how traditional Taylorist work models are built. Agile is fundamentally much more in line with Deming’s ideas giving much more control to the implementors and that is antithetical to at least 80%+ of businesses in the West and probably Asia too.