Sorry, I Can't Talk to You This Iteration

No, seriously, I actually heard that on a project once upon a time.
The client’s team had gotten far too focused on capacity and lost sight of delivery. Management wanted more stuff faster, so they focused on full utilization and commitment. As a result they were in a place where time for collaboration, knowledge transfer, and you know, teamwork had to be scheduled. Management had clearly lost sight that 100% utilization means no slack for conversations. They’d missed the problem that 100% utilization turns freeways—and software teams—into parking lots.

Intended or not, teams and individuals on the project ran with that mindset to an extreme. Collaboration and cross-team assistance fell off drastically, as did the sense of a shared goal: working software delivered to the customers.
Such an emphasis on capacity and commitment isn’t healthy. I’ll go so far to say it’s a cancer. Regardless whether you’re “agile” (whatever that means), waterfall, or something else, you must leave slack time in your schedule. Without slack you’ll never get your teams working on the most important aspect of any software methodology: continual improvement and adaptation.

Healing up this mindset and culture isn’t easy. It’s an issue with management’s pressure and unreasonable expectations. That can be a result of a lack of skills with the delivery teams’ ability to ship; however, honest change needs time for that change.
Generally management is open to discussions around impacts to delivery or business value. Remember, misguided as the decisions might be, they’re an attempt to meet deliverables and ship software. Frame your case in that context and you might have some luck.
Start gathering hard data around situations like:

1. Work items blocked by inability to get time for discussions. Can’t get time with Team <X> to discuss the API work item you’re on right now? Note that and consolidate with other data.
2. Work items slipping past the iteration. Are those blockages from #0 bad enough that you can’t finish your work? Make sure the reason behind it is clear to people up the chain.
3. Lack of knowledge transfer. Shared codebases are critical, even on large projects. Can’t get time to understand critical aspects of what you’re working on? Document, escalate.

Make sure you’re approaching this from a positive, not negative, direction. Don’t even get out of bed if you’re planning on a “This is stupid and everyone sucks!” pitch. Instead, frame it as “Look, this is costing us <X> hours, <Y> blocked user stories, and <Z> <fill_in_blank/>.”
Additionally, come to the table with a suggested approach for fixing it. “Look, can we reserve some slack time each iteration for more ad-hoc discussions? Having some honest time for collaboration will help us prevent the <X> hours lost, <Y> blocked stories, and <Y><fill_in_blank/> we’ve seen the last couple iterations.”
Every team’s primary focus should be working software in production. Blocks to effective communication and collaboration are a direct impediment to that. Work to cure that cancer!