Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm not a big fan of Scrum

okigiveup.net

Post reply on HN
Print view View original

121–130 of 387 posts

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

#121

Post by afroisalreadyin »

shepbook wrote: post #84
afroisalreadyin wrote: post #70

Earlier quoted context omitted.

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

I feel much the same way as much of what you've said in this post. I'm curious what you think of things like the #NoEstimates camp that removes the ambiguity and "gut check" nature of things like points or even time estimates?

I read the first chapter of the no estimates book, and have to admit that I found it weak on arguments and poorly written. I think there is real value into doing software estimations if you take them seriously, even using story points, but there must be better ways of using those estimates. One really interesting way of doing this is the Monte Carlo estimate method I linked to in the blog post. Would love to try that sometime, and see how it works out.

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

#122

Post by lmm »

tener wrote: post #93
lmm wrote: post #68

Earlier quoted context omitted.

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

Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.

Design is better when it's informed by implementation, IME. The only complete specification is working code; if you accept something lower-fidelity then it's very easy to miss ambiguities.

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

#123

Post by dasmoth »

timwaagh wrote: post #76

managers like it. control. results. evaluation. they get to treat programmers like laborers. programmers don't really have anything to gain with it. what surprises me, is that sometimes programmers ask for it. it illustrates how strong the desire is to follow the latest trend.

>>> what surprises me, is that sometimes programmers ask for it. it illustrates how strong the desire is to follow the latest trend.

While I'm far from a Scrum fan, it's not necessarily the worst thing in the world. For instance, it's probably better than "just do what the project manager says", especially if he tends towards micromanagement. And double-especially for people who thrive in group discussions but have trouble managing 1:1s.

I suspect the trades also look different depending on level of experience. Scrum, at least in some incarnations, tends to be quite egalitarian, so I can see it appealing to more junior devs in environments where they feel the seniors get to do all the interesting stuff.

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

#124

Post by VLM »

nxzero wrote: post #9

Maybe it's me, but the real issue with professional scrum masters is that it's rare to find any that practice agility as a way of life. Majority of professionals I've met appear to lack any ability to improvise and literally just follow the book on what to do without any critical analysis of how their situation fits with the defaults provided. Basically, my issue with scrum is its community.

Superficially the google term you're looking for is "cargo cult"

But how to fix cargo cult depends on the root cause and there are many:

1) Authoritarianism, my boss said read this book, this book said XYZ, therefore XYZ is true. How could the book possibly be wrong? Or for book, insert rockstar ninja consultant or training class or whatever.

2) Religious belief, sure none of this makes logical sense but if you have blind faith and are not one of those apostates, it'll work just fine. Just relax and perform the ritual.

3) Deep game, where we actually run on anarchy or waterfall but someone needs XYZ on their resume so superficially we've skinned it as XYZ. Dig enough and you'll find what really runs the place is something else.

4) Blame games, a large part of management is how blame is distributed, not just distributing work, and when a subgroup who thinks they're agile-ing to distribute work comes in contact with a group using agile mostly to distribute blame or to stall for time or just to goof off on company time, its kinda like matter-antimatter.

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

#126

Post by specialist »

cechner wrote: 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."

More like wandering in the desert, hoping you find the promised land.

Been thru scrum master training 3 times, been on many "agile" teams. I've never heard this rationalization. Rather, a common justification for "agile" was you always have a working product. Which might be nice if things worked out that way.

Also, PMI style critical path worked just fine for figuring out that "straight line".

Scrum and "agile" democratized project management, empowering every poseur to claim expertise and ability. Whereas PMI required real effort to learn and master, Scrum flavored "self help" books can be flipped thru before you finish your coffee and then safely stored in plain sight on a book shelf, never to be touched again, allowing said poseur to claim the daily mutant chaotic dysfunctional mismanagement that they've always done is now "agile".

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

#127

Post by bbarn »

cechner wrote: post #3
cechner wrote: 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…

oh and I have attended some of those expensive Scrum 1-week courses and saw the darker side of that community - it definitely has a cult following that give it a bad name, but I've been to similar conventions around design patterns, object-oriented and (to a lesser degree) functional programming so I think that the community problem is not particular to Scrum.

Those with the loudest voices simply have the loudest voices, be they right or wrong.

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

#128

Post by humanrebar »

lmm wrote: post #118
humanrebar wrote: post #105

Earlier quoted context omitted.

> You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and r…

> I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7". Which may well be the right choice for the business at that point. More generally, it's…

You misunderstand. If more than a small minority of your code cares what OS it's running on (beyond obvious excepted), you have a large amount of technical debt. Cleaning that up, either by refactoring or replacing the offending code, is in the business's best interest because it keeps costs down and keeps more options available to the business.

The 'business people' are not qualified by themselves to say that the cost-benefit analysis of the refactoring is worth the effort. Because while they may have a good idea of the customer benefits, they generally have little insight into what the future costs of technical debt are. You see this obviously demonstrated by 'business people' who are shocked that there is work to do on five-year-old code that has been working fine for years. Any reasonably experienced developer, any many junior developers besides, can tell you that code rots if it's not maintained properly.

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

#129

Post by lmm »

fsloth wrote: post #116
lmm wrote: post #68

Earlier quoted context omitted.

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

"The user-facing design needs to drive the API interface, not the other way around." I don't see how this need would nullify the ability to modularize code.

Modularize by functionality, not by layer. Start with a simple end-to-end path and grow outwards, rather than trying to go top-down or bottom-up, and don't split into distinct layers until you're actually deriving value from doing so. Writing code when you don't have the use case yet is always a bad idea.

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

#130

Post by gedy »

maxxxxx wrote: post #22
cageface wrote: 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".

TBH this is what I've always assumed it should be from day one with Scrum, after training with Ken Schwaber etc. The backlog is not a Todo list.

It's the only way that seemed sane without twisting user stories into weird refactoring or architecture stories and keeping team from writing garbage code waiting for these "tech stories" to clean it up.

Post reply on HN