Live data from Hacker News

Why I'm not a big fan of Scrum

okigiveup.net

21–30 of 387 posts

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

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

> The daily standup, IMO, should be only to remove impediments, and if you have none, then a sentence or two will suffice.

100% this. The only thing a synchronous team-wide meeting is useful for is revealing a significant issue and getting a prompt and definite acknowledgement from the team. And then, if it's a priority, some help with the issue. But given the proper tool, even that feature can be made asynchronous.

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

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

In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a "No".

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

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

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

#24
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 intended to be the straightest line towards measuring your real progress on a project, and not much else

There's slightly more to it than that: it also encodes an assumption that you're working with a single fairly-tightly-integrated group (with synchronisation points at least daily). It's possible that this helps with estimation and scheduling -- it's a lot less clear that it helps get the best outcome in other respects.

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

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

[deleted]

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

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

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.

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

#27

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.

He makes suggestions at the end, in the section "Ideas for Alternatives", after the sentence "The default answer to any substantial criticism is "What is your alternative?""

In summary, he suggests eliminating the review, planning and stand-up meetings (replacing them with asynchronous & as-required meetings), increasing the frequency of retrospectives, and spending time analyzing the backlog to see what the underlying causes are and tackling those.

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

#28

do we see bank analysts playing 'planning poker' when it comes to putting together pitch decks or research analyses? no. and they'd transfer out of any group where a manager tried to implement such a practice. if a software engineer is more than a couple years out of college, i don't think she/he should put up with it either.

> do we see bank analysts playing 'planning poker' when it comes to putting together pitch decks or research analyses? no.

Most industries (don't know about bank analytics in particular) are more personality driven and/or more repeatable. There are few industries that:

- make entirely new things on a regular basis

- are mysterious to laypeople

- cannot ship 50% of a solution and get 50% of the value

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

#29
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 just move new item from backlog to sprint and work on it." - This breaks traditional scrum estimating.

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

#30
I agree that there are individuals and companies who have defined such ridged structure and expectation into their Scrum method that they can no longer be considered an agile approach missing two of the key purposes of agile approaches:

* Individuals and interactions over processes and tools * Responding to change over following a plan

Now, I cannot say that Scum abstractly is a bad approach to attempting to be more agile. Many of us have employed some form of it with varying degrees of success, but, the expectations on software developers from a business perspective are more rigid for business development and tracability purposes, which can,on occasion, omit the consideration of resource demands and complexities.

Often, i believe, it is that a lack of understanding the purpose of the agile manifesto and the poor implementation of a method at the top level of the developer and managment ladder which is the underlying cause.

In the post, the author cites 3 hour or more meeting where he feels there are too many people there. This would be an item for the retrospective feeding the next iteration, but he only says "Blergh" about the needed feedback.

He states that the standup is more ritualistic, but the point is to ensure each member understands where the sprint stands, inspire collaboration, but really take ownership of the code. It could be that the team size is too big, or that the team really has not taken ownership of their code.

When all is said and done, you have to buy into the Scrum process, the process has to be flexible, and the stakeholders have to not believe it is a magical development method that fixes all the issues of the software development process.

Post reply on HN