Live data from Hacker News

Why I'm not a big fan of Scrum

okigiveup.net

61–70 of 387 posts

Re: Why I'm not a big fan of Scrum

#61
post #48

I like how Scrum promotes transparency and trains each individual to become self-managed (or at least getting better at it). But it often feels like it's being hyped up, with many people getting obsessed over its practices/rituals. Estimating work is a nice idea, but using 'story points' for it just feels like a bad API decision - I have never seen a new Scrum team member (including me) getting it at 1st try. And may…

I am a SM and a dev and it's not at all a comfortable position to be in, because it's often making demands on my time and there are conflicts of interest (but not as bad as SM/PO or SM/manager).

The SM is major piece of the Scrum puzzle and a lot of practices lose their value if the SM is not paying attention.

This over-reliance on the SM is a minus for Scrum IMO.

Re: Why I'm not a big fan of Scrum

#62
post #4

In my opinion, the good thing about Scrum is that you can tweak the rules to fit your needs, aka, "Scrum in name only". The daily standup, IMO, should be only to remove impediments, and if you have none, then a sentence or two will suffice. I see the DS as the most useful meeting, as you are aware of what your workmates are doing. And if Scrum is still a pain in the back, then you have Kanban, which is sort of Scrum…

If developers talk within their team, they should constantly be aware of what their workmates are doing.

If communication is a problem, having a daily standup just pretends the problem doesn't exist, rather than solve it.

Re: Why I'm not a big fan of Scrum

#63
post #7

I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…

One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board.

The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs).

Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a question "what debt/tooling issues caused you the most pain this sprint? and a parallel track for debt/tooling stories").

Re: Why I'm not a big fan of Scrum

#64
post #2

Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this article would detract from the general problem here: Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else If youre working on a project where it is important that you have as-accurate-as-is-realistic an…

>Scrum is not opinionated about the actual development methodology so claims about how it affects the code that is written are themselves a bad smell IMO. Pretty much every kind of deadline driven development ramps up technical debt. Scrum certainly isn't the worst in this respect (developers make their own deadlines, and conscientious ones will build the time in), but the emphasis on commitment and the pressure to d…

if pressure is ramping up and quality down the sprints arent serving their purpose.

One of the few defining characteristics of scrum is that the developers define how much they can achieve, and this estimation is improved over time. If this is not happening there is something else wrong with the culture and Scrum is being used as a scapegoat.

Re: Why I'm not a big fan of Scrum

#65
post #23
post #2

Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this article would detract from the general problem here: Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else If youre working on a project where it is important that you have as-accurate-as-is-realistic an…

I've seen the "you're doing it wrong" argument so many times (I applied it myself a few times). Scrum is complex and not always possible to follow exactly, so this is to be expected but it makes me wonder, how many successful projects are out there that are following the true Scrum methodology? My guess is that it's a few more than the classic waterfall but I still seem to see far more failure than success stories.

The very idea of a one-size-fits-all process is unrealistic IMO. Something will always be customised in practice.

Regarding success stories, it might be that process doesn't play such a critical role as long as solid engineering techniques are used and the team is competent.

Re: Why I'm not a big fan of Scrum

#66
post #49

Earlier quoted context omitted.

I leave my current role in just under two weeks for the very reason you describe. I'm tired of being the "difficult dev" that everyone has grown to hate. Let them launch. Let it fail. Let's see who the arsehole is then.

You, because the moment you leave you become that-guy-who-we-can-safely-blame. Mostly joking but plenty of places do work like that.

Yes, they'll blame him. It won't make sense for the most part, but it'll still happen. Probably largely things like "it only tomelders had worked with us more instead of being 'difficult', we wouldn't be in this mess", even if the 'mess' is precisely what he was advocating people work on before he left...

Re: Why I'm not a big fan of Scrum

#67
post #7

I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…

One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a que…

In my experience, you struggle to move that dial from 100%.

Re: Why I'm not a big fan of Scrum

#68
post #7

I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…

It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by the end of a sprint, even for quite complex, technical components. Why can't we make some sub-component this sprint then the UI bit the next? I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.

> Why can't we make some sub-component this sprint then the UI bit the next?

Because that's how you get bad UI. The user-facing design needs to drive the API interface, not the other way around.

Re: Why I'm not a big fan of Scrum

#70
post #7

I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…

Author of the post here, thanks for your comment. As you said, the fact that you have to stick out your neck and fight for code quality is very annoying, and after some time, one just stops doing it, and starts flowing with the "add the one more line of crap to get things working and collect the points".
Post reply on HN