Scrum of Scrums – A importância do sincronismo entre times

A reunião Scrum of Scrums (SoS) é um evento que acontece em projetos ágeis em larga escala, e colabora com a comunicação, gestão de dependências entre ARTs (Agile Release Train), visibilidade do progresso em relação aos milestones, objetivos da PI  e impedimentos dos times.

Das várias estruturas de ágil escalado atual, o Scrum of Scrums (SoS) ainda é o mais antigo e o mais usado onde Jeff Sutherland e Ken Schwaber são os dois indivíduos creditados com a introdução deste evento.

Introdução ao Scrum of Scrums

Jeff Sutherland tem a seguinte definição da SoS:

Enquanto os eventos do Scrum continuam ocorrendo (planning, daily, review e retro) e os times executando o backlog das Sprints, na Scrum of Scrum o SM (Scrum Master) de cada time com o RTE (Release Train Engineer), famoso líder servo e coach do ART, facilita este evento e os processos, apoiando os times na entrega de valor.

Vale aqui iniciar detalhando alguns pontos importantes e boas práticas relacionadas ao formato de uma reunião Scrum of Scrum:

Frequência

• Semanalmente ou com maior frequência (se necessário).

Duração

• 30 minutos seguida da “meet after” em eventuais resoluções de problemas.

Participantes

• RTE (Release Train Engineer);
• SMs (Scrum Masters);
• Outros (quando necessário).

Facilitador da reunião

• RTE (Release Train Engineer)

Agenda de uma Scrum of Scrums

De acordo com o SAFe (ScaledAgileFramework), a proposta de agenda para uma reunião Scrum Of Scrum seria a seguinte:

Objetivamente, a reunião Scrum of Scrum deve ter ênfase nos times (objetivos da Sprint) e resolver seus impedimentos, não devendo ser uma reunião de status report, ou seja, do progresso do time de desenvolvimento aos gestores.

Algumas questões que devem ser tratadas na SoS:

• O que seu time realizou desde a última reunião?
• Dos problemas encontrados, algum afetou significativamente seu time?
• As dependências estão resolvidas ou endereçadas?
• Alguma preocupação com o trabalho de outros times?
• O que sua equipe deseja realizar antes da próxima reunião?
• A velocidade foi estabelecida para o time?
• Todas as histórias já foram escritas e estimadas?
• As ferramentas de gestão ágil estão sendo preenchidas?

O Scrum of Scrums é uma técnica ágil que deve ser entendida como uma forma para integrar o trabalho de vários times de scrum (geralmente de cinco a nove membros cada) trabalhando no mesmo projeto.

Ela permite que as equipes se comuniquem umas com as outras para garantir que a saída do incremento de cada equipe se integre bem à saída das outras equipes, e especialmente nas áreas em que há sobreposição ou a sequência de eventos é importante.

Executando uma Scrum of Scrums

A coordenação das várias equipes é realizada em uma reunião do Scrum of Scrums, que pode ser realizada diariamente, duas vezes por semana, ou no mínimo uma vez por semana onde cada equipe Scrum possui o seu Scrum Master ou um membro designado a participar da reunião.

Se o material que uma equipe em particular deseja discutir é altamente técnico, tanto o Scrum Master quanto um membro da equipe tecnicamente qualificado podem e devem participar.

Essa reunião é realizada de maneira muito semelhante à reunião do Daily Scrum que cada equipe realiza diariamente, mas não se limita a um timebox de quinze minutos.

O objetivo da reunião Scrum of Scrums é garantir a coordenação e a integração dos resultados das várias equipes, eliminando todos os impedimentos. Isso pode envolver duas ou mais equipes trabalhando juntas por um tempo, renegociando áreas de responsabilidade e assim por diante.

Para acompanhar tudo isso, é importante que a Scrum of Scrums possua um Backlog de Produto próprio para ser mantido pelo RTE (Release Train Engineer).

Scrum of Scrums em grandes organizações

Uma estrutura SoS pode ser eficaz mesmo em organizações maiores com muitas equipes múltiplas, desde que as reuniões sejam conduzidas adequadamente.

Seu objetivo deve ser garantir que as equipes individuais cumpram os objetivos da Sprint e que o objetivo geral do projeto de todas as equipes seja atingido.

Problemas e Valores da Scrum of Scrums

Allan Shalloway escreveu 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 x Escalar Scrum para corporações, onde 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 praticando o 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.

Veja o exemplo abaixo:

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 o trabalho de suporte para vários outros times. Orientar-se através de Business Value requer olhar através dos Product Owners.

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.

Imagine 3 times separados:

• Um composto de pessoas de UI;
• Um de camada de regras e lógica;
• Um composto por pessoas de banco de dados.

Esses 3 times ficaram muito mais efetivos quando 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 agora 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 permitiu que as funcionalidades finais fossem construídas muito rápido.

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 devem trabalharem juntos, sendo 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 a reunião Scrum of Scrum oferece valor para seus times da seguinte forma:

• Perceber o que acontece no sistema a partir dos outros times;

• Identificar as situações onde nós podemos ajudar uns aos outros;

• Identificar situação onde os times precisam de coordenação;

• 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 era 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 múltiplos times para situações desconhecidas.

Discussões devem ser reservadas para uma reunião separada com o objetivo de manter a reunião curta e focada. Traga os problemas bloqueadores para cada reunião SoS até que sejam resolvidos. Identificar e priorizar os bloqueios é um dos maiores benefícios da reunião Scrum of Scrum.

Ainda devemos levar em consideração que, 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.

Referências

• https://www.agilest.org/scaled-agile/scrum-of-scrums/
• https://www.infoq.com/br/news/2008/12/scrum-of-scrums/
• https://leonardo-matsumota.com/2018/09/19/agil-em-larga-escala-scrum-of-scrums-sos-meeting/