
Ask HN: Does Scrum add value? - Jdam
In several companies now, I found myself sitting in boring meetings for hours every 1-2 weeks, doing some kind of retrospective that nobody really participated in and some wild guessing aka &quot;planning&quot;. The sprints never really finish (for valid reasons though) and I&#x27;m feeling that this process is just done because people heard that this is how it&#x27;s done nowadays and management is extracting some super-nonsense bogus-numbers of &quot;team velocity&quot; and the like out of that. I think it would save a lot of time and increase actual productivity if the PM just asks an engineer &quot;when can we roughly ship this feature?&quot; every now and then.
What is your Scrum experience? Does it actually add value?
======
wernsey
Scrum seems perfect if you approximate your developers as frictionless balls
in a vacuum, but in the teams I've been in there are several problems

I think that Scrum actually decreased productivity. The developers build in
lots of "fat" to their estimates: A story that could take 4 hours gets divided
into 4 tasks that are estimated as 2 hours each just to be sure.

I've also seen tasks that should take five minutes (eg. change the IP address
in a config file) get estimated as an hour. The developers estimate very
conservatively and the PMs and Scrum master aren't technically adept enough to
do anything about it.

Management seemed to like Scrum regardless because it provided transparency. I
think they prefer the loss of productivity to a situation where they have no
real idea over how their projects are progressing.

~~~
davelnewton
> The developers build in lots of "fat" to their estimates [...]

Then they're cheating, i.e., not being honest. Agile requires discipline and
transparency. If you avoid those overheads (and they are an overhead) then why
bother?

There's a difference between "business" and "productiveness". If a dev
finishes a "1 hour task" in five minutes then they should move on to their
next task. When you look at the burn down/up charts the discrepancy will be
visible.

Part of the point of agile is precisely to _expose_ poor estimation.

------
davelnewton
Doing agile wrong doesn't invalidate agile, it invalidates your process.

All estimation is guessing.

If your team's velocity is "super-nonsense" and bogus then the team isn't
estimating well. Reasonably-accurate velocity allows reasonably-accurate
prediction of deliverables.

If nobody is participating in the meeting then it _is_ useless. I haven't
found retrospectives to be overly-helpful at my current job because they don't
drive change. If they don't drive change, _then_ there's no point.

If your estimates are essentially random, then they _are_ useless, because
nothing meaningful (in the business sense) can be derived from random data.

If your sprints never finish then you're not doing sprints.

