In what sense? If they keep missing the planned sprint so that they must take less and less work each following sprint, isn't this telling the company there's something wrong somewhere? (Not necessarily the developers, mind you).
In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything".
If you missed estimates without agile/sprints, and now miss estimates with agile/sprints, you may think "well, at least we're doing industry standard practices now - estimates are always gonna be missed anyway, but now we're more agile".
But now you have the attendant overhead of planning/meetings which is using up time that could be better spent somewhere else.
Something not necessarily mentioned too much that I see, is that if you actually have all those people (PM, PO, tech/dev lead, etc), is that they all have to be good/skilled and generally on the same page. If two are good and one is bad, it's all bad. The system is only as good as the weakest participant.
> In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything".
This is true regardless of whether they use sprints or not. Such a project is doomed regardless. I don't think any methodology will fix a project where most of the team is coasting, don't want to do the real work, or do not believe in the end goal.
> The system is only as good as the weakest participant.
I agree about this weakness! I think this is a reality of any software development endeavor.
How would it be better without sprints, though? One thing agile proponents claim, which I think has at least a measure of truth, is that agile doesn't make projects succeed, but it does make problems visible earlier. I think we can all agree visibility is a good thing?
So let's take the perfect project: all devs and stakeholders are stars, they never make mistakes, their customers understand their own needs perfectly, the budget is just right, no errors at all anywhere. This idyllic project needs no "methodology": no sprints, no managers, no nothing.
The problem is that the above project doesn't exist. Back in the real world, where people are fallible, mistakes are made and misunderstandings abound, how can we surface those problems as early as possible, when they are less costly to fix? (when possible, of course -- some projects are doomed regardless)
kanban, deliver something when it's done (even incremental when possible), fast feedback...
The notion of "here's what we'll do in the next X weeks" takes a certain amount of planning which (imo) is often better spent just doing first. As/when issues/questions come up, they need to be addressed then, not waiting.
You surface the problems early by some planning, then some work, then some feedback. "Sprint boundaries" don't seem to help in any of that. They help other people who want to know when something might be 'done', but it doesn't help me get feedback or clarify misunderstandings any faster.
Kanban is good for some situations, but in my experience the problems of a weak team (or lack of vision of the big picture) only get exacerbated with this methodology.
Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.
And... in my experience, 'sprints-point-cards-planning-estimating' can also be a recipe for having the team on a constant death march to burnout. Doesn't mean it always is, but... find what works for the team. Let the team decide. I'd go further and say "let the people doing the bulk of the code work make these decisions first". Make process adjustments after some baselines are established to see if those adjustments are worth it or not.
Death marches can happen regardless of the methodologies used to get there. I've seen death marches up close before the word 'agile' was even a thing in the software world (and have seen it well after, in 'agile' organizations). If the team decides to not do any work for a day because. they're exhausted.... let them have it.
Being the person to say "let's stop doing X and do something different" has generally not served me well in team settings. Whether or not others on the team agree or even care, they often don't want to be vocal about stuff, and would rather just punch in and do some work and go home.
The psychology around "team decisions" is a weird one, and I don't think there's always as much 'group buy in' or consensus as people might think.
