При переходе в продакшн аджайл завершается?

А как component ownership в продакшкне мешает шарингу знаний о компоненте?

У команды поддержки обычно другие знания - про баги, условия появления и частоту, про обходные пути

А почему тогда он не Окей в разработке?

Потому что тогда знания оседают в одной команде, отвечающей за разработку компонента

а тоже самое не происходит с фичами?

И они могут нагородить так что им только заблагорассудится, ибо никто не будет внутрь заглядывать

Так фичи маленькими же должны быть)

никто не мешает городить забор маленьких фичах и знание о разработке живёт так же в изолированной структуре команды, просто её называют фича-тим?

Так команда же не единолично решает над чем работать, а на общем планнинге. Если остальные команды ок с тем что те копаются в одном и том же никого туда не пуская, несмотря на все подсвеченные риски, то вопрос скорее к другим командам, а не к этой)

Ну вот пример, 10 команд, каждая берёт в разработку некую задачу (не фичу как готовое решение, т.к. на уровне планинга - ответа на вопрос HOW ещё нет, а фичу как задачу).
маленькая фича в которой (кусок дата модели, логика, конфигурация и немного интеграций), к примеру L1 "шина" которая отвечает за единственную активацию порта на AAA Cisco ), знание осталось исключительно в этой команде, фича ушла в прод.  
Вопрос, чем изолированное знание о разработке фичи в фиче-команде А, отличается от изолированного знания в компонент-команде Б?

Да, вижен у фиче команд пошире, но шарингу я не понимаю как это помогает, если эта "ФИЧА" лонг тёрм (очень БОЛЬШАЯ такая фича похожая на эпик и которая умещается не меньше чем в 3 спринта) кто-то решил продолжить работу над фичей, то команде придётся топать в команду А и так же перенимать знания:
1. Почему в папке Classes так много всего
2. Кто додумался посредние файла в 1500 строк (реальный пример) воткнуть jump
3. И т.п. :)
Но то же самое происходит и с компонентой, только копать дольше и сложнее.

3 спринта одной команды?

ну это была ирония, т.к. если команда делает фичу 3 спринта, то что то тут не по SMART

когда команда обучается новой области — это не потеря, она повышает свои компетенции, при этом делает самые важные PBI. А когда в течение спринта команда зависит от другой команды за которой компонент — это сложность в коммуникациях, появляется необходимость управлять этой зависимостью, уменьшается автономия команд — в результате появляются потери в виде очередей, переключения, недоделанной работы

я с Вашего позволения порублю месадж на несколько
1. а фичи не могут иметь зависимости?
2. Я не говорил что это потеря, я говорил будь то фича или компонент команда, решение которое делается здесь и сейчас —изолировано— и что бы его понять "не важно какого типа команда" придётся потратить время и запустить другую команду в код другой и тут несколько вопросов:
- а что за кейс такой? (т.е. есть прод и команба Б просто что бы фиксить что то идёт изучать) или она на пленинги приходит в команду А и говорит, мы забираем овнершип этой фичи? или как то иначе?
-  в чём собственно отличие, что фичу команда будет копать что компоненту?! (ну разве только в специфике глубокой)
3. Автономия - довольно контекстная штука, но допустим да "хотя конечно спорно".
4. управление комуникациями это всегда эффорт, что в фиче что в компонент тимах, этот оверхед снижается или увеличивается при наличии дисфункций, но имхо не вижу как на это влияет архитектура.

по п.2 я не про тестирование Е2Е итак понятно что шарится на всех

Не совсем понял вопрос 2, но попробую расписать кейс.
2. До планинга на пбр команда, не имеющая знаний в компоненте погружается в этот компонент в контексте PBI и все на этом. Да, команде-ментору по компоненту придется потратить время на введение в курс дела другой команды

Ну а как ты определишь чей баг?

Фича, компонента