Why I'm not a big fan of Scrum

I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning. But to get a feature out quicker, no. If anything, it seems to me that writing bad code requires more time than writing clean and elegant code.

In the end, "technical debt" becomes a way to shift the blame from your own (the team's) inadequacy at planning, designing and developing, towards supposed time constraints that always lie outside of the team's responsibility.

Scrum is a system of managing people, not a software development methodology.

It's about transforming programmers into cogs and gently forcing them to obey certain rituals every day, until they slowly give up their individual creativity and initiative and become good 'team players' .

And when someone says 'team player', I hear 'you belong to us now'.

I disliked scrum since the moment it was decreed upon our team.

And that's because pretty soon our team became obsessed with points and respecting the religion rather than doing the actual work.

The final drop came when I refactored some code, made it twice as fast using half as much memory (the proverbial 'much better'), only to have to fight the team to accept the changes, because that wasn't in the backlog.

Methodology is only good when it helps you achieve your goals easier and faster, safer, etc.

But when the methodology becomes the goal, then your job changes into satisfying the methodology, rather then being the best at what you like and enjoy.

And this is the exact status quo that larger organisations love - people focused on small irrelevant tasks, while the 'grand scheme' is determined by management.

Not for me. I use certain parts of it in my work today (develop in sprints, demo at the end of sprint, planning, backlog and current tasks), but if I see "we use scrum" in the job description, then I'm not your man.

Story points are a measure of "relative amounts of effort". A 2 point story is twice as hard, as far as effort to implement it than a 1 point one.

> Scrum meetings (aka rituals) have been among the most miserable hours of my life...

Would you rather have many meetings almost every day, or a single big ol' meeting every few weeks so you can focus on coding without interruptions?

> The review meeting causes utterly unnecessary anxiety (Oh my god, will my feature work?)

It should not cause anxiety because it MUST work. The review meeting is to show stakeholders a "potentially shippable product increment". Everything you show on the review meeting should have been extensively tested already.

> Why estimate stories that you are going to break down anyway?

You only break down stories if they are too big. You are not supposed to work every detail on a planning meeting.

> but in Scrum, the retro is explicitly supposed to be about the Scrum process itself, not about the codebase

The retro is not about the scrum process but about how it is working for the team. All these issues you have already complained about should be reserved for this meeting where the whole team can decide which adjustments to make.

> The main goal of Scrum is to minimize risk and make sure the developers do not deviate from the plan. I will come back to "Scrum controlmania" later.

It is regretful that, like all the other "why scrum sucks" posts I've seen on HN, it all boils down to a bad scrummaster not managing expectations and taking the time to explain where the process really comes from.