4 ms·

Scrum is terrible and an abomination of what agile was supposed to be. Arbitrary sprints with perverse incentives that reduce taking riskier long term bets and

Scrum is terrible and an abomination of what agile was supposed to be. Arbitrary sprints with perverse incentives that reduce taking riskier long term bets and prevent any sense of ownership for engineers. Works fine when you have junior engineers but competent professionals are much better served but ditching this crap.

eyelidlessness 5y ago
I’ve worked with plenty of senior engineers who prefer it too. As I said in my own reply, I personally don’t. But I don’t think it’s right to frame it as determined by experience level. I do think, like OP, it’s good to prioritize finding team fit where there needn’t be conflict over things like this. Edit: also, universally rejecting tools/processes is just as much a rejection of Agile principles as adopting them blindly. The whole idea is to choose what works for people doing the work.
more_corn 5y ago
I felt the same way when I had scrum imposed on me by an incompetent person. I have since come back around and implemented scrum myself to track some stuff I’m working on. It’s good for details.
- 59nadir 5y ago
  I had this same experience by proxy and myself was very skeptical. I had asked people around me what they thought about scrum and almost universally people were unclear on what it was supposed to do for them and for each person there was a different complaint. I read some books on it and overall surveyed it and found that in each of these cases they weren't really doing scrum and were never told why they'd be doing each part because no one bothered. I implemented scrum with my team after explaining exactly what benefits we wanted out of it (for the team mainly, but it also helps stakeholders) and it's a lot better than the pseudo-agile unstructured work we had before at the very least. We're a part of the planning process, we know the basic motivations behind the things we're doing (user stories' "... so that..." section) and a much clearer picture of when a feature is done (acceptance criteria), our time evaluations are the only ones that matter and have nothing to do with some manager's idea of when something ought to be done. I'm sure we'll adjust things as time passes and we recognize deficiencies, but I'm pretty happy with even the basic things we get out of it and some of our team members who were previously not happy with scrum are saying it's much better when you know why you're doing these things and when you actually do key parts of the process and don't rip out important bits.

eyelidlessness 5y ago

I’ve worked with plenty of senior engineers who prefer it too. As I said in my own reply, I personally don’t. But I don’t think it’s right to frame it as determined by experience level. I do think, like OP, it’s good to prioritize finding team fit where there needn’t be conflict over things like this. Edit: also, universally rejecting tools/processes is just as much a rejection of Agile principles as adopting them blindly. The whole idea is to choose what works for people doing the work.

more_corn 5y ago

I felt the same way when I had scrum imposed on me by an incompetent person. I have since come back around and implemented scrum myself to track some stuff I’m working on. It’s good for details.

59nadir 5y ago
I had this same experience by proxy and myself was very skeptical. I had asked people around me what they thought about scrum and almost universally people were unclear on what it was supposed to do for them and for each person there was a different complaint. I read some books on it and overall surveyed it and found that in each of these cases they weren't really doing scrum and were never told why they'd be doing each part because no one bothered. I implemented scrum with my team after explaining exactly what benefits we wanted out of it (for the team mainly, but it also helps stakeholders) and it's a lot better than the pseudo-agile unstructured work we had before at the very least. We're a part of the planning process, we know the basic motivations behind the things we're doing (user stories' "... so that..." section) and a much clearer picture of when a feature is done (acceptance criteria), our time evaluations are the only ones that matter and have nothing to do with some manager's idea of when something ought to be done. I'm sure we'll adjust things as time passes and we recognize deficiencies, but I'm pretty happy with even the basic things we get out of it and some of our team members who were previously not happy with scrum are saying it's much better when you know why you're doing these things and when you actually do key parts of the process and don't rip out important bits.