3 ms·

I believe the SCRUM rejection comes from the direct experience of working in a team that uses it, and eventually realizing that all of the meetings and concepts

I believe the SCRUM rejection comes from the direct experience of working in a team that uses it, and eventually realizing that all of the meetings and concepts because an end in itself. SCRUM usually degrades to more discussions about story points than about what is being built.

shiroiushi 2y ago
I think this is just an example of the fact that any tool can be misused or used poorly. I used scrum at my last employer, and it worked quite well. But we didn't use it stupidly; it was just a tool to keep track of what we were working on, and plan what we were going to work on next, that's all. Sure, we had some discussions about story points, but they were quick. When we had to assign story points to a task, we'd all use story point playing cards (they have the typical Fibonacci sequence story points printed on them: 1, 2, 3, 5, 8, 13, 20) and turn them over at the same time to basically vote on the points. If there were any large disagreements (one person voting 1 while everyone else votes 8 for instance), we'd stop and discuss why that person thought it would be so much more or less effort. Usually, 30 seconds of discussion would clear up the disagreement and we'd move on to the next task. The whole meeting would last less than 1 hour, and was held every 2 weeks. And I think it had a secondary benefit: it got us all in the room together to just talk to each other as team, instead of just sitting in front of our computers and not talking to anyone, which was our usual activity. Social interaction is good for people.
- skydhash 2y ago
  If someone votes 1 while the others votes 8, he’s either too optimistic or an expert on that subject. The points themselves don’t matter, because things are either hard or easy, and that usually depends on the person doing it. No committee can decide that. And they will either get done or cancelled any way. The only things that really matter is their current priority. And that’s the business decision (influenced by several factors, including the advices of the devs). The points assignments are thus useless and you’re spending 1 hour every two weeks on it. But if it makes everyone happy… And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies.
  - shiroiushi 2y ago
    The points assignment wasn't useless; it was just for tracking relative difficulty. Some tasks were trivial, only taking a couple of hours, so they got a "1", while other tasks were projected to take 2 weeks, so those got an "13". The idea was to pick a bunch of tasks that were basically do-able within the 2-week sprint, and ignore the rest, so while 1 dev might take on a 13-point task and nothing else, another dev might take a bunch of 1s and 5s. And yes, the priority had to be factored in too, which was influenced by both customer requests and dev input (i.e., "this is super easy and I can have it done today" or "this is difficult and will take a month"). >And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies. You can, but no one actually does it in practice. Individual team members might chat together from time to time, but putting everyone in one room together forces them to interact with all their other team members and talk about real work-related stuff, instead of just hanging out with their one buddy and talking about something irrelevant.

shiroiushi 2y ago

I think this is just an example of the fact that any tool can be misused or used poorly. I used scrum at my last employer, and it worked quite well. But we didn't use it stupidly; it was just a tool to keep track of what we were working on, and plan what we were going to work on next, that's all. Sure, we had some discussions about story points, but they were quick. When we had to assign story points to a task, we'd all use story point playing cards (they have the typical Fibonacci sequence story points printed on them: 1, 2, 3, 5, 8, 13, 20) and turn them over at the same time to basically vote on the points. If there were any large disagreements (one person voting 1 while everyone else votes 8 for instance), we'd stop and discuss why that person thought it would be so much more or less effort. Usually, 30 seconds of discussion would clear up the disagreement and we'd move on to the next task. The whole meeting would last less than 1 hour, and was held every 2 weeks. And I think it had a secondary benefit: it got us all in the room together to just talk to each other as team, instead of just sitting in front of our computers and not talking to anyone, which was our usual activity. Social interaction is good for people.

skydhash 2y ago
If someone votes 1 while the others votes 8, he’s either too optimistic or an expert on that subject. The points themselves don’t matter, because things are either hard or easy, and that usually depends on the person doing it. No committee can decide that. And they will either get done or cancelled any way. The only things that really matter is their current priority. And that’s the business decision (influenced by several factors, including the advices of the devs). The points assignments are thus useless and you’re spending 1 hour every two weeks on it. But if it makes everyone happy… And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies.
- shiroiushi 2y ago
  The points assignment wasn't useless; it was just for tracking relative difficulty. Some tasks were trivial, only taking a couple of hours, so they got a "1", while other tasks were projected to take 2 weeks, so those got an "13". The idea was to pick a bunch of tasks that were basically do-able within the 2-week sprint, and ignore the rest, so while 1 dev might take on a 13-point task and nothing else, another dev might take a bunch of 1s and 5s. And yes, the priority had to be factored in too, which was influenced by both customer requests and dev input (i.e., "this is super easy and I can have it done today" or "this is difficult and will take a month"). >And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies. You can, but no one actually does it in practice. Individual team members might chat together from time to time, but putting everyone in one room together forces them to interact with all their other team members and talk about real work-related stuff, instead of just hanging out with their one buddy and talking about something irrelevant.