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

111–120 of 387 posts

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

#111

Post by fsloth »

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

In a non-broken organization technical leads (or equivalent) have same level of authority to guide development as feature driven personnel and the necessity of features vs. quality can be triaged in bright daylight.

If the organization is not sane, that's another thing of course (and often the case, sadly).

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

#112

Post by discreteevent »

afroisalreadyin wrote: post #70
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…

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

"Lean" is supposed to address quality and habitability more. 2 of the 7 tenets of lean focus on it:

Build Quality In

Optimize the Whole

I've never practiced it and my only exposure has been reading some of the book "Lean Architecture". But it certainly seems like an improvement over Scrum which seems blind to some of the most critical things in developing complex innovative systems. In fact I'm convinced that Scrum was designed to work with basic information systems where a feature consists of essentially adding a new data entry form or report for a database (e.g. a lot of web stuff)

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

#113

Post by Ntrails »

taneq wrote: post #49
tomelders wrote: post #26

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.

I will always blame whoever most recently left for everything. The rain, the chair being broken, the mouldy cream cheese in the fridge.

No jokes. It's Brads fault.

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

#114

Post by VLM »

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

OK medical in general, obstetrician in specific. Or perhaps dentist. Certainly the whole pathology sector.

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

#115

Post by cheriot »

Keep in mind that Scrum was designed by consultants working for organizations that don't understand software development. So they designed a process that can make sense to people outside our industry. In order for it to go well, though, the person running the Scrum process needs to know how shit really works. This is rarely the case.

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

#116

Post by fsloth »

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.

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

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

#117

Post by beerwulf »

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.

Sounds like you've never worked in a shop where they think "agile" == "no need to plan ahead"

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

#118

Post by lmm »

humanrebar wrote: post #105
lmm wrote: post #75

Earlier quoted context omitted.

> I see this in particular with old but stable subsystems that will need to be ported to new environments someday, but it's never a good day to lay the groundwork for that inevitable change. I think it's correct to defer that work until you need it. You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. As and when porting becomes an actual busines…

> 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 not like doing it now makes it faster than doing it later: you have to put the same amount of total work in either way. In fact you have to put more work in if you do it now, because you will have to ensure that any subsequent changes don't break the porting. If you have other tasks that are a higher priority than porting, you should do them first, almost by definition. Of course if the port is your highest priority then that is what you should be working on (again almost by definition). Porting should be left as late as possible, but no later.

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

#119

Post by specialist »

deejbee wrote: post #56
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…

This sounds like more of an issue with technical debt management. I'm much more of a proponent of Kanban, whenever possible, so in this case if a user story requires a refactor or architectural change then that's just fine. Also regular code reviews to eliminate hacking and sanity checking automated tests shouldn't be made optional, they should be actively encouraged by the team leads and dev manager.

Kanban is the software development equivalent of the Concentration (Memory Match) card game.

https://en.wikipedia.org/wiki/Concentration_(game)

As though a useful, usable product design (architecture) could be divined thru piecemeal revelation.

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

#120

Post by Noseshine »

deejbee wrote: post #56
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…

This sounds like more of an issue with technical debt management. I'm much more of a proponent of Kanban, whenever possible, so in this case if a user story requires a refactor or architectural change then that's just fine. Also regular code reviews to eliminate hacking and sanity checking automated tests shouldn't be made optional, they should be actively encouraged by the team leads and dev manager.

    >  if a user story requires a refactor or architectural change then that's just fine
Those clear cases are not the problem since they are... clear. There is a lot of need for refactoring that arises only slowly and not through one feature. It's more like the boiling frog thing (which by the way is a bogus story but I still use it nevertheless because everybody understands the point). So a problem is you can never really justify the refactoring effort using one specific new feature. It's like partial vs. full cost accounting, sometimes you just have things you can't break down but it still needs to be done (paid). Which makes this a real problem for organizations who don't have the accounting set up for this. In my experience especially large firms may have teams that get their budget "per feature", so even the best manager can't solve that problem - the next (management) layer above doesn't care though because your little software team is too small to get them to laboriously change the accounting process and the SAP system.
Post reply on HN