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.
> 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.
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.
> 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.
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.
> You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms.
Your statements are dogma. "You must've just done it wrong" is scrum marketing. If it works it's scrum, if it didn't work it must not've been.
> Strawman.
Go on then, explain? Your gripe was that your team, that you admitted didn't find value in retrospectives, didn't bring up process issues in retrospectives. Why would they? They didn't find them valuable. Probably because the things brought up in retrospectives never got addressed. Agile solution? Add more process. Again, this is dogma.
> Of staff or customers? Attrition is very low of both. Not sure it's that relevant though.
If I employ 500 engineers and they're all miserable and constantly leaving, and we're never adding value to our clients, should I be proud that I employ 500 engineers? What does team size matter? Value-creation and employee happiness are the metrics that determine the health of an engineering org. Which I chose to label as "throughput", or how much value is created, and "attrition", a proxy for employee happiness.
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.