Hacker News Reader

Comment by xedrac | Hacker News Reader

Scrum is the bane of my existence as a developer. It sucks all creativity and enjoyment out of software development, and replaces it with anxiety, shame and mountains of tech debt. And don't get me started on the velocity metric that so many managers can't seem to live without (see Goodheart's Law). For whatever reason, I'm 10x more productive when I have the autonomy to bounce ideas off my team and proceed in the best way I see fit.

View on HN

Next time someone tells me at a job interview that they use "scrum", I will ask them two questions:

1) do you have retrospectives, and what typically happens there?

2) have you ever changed anything, as a result of the feedback given by developers at the retrospective? please provide a specific example.

If they say "no" to either of these questions, it is the bad kind of scrum.

If they say "yes", and give any non-bullshit answer to the second one (for example "we had 2-week sprints but then developers changed it to 3-weeks" or vice versa; the exact details are not important), it has a chance to be the good kind of scrum.

If someone says "we don't do retrospectives, because they are a waste of time", they are kinda right, but for the wrong reasons. The retrospective is where developers provide feedback about the process, and can choose to change it. If you have a strictly top-down managed company with zero developer autonomy, in such case having retrospectives is indeed a waste of time, because no matter what the developers might say, nothing ever changes as a consequence. But that doesn't mean that the retrospectives suck; it just means that the company sucks.

> I'm 10x more productive when I have the autonomy to bounce ideas off my team and proceed in the best way I see fit.

Why would scrum be a hindrance to that? I don’t know if any principle, artifact or event that is there to reduce team autonomy or to prevent the team from bouncing ideas of each other. And it seems scrum is intended to let the team procede whichever way they deem best.

I don't think it's scrum that's the problem. I used to be a big proponent of it when it came about. But in those early days of agile there was excitement that we were gaining this control over our own development process. That was never going to really happen. The company I worked for was doing development work for government and started pushing agile as a way to do it, eventually transforming itself into an agile consultancy. It pains me to look at the profile of people I worked with back then, great people, who now just peddle what I consider bullshit. Anyway for myself I no longer do any of that, just dev work, and I've been on good and bad teams. The process doesn't actually make a difference.

Just like there are companies who say they are Agile, but they are not, there are teams who think they have Scrum, but it is not Scrum. If you say that Scrum encourages tech debt and you had no autonomy then probably it wasn't Scrum. The other option is that you were using Scrum where it doesn't fit.

By Pareto principle: 80% of times when I see "The tool X sucks" it is because people are using wrong tool or they are using tool wrong.

We can debate the purity of scrum, but in practice, every company I've worked for has modified it to suit management desires, and those modifications have almost always been to the detriment of developers. For example, the "complexity" of a story is inevitably interpreted as "time". And the end of every sprint is often turned into a deadline that leads to tech debt. Creative development is not always a linear process, which scrum somewhat enforces. I think it could work if every story was treated as a spike, and every spike could be pre-empted by new spikes as you discover new things. If it was able to truly flow the same way software devs actually think and work, then it could work. The result of a spike could be a finished work, or perhaps many other spikes. This would model creative development better. But companies don't go for this because they cannot easily estimate time and schedules.

> but in practice, every company I've worked for has modified it to suit management desires

I agree that is the way it is often, but that is to the argument to the poster before: not SCRUM anymore.

I know what you are talking about, but those are the things I would never agree upon. This is against scrum, against agile. Where I can agree that scrum is not always the way, I truly believe agile is how software development should be done, so I can't even count how many of conversations about it I had with all those managers. Outcomes were two: they agreed to change and project was successful in most of the cases or I quit and project failed in most of the cases, so my experience is only strengthening my views over time.

Once I worked in a team that used scrum almost correctly, and it was a great experience.

Then there was a change in management, and the new manager decided to "introduce scrum" to the whole company. We were told to stop doing what we did previously, and instead to do what the new manager called scrum. Unsurprisingly, it was the same parody of scrum that most companies use. The productivity plummeted, and the developers in our team gradually left the company.

I suspect that scrum works well when it is introduced by the developers, and works horribly when it is introduced by the managers.

The only thing that worked for me when fighting managers as such was to expose where they are wrong about scrum and/or agile. Foursquare, boldly, without emotions. Speak up guys, you are paid to be experts, share your expertise with the org.

I was told this once by a scrum trainer when I told him it sucked. I then challenged him to figure out which part we were doing wrong. He couldn't coz we pretty much did it to the letter - following the directives from another scrum trainer.

I call it the no true scrumsman fallacy.

Doing it "properly" means doing a series of mini waterfalls. Thats just how it was designed.

I'd say it functions as a poor but semi functioning compromise between an intransigent waterfall management and an agile team.

People like you who complain about scrum often complain about things that are not part of scrum. Velocity is never mentioned in the scrum guide for example. What you describe is nothing like scrum.

In my daily work life, academic discussions of "what is scrum (or whatever)" isn't of practical value. What matters is what your employer is requiring you to do. I have yet to work at a company that uses agile methodologies in a manner that doesn't effectively torture devs.

I'm not saying such companies don't exist, only that I've never personally worked for them.

I use "agile" as a filtering term these days. If the job description mentions being an agile shop, I know that job isn't for me. If they use agile principles but don't advertise it, I want to see what the process actually is before deciding to accept the position.

I think you are missing one thing: why do you allow managers to say how to develop software when you are hired to be an expert on that matter? I know, I know, it is convenient to not to take responsibility and just complain, but that would be so frustrating for me that I couldn't take it. And, yes, in my experience I saw many times where people who are not experts say how something should be done, for example they say "refactor is not needed" or "tests are too expensive". In that case I ask them one simple question: "how many contributions to the codebase you made last month?" The answer is usually silence. If they still oppose I just quit the job and watch the project fail from my colleagues' reports. Simple as that.

> why do you allow managers to say how to develop software when you are hired to be an expert on that matter?

Because at most companies, you have a simple choice: follow the prescribed procedures, or work somewhere else. I have absolutely quit jobs that were too egregious, but that doesn't change the situation at that company.

Maybe losing valuable people is not affecting company straight away, but it surely affect the project. And with few project failing miserably (as they will if you do corporate waterfall) something might change. If not, then the whole company might fail. Remember, companies compete with each other, it just takes more time for some to fail.

It is important if you want to fix it. If you think scrum is the problem, then changing scrum to something else might appear to make sense. However if the problem is not in your framework but with tangential organizational goals then it won't matter which framework you use. I'd say that's pretty relevant to discuss.

Reply on news.ycombinator.com