Não há conceito de "clara visão arquitetônica" no Scrum ou no ágil!
Sou arquiteto há muito tempo e está claro para mim que, para ter uma visão arquitetônica, é necessário ter uma visão clara dos requisitos futuros. Como na maioria dos casos, os requisitos não são claros, não faz sentido ter uma visão fixa.
O que é necessário é ter uma arquitetura que seja adaptável o suficiente às mudanças nos requisitos. Em outras palavras, as coisas mudam e a arquitetura muda - não estou defendendo uma arquitetura "flexível" que possa ser reconfigurada. Estou falando de aceitar que a arquitetura que temos hoje será obsoleta em breve e precisará ser alterada, para que ninguém "se case" com ela.
A propriedade do código coletivo significa que todos deveriam - em teoria - ser capazes de mudar qualquer coisa. Isso deve ser entendido como o "oposto de silos". Em outras palavras, pode haver uma barreira de habilidades, o que é normal e esperado - nem todo mundo é um DBA experiente que pode ajustar as consultas SQL, para dar um exemplo - mas a partir disso, não se segue que apenas um DBA pode mão otimizar consultas. Haverá um "especialista em domínio de recursos" que pode ajudar outras pessoas a se tornarem proficientes, mas as tarefas ainda devem recair sobre todos.
Por exemplo: se eu sou especialista em domínio no recurso "A", ainda espero que alguém trabalhe no recurso "A", mas provavelmente será consultado quando houver grandes alterações ou quando as pessoas precisarem de ajuda. O recurso "A" certamente não seria o meu recurso. Será um recurso que eu conheço bem. Será do meu interesse conhecer muitos outros recursos e o interesse de outras pessoas conhecer esse recurso.
Em síntese: a arquitetura é projetada e redesenhada várias vezes pelos desenvolvedores conforme os requisitos surgem e mudam. Todos devem fazer as alterações necessárias de acordo com suas habilidades e saber quando pedir ajuda. Não há visão de longo prazo sobre a arquitetura, porque confiamos nas pessoas e não confiamos nos requisitos .