5 ms·

The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worke

The brilliant thing about Scrum marketing is it's pitched and talked about as infallible. If it didn't work, it's because you didn't do it right. If Scrum worked for you, you must've done it right. > If you don't, or do "Scrum but not quite", then when things don't quite work out, you're on your own. So, if you do exactly as Scrum prescribes and do not find success, in what way aren't you "on your own"?

shados 5y ago
I think I'm expressing myself incorrectly. Scrum "by the book" has a lot of material on the edge cases. How you handle almost every case that can happen in a software development team. So you can follow it like a workflow. Something unusual happens, you look in the book, do what it says. It's flaws are fairly well documented and understood, too. That's what I mean by being "on your own" if you don't follow it. At that point you can't just use a book to figure out next steps. You have to actually talk it out and use your brain to figure out what to do, because its unlikely your internal process has as much documentation around every single "paved paths". It's also just a process. What does it mean not to find success here? If you ship broken software, it's unlikely to be because you didn't move the right ticket in Jira. If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc. Don't get me wrong: I very much dislike Scrum and you'll never see me push for it in a team. My point was merely that if you take an "On rails" experience like Scrum, and tweak a few little things, you lose on almost everything. The books no longer apply. When the entire point of this particular process is basically the books and documentations, doing "Scrum but not quite" really kills the point.
- void_mint 5y ago
  > If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc. Yeah this is the nonsense propaganda I'm talking about. "If it didn't work, it's because you needed to do it more", which I think is absolute nonsense.
  - dave1999x 5y ago
    If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse. It's like baking a cake without adding sugar; it's not really a cake anymore. Sometimes teams don't understand practices and will discard them. As an example - retrospectives. I've worked on teams where we inspected and adapted our process on demand. We didn't wait till the end of a sprint. I've managed individuals on teams where they're discarded retrospectives. They've complained to me about certain processes (not scrum ones) and when I've asked, "why didn't you raise this in the retrospective?". "We stopped them, we didn't see any value". No doubt they weren't getting value out of them, but that doesn't mean they were doing things well and they lost opportunity to improve as a group. For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.
    - void_mint 5y ago
      > If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse. Dogma. > It's like baking a cake without adding sugar; it's not really a cake anymore. Nonsense. > No doubt they weren't getting value out of them This piece goes against this piece: > , but that doesn't mean they were doing things well and they lost opportunity to improve as a group. Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end? > For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now. Less interested in size, more interested in throughput/attrition.
      - dave1999x 5y ago
        > Dogma > Nonsense You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms. >Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end? Strawman. I'm afraid you'll have to take my word for it that the team where just bad at it. They got better with coaching and even managed to see some value. The values behind the process are more important. This team just weren't talking to each other about their own performance. > throughput/attrition Of staff or customers? Attrition is very low of both. Not sure it's that relevant though. 3 engineers have left in the last 2 years and one of those three is returning. Is that a good thing? As for throughput, even the slowest of teams ship on a daily basis. Not sure what other context you could mean.

shados 5y ago

I think I'm expressing myself incorrectly. Scrum "by the book" has a lot of material on the edge cases. How you handle almost every case that can happen in a software development team. So you can follow it like a workflow. Something unusual happens, you look in the book, do what it says. It's flaws are fairly well documented and understood, too. That's what I mean by being "on your own" if you don't follow it. At that point you can't just use a book to figure out next steps. You have to actually talk it out and use your brain to figure out what to do, because its unlikely your internal process has as much documentation around every single "paved paths". It's also just a process. What does it mean not to find success here? If you ship broken software, it's unlikely to be because you didn't move the right ticket in Jira. If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc. Don't get me wrong: I very much dislike Scrum and you'll never see me push for it in a team. My point was merely that if you take an "On rails" experience like Scrum, and tweak a few little things, you lose on almost everything. The books no longer apply. When the entire point of this particular process is basically the books and documentations, doing "Scrum but not quite" really kills the point.

void_mint 5y ago
> If you implemented Scrum "by the book", the likely "failure cases" are more things like people refusing to actually follow the process because they find it to be a waste of time, the overhead is too high, people are sick of looking at the book, etc. Yeah this is the nonsense propaganda I'm talking about. "If it didn't work, it's because you needed to do it more", which I think is absolute nonsense.
- dave1999x 5y ago
  If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse. It's like baking a cake without adding sugar; it's not really a cake anymore. Sometimes teams don't understand practices and will discard them. As an example - retrospectives. I've worked on teams where we inspected and adapted our process on demand. We didn't wait till the end of a sprint. I've managed individuals on teams where they're discarded retrospectives. They've complained to me about certain processes (not scrum ones) and when I've asked, "why didn't you raise this in the retrospective?". "We stopped them, we didn't see any value". No doubt they weren't getting value out of them, but that doesn't mean they were doing things well and they lost opportunity to improve as a group. For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.
  - void_mint 5y ago
    > If you aren't following the Scrum practices, then you aren't doing Scrum. For better or worse. Dogma. > It's like baking a cake without adding sugar; it's not really a cake anymore. Nonsense. > No doubt they weren't getting value out of them This piece goes against this piece: > , but that doesn't mean they were doing things well and they lost opportunity to improve as a group. Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end? > For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now. Less interested in size, more interested in throughput/attrition.
    - dave1999x 5y ago
      > Dogma > Nonsense You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms. >Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end? Strawman. I'm afraid you'll have to take my word for it that the team where just bad at it. They got better with coaching and even managed to see some value. The values behind the process are more important. This team just weren't talking to each other about their own performance. > throughput/attrition Of staff or customers? Attrition is very low of both. Not sure it's that relevant though. 3 engineers have left in the last 2 years and one of those three is returning. Is that a good thing? As for throughput, even the slowest of teams ship on a daily basis. Not sure what other context you could mean.