Как правильно релизиться в больших компаниях?
1. Фича-тим это хороший инструмент менеджера, для синхронизации технических решений и соответственно снижения рисков. В одновременные релизы разных команд я не верю.
2. С "версионностью" мне кажется не так много сложностей на самом деле. 
Если воспринимать результат работы каждой команды как какой-то сервис с api наружу (а так наверное и есть), то по сути от команд требуется обеспечивать обратную совместимость новых версий api со старыми - задача которая в любом случае полезна. 
Делать версионность без обратной совместимости - очень плохая идея как мне кажется. Тут и затраты на поддержку, и затраты на переподключение у всех остальных команд.
Еще очень важно, чтобы был вменяемый CTO / архитектор всего этого зоопарка. Ну или хотя бы просто был.
Видел живые проекты где не было продумано общей архитектуры, - поверх слоя основных сервисов по бизнес требованиям писался 2й слой, через годик поверх 2го слоя писался 3й, ... в итоге к нашей эре слоев было ~12 и как это точно работает не знал мне кажется никто, - что впрочем не мешало проекту иметь десятки миллионов пользователей.
Многие рекомендуют постоянные команды. Т.е. фича тим не собирается под фичу, а на команду назначается фича. После разработки фичи команда остается той же просто ей дается другая фича.
Можно делать "внутренний опернсурс" - допустим у вас компонентные команды, но при этом одной команде понадобилась фича в компоненте другой команды. Она может  предложить патч для этого компонента, а другая команда рассмотрит его, накатит на компонент либо отвергнет.
см также
https://www.thoughtworks.com/mingle/scaled-agile/2...
www.discussagile.com/blog/dependency-management-in...
https://www.scaledagileframework.com/value-stream-...