[dave1999x]

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]

> 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]

> 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.

[void_mint]

> 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.