Iniciado os estudos para Certificação Scrum, me deparo com boa parte que acabei aprendendo mas não utilizando, como o Scrum of Scrums (SoS) , que nada mais é que uma importante técnica para escalar Scrum em grande times e projetos.  Trabalhada em reuniões que permitem agrupar os times para discutir seus trabalhos, focando especialmente em área de sobreposição e integração.”

Definição

Uma técnica para escalar Scrum em grupos grandes (mais de 6 pessoas), consistindo em dividir os grupos em equipes Agile de 5-10. Cada Daily dentro de uma sub-equipe termina designando um membro como “embaixador” para participar de uma reunião diária com embaixadores de outras equipes, chamado Scrum of Scrums.

Dependendo do contexto, os embaixadores podem ser contribuidores técnicos, ou Scrum Master de cada equipe, ou gerentes de cada equipe.

O Scrum of Scrums transcorre como uma reunião diária normal, com os embaixadores que informam as conclusões, as próximas etapas e impedimentos em nome das equipes que representam. Espera-se que a resolução de impedimentos se centre nos desafios da coordenação entre as equipes; As soluções podem implicar concordar com interfaces entre equipes, negociar limites de responsabilidade, …

O Scrum of Scrum realiza seu acompanhamento dos itens através de um backlog próprio, onde cada item contribui para melhorar a coordenação entre equipes. Neste ponto consigo ver várias oportunidades de implementações em equipes de Sustentação de Sistemas, como a que eu trabalho hoje.

Lendo diversos artigos para buscar entender limitações e pontos onde a aplicação venha a aparesentar baixa performance ou qualquer entrave, cheguei a Allan Shalloway, que preve alguns problemas em praticar Scrum com grupos grandes (350 pessoas ou mais). 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 estamos escrevendo código de qualidade, mas não adicionamos funcionalidade ou design até que eles sejam necessários.
  • 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.

Já Mike Dwyer diz preferir 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.

O que mais acabaremos encontrando como receita para o sucesso da reunião Scrum of Scrums será o que todos já devemos ter em mente: “Manter a reunião curta. 15 minutos no máximo. Mantenha-a focada. O que os outros querem/precisam ouvir? 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.

Espero que tenham costado e que curtam. Conforme meu aprofundamento na metodologia e a leitura e entendimento do SBOK irei compartilhar mais conhecimento.

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/