That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.
And it’s something that good devs will already be trying to accomplish anyway. There’s also the part about breaking stuff down into small parts so that small cycles of meaningful dev can be accomplished. But that’s mainly to be able to release small and often - another thing you should already be doing to incrementally update your app avoiding big releases. It also stands in the face of waterfall development, though I see lots of teams doing test at the end still, making it waterfally.
I also see too many agile teams that have iterations that never finish, get feedback in prod, create half complete features that are weird or don’t gel - all in the name of agile.
I think the kids that get it were already doing it as it’s common sense. The rest end up sticking an agile badge on their practices when it’s all but.
The patron wants more, the creator doesn't want to create more, so you need to force a detente so the patron will continue to pay the creator, and the creator will continue to produce.
You get t-shirt sizes and points when the patron feels the creators aren't doing what they said they'd do, so in a way it's a communication problem, yes, but the cause of the communication problem is that there is almost never an alignment between the two groups, and so you need some kind of shared language where expectations can translate, and accountability can exist at all, usually in some flawed form.
The problem, in my experience, is many development contracts are still structured in such a way that this becomes too difficult. Management fearing early exposure to the customer will lead to scope creep and cost growth.