Ask HN: Does Scrum add value?
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?
3 comments
[ 3.2 ms ] story [ 20.6 ms ] threadI 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.
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.
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.