Live data from Hacker News

Why I'm not a big fan of Scrum

okigiveup.net

11–20 of 387 posts

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

#11
post #5

For our dev team Scrum works fine, the key is to use it just as a framework, and not following every rule to the letter. For example: - Obsession with points We don't have that obsession, sometimes we even don't assign story points, just hour estimates - Meeting extravaganza - Again, for example remote people don't need to attend all meetings, sometimes we just clarify the work items outside the meetings. - The sprin…

Using time instead of points breaks the whole concept of sprint-based estimation which Scrum tries so very hard to defend. Basically Scrum claims that software developers can't estimate based on time so it forces them to use an abstract number instead. Over time this would lead to being able to estimate a project in sprint-sized blocks.

This is why sprints have a fixed duration, the sprint backlog should not be changed, stories are awarded the full points or 0 during review, commitments to finish the sprint, etc.

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

#13
post #5

For our dev team Scrum works fine, the key is to use it just as a framework, and not following every rule to the letter. For example: - Obsession with points We don't have that obsession, sometimes we even don't assign story points, just hour estimates - Meeting extravaganza - Again, for example remote people don't need to attend all meetings, sometimes we just clarify the work items outside the meetings. - The sprin…

[deleted]

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

#14
post #5

For our dev team Scrum works fine, the key is to use it just as a framework, and not following every rule to the letter. For example: - Obsession with points We don't have that obsession, sometimes we even don't assign story points, just hour estimates - Meeting extravaganza - Again, for example remote people don't need to attend all meetings, sometimes we just clarify the work items outside the meetings. - The sprin…

Sounds like you are doing "scrum but" aka your own methodology.

However their article is criticizing pure unadulterated scrum.

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

#15
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.

Scrum is actually part of the problem, IMO. I've seen many teams turn scrum into a hammer and treat all future problems as nails.

Example problem: The foobar story has failed failed for the third sprint in a row.

Likely discussed in retrospective (plausibly good ideas, mind you):

- We need to break down stories more before we estimate them.

- Or we need to stop underestimating foobar stories.

- Or we need to focus on unblocking subtasks related to foobar stories.

Probably unconsidered:

- The foobar code is a mess and needs to be refactored.

- Or the foobar subsystem is too coupled to the Fizzbuzz subsystem.

- Or the need for some developer tools to increase productivity in the foobar ecosystem.

Since scrum is methodology oriented, methodology is the first tool teams reach for when a problem is encountered. And I see this after team leads make it explicitly OK to discuss technical subjects in retrospectives.

I'm not a psychologist, so I can't describe why this phenomenon happens, but I see it regularly.

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

#17

After I read this complain-based article, my only question for this author is what's your fix/suggestion? Otherwise, I don't get what the point of this guy write this article.

Deconstruct Scrum and perhaps something like RUP/DAD (Scrum doesn't tackle the whole lifecycle) into components and understand what the purpose of each component is.

Start from Kanban and add stuff until you get a process that matches the critieria of the organisation.

This requires a lot of skill though, so many teams are stuck with one-size-fits-all tools like Scrum, especially now that it's become a management buzzword. And it does a not too bad job at delivering somehing of passable quality not too late. :)

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

#18

After I read this complain-based article, my only question for this author is what's your fix/suggestion? Otherwise, I don't get what the point of this guy write this article.

Describing drawbacks and problems is value added. Theoretical physicists regularly know about problems for decades before solutions are found. Precisely describing the problem can get the intelligent diaspora organized around finding improvements to the situation.

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

#19
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…

This kind of tweaking is frowned upon and you will be chastised for doing it.

Yes you can do it (and probably should when you understand the purpose of each Scrummy practice), but don't expect to be praised by Scrummers.

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

#20
post #5

For our dev team Scrum works fine, the key is to use it just as a framework, and not following every rule to the letter. For example: - Obsession with points We don't have that obsession, sometimes we even don't assign story points, just hour estimates - Meeting extravaganza - Again, for example remote people don't need to attend all meetings, sometimes we just clarify the work items outside the meetings. - The sprin…

I'm a designer and my experience with small scrum teams has more or less been the same - a lot of the issues are handled by developers who are given some agency to self-manage and who are half-decent at doing so. I've only worked in one environment that was true scrum, and I don't know if it was the process or the organization — but it felt so overly boxed-in.

The last point has been the biggest one for me. Across multiple organizations working in the scrum process I've occasionally felt like just getting some time to talk to developers for future exploratory work is like pulling teeth because the scrum process relies so heavily on tangible tasks. I think that's a time management thing that has to be established with teams ahead of time — like "hey 80% of your week are these tasks, but you have 20% set aside for research/discussion'

Post reply on HN