3 ms·

I disagree... kind of. Every team is different and will have different strengths and weaknesses. Scrum should act as a framework to get your team to do the thi

• BlargMcLarg 4y ago
  >If your team just carries on doing that same old things because "that's the way it's always been done", then retros could easily be the most important part. This tends to happen even with retros. Retros assume a lot of things about a team in order to work which just don't hold for a vast majority of teams. That's the problem with almost every methodology. They make assumptions on how a team should work in order for the tool to do its job. If the team doesn't work that way, it's the teams fault. You obviously can't blame a tool, but a tool isn't particularly useful when it doesn't solve the problem, either. Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up. They don't want to share frustrations. Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything. Which then puts the time spent doing the retrospective in question, or worse, it causes frustration because it keeps individuals from burying their problems. There are so many ways retros can be a big nothing burger, none of which are inherently the problem with retros. Then someone comes along saying "have you tried this". No Captain Obvious, I haven't tried using a coconut to smash against the wall instead. I'm sure it will break now, and I won't risk getting coconut splinters in my face.
  • superfrank 4y ago
    First of all, I hear your frustration. I've been a part of way too many teams that just do things for the sake of doing them. It sucks when it seems like no one else cares or will even acknowledge that it's a waste of time. I'm not trying to push any particular part of scrum on anyone. My point was that I think teams should look to agile as a bunch of suggestions and should change or remove things as they see fit. If it's not working, scrap it. If retros assume your team works in one way, and your team doesn't work that way, change how your team does retros or don't do them. Hell, at one company I worked at that was going through a particularly rough transition, we moved our "retros" to 3pm on Friday, brought beers, and by the 15 minute mark it was usually just a bitch-fest about everything that was going wrong at the company. They weren't the most productive retros ever, but it was what the team needed at that time. > Example for retros. They solve agreeableness and bottling things up, in theory. In practice, a lot of people stay agreeable and continue to bottle things up. I disagree. From what I've seen, people are a lot more willing to speak up if they know they're not the only one feeling that way. It's easier to "yes and" someone else's complaint that speak up on your own. I just ran our retro today, where one of the more quiet members only had positive things to say until one of the other members of the team mentioned how they were having trouble getting reviews on PRs in a timely manner. Once that was out there the quiet team member was happy to hop in and share her issues around the same thing, but I doubt that would have happened if someone else hadn't "popped the cork". > Maybe they try a few times, only to notice what they say doesn't really affect the future, leading to more frustration than just not saying anything. This sounds like the real root of your problems. If nothing is coming from your retros, I can see why you would be frustrated (I would be too). Our retros end with us going over the list of action items and assigning owners. Our next retro then starts with us going over that same list and seeing who got what done. For my current team that works really well and we've actually had some pretty great things come out of our retros because of it. I'm not trying to push that on you, but just giving an example of what works for us. I hope I don't come off as offensive, but it really sounds to me like your team is pretty dysfunctional. I'm not sure there's really any process to get around that. Saying retros are useless when no one on your team cares is kind of like saying power steering is useless when your car is on fire.
• conradfr 4y ago
  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.