Dizemos que estamos aplicando o Scrum em escala quando temos mais de um time trabalhando no mesmo projeto. Isso geralmente acontece quando é solicitado para o projeto um passo mais rápido de desenvolvimento, ou é solicitado mais outputs/valor.
Antes de mais nada é muito importante lembrar que as regras do SCRUM permanecem válidas para a aplicação do Scrum em escala.
Uma regra fundamental que ocorre nesta modalidade é:
1 Produto = 1 Product Backlog = 1 Product Owner
ou seja, não importa quantos times estejam trabalhando no mesmo projeto, eles irão responder ao mesmo Product Owner e trabalhar com os itens do mesmo Product Backlog! Porém… Cada time terá seu Sprint Backlog.
E é só um Scrum master? Não, você pode ter mais de um Scrum master trabalhando com os times nesta situação.
Com certeza já ouviram a máxima de: “time que está ganhando não se mexe” certo?
Pois bem, aqui ela é mais ou menos válida também!! rs O que isso quer dizer?
Toda vez que fizermos qualquer mudança em um time Scrum, teremos ao menos uma redução de velocidade momentânea! (a esperança é que depois acelere)- isso se deve ao fato dos times terem que entender como se dividir, como dividir as tarefas, como alinhar as dependências…. enfim entender como é que vão implementar o projeto sem se matarem e atrapalharem rs!
Neste cenário de escala um termo aparece muito é é muito importante: dependência.
O time Scrum deve trabalhar ao máximo para reduzir as dependências entre eles e o que estão fazendo, da forma mais transparente possível, isso irá ajudar na integração dos incrementos de cada time, que deverá ser integrado já que todos os incrementos devem ser aplicados sobre os incrementos anteriores, além de serem testados, usáveis e potencialmente liberados para produção (lembram?!)
Indo nessa linha aqui também vale que: 1 PRODUTO = 1 DEFINIÇÃO DE PRONTO!
Não há nenhum requisito que diga que os Sprints dos times devam ser casados, porém ajuda né!? rs Assim como ajuda os times serem funcionais, ou seja, capazes de mexerem em todas as camadas necessárias do projeto, não em componentes especificos.
Complexo? rsrs
No meio disso tudo os times tem que se atentarem aos débitos técnicos que são os ‘cambalachos’, ‘jeitinhos’, ‘correções de última hora’ que são feitas, que podem (e geralmente vão) afetar próximas entregas. Esses pontos devem ser sempre alinhados entre os desenvolvedores e o Product Owner e sempre sempre deve ter algum item desses que deve ser puxado do Product backlog para ser ajustado.