Exactly. And if somebody wants to complain about a process methodology not working because management at their company is stupid or a bunch of assholes: nothing fixes that.
90% of the time the cure for needing to do "undercover" work is explaining that it is needed to accomplish what the company expects to get out of a task. It often happens that incorrect assumptions get embedded in a plan, and an engineer is asked to do X on the assumption that doing X will also accomplish Z, and they think, "Ugh, they want me to do X but they won't give me time to do Y and Z, what the fuck do I do, Z isn't going to get done and then it will be my fault because I was tasked to do X and they think that's the same thing." Just communicate: "I think what is expected is that if we do X then Z will also be accomplished. In this case, doing X won't accomplish Z. We will also need to do Y and Z, which is additional work."
Then if they say, "Just do X," you don't have to fret about Y and Z, because you have set expectations appropriately. In a dysfunctional environment, where the scrum master or project manager is mechanically executing a process without knowing what any of it means, you may need to escalate or reach out beyond the team to find somebody who appreciates your warning that X will not accomplish Z.
Of course there may be no such person, but in that case, no process will save you.
I've even seen this used effectively to talk about technical debt. "Look, I think the assumption in management is that we're making progress on moving away from the legacy services and deprecating our old auth solution, but in fact, if we do this we will be making ourselves even more dependent on the legacy services, and we'll be adding new public APIs that can't be properly secured. I just want to be sure that [manager's name] is aware that that is how we're shaving a month off this plan." Needle scratch, management wasn't aware that there was any downside to the expedited plan that project management had squeezed out of the engineers, because project management did not understand the language of technical debt. It was all engineer blah blah to them, and it didn't occur to them that management needed to hear it.