I would have guessed more HN readers would attempt to understand the desired outcomes, how the implementation attempts to achieve them, then take the good from the bad as a source of constant improvement.
The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
I'll be the first to admit that managing a complex project's timeline is not a skill of mine. All I know is that the franken-scrum monstrosities that I have been subjected to in various organizations have all had a very negative impact on my morale and productivity. The problem I see is that the the business will want to make tradeoffs that the developers may not like. How you reconcile the two without hurting morale is the challenge. I left my last company largely because their version of scrum was sucking the life out of me.
My problem is not whether I “like” management’s tradeoffs they force me as a developer to make; my problem is that managements typically don’t take accountability for choosing to make them.
And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.
> then take the good from the bad as a source of constant improvement.
I worked as an engineer, PM, and a manager, when I was an engineer and scrum was applied wrongly, I tried to communicate for that “continuous improvement”, but that only works with an actual leaderships that listen, 99% of your middle management are just power hungry folks that are kept in their positions to take the shit instead of senior managements, when I worked as a PM however and tried to customize those agile tools per project and per team personalities too, everyone was happy, projects got delivered and things worked as expected. In 90% those situations you can never blame the engineers, look at the work environment as a workshop, the guy working in that shop is the PM and the tools are your engineers, ultimately that guy is accountable for the success or failure to deliver that work, if you start blaming the tools you have in the workshop, then you are the incompetent one, simply put.
I think Scrum done well works rather well but retrospectives tend to be a lie.
Teams generally aren't allowed to stop doing sprints. In some places they aren't even allowed to pick start and end dates because management wants all teams on the same cadence.
If you use Jira - there's often all kinds of stupid imposed workflows. Mandatory fields depending on ticket types etc. If it's not useful to your team - tough shit, you don't have a choice.
Want to stop doing story points and use tshirt sizes? You can't, management monitors velocity as performance indicator.
Once you've had a few suggestions shot down because of top-down mandates, why even bother with retros?
Basically, scrum is very frequently a top-down management technique and teams aren't actually self-organizing because management can't deal with 10 teams each doing things their own way.
Tried saying "this process sucks, can we do it better?". Was told that Scrum is what all organisations use, there's nothing else (except Waterfall), and that this is "best practice".
The people who are silent in the retros are probably jaded and cynical about the whole process. And if the manager knew their shit, they'd do something about that instead of accepting that some of their team are not engaged with the process.
I've spoken up in many retrospectives, but when nothing changes, it's hard to take them seriously. What's the point of a retrospective if your feedback is simply discarded?
I'm also very surprised by what the overall thread is saying.
Scrum and the agile movement in general have been a revolution for the better in management and organization, in my point of view.
The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.