Ask HN: Does Scrum add value? | Hacker News Reader

Ask HN: Does Scrum add value?

3 pointsJdam3 comments

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 "planning". The sprints never really finish (for valid reasons though) and I'm feeling that this process is just done because people heard that this is how it's done nowadays and management is extracting some super-nonsense bogus-numbers of "team velocity" 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 "when can we roughly ship this feature?" every now and then. What is your Scrum experience? Does it actually add value?

View on HN

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.

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

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.

Reply on news.ycombinator.com