Yes but raw velocity is not the only thing that matters. For some projects it is, but for many the accountability of Scrum + the grouping helps with dependency management across an organization.
Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it.
Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
> It creates the illusion of accountability while creating artificial touch points
I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless.
> The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.
> If your org treats accountability as "an illusion" then it's doomed to fail regardless.
That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity".
The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case.
About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc..
Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.
To me, what you're looking for doesn't exist. Ignoring Scrum, the question is "how do we know our engineers are effective?"
You know Scrum's attempt to answer that. Regardless, no matter what methodology you pick - it's bad. But, you have to answer it. Otherwise engineering is a black box without a way to peer in.
I know many engineers would prefer it that way, but that's just not realistic.
In the end the whole thing has to be an agreement between people.
> This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.
It's interesting that you use this analogy. I've always compared Scrum to Communism or faith healing: If it doesn't work for you, you either didn't implement it correctly or you didn't believe in it enough.
Right, exactly. In other words, the claims it makes are unfalsifiable, because if they don't come to fruition then clearly there must be some other factor in play.
It’s not that no 1 has done it correctly. It’s that no 1 wants to even do scrum. Most management do pretend scrum. It’s like hype driven development. You just get on the train without caring where it goes.
