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

91–100 of 387 posts

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

#91

Post by matthewmacleod »

UK-AL wrote: post #55
hidro wrote: 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 have never seen a new Scrum team member (including me) getting it at 1st try." - I've never seen one get an accurate time based estimate either. Even experienced ones.

That's one of the reasons that Scrum doesn't use time-based estimates.

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

#92

Post by crdoconnor »

richardwhiuk wrote: post #67
crdoconnor wrote: post #63

Earlier quoted context omitted.

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

In my experience, once it becomes a tracked metric that can be used to destroy a manager's career you can bet the dial will start to move.

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

#93

Post by tener »

lmm wrote: post #68
thackerhacker wrote: post #52

Earlier quoted context omitted.

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.

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.

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

#94

Post by afroisalreadyin »

mms1973 wrote: 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 is also what I see the best-led companies do, not caring about what is Scrum and what it is not, and taking the pragmatist path. One thing I really regret at my current job is missing the Kanban workshop. It definitely appears to be much nicer.

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

#95

Post by zelos »

humanrebar wrote: post #28
thefastlane wrote: post #10

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

I don't think those are all that true of software in general. Most software isn't particularly new: how many "Yet Another CRUD app" projects are there? And with software you can ship a percentage of the features and add more later, unlike (say) hardware manufacturing, civil engineering, chemical engineering or architecture.

Maybe software is reasonably different in that there are a lot of management level people with little technical knowledge of how the work gets done? I don't know how that compares to other similarly technical industries.

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

#96

Post by crdoconnor »

mirekrusin wrote: post #87
crdoconnor wrote: post #63

Earlier quoted context omitted.

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…

For most companies static 100% image would do for this dial.

Only if it's untracked. If it's tracked and the responsibility of management it'll go down.

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

#97

Post by matthewmacleod »

thefastlane wrote: post #10

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.

I am just baffled by the assumption that such practices only exist to piss off engineers.

I do a bit of planning poker with my team every couple of weeks, despite being a pretty experienced engineer, and it's great. It's been good at exposing assumptions or concerns that members of the team have, or about confirming that everybody is on the same page wrt. what the complexity of a particular task is likely to be.

I reckon that more groups should be doing this, and not fewer.

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

#98

Post by dasmoth »

cechner wrote: post #60
dasmoth wrote: post #24

Earlier quoted context omitted.

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

I agree, it is often not the best approach. But many situations demand a well defined approach to estimation and although the OP tried to preempt this, he didnt provide an alternative

I reckon most experienced coders can cope with estimation when it's justified (i.e. "can we realistically get this done before ? And if not, is there a useful subset we can manage?"). The bigger problems come when estimation isn't about keeping promises, but rather a part of some form of scientific management aimed at "getting velocity up".

There's also something of an uncertainty principle here -- more precision of estimation is possible, at the expense of increased expected timescales (partly due to padding, partly due to picking lower-risk approaches).

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

#99

Post by gearhart »

crdoconnor wrote: post #63
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…

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…

When I read this I assumed you meant a dial that represents the current level of technical debt, rather than a dial that represents how much technical debt you're allowed to accrue.

The other interpretation might be a neat solution. Allow developers to indicate publicly what proportion of the time their last tasks took, they should have taken had there been no technical debt. It would handle the communication from developer into business-speak pretty effectively.

Post reply on HN