Qual é o tempo máximo que o Scrum recomenda que um time gaste em uma reunião diária de Scrum?

Reunião diária pode ser muito mais do que você imagina.

Essa semana assisti a palestra da Priscila Soares Elpo “As 10 lições que eu aprendi implantando o Scrum”  no TDC Online. No geral, o que mais me chamou atenção foi como o time percebeu e aprendeu a importância da reunião diária ( ou daily meeting) durante a adoção do Scrum.

Para contextualizar, o time acreditava que já possuía uma boa comunicação e interação, pois eles trabalharam juntos há um bom tempo. Com isso, eles entenderam que essa reunião diária poderia ser desnecessária. Portanto, ao “rodar” uma primeira versão do Scrum, eles não a adotaram. Passou-se o primeiro sprint, faliram, e em suas lições aprendidas, eles entenderam que uma das causas desse resultado foi o fato da comunicação ter falhado e assim tomaram a ação de utilizar a reunião diária, e viram ganhos com ela.

De verdade, adorei esse testemunho, a palestra toda foi um exemplo de aprendizagem emergente na adoção do Scrum. Atualmente eles não usam o framework original, eles tem a própria versão, que é uma outra abordagem super legal (às vezes, as empresas impõem a adoção de alguma metodologia de uma hora para outra e a experiência acaba tornando-se um desastre).

Mas o que é essa reunião diária, que parece ser tão milagrosa para facilitar a comunicação de um time? Primeiro, não tem milagre. É somente um momento para promover a comunicação e visibilidade entre o time de scrum que está executando o projeto e avaliar o progresso do planejado. E tomar determinadas ações, caso necessário.

Então é uma reunião de status para meu gerente? Não, podemos entender que é uma reunião de comprometimento do time com o time. Para tanto, cada membro da equipe deve responder as três perguntas de forma objetiva:

1. O que eu fiz ontem?
   – Dadas as atividades do sprint, o que já consegui realizar no dia anterior.
2. O que vou fazer hoje?
   – O que eu planejo a fazer hoje.
3. Há algo impedimento o andamento da minha atividade?
   – Algum fator não está permitindo que eu evolua em minha atividade, como posso removê-lo?

Essa reunião deve ser demorada, né? Também não! É rápida, recomenda-se quinze minutos no máximo para realizá-la. Esse timebox é ideal para um time grande. Seguir o roteiro das três perguntinhas, ajuda para que a reunião seja focada. E quando surgir assuntos muitos técnicos, discutam após a reunião diária ou no momento apropriado.

Vixi, é dificil reunir todos do time, meu gerente, o cliente, o papagaio, o periquito, o papa? Virou happy hour?! Não precisa de todas essas pessoas. Você precisa ter somente as pessoas que estão comprometidas. Isto é, Scrum Master – o facilitado da reunião-, Time de desenvolvimento – galera que está executando a sprint – , até o Product Owner (PO), se for necessário.

Qualquer pessoa pode participar da reunião diária, porém apenas como ouvintes.

Ah, mas é difícil reunir todos ao mesmo tempo. Como vou fazer isso? Todos precisam entrar em acordo para definir um lugar e um horário, o qual será “religioso”. Pode ser próximo da baia, na copa, em uma sala de reunião, após o almoço, no horário X. Faça-o simples. Falando em acordo, defina também um acordo de time para que todos estejam focados, ouvindo atentamente o outro colega, evitar conversas paralelas, celulares, computadores que atrapalhem a dinâmica da comunicação.

A daily meeting ajuda a diminuir os riscos do projeto, pois quando um impedimento é previsto ou mencionado, o time já pode tomar ações para que tenha menor impacto no andamento da sprint,e por consequência, no projeto. Ressalto, que a reunião diária não tem como propósito ser um informe de impedimento. Ou seja, quando ocorrer algum problema, fale o quanto antes para o Scrum Master.

Segundo o Rafael Sabbath: "A reunião de Daily Scrum é também conhecida como Daily Meeting (reunião
 diária) ou Stand-up Meeting (reunião em pé)". Nós, do agile.pub, destacamos a necessidade dela ocorrer em pé, para justamente ser rápida e objetiva.

A reunião diária é algo simples e nenhuma novidade para o mercado, pois antes de eu trabalhar com agilidade, via essa prática em indústria para linha de produção. Seu diferencial no Scrum é o roteiro, aumentando o foco para atingir seu objetivo.

Ao meu ver, a reunião diária permite que criar uma dinâmica da interação de pessoas, gerando a auto-organização e minimizando enumeras reuniões sem objetivo. Caso não seja possível sua realização, é preciso se antecipar e concentrar-se em alternativas para que ela ocorra.

É isso. Tem dúvidas sobre aplicar ou você percebe alguma disfunção na sua reunião diária, comente e vamos conversando.

Abraços.

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?

1. 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).”

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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' ".

#ágil #ágeis #mitos #scrum #prática #gerenciamentodeprojetos #projetos