To take the typical scrum/agile method as our context...
First and foremost, you're supposed to deliver things that have value. In most cases though, this is very much a "soft science". You can have an incredibly full backlog of items with things nobody asked for, as the feedback loop after a release is often non-existing and the team is working on the next thing already.
Likewise, issues (due to laziness or incompetence) are super easy to mask. The engineer can call out some unexpected dependencies, setbacks, unclarities in the story (shifting blame), hardware issues, the list of excuses is endless. It's not like the PM understands any of it, so "it is what it is". The story is moved to the next sprint, or is split in two.
Same for task estimation. In particular with a dynamic where the PM is technically clueless, which is common as a team holds a wide variety of tech skills nobody can understand in total, it's easy to inflate estimates. There's little to no incentive to stretch your productivity, in fact it's a type of self-harm. Because next you'd be expected to deliver at that stretch level forever. Better to under-perform a little, create some breathing room.
Quality: often unmanaged, as amount of story points delivered is typically a primary metric.
Now combine all this and you can have a team looking busy/productive whilst it's delivering nothing of value, too late, and with poor quality. Without setting of any alarm bells. The lack of value, productivity and quality is close to invisible.
Now imagine having dozens if not hundreds of such teams, lol.