De acordo com Mike Cohn, autor de Agile Estimating and Planning, a reunião Scrum of Scrums (SoS) "é uma importante técnica para escalar Scrum em grande times e projetos. Essas reuniões permitem agrupar os times para discutir seus trabalhos, focando especialmente em área de sobreposição e integração."
Allan Shalloway está escrevendo um novo livro "Lean Software Development: Scaling Agile to the Enterprise" e ele perguntou sobre a experiência das pessoas quanto ao uso de "Scrum-of-Scrums para coordenar times (no qual eu fui bem sucedido) vs ecalar Scrum para corporações (que várias pessoas disseram que não conseguiram aplicar por uma variedade de razões)." Alan vê problemas para praticar Scrum com grupos grandes (350 pessoas por exemplo). Neste caso há vários diferentes produtos sendo construídos com componentes compartilhados. Ele cita 3 exemplos de problemas que ocorreram:
- Nível Técnico. Dado que estávamos fazendo desenvolvimento iterativo, os times esperam seguir princípios de design emergente. Isso significa que etamos escrevendo código de qualidade, mas não adicionamos funcionalidade ou design até que eles sejam necessários. O Time A escreveu um encriptador sem o uso de uma interface simplesmente porque eles precisavam apenas de 1 tipo. O Time B depois precisou de um encriptador que era levemente diferente do encriptador do Time A. A melhor forma de proceder seria o time A modificar seu código e assim, passar a ter uma interface para o encriptador - algo que não era necessário antes. Primeiro, é bem provável que o Time B nem mesmo saberia sobre isso. Mas mesmo que ele soubessem, o Time A não tem nenhum incentivo para ajudá-los a modificar seu código.
- Nível Inter Times. A forma como os times trabalham juntos quando há diferentes Product Owners e Scrum Masters para cada time, nem sempre é tão óbvia. Mais uma vez, uma visão mais abrangente ajuda. Isso é especialmente verdade quando há um time de componentes fazendo trabalho de suporte para vários outros times. Orientar-se através de business value requer olhar através dos product owners. Eles podem cooperar, porém, mais uma vez, eles podem não cooperar.
- Nível de Estrutura do Time. Muitos times scrum trabalhando juntos tem problemas sérios para entregar uma funcionalidade final quando muitos times estão envolvidos. Eu vi 3 times separados, um composto de pessoas de UI, um de pessoas de camada de regras e lógica e um composto por pessoas de banco de dados, ficaram muito mais efetivos quando eles foram reorganizados em 3 diferentes times separados por funcionalidades. As pessoas nos grupos re-organizados ainda executavam mais ou menos as mesmas funções mas agoram eram capazes de mover pelas as funcionalidades, não partes de funcionalidade que estavam em uma camada. Isso causou alguns problemas de integração entre times mas permitou que funcionalidades final fossem contruídas muito mais rápido. Isso também é o que Bas Vodde e Craig Larman recomendaram em: Escolha times de funcionalidades ao invés de Times de Componentes.
Mike Dwyer diz que prefere o SoS e Meta Scrums: "para coordenar a decomposição de estórias, de forma que assim você não termina com a mesma coisa construída por vários times. Aquelas coisas devem ser trabalhadas através de conversas diárias e frequentes que ocorrem em todos os níveis." Em sua experiência, times bem conduzidos focam na infraestrutura, dados e arquitetura para fazer um bom trabalho de reunir código compartilhado. Finalmente ele diz que product owners e gerentes trabalharem juntos é de importância vital para definir o tema do release, porque isso ajuda a dar direção e suporte para os times, quando eles precisam.
Ilja Preuß diz que SoS oferece valor para seus times: "isso nos ajuda a perceber o que acontece no sistema a partir dos outros times; isso ajuda a identificar as situações onde nós podemos ajudar uns aos outros; ajuda a identificar situação onde os times precisam de coordenação; e simplesmente ajuda a manter o sentimento de que nós estamos no mesmo barco e em manter as pessoas conectadas certificando-se de que pelo menos 1 membro de cada time veja 1 membro de cada um dos times uma vez por dia."
Christophe Louvion também usou SoS para gerenciar integrações diárias entre times. O time meta, composto de Engenheiros Sênior de subprojetos, era responsável por:
- definir padrões (APIs, SLAs, logging de erros, estrutura de repositório de código, processo de build automatizado, scripts de deployment automatizados utilizados por todos os times, etc)
- testes diários de integração (automatizados)
- cruzamento de código de subprodutos / revisões de arquitetura
- antes de um grande release, o time deveria disparar testes da base do design entre multiplos times para situações desconhecidas
O SoS era o primeiro time a iniciar, preparando o terreno para escalar. O time era extremamente experiênte. Ao longo do tempo, cada membro do SoS se tornou o líder dos times de subprodutos, trabalhando tanto a nível de SoS quanto no subproduto.
Finalmente Walter Bodwell compartilhou sua receita para o sucesso da reunião Scrum of Scrums: "Mantenha a reunião curta. 15 minutos no máximo. Mantenha-a focada. O que os outros querem/precisam ouvir? As duas primeiras questões que as pessoas respondem no SOS podem realmente ajudar na colaboração, tornando os outros cientes do que você está trabalhando no momento. Eles podem dar sugestões, te avisar de alguma coisa, etc. Mas discussões devem ser reservadas para uma reunião separada para manter a reunião curta e focada. Traga os problemas que bloqueiam para cada reunião SoS até que sejam resolvidos. Identificar e priorizar os bloqueios é um dos maiores benefícios do SoS." Pelo fato de que a SoS frequentemente acontece em diferentes fuso horários e com sotaques muito diferentes, ele acha que ajuda muito compartilhar uma pauta antecipadamente.