Why I'm not a big fan of Scrum • Hacker News Board

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

#271

Post by pc86 » Mon, Aug 08, 2016, 5:35 PM UTC

joe8756438 wrote: post #142

I disagree with most of the major criticisms here. I think it is a valid description of an experience using scrum half-heartedly, but not an argument against its purpose or value. Points, for example, the argument is based on the premise that teams are obsessed with points. What if the teams use points as a framework to discuss complexity? I have worked in scrum groups where if something was given a large point value…

> Long meeting times with the wrong people in the meeting? That's a managerial issue and has nothing to do with scrum.

Even with two-week sprints the majority of your last day is entirely meetings between the review and retrospective. In my experience one-month sprints are more common, especially in large enterprises and government, and you will literally have 7 hours of meetings on that final day if you follow the Scrum handbook.

Long meetings are built into Scrum.

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

#272

Post by ktRolster » Mon, Aug 08, 2016, 5:36 PM UTC

patothon wrote: post #238

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…

I don't like scrum myself, but let me try to defend it because I think the problem of most of the people who don't have a good experience with scrum is a misunderstanding of the underlying principles behind it. Let's just remember that Scrum is just a tool that is trying to replicate some practices of the toyota production system (TPS), and an important principle of the TPS is continuous improvement, and Scrum has th…

Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything

This sort of thing is only useful for managers who don't understand what is going on. Since they are unable to look at code and understand it, 'points' give them a semi-opaque substitute.

If management trusts the team, it is not necessary.

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

#273

Post by ktRolster » Mon, Aug 08, 2016, 5:38 PM UTC

bmj wrote: post #140

s_kilk wrote: post #82

Earlier quoted context omitted.

This is how we ended up with the "Shadow Sprint" at a previous workplace. A whole bunch of utterly essential engineering work was left out of the sprint process, so many of us would just go ahead and do what needed to be done anyway while working on whatever tickets we'd picked up frome the "real" sprint. Utterly dysfunctional of course, but if it's do-or-die, I'd prefer to 'do'.

How did you handle regression testing of the refactored functionality? That's our biggest hurdle. QC is swamped with "regular" sprint work, so there's no way they manage any additional load during the sprint.

Only refactor things in sections of code that you're changing anyway. That way QA already needs to test those sections of code, and gets no extra work.

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

#274

Post by xemdetia » Mon, Aug 08, 2016, 5:38 PM UTC

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.

If you have a management team that is very weak when it comes to planning agile does help a lot allowing the world of actual work estimates to enter the equation, or in the sprint structure you can broach the question 'what gets bumped to do this?' If a management team has an endless leash they just stack a thousand different arbitrary pieces in a pile, call it a release and set a deadline. Using agile enforces a workflow for short term planning where one didn't exist.

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

#275

Post by xorblurb » Mon, Aug 08, 2016, 5:40 PM UTC

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.

And in a way it's saner than if you blamed over and over some people who still work 5m from you, even if they deserve it; and we all have stories about that kind of people.

You often needs to be more subtile with them (x) than blatantly calling on their bullshit every time...

(x): I mean to try to influence them so they progress so your life is better, not to shit on them

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

#276

Post by douche » Mon, Aug 08, 2016, 5:41 PM UTC

daemin wrote: post #210

new_hackers wrote: post #185

Earlier quoted context omitted.

I believe the technical debt could be measured as: The time it takes to change code that is already written. For instance, if you want feature N+1, but to do feature N+1 you need to change feature N, then the amount of time you spend changing feature N is the technical debt. So when you are estimating, you could say: We need to refrob the whozzit to make it compatible with foo 2.0, then that work could be captured as…

That will mean Technical Debt is dependent on what features you want to implement as to how much code has to change to support it. Still makes it rather subjective and hand-wavy.

If the technical debt is in areas that you will very rarely go back into, then it could perhaps be considered low-interest, compared to technical debt in high-churn code paths.

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

#277

Post by maxxxxx » Mon, Aug 08, 2016, 5:42 PM UTC

matthewmacleod wrote: post #107

maxxxxx wrote: post #22

Earlier quoted context omitted.

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

We tend to bundle that work up and include it in tickets with the full acknowledgement of the rest of the team. "Oh, since we're adding new email features, we'll need to clean up some of the old email code. That will add additional complexity to this task, so we will estimate it higher." It works, allows us to still track the impact on velocity, keeps everyone informed, and makes technical debt clear and trackable.

This is how it should work in my view. You just need managers that are disciplined and don't tell you to not clean up old code because of deadline pressure.

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

#278

Post by xorblurb » Mon, Aug 08, 2016, 5:43 PM UTC

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.

In your church, maybe.

In a country where logic reigns, it depends.

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

#279

Post by hawleyal » Mon, Aug 08, 2016, 5:49 PM UTC

It's a project management methodology, not a software development methodology. Some of these gripes seem not to be accusations of the method but actually the application by whatever organization.

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

#280

Post by Udik » Mon, Aug 08, 2016, 5:51 PM UTC

nilkn wrote: post #258

Udik wrote: post #246

Earlier quoted context omitted.

but it presents problems months down the line when a new feature needs to be added or an existing one changed in a non-trivial way. I think I have yet to see any software to which this doesn't apply sooner or later. While the whole point of "technical debt" is that it is something you're supposed to knowingly acquire because of time constraints. You're basically saying "we knew it was wrong, but they forced us to do…

> And if I am under pressure by the management is because I spent time developing without understanding what I was doing; a better developer would have gotten it right at the first try, and there would be no technical debt. While this reasoning is probably not technically wrong, I'm not sure if it's relevant to the real world. You can always make an argument of form "there exists a developer who could have got this f…

I guess that what I'm trying to say - and that got clearer to me while replying to other comments in this thread- is that it feels we're using the term "technical debt" as a way to avoid talking about personal skills or lack thereof, and to avoid admitting our or other people's faults. If I say that we need one more week of work on something because of technical debt due to the exceptional circumstances is one thing; if I say that it is because one of my colleagues didn't do his or her job properly, it's different. Remember that the business might have no clue of how long or difficult some tasks are and judge them only by the amount of work required. So a series of bad design decisions and consequent technical debt can give the impression of a very hard task on which everybody is working skillfully, while in fact it's an easy task with somebody that doesn't know how to do his job.

As for your other points: maybe one of my team members produces consistently more technical debt than the others. Is it still technical debt? Manager or designers can be the source of time pressure for those down in the chain, because bad planning or decisions, made in absence of time pressure, can force others to work under pressure. Again, "technical debt" masks the real problem. I might not have worked in extremely high pressure environments - but I've surely worked in teams where we were leaving the office at ten or eleven pm every night for months on end just because demented design decisions had been made by the much respected solution architect.