No artigo anterior eu escrevi sobre a Sprint Planning e para dar seguimento aos eventos do Scrum, vou falar sobre a Daily Scrum, que é um evento que costuma ter muitas disfunções e passa a ser um PDS (Ponto de Situação). Então vamos a isso!
Conforme está escrito no Scrum Guide, a definição é:
“O objetivo da Daily Scrum é inspecionar o progresso rumo ao Sprint Goal e adaptar o Sprint Backlog conforme necessário, ajustando o trabalho planeado que se aproxima. A Daily Scrum é um evento de 15 minutos para os Developers da Scrum Team.“
Vamos tratar da disfunção mais comum da Daily Scrum. A Daily é uma sessão dos Developers para eles mesmos. A Daily não é uma sessão do Scrum Master nem do Product Owner. A participação do SM e/ou do PO é OPCIONAL na Daily.
O que acontece com a maioria das equipas é que a Daily Scrum é organizada e facilitada pelo Scrum Master e quando o SM não pode participar da sessão, a equipa também não participa. Ou seja, a sessão passou a ser do SM e não dos developers.
Esta disfunção acontece por alguns fatores:
Foco nas 3 perguntas “malditas”
O que fiz ontem;
O que vou fazer hoje;
Impedimentos e bloqueios.
Algum Stakeholder (ou chefe) participa da sessão e faz perguntas de como está o projeto ao invés de escutar a sessão.
A equipa (algumas pessoas) aprofunda demais no detalhes do trabalho e a sessão “estoura o tempo”;
O Scrum Master não sabe/consegue facilitar a sessão de forma que seja objetiva;
A maior parte das equipas não têm Sprint Goal, logo, a Daily Scrum é para falar de cenas que a equipa quer entregar;
Os developers acham que é perda de tempo e queriam estar desenvolvimento ao invés de participar de mais uma reunião
Eu poderia listar mais um monte de disfunções, mas preferi citar as que mais acontecem. O Scrum Master tem um desafio imenso para evitar que as Dailys fiquem disfuncionais e que a equipa perceba o valor de participar e colaborar na sessão.
Mas não é muito difícil facilitar as Dailys meetings, mas dá um pouco de trabalho e é necessário preparação para a sessão. Vou partilhar algumas dicas para facilitação remota:
Entre na sessão com ânimo, dê bom dia a todos e tenha a sua câmera do portátil ligada;
Interaja com as pessoas que também tem as câmeras ligadas para encorajar este comportamento;
Tenha um acordo com a equipa que a Daily vai começar no máximo com 1 a 2 minutos de atraso;
Tenha seu o seu ecrã partilhado com o board da equipa na visão de User Story;
Ao iniciar a sessão, puxe conversas e alinhamentos sobre as User Stories que está mais próxima do Closed (da direita para a esquerda do board) e mais ao topo do board;
Validem e conversem sobre o que a EQUIPA Scrum deve fazer para terminar as User Stories mais próximas do closed;
Repita esse procedimento para mais algumas User Stories próximas ao Closed;
Se a Equipa tiver User Stories bloqueadas, passe por elas e validem por que está bloqueada, o que deve ser feito para desbloquear, qual o impacto do bloqueio para a Sprint Goal e alinhem um plano de desbloqueio com uma data de resolução;
Utilize cerca de 10 a 12 minutos nas conversas do board com foco nas User Stories;
Antes de encerrar a sessão, deixe tempo livre para as pessoas partilharem temas relevantes sobre a Sprint e o trabalho que está a ser desenvolvido.
Se conseguir seguir grande parte destas dicas, com o tempo e prática, a sessão ficará mais rápida, objetiva e colaborativa. Falo isso por experiência própria pois facilito Dailys a muitos anos e tem dado certo utilizar esta abordagem.
Em Outubro de 2022, eu estava a trabalhar como Enterprise Agile Coach num cliente e passei algum tempo facilitando as sessões da equipa para ajudar com muitas disfunções que tínhamos. Uma delas era a daily, mas também de não conseguirmos colocar os itens em closed
Como podem ver na imagem, tínhamos 45 User Stories quase closed que estavam paradas nas colunas “Ready 4 BL” e “QA 4 BL” a semanas. Eu usei as dicas citadas acima desde o 1º dia que comecei a facilitar as sessões e passei por TODOS os work items diariamente até que o BL (Business Lead = Product Owner) entendesse que ele deveria parar e trabalhar nas User Stories pois o gargalo era ele.
Ponto Importante: Eu já havia falado com o BL várias vezes sobre ele ser o gargalo mas ele nunca resolvia o tema, logo, entrei em campo para expor o problema diariamente até que ele entendesse que deveria fazer otrabalho dele. E fez.
Ainda na 1ª semana o BL pediu ajuda para 2 pessoas da equipa para trabalharem em pair-programming e ao final da Sprint TODAS as User Stories estavam em closed.
É como escrevi logo acima, não é tão difícil, mas dá trabalho e temos que dar um jeito de facilitar a vida da equipa e sermos mais eficientes.
De maneira geral, a Daily Scrum foi criada com vários objetivos e um deles é de melhorar as comunicações, identificar impedimentos, promover a tomada de decisões rápidas e, consequentemente, eliminar a necessidade de outras reuniões.
Atualmente estou envolvido num projeto que tem várias equipas e sub-sistemas e estou a utilizar a mesma técnica na Scrum of Scrums e foi preciso somente alguns dias para colocar as coisas no eixo.
Para concluir, gostava de refletissem sofre a efetividade das Daily Scrum que vocÊs participam, seja como Scrum Master ou outra role e se acharem que podem melhorar a sessão, façam.
Espero que tenham gostado e que consigam diminuir as disfunções do dia a dia para que as equipas agile trabalhem melhor.
Nos próximos artigos vou continuar a escrever sobre os eventos do Scrum e apontar as minhas percepções / experiência sobre a framework Scrum.
Quer perceber mais sobre o Scrum e outros temas?
Inscreva-se em nossa newsletter para receber nossos conteúdos e novidades.
Até breve.
Referências:
Autor: Ricardo Caldas
Comments