4 ms·

That sounds like you weren’t doing scrum right. It’s also possible I wasn’t doing it right and was doing a healthy version of it?

ch4s3 4y ago
Every scrum proponent always responds to any criticism with a no true Scotsman claim. I’ve never personally seen or heard second hand of a successful scrum implementation, and the SWE academic literature doesn’t support it either. I’d argue that spending time on activities like scrum poker or sprint planning are actively harmful for most kinds of teams. The points games are inherently adversarial, only add value for scrum masters, and waste time that could be spent understanding requirements/business problems better. The incentives are inherently perverse and the whole exercise encourages and rewards dishonesty.
- sodapopcan 4y ago
  Well I feel it was successful on my old team. We weren’t micromanaged and owned our own process. We story pointed and those metrics were only ever seen and used by us. We got tons of value out of retros (had loads of difficult conversations with high levels of trust). We didn’t have a scrum master—everyone knew how to run all meetings and process. We worked closely with our customers doing rapid prototyping as to not waste time building features they only thought they wanted. We showed progress to the org via demos. I feel like it worked really well and really enjoyed it. As far as no true Scotsman, I didn’t mean it like that—I don’t care if people don’t want to use scrum, but I do take light exception when people shit on it an go on to describe a process that is alien to me. Though I guess what my teen was doing was a bit more of a mix of scrum and XP.
  - ch4s3 4y ago
    > We story pointed and those metrics were only ever seen and used by us That seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? > but I do take light exception when people shit on it an go on to describe a process that is alien to me Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off. It sounds very much like you were doing some flavor of XP with a few scrum meetings sprinkled in. This isn’t the process scrum evangelists and consultants are pushing. But I’d still argue that most story pointing meetings are wasteful.
    - sodapopcan 4y ago
      That’s fair. Honestly I haven’t gone too deep into the source material. Most of my knowledge comes from two former coworkers and current friends who were well versed and experienced in XP and agile and had a huge impact on the engineering culture at the company I was talking about. I actually don’t disagree that story-pointing feels like a waste of time, but I do find it useful to talk about what’s involved in a task and figure out how long is might take. I don’t think it’s unreasonable for management to want a rough idea of when something will be delivered, mostly so that they are able to plan themselves. Of course, it all depends on endless variables as to how much process a company needs. In larger companies with multiple teams, I strongly believe in self-organizing teams with a well-defined point of contact and freedom to implement as much or as little process as they want. Edited to fix horrendous typo as a result of typing on my phone. I likely didn’t catch them all.
      - ch4s3 4y ago
        Yeah, I think periodically talking with product folks about the nuts and bolts of a task is really useful. It’s even quite useful to think about when tasks are becoming large. That sparks a lot of good conversations. The specifics of how to best do that will vary a lot team to team.
    - JamesBarney 4y ago
      There another issue I've seen with all the forced estimation that gives questionable values to the business. When devs overestimate they then tend to take the extra time to overengineer the solution, and when they underestimate they tend to take on technical debt to make the very arbitrary deadline.
      - ch4s3 4y ago
        I think it also incidentally discourages the trade off conversation by artificially time boxing work.
    - vlovich123 4y ago
      We do it pretty lightweight as a way to estimate the whether there’s the right amount of work to fill up ~2 weeks. Senior engineers get a lot more leeway to reprioritize on the fly.
- slt2021 4y ago
  the good thing is that when you see that Scrum process is broken and is not going to improve, that is as clear signal as it can get for a developer to quit to a better place.
  - ch4s3 4y ago
    That would be my recommendation.
- 64StarFox64 4y ago
  Genuinely curious about this: is there a specific white paper (or collection) to which you're referring?
  - ch4s3 4y ago
    I’d have to dig back into the literature, I don’t have anything at hand. Basically for every pro-scrum paper you’ll find a criticism. A few people have done meta analyses and found no benefits. There should be something in IEEE but I’m on a plane right now.
- nunez 4y ago
  planning can be useful if stories entering the queue are refined in real time and the team knows where they are going. best case, it's a ten minute "here's the backlog; who needs work?; what are we shipping this week?" conversation...but this assumes a high-performance team of go-getters where every story is vetted well enough for anyone to pick up (that convo can be had on slack, btw, just like standups.) the problem is "scrum masters" waiting to refine/reject stories during refinement (or not refining at all), or engineers not updating their cards frequently enough, or nobody guarding the backlog and allowing anyone to dump stuff into it. when these things happen, you get three-hour-plus-long sprint planning that wastes everyone's time the other thing I absolutely hate are capital-r-Retros. retros are supposed to be the meeting that everyone looks forward to, but they often get skipped because it's an hour of people sharing platitudes because the room isn't safe enough to REALLY say what you feel. if i ran retros, they would be at a nearby pub or chill restaurant, over beverages and food, with no real structure other than "at some point we should talk about how this week went."
  - sodapopcan 4y ago
    OMG yes, the retros at my current company are just full of platitudes (and that’s what people look forward to) and I hate it. People do bring up difficult topics but because want to get through every. single. topic. the difficult convos get rescheduled to yetanothermeeting so there’s time to talk about all the positive stuff (which, again are just platitudes, nothing constructive). I tried to change this and got shot down. Otherwise (and I’m forgetting which thread I’m in here so maybe repeating myself), I have experienced incredibly valuable retros. They were structured but still fun. And very much agree with the first paragraph. I also agree it could just be done on Slack, but I personally like having a daily meeting where I get to see my team all together… so long as that meeting is short (max 5 mins on a good day).

ch4s3 4y ago

Every scrum proponent always responds to any criticism with a no true Scotsman claim. I’ve never personally seen or heard second hand of a successful scrum implementation, and the SWE academic literature doesn’t support it either. I’d argue that spending time on activities like scrum poker or sprint planning are actively harmful for most kinds of teams. The points games are inherently adversarial, only add value for scrum masters, and waste time that could be spent understanding requirements/business problems better. The incentives are inherently perverse and the whole exercise encourages and rewards dishonesty.

sodapopcan 4y ago
Well I feel it was successful on my old team. We weren’t micromanaged and owned our own process. We story pointed and those metrics were only ever seen and used by us. We got tons of value out of retros (had loads of difficult conversations with high levels of trust). We didn’t have a scrum master—everyone knew how to run all meetings and process. We worked closely with our customers doing rapid prototyping as to not waste time building features they only thought they wanted. We showed progress to the org via demos. I feel like it worked really well and really enjoyed it. As far as no true Scotsman, I didn’t mean it like that—I don’t care if people don’t want to use scrum, but I do take light exception when people shit on it an go on to describe a process that is alien to me. Though I guess what my teen was doing was a bit more of a mix of scrum and XP.
- ch4s3 4y ago
  > We story pointed and those metrics were only ever seen and used by us That seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion? > but I do take light exception when people shit on it an go on to describe a process that is alien to me Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off. It sounds very much like you were doing some flavor of XP with a few scrum meetings sprinkled in. This isn’t the process scrum evangelists and consultants are pushing. But I’d still argue that most story pointing meetings are wasteful.
  - sodapopcan 4y ago
    That’s fair. Honestly I haven’t gone too deep into the source material. Most of my knowledge comes from two former coworkers and current friends who were well versed and experienced in XP and agile and had a huge impact on the engineering culture at the company I was talking about. I actually don’t disagree that story-pointing feels like a waste of time, but I do find it useful to talk about what’s involved in a task and figure out how long is might take. I don’t think it’s unreasonable for management to want a rough idea of when something will be delivered, mostly so that they are able to plan themselves. Of course, it all depends on endless variables as to how much process a company needs. In larger companies with multiple teams, I strongly believe in self-organizing teams with a well-defined point of contact and freedom to implement as much or as little process as they want. Edited to fix horrendous typo as a result of typing on my phone. I likely didn’t catch them all.
    - ch4s3 4y ago
      Yeah, I think periodically talking with product folks about the nuts and bolts of a task is really useful. It’s even quite useful to think about when tasks are becoming large. That sparks a lot of good conversations. The specifics of how to best do that will vary a lot team to team.
  - JamesBarney 4y ago
    There another issue I've seen with all the forced estimation that gives questionable values to the business. When devs overestimate they then tend to take the extra time to overengineer the solution, and when they underestimate they tend to take on technical debt to make the very arbitrary deadline.
    - ch4s3 4y ago
      I think it also incidentally discourages the trade off conversation by artificially time boxing work.
  - vlovich123 4y ago
    We do it pretty lightweight as a way to estimate the whether there’s the right amount of work to fill up ~2 weeks. Senior engineers get a lot more leeway to reprioritize on the fly.
slt2021 4y ago
the good thing is that when you see that Scrum process is broken and is not going to improve, that is as clear signal as it can get for a developer to quit to a better place.
- ch4s3 4y ago
  That would be my recommendation.
64StarFox64 4y ago
Genuinely curious about this: is there a specific white paper (or collection) to which you're referring?
- ch4s3 4y ago
  I’d have to dig back into the literature, I don’t have anything at hand. Basically for every pro-scrum paper you’ll find a criticism. A few people have done meta analyses and found no benefits. There should be something in IEEE but I’m on a plane right now.
nunez 4y ago
planning can be useful if stories entering the queue are refined in real time and the team knows where they are going. best case, it's a ten minute "here's the backlog; who needs work?; what are we shipping this week?" conversation...but this assumes a high-performance team of go-getters where every story is vetted well enough for anyone to pick up (that convo can be had on slack, btw, just like standups.) the problem is "scrum masters" waiting to refine/reject stories during refinement (or not refining at all), or engineers not updating their cards frequently enough, or nobody guarding the backlog and allowing anyone to dump stuff into it. when these things happen, you get three-hour-plus-long sprint planning that wastes everyone's time the other thing I absolutely hate are capital-r-Retros. retros are supposed to be the meeting that everyone looks forward to, but they often get skipped because it's an hour of people sharing platitudes because the room isn't safe enough to REALLY say what you feel. if i ran retros, they would be at a nearby pub or chill restaurant, over beverages and food, with no real structure other than "at some point we should talk about how this week went."
- sodapopcan 4y ago
  OMG yes, the retros at my current company are just full of platitudes (and that’s what people look forward to) and I hate it. People do bring up difficult topics but because want to get through every. single. topic. the difficult convos get rescheduled to yetanothermeeting so there’s time to talk about all the positive stuff (which, again are just platitudes, nothing constructive). I tried to change this and got shot down. Otherwise (and I’m forgetting which thread I’m in here so maybe repeating myself), I have experienced incredibly valuable retros. They were structured but still fun. And very much agree with the first paragraph. I also agree it could just be done on Slack, but I personally like having a daily meeting where I get to see my team all together… so long as that meeting is short (max 5 mins on a good day).