Hacker News Reader

Comment by RHSeeger | Hacker News Reader

And yet, every single time I've been involved in scrum, specific goals have been assigned to every cycle, and people expect those goals to be met.

> Scrum uses timeboxing for all of the Scrum events and as a tool for concretely defining open-ended or ambiguous tasks.

View on HN

> And yet, every single time I've been involved in scrum, specific goals have been assigned to every cycle, and people expect those goals to be met.

I don't doubt that's true, but it's not how things are supposed to work in scrum: https://www.scrum.org/resources/commitment-vs-forecast

If Scrum is X, but everyone saying "Scrum" is referring to Y, is Scrum X or Y?

The answer is it doesn't matter. The problem here is that people are doing Y not X, and discussing semantics is only useful as an appeal to authority (which to be fair can be pretty darn useful sometimes).

There's a painful parallel to democracy here but that would probably be too off topic.

Scrum/Agile are useful tools to get buy in and a bit of restructuring done, but I feel as soon as you start doing real work you will just have to figure out what flavor works for your team, and what modifications need to be made to the process to make that happen.

The Agile Methodology is to argue about The Agile Methodology.

It's the CIA Simple Sabotage Field Manual applied to project management.

Any work accomplished is entirely accidental, and will be remedied during the next sprint planning meeting.

I never heard good things about scrum. Just people saying "that's not how scrum is done!" all the time.

Edit: I don't mean to say scrum proponents are wrong, but if so many people get it wrong there seem to be a fundamental problem with scrum.

> but if so many people get it wrong there seem to be a fundamental problem with scrum

It's the same problem with all methodologies - if the management is in charge of the process and it doesn't like some aspect of the process it will ignore that aspect.

This isn't solvable by tweaking the methodology.

I hate management as the next dev, but blaming the "customers" of the methodology doesn't help.

No process can fix bad management.

And no management can fix a bad process too.

This doesn't particularly make sense.

It makes sense if you don't include "replace the current process" in the set of "fix current process".

Reply on news.ycombinator.com