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

171–180 of 387 posts

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

#171

Post by Udik »

je_bailey wrote: post #157

The aha moment for my team which changed us from a mindset of dealing with scrum to enjoying it was when we moved from aiming towards a number of story points to complete towards committing to the stories that we could individually complete in a sprint, without a concern for the associated story points. All of a sudden story points disassociated with time. They just became a number. a combination of complexity and un…

Is each developer just working on as many stories as he can in a sprint, picking from a prioritized list? Because otherwise, how do you estimate what you can complete in a sprint? Don't you commit beforehand to deliver a certain amount of stories? And doesn't that translate to a certain number of story points?

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

#172

Post by jroseattle »

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…

> Because the stories are always articulated in terms of user facing features they encourage developers to hack things together in the most expedient way possible and completely fail to capture the need to address cross cutting concerns, serious consideration of architecture, and refactoring.

This is one of our biggest challenges. Much of the work we're doing isn't confined just to a user feature, so square-peg-round-hole syndrome affects us a lot.

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

#173

Post by softawre »

alistairSH wrote: post #162

One of the first things I was taught when I did my first Scrum Master course was that scrum is just guidelines. Teams are self-organizing and need to do what works for them. Most of the criticisms in this piece can be resolved by team members adapting processes so they work for the team. I've also encountered most of those problems in non-agile, non-scrum teams as well. Instead of obsessing over points, it's hours. M…

Exactly true. I hate to say "that's why all of these articles are dumb", but really - is adapting something to your people that hard or unexpected?

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

#174

Post by WhitneyLand »

mgkimsal wrote: post #79
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've been in situations like this, and when I've brought up techdebt issues, I get "YAGNI". I've tried to frame technical debt issues in terms of how it will impact future feature requests, performance, etc, and YAGNI is what normally comes back. Until... they actually NI. Then it's a hair on fire crisis. Fortunately have not been in that type of situation for years, but I know they still happen.

For those that didn't know - "You aren't gonna need it" (acronym: YAGNI) is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.

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

#175

Post by thackerhacker »

dozzie wrote: post #166
ozmbie wrote: post #148

Earlier quoted context omitted.

Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value. What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.

> As a customer, you've given me no value. Erm. But it's you who is the customer in this scenario, not him? Or am I missing something?

He's saying that eventually when your feature surfaces as a UI the customer may not like it.

To which I have 2 responses:

1. not all features need a UI to be useful

2. this also demonstrates the infantilising nature of scrum where no developers can be trusted to think deeply, talk to stakeholders and otherwise do the right thing in a fully-rounded way but must just follow the exact instructions expressed

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

#176

Post by coredog64 »

Meegul wrote: post #43
dudifordMann wrote: post #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…

His complaint about the standups interrupting productive work rings a bell with me though. I see no reason why a daily status update over the general channel on slack doesn't serve the same purpose as a standup meeting. In fact, make it so there's a loose timeframe, say 30 minutes, and you wouldn't be interrupting people, nor forcing them to stare at a wall. My team hasn't tried anything like that, but I think it cou…

In the commentary for a previous story, another user mentioned that they have a "today-I-will" room in Slack. I've been itching for a chance to bring that up with my management.

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

#178

Post by existencebox »

jcadam wrote: post #81
camtarn wrote: post #33

Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resem…

Retrospectives for us consist of the dev team sitting in a room getting lectured by the PM on why we consistently fail to close all of our stories, and asking for our opinion on what new processes can be introduced to fix it. Of course, feedback is solicited, but it is an unspoken rule that criticism of project management is verboten. However, criticism of self and others on the dev team is absolutely allowed and enc…

This is familiar to me. However, I'm not sure you'll like my "fix". The PM should never be outside the discussion. The moment they become a separate entity, an unaccountable entity, dev can become more and more pathological. It is for us to stand up to that, communicate the difficulties in task estimation, keep a strict paper trail on when specs get shifted/scope creeps so that we have a well backed response when this discussion happens.

I would even argue that in the same way the "brown nosers" are trying to make some positive impact for themselves, as risky as it is, you can do better by fighting bad product management. If you feel the pain, your team does, and likely, your manager might as well. (if it's also a separate entity from the PMs.) The loyalty and trust you can build by defending your devs and being a force for good can be absolutely invaluable as your career goes on.

By and by, although I acknowledge the risk, if you shape your rebuttals well, you can find yourself bringing PMs to your side (a recent "spirited" discussion in which a PM was refusing to institute KPIs to track their features ended with their other PM peers questioning their resistance and backing the eng push for better telemetry, because when it came to "how can we justify how well we're serving clients if we _don't know_" this speaks even across lines.)

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

#179

Post by JoeAltmaier »

vpeters25 wrote: post #169

> First of all, what are story points? Are they measures of time it takes to complete a story? If yes, then why are they not in terms of time? Are they measures of complexity? Story points are a measure of "relative amounts of effort". A 2 point story is twice as hard, as far as effort to implement it than a 1 point one. > Scrum meetings (aka rituals) have been among the most miserable hours of my life... Would you r…

For some engineering tasks, the work and the planning are almost the same thing. Once you've explored the problem, the code is the small part.

When asked to estimate, the answer is "I'll let you know when I'm getting into it". Then you're made to do a 'spike', which is indistinguishable from doing the task. Except do it in a day now. So the Engineer thrashes around trying to figure it all out in a day, and comes up with some number. The planning phase is now over, so they're supposed to just execute, regardless of what (bogus) number they found. So they start. At the end of the sprint, they've done less than if they'd just started the task the first day. They get 'measured' as a low performer. Of course its the process that's performing badly, not the Engineer. They get frustrated, resentful and stop cooperating with the scrum master.

I've seen this so many times at so many places its just exhausting. No amount of discussion can convince the evangelical Scrum experts that something is wrong with the process.

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

#180

Post by lkrubner »

I think the argument for scrum is something like "Our big organization has complicated politics and scrum is one way of dealing with those politics." However, I often wish the management would directly address the internal politics that undermine productivity. I realize that it is awkward and uncomfortable for managers to talk honestly about the differences they have with other managers and other teams, but that is also their profession. That is, working through any relationship that undermines productivity is the job of a manager.

I wrote about this here: "The Agile process of software development is often perverted by sick politics"

http://www.smashcompany.com/business/the-agile-process-of-so...

Post reply on HN