Scrum é uma metodologia de gerenciamento ágil de projetos que vem ganhando popularidade nos últimos anos, utilizado principalmente em projetos de desenvolvimento de software, onde o grau de incerteza e variação de escopo tendem a ser altos.
Assim como a maioria dos métodos ágeis, Scrum funciona melhor com times relativamente pequenos, até 7 ou 8 integrantes. Isso se deve em grande parte ao fato de que a comunicação direta e constante é um dos fundamentos do método. Quando o time cresce acima desse limite – que como tudo no Scrum, é empírico – o esforço de comunicação começa a se tornar gradativamente maior, as informações tendem a fluir mais lentamente e começa a ser necessário empregar outros mecanismos para garantir que os stakeholders recebam as informações de que necessitam. Em resumo, a eficiência começa a cair gradativamente.
Considere ainda que, em diversos projetos, não é possivel ter todo o time compartilhando o mesmo ambiente físico. Em alguns casos, as equipe podem estar inclusive em países e fusos horários diferentes, o que dificulta ainda mais a comunicação e interação entre os integrantes da equipe.
Uma das soluções proposta por Ken Schwaber, um dos criadores do Scrum, em seu livro ‘Agile Project Management with Scrum’ (que recomendo fortemente) para aplicar Scrum em equipe maiores é o chamado ‘Scrum of Scrums’. Em resumo, significa quebrar o time em equipes menores, multi-disciplinares, evitando assim os ‘silos de competências’. Esses times menores, que estarão dentro do limite de integrantes recomendado, devem ser auto-suficiêntes, no sentido de serem capazes de entregar conjuntos completos de funcionalidade a cada Sprint.
Para sincronizar os esforços dos diversos times, os Scrum Masters de cada equipe devem se reunir no equivalente a ‘Daily Metting’ - participam apenas os representantes de cada time, e o Scrum Master Principal. Nessa reunião também se aplicam os mesmos principios da original: Os representantes de cada equipe dizem o que o foi realizado desde a reunião anterior, em que irão trabalhar até a próxima, e o que está impedindo-os de realizar seu trabalho ou obter o máximo desempenho. Para auxiliar as diversas equipes, é recomendado que exista a figura do Scrum Master central. Este herda as mesmas atribuições dos Scrum Masters no Scrum tradicional, mas seu compromisso é relativo ao conjunto dos times. Por exemplo, se diversas equipes reportam problemas com o ambiente de homologação, é seu papel conseguir (de alguma forma) que esse impedimento seja removido. As retrospectivas, que ocorrem no final de cada Sprint também devem ser realizadas de forma semelhante, com os representantes de cada time.
Para isso, algumas condicões devem ser observadas. Em especial, o projeto deve ser passível de ser divido em funcionalidades e essas distribuídas aos diversos times, o que nem sempre é simples. É preciso também criar uma arquitetura inicial, padrões e práticas claras de engenharia, de forma a evitar que o sistema se torne uma colcha de retalhos.
Em seu livro, Ken menciona algumas equipes que utilizaram, com sucesso, um ‘Sprint Zero’, onde especialistas (engenheiros seniores) foram responsáveis por criar uma arquitetura inicial, além de definir os padrões que seriam utilizados no restante do projeto. Nos Sprints seguintes, cada um dos diversos times que foram formados recebeu pelo menos um dos integrantes do ‘Sprint Zero’, que se tornou responsável por disseminar o conhecimento da arquitetura e garantir a aderência das novas funcionalidades desenvolvidas aos padrões e práticas de engenharia de software. Esses integrantes se tornaram a ponte para disseminar a visão comum do projeto entre os times.
Claro, coordenar os esforços de um conjunto de equipes tende a ser um desafio maior do que em times simples – e exigirá deles, Scrum Master e Product Owner as conhecidas adaptabilidade, flexibilidade e criatividade tão conhecidas no Scrum. Caberá ao time do projeto bolar soluções para os problemas que surgirem, não apenas nas questões técnicas mas também em aspectos como comunicação e integração, fatores críticos ao sucesso de qualquer projeto, e em especial para equipes geograficamente separadas. Soluções criativas como blogs, wikis, programas de mensagens instantâneas podem auxiliar bastante. Existem opções gratuitas para todas essas ferramentas. Pessoalmente, recomendo ainda que a reunião diária seja realizada utilizando uma ferramenta de video-conferência, ou no mínimo, com de um conference-call. Uma conversa de alguns minutos pode eliminar algumas dezenas de e-mails.
