Quando o Scrum é apresentado em uma organização, na maioria das vezes, a equipe de desenvolvimento abraça a ideia com muito entusiasmo. Afinal, o Scrum preconiza organização, autonomia, times multidisciplinares que reconhecem qualidades individuais, enfim, reforça pontos positivos para a equipe como um todo. Quem não gostaria de fazer parte de uma Equipe Scrum?
Entretanto, com muita frequência, após a “lua-de-mel" com o Scrum, começam a surgir comentários como:
“Desde que o Scrum começou só o que eu faço é ir em reuniões. Eu não me tornei um desenvolvedor para ficar em reuniões o dia inteiro.”
“Com o Scrum eu esperava que nós desenvolvêssemos a cultura de equipe, mas ao invés disso parece que desenvolvemos uma cultura de reuniões.”
“Eu pensava que as reuniões do Scrum tinham durações pré-definidas, mas, por exemplo, nossa reunião diária (daily Scrum) dura pelo menos 30 minutos e depois disso nós ainda não temos um plano concreto como a equipe.”
O Guia Scrum declara que os eventos pré-determinados (eles são propositalmente não chamados de reuniões) são usados para criar regularidade e para mitigar a necessidade de reuniões não previstas. Todos os eventos devem ter duração definida previamente, assim como todo evento tem uma duração máxima. As execuções (Sprints) tem duração de 1 mês e os eventos pré-determinados são:
Reuniões diárias (Daily Scrum): 15 minutos
Planejamento da execução (Sprint Planning): no máximo 8 horas
Revisão da execução (Sprint Review): no máximo 4 horas
Retrospectiva da execução (Sprint Retrospective): no máximo 3 horas
Refinamento das Pendências do Produto (Product Backlog Refinement): na média de 10% da capacidade da Equipe de Desenvolvimento
Considerando essas durações pré-definidas, nota-se que o Scrum não é um método, ou modelo, que resulte em uma cultura de reuniões. Então, o que é essa percepção de cultura de reuniões que frequente surge?
Razões que eu imagino para surgir essa percepção de uma “cultura de reuniões” no Scrum:
As reuniões não são controladas para ficarem dentro do tempo previsto. Mais tempo do que o previsto no Guia Scrum não deve ser necessário. É um alerta de que há algo errado.
Eventos do Scrum não têm uma estrutura clara. Sem uma estrutura (e uma pauta) claramente definida, fica difícil respeitar uma duração pré-definida e alcançar o resultado esperado.
A equipe não está devidamente preparada. Todo evento do Scrum requer a sua devida preparação pela Equipe. Para mim, essa não é somente uma característica do verdadeiro profissional, mas também um indicador de respeito com a equipe.
As reuniões não previstas no Scrum são valorizadas. É muito comum à equipe ter que atender outras reuniões além das reuniões previstas no Scrum, como por exemplo: apresentações para o nível estratégico da organização e as reuniões de “status” para o cliente. Elas são algumas vezes necessárias, mas devem ser evitadas, ou no mínimo limitadas, em termos de quantidade, o máximo possível.
Reuniões são marcadas desconsiderando a agenda do desenvolvedor. Para a maioria dos gerentes, frequentar reuniões intermináveis faz parte da sua função. Eles costumam “pular” de uma reunião para outra. No entanto, para um desenvolvedor a vida é diferente. Programar exige muito foco, consequentemente um tempo para se concentrar. Paradas sucessivas para reuniões (e não importa se elas são curtas) resultam em perda da concentração e necessidade de mais tempo para outro momento de concentração até atingir o foco anterior. E isso é uma das principais causas da improdutividade no trabalho.
Figura: Exemplo de reuniões colaborativas, divertidas e energizantes em eventos Scrum.
Como prevenir o Scrum para não ser percebido como um incentivador da “cultura de reuniões?
Os eventos do Scrum não são reuniões, mas oportunidades para uma conversa. Tobias Mayer descreve isso perfeitamente no seu livro “The Peoples Scrum”: “Scrum é centrado nas pessoas e pessoas conversam. Existem conversas para planejar, alinhar e para refletir. Nós devemos ter todas essas conversas, mas no tempo apropriado e com uma duração adequada, com o objetivo de instruir nosso trabalho. Se nós não temos essas conversas, não saberemos o que estamos fazendo (planejamento); não saberemos como estamos indo (alinhamento); e continuaremos repetindo os mesmos erros de sempre (reflexão).”
Cumpra as durações pré-definidas para os eventos do Scrum. Tome como exemplo as Reuniões Diárias; Eu acredito que esse evento, com frequência, excede a duração prevista, embora você somente aprenda realmente a fazer uma boa Reunião Diária, quando você respeitar os 15 minutos previstos para ela. Uma duração maior para essa reunião não garantirá que você consiga um bom alinhamento para a equipe ou crie um plano perfeito para o dia. Cumprir as durações pré-definidas para os eventos do Scrum, mesmo sem que os objetivos deles sejam atingidos, forçará a equipe a se comprometer e a focar em encontrar uma solução dentro do tempo previsto da próxima vez. É uma questão de educação. Além disso, se você não cumprir as durações, não haverá senso de urgência que faça você ou a sua equipe consertar esse comportamento no futuro.
Prepare o cronograma para os eventos do Scrum com antecedência e garanta que as metas de cada evento estão claras. Comunicar o cronograma com antecedência! – isso, por si só, já garante que todo membro da equipe tenha a oportunidade para se preparar adequadamente, além de demonstrar para toda a equipe que tipo de preparação você espera dela (ao estabelecer e divulgar claramente as metas de cada evento). Por exemplo, se alguém quiser apresentar uma “demo” de uma determinada funcionalidade de um Software em uma Revisão da execução (Sprint Review), saberá que deve comunicar a sua intenção com a maior brevidade possível para que seja reservado algum tempo para essa atividade no evento.
Não considere o Refinamento das Pendências do Produto (Product Backlog Refinement) um evento. O Guia Scrum descreve o Refinamento das Pendências do Produto como uma ação para adicionar detalhes, estimativas e definir ordem para os itens Pendentes do Produto (Product Backlog). O refinamento das pendências não é um componente formal da estrutura do Scrum, mas sim um processo contínuo para a melhoria das pendências do produto. Não deveria ser considerado uma reunião, mas sim uma atividade colaborativa da equipe para a análise e revisão dos itens pendentes do produto. A recomendação é: gaste em média 10% da capacidade da equipe de desenvolvimento no refinamento – a forma como deve ser feito não é prescrita, cabe a equipe definir.
Crie períodos de “Não perturbe!”. Durante esses períodos a equipe de desenvolvimento não terá qualquer reunião e somente será “perturbada” por alguém que não seja da equipe quando for realmente urgente. Certamente, isso não deve interferir na intenção de colaboração e transparência na comunicação que o time queira ou deva praticar, mas um balanceamento saudável com a necessidade de foco da equipe nas atividades de desenvolvimento do produto deve ser respeitado.
Garanta que a diversão esteja presente. Os eventos Scrum ou qualquer outro evento não-Scrum não devem ser chatos, maçantes ou sugadores de energia. Minha intenção é sempre encorajar a diversão, energia, interações e colaborações em cada evento. Algumas dicas simples para alcançar isso são (i) não usar aqueles “PowerPoints” espetaculosos; (ii) colocar as cadeiras em círculos e (iii) minimizar o uso de notebooks. Importante: não considere os eventos uma cerimônia com toda a pompa e cerimonial atrelado, mas sim uma oportunidade para colaborar, aprender e se divertir.
Crie um calendário de execuções (sprints). Dê transparência ao seu projeto por meio da criação de um calendário de execuções que contenha todos os eventos Scrum e outras reuniões. Isso permite à equipe ter a percepção do que é esperado deles durante as execuções e ajuda muito no planejamento das execuções. Algumas vezes a equipe achará que existem muitas reuniões previstas, mas um calendário de execuções transformará esse “achismo” em um fato, e com fatos é mais fácil lidar e gerenciar.
Aceite e se envolva com as reuniões com os clientes. Considerando o "modelo mental" dos Métodos Ágeis, a colaboração com o cliente é vital para o sucesso do desenvolvimento do produto. Assim, a relação com os clientes não deveria ser uma relação do tipo fornecedor-cliente, mas sim uma parceira onde o cliente é parte da equipe, como o desejo de contribuir para a criação de um “produto perfeito”. As reuniões com os clientes devem ser vistas como uma oportunidade para entender o por quê e o que é o produto para que as chances de sucessos aumentem.
Para mim, Scrum não significa a criação de uma cultura de reuniões. Tampouco algo radicalmente diferente dos métodos de gestão de projetos ou desenvolvimento de produtos tradicionais. Entretanto, eu consigo entender os argumentos das pessoas que frequentemente fazem essas comparações. É muito fácil transformar, ou distorcer, as recomendações dos métodos de gestão.
Se você gostou desse artigo: compartilhe. É só clicar no botão mais abaixo. Também ficarei muito feliz em ouvir a sua opinião.
Abs e sucesso sempre!
WL
Ps:
Se você quiser citar esse artigo ou parte dele em seu trabalho acadêmico basta copiar a referência a seguir: RIBEIRO, Wankes L. Scrum e o mito da criação de uma cultura de reuniões. Disponível em: http://www.wankesleandro.com/ Acesso em dd/mm/aaaa.
Este artigo é uma versão autorizada e adaptada do artigo original em inglês do Barry Overeem "Scrum Myths: Scrum is 'Meeting Heavy' ".