Какие подходы традиционно использовались в организациях? (и до сих пор их можно встретить в государственных или очень крупных корпорациях)
Сначала были команды-отделы (аналитики, разработчики и т.д.), так называемы "функциональные колодцы". С началом движения Agile договорились, что при таком подходе любая работа занимает слишком много времени на координацию для её завершения. И такие команды в современных организациях остаются только, если:

1. компетенцию очень сложно передать другим (data science, compliance и cybersecurity и т.д.);
2. такие люди нужны в команде ооочень редко и нет смысла их заводить в какую-то команду (финансисты, HR, бухгалтерия).

Такие команды можно оставлять, если зависимости на них от других команд минимальны при создании ценности. Большая же часть команд должна быть кросс-функциональной.

Т.е.получаем команду или группу команд, внутри каждой из которых есть все необходимые компетенции (тестирование, разработка и т.д.) и каждая может независимо делать доработки. Но, зачастую, только какой-то одной компоненты/сервиса/системы (редко нескольких), т.е. команды-компоненты/системы. В таких случаях, доработка на этой системе проходит достаточно хорошо. А вот бизнес смысла нет (мы сейчас не говорим про доработки "монолитов", когда любой бизнес функционал делается в общем коде). Только вот почти любая бизнес задача требует разработки на нескольких системах/компонентах. И, в итоге, опять требует больших затрат на координацию и приоритизацию.
Где сейчас имеет смысл держать такие команды:

1. монолиты, не разбитые на компоненты/сервисы;
2. независимые системы (обычно на этапе создания какой-то функции, до входа в общий ландшафт организации);
3. legacy системы. Если систему собираются выводить из эксплуатации, то обучать работе с ней другие команды невыгодно и остается команда, которая "проводит систему в последний путь".

Некоторые говорят, что сейчас этот подход пропагандирует SAFe, но там сложнее. Разберем позже.

Следующим подходом, а иногда в параллель с предыдущим, стали кросс-компонетные команды. Но, опять же, для того, чтобы команды меньше тратили времени на обучение и больше на разработку, появились специализации по бизнес функционалу. Например, одна команда пишет корзину, другая обработку платежа, третья списки. На старте чего-то большого это хорошо, т.к. для всех есть критически важный функционал и вроде все по большей части независимы. Однако, здесь появляется другая проблема. Со временем происходит снижение поставляемой ценности, и команда начинает придумывать себе задачи, вместо того, чтобы переключиться на самое важное для продукта в целом. И мало кто может заметить этот момент. Особенно, если есть деньги и можно не особо вдаваться в детали какой возврат на инвестиции от команды идет. Это постоянно случается в крупных компаниях, где деньги берутся из общей копилки и никто не хочет терять подчиненных. Такие команды-функции хороши и полезны когда:

1. нужно довести до работоспособности много функций нового процесса быстро и параллельно;
2. во время миграции со старой платформы на новую, чтобы быстро сделать самые важные блоки.

Чтобы избежать снижения прозрачности и дисфункций предыдущего подхода руководство может внедрить различного рода контроли. Например cost/value подход. Сам по себе он неплох, но структура все равно будет направлять команды на разного рода дисфункции. Чтобы это системно полечить, компании со временем начинают использовать подходы к структуре из LeSS. Где команды становятся полностью end-to-end и кросс-функциональны, так называемые feature-teams. И каждая команда может взять любую задачу из списка самых приоритетных по "продукту". Это конечно дороже чем предыдущий подход, за счет того, что люди тратят больше времени на обучение. Однако, это окупается за счет работы на самое ценное вместо непонятных "бантиков". Понятно, что когда приходят новые "большие задачи", команды ради скорости могут вернуться к предыдущему подходу. Но потом снова нужно будет развиваться до этого типа.
Подобную структуру рекомендуют когда:

1. есть дисбаланс в функциональности для реализации и нужно многими командами сделать доработки в одной области;
2. рыночные потребности часто меняются и нужно быть очень гибкими, быстро переключаясь на развитие различного функционала;
3. команды долгое время работают в своих функциях и необходимо убрать функциональный "феодализм".