3 ms·

What's the point of even doing "sprints" then?

superfrank 4y ago
Can you elaborate further? I don't understand what part of my response this is directed at. Edit: Nvm, I figured it out. I assume you're referring to this? > Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint". Honestly, not a ton. If we worked in isolation, we could probably drop them and little would change for us. The value that I feel like they bring are: - It forces developers to agree on and commit to a certain amount of work for those two weeks. If a dev says, I'm going to do these three things and two weeks later they're not done with #1 it's a red flag. They may have a totally legitimate reason, but it at least forces us to ask the question. - Kind of in the same thought process it helps us break month long projects down into smaller deliverables and communicate the status outward. We could easily do this without sprints, but some sort of break down is needed, so why not sprints? - Other teams are doing more traditional sprint planning, so it gives us all a common language to communicate in. If we need something from another team, being on the same schedule as everyone else is nice. - Our release schedule is tied to sprints. Without sprints it'd be much harder to keep track of what is going out when. Just to give more detail, we do have a sprint planning meeting, but it's basically just all of us meeting and saying what we're working on in the next sprint. Like I said in my original comment, we took the parts that worked for our team and threw away the rest.
usr1106 4y ago
The whole terminology shows an attitude hostile to employees, just squeezing out the last drop of juiceout of them. Nobody can sprint all the time, sometimes you just need to walk slower. I think I have seen 3 types of people * some get cynical and just don't care about the sprint goals. What doesn't get done this sprint gets carried over to the next one * others really want to get ticked off everything. So they compromise on quality, pile up technical debt. Eventually they hope the project will be closed or they move one. * 3rd category burns out themselves. This can end badly, I have seen suicide attempts, people disappearing from their family and of course sick leaves and quitting their jobs. I don't think planning every 2 weeks is a bad thing. It just makes sure that plans get reviewed, updated, and refocussed frquently enough. Whether the goals have been reached or not I don't care that much. Retros are often a waste of time. Yeah, we underestimated something. We forgot a task. Unforeseen customer support suddenly had higher priority. There is always some reason why things went differently, despite all intentions to do it better every time. Edit: No I don't think all sprints go just completely wrong. But there is always something that didn't work out. Maybe 30% on average? With my current team we try to mostly look at the 70% that we got done reasonably well and then we move on carrying over what still needs to be done.
- icedchai 4y ago
  As for #1, estimates are usually wrong, because people are often extremely optimistic. And requirements are often incredibly vague. To expect to meet 100% of your "sprint goals" is unreasonable. It's not cynicism, it's being realistic. Retros are a big waste of time about 95% of the time.
- conradfr 4y ago
  Thanks for your reply.

Can you elaborate further? I don't understand what part of my response this is directed at. Edit: Nvm, I figured it out. I assume you're referring to this? > Sprint planning on the other hand is almost completely unnecessary since we have a bunch of long running one person projects that will get done when they get done. Each sprint is basically just everyone going, "I'm continuing what I was working on last sprint". Honestly, not a ton. If we worked in isolation, we could probably drop them and little would change for us. The value that I feel like they bring are: - It forces developers to agree on and commit to a certain amount of work for those two weeks. If a dev says, I'm going to do these three things and two weeks later they're not done with #1 it's a red flag. They may have a totally legitimate reason, but it at least forces us to ask the question. - Kind of in the same thought process it helps us break month long projects down into smaller deliverables and communicate the status outward. We could easily do this without sprints, but some sort of break down is needed, so why not sprints? - Other teams are doing more traditional sprint planning, so it gives us all a common language to communicate in. If we need something from another team, being on the same schedule as everyone else is nice. - Our release schedule is tied to sprints. Without sprints it'd be much harder to keep track of what is going out when. Just to give more detail, we do have a sprint planning meeting, but it's basically just all of us meeting and saying what we're working on in the next sprint. Like I said in my original comment, we took the parts that worked for our team and threw away the rest.

usr1106 4y ago

The whole terminology shows an attitude hostile to employees, just squeezing out the last drop of juiceout of them. Nobody can sprint all the time, sometimes you just need to walk slower. I think I have seen 3 types of people * some get cynical and just don't care about the sprint goals. What doesn't get done this sprint gets carried over to the next one * others really want to get ticked off everything. So they compromise on quality, pile up technical debt. Eventually they hope the project will be closed or they move one. * 3rd category burns out themselves. This can end badly, I have seen suicide attempts, people disappearing from their family and of course sick leaves and quitting their jobs. I don't think planning every 2 weeks is a bad thing. It just makes sure that plans get reviewed, updated, and refocussed frquently enough. Whether the goals have been reached or not I don't care that much. Retros are often a waste of time. Yeah, we underestimated something. We forgot a task. Unforeseen customer support suddenly had higher priority. There is always some reason why things went differently, despite all intentions to do it better every time. Edit: No I don't think all sprints go just completely wrong. But there is always something that didn't work out. Maybe 30% on average? With my current team we try to mostly look at the 70% that we got done reasonably well and then we move on carrying over what still needs to be done.

icedchai 4y ago
As for #1, estimates are usually wrong, because people are often extremely optimistic. And requirements are often incredibly vague. To expect to meet 100% of your "sprint goals" is unreasonable. It's not cynicism, it's being realistic. Retros are a big waste of time about 95% of the time.
conradfr 4y ago
Thanks for your reply.