Scrum daily - Faça as 3 perguntas por desenvolvedor ou vá em tickets?
Somos uma pequena equipe de cerca de 5 desenvolvedores.
Estamos usando um sistema de gerenciamento de tickets que tem um Scrumboard virtual.
No Scrumboard existem várias colunas. Os itens nas colunas são classificados por prioridade:
New | Consultation | Working | Waiting | Test & Review | Done
Consulta = Precisamos de feedback de alguém de fora
Esperando = Esperando por alguém ou algo
Temos cerca de 40-50 tickets ativos enquanto fazemos um sprint de 2 semanas.
Em um Scrum diário padrão, geralmente cada desenvolvedor responde a 3 perguntas:
O que eu fiz ontem?
O que vou fazer hoje?
Quais são meus impedimentos?
De alguma forma, nosso processo é diferente:
Vamos por coluna e depois por cada ticket na coluna.
Fazemos isso por vários motivos:
- esse processo se desenvolveu sozinho, nós não planejamos, simplesmente aconteceu
- alguns desenvolvedores iriam "se afastar" quando outros falavam e não ouviam. Sim, geralmente leva apenas 15 minutos diários, então pode-se esperar que ouvir durante esse tempo seja possível. Mas como todos nós trabalhamos em casa, não podemos perceber se alguém está ouvindo ou não.
- quando um desenvolvedor termina com suas 3 perguntas, ele pode não ouvir as outras, já que seu foco se foi
- o desenvolvedor está visível no tíquete, mas pesquisar seu próprio nome para encontrar os tíquetes em que você está trabalhando leva um pouco de tempo. Existem maneiras de mudar a visualização, mas a mudança constante se torna irritante rapidamente para todos
- se formos pelo desenvolvedor, ele às vezes negligencia um tíquete importante ao fazer sua apresentação
Seguir as colunas e depois os tickets parece mais "natural", também todos parecem mais ativos na escuta, já que o próximo ticket pode ser o seu. Também não esquecemos nenhum detalhe importante ou ingresso. Na maioria das vezes, os desenvolvedores indiretamente respondem às 3 perguntas dessa forma também, mas nem sempre. Este processo ainda parece um pouco superior - pelo menos em nosso ambiente!
Então você SEMPRE deve seguir as 3 perguntas, ou você deve ir pelos ingressos?
Ou há uma maneira de saber quando qual abordagem é "melhor"?
(Talvez esta imagem possa ajudar a entender minhas dúvidas)
Respostas
Então você SEMPRE deve seguir as 3 perguntas, ou você deve ir pelos ingressos? Ou existe uma maneira de saber quando qual abordagem é "melhor"?
A versão 2020 do Guia Scrum removeu as três perguntas, enquanto a versão 2017 do guia diz o seguinte:
A estrutura da reunião é definida pela Equipe de Desenvolvimento e pode ser conduzida de maneiras diferentes se focar no progresso em direção à Meta da Sprint. Algumas equipes de desenvolvimento usarão perguntas, outras serão mais baseadas em discussões.
Portanto, faça o que achar melhor ou pergunte à sua equipe o que eles preferem e acham mais útil.
As três perguntas são um exemplo de como o cotidiano pode ser conduzido, porque focalizam a discussão nos itens básicos que você precisa abordar para coordenar seus esforços em direção ao objetivo. Se você acha que discutir os tíquetes é uma abordagem superior, vá em frente.
Apenas certifique-se de não se perder em muitos detalhes (você sempre pode discutir com mais detalhes após o diário) e vá além da caixa de tempo que por sua vez fará com que as coisas se transformem em uma reunião e dará às pessoas mais oportunidades de check-out mentalmente.
TL; DR
Você deve seguir o conselho por desenvolvedor ou coluna? Nem. Ambos são anti-padrões.
Não trate o standup como um puxão de status da equipe e, definitivamente , não o use como uma mini-revisão do status de cada tarefa planejada para todo o Sprint. Se você mantiver o escopo da trocação para o trabalho do dia atual, a questão de como melhor "andar na prancha" (dica: não há, porque você não deveria fazer isso) vai embora.
Concentre-se novamente na coordenação da equipe
Sua pergunta começa com uma suposição fundamentalmente falha: que realizar um relatório de status em todos os tickets é benéfico ou até desejável no Scrum. É realmente um problema X / Y na medida em que a equipe está perdendo todo o objetivo da preparação diária, que é fazer o planejamento e coordenação just-in-time para as atividades do dia atual.
As "três perguntas" são apenas um meio para um fim. Em equipes menos maduras, ter diretrizes ou pontos de discussão pode ajudar os membros da equipe a identificar as dependências entre as tarefas. A intenção não é fornecer um relatório de status, no entanto. O objetivo é sempre ajudar a equipe a planejar o trabalho do dia atual de forma colaborativa. Por exemplo:
Sandy: Ontem trabalhei no embiggening do widget central. Hoje eu preciso enlaçar a engrenagem primária, mas preciso do whatchamacallit de Susan para fazer isso.
Susan: Ontem terminei o whatchamacallit, então está pronto para Sandy. Hoje eu queria trabalhar no frobnosticator, mas estou preso até que a história de MacGuffin esteja completa. Alguém já está trabalhando nisso?
Em outras palavras, não use a postura diária para "andar na prancha". Use-o para permitir que a equipe se auto-organize em torno do dia de trabalho! Se as perguntas ajudarem a equipe a fazer isso, ótimo. Se não, jogue-os fora.
Da mesma forma, apenas o trabalho já em andamento ou planejado para o dia deve ser discutido no standup. O trabalho no Sprint Backlog ou em um estado pendente só é relevante se for uma dependência de uma tarefa atual, um bloqueador de outra coisa ou alguém planeja puxá-lo como trabalho em andamento hoje .
Se você realmente deseja um status Sprint, aproveite sua coluna Concluído e seu gráfico burn-down para determinar se você está no caminho certo para cumprir a meta do Sprint. Se o status do objetivo do Sprint estiver em questão, isso provavelmente merece uma reunião separada fora da preparação diária e, definitivamente, alguma atenção de todo o Time Scrum durante sua próxima Retrospectiva do Sprint. Na melhor das hipóteses, andar na prancha é uma solução temporária para encobrir comunicações ineficazes ou radiadores de informações ausentes / inválidos. Na pior das hipóteses, evita ativamente que a equipe colabore no planejamento just-in-time, favorecendo o relatório de status em vez de interações entre os membros da equipe.
A abordagem das três questões é focada no indivíduo, mas a abordagem do conselho está focada na equipe e nos objetivos do sprint. (Ou, pelo menos, a meta do lado direito do quadro.) Em minha experiência, uma armadilha das três perguntas é quando um indivíduo sente que precisa provar que está trabalhando. Mas indo por ingressos, você pode nem falar com todos os indivíduos.
Como sugeri acima, o que é melhor depende de seus objetivos.
Se a equipe for coesa e o tabuleiro refletir o caminho para a meta, use o tabuleiro. (Eu sugiro ir mais longe e usar o quadro explicitamente da direita para a esquerda: colocando o foco em terminar as coisas.)
Mas se a equipe é nova ou ainda não está trabalhando bem em conjunto, ou se o tabuleiro não representa realmente o objetivo, então as três perguntas podem ser uma aposta melhor. O objetivo do sprint pode ser, na verdade, "fazer essa nova equipe formar" ou "integrar a Frankie para que ela seja eficaz". Se for esse o caso, você definitivamente quer ter certeza de que todos têm a chance de falar sobre o que estão fazendo e o que funciona e o que não funciona.
Ou há uma maneira de saber quando qual abordagem é "melhor"?
Uma coisa com o desenvolvimento Agile é que ele oferece flexibilidade para os objetivos do projeto e organização. Uma coisa que você pode ser flexível sobre como seus diários estão sendo feitos é melhorar iterativamente. Colete feedback de sua equipe, discuta a estrutura diária em sua retrospectiva de sprint e não tenha medo de experimentar as sugestões de sua equipe.
Atualmente trabalho em uma equipe em que temos as duas abordagens - ambos temos uma tarefa diária orientada e "três perguntas" diariamente. O primeiro é de dez minutos diários entre os desenvolvedores para discutir o quadro atual e ter espaço para algumas observações técnicas; a segunda é uma diária de quinze minutos que é muito mais centrada nas “três perguntas” na tentativa de ter um dia a dia mais humano com a equipe mais ampla.
Tínhamos uma rotina diária de desenvolvedor e suas tarefas, mas decidimos descartar o processo pelos motivos que você mencionou em foco, preocupações com o tempo e falta de um entendimento coeso do status das tarefas relacionadas. E sim, filtrar constantemente as tarefas por desenvolvedor era um incômodo para nós também.
Não posso comentar, então acrescentei meus dois centavos como resposta.
Se eu puder sugerir: "as três perguntas" podem ser "olhando para o seu umbigo", enquanto você realmente deseja que todas elas estejam "olhando em volta".
A primeira coisa que eu faria é encontrar uma maneira de agrupar sua lista de tarefas de uma forma que lhe permita considerar as tarefas relacionadas de uma forma "útil para os negócios". (Além disso, encontre uma maneira funcional de "marcar" tarefas que podem estar relacionadas a mais de um grupo. No software, tudo geralmente está relacionado de alguma forma a todo o resto.)
Então, eu pediria à equipe que considerasse cada grupo junto com vocês e ajudasse todos vocês a escolher (!) Quais - por consenso mútuo e informado - deveriam ser as "três perguntas do dia" da equipe.
Por um lado, os desenvolvedores de software aprenderam a adquirir uma capacidade superior de se concentrar em qualquer que seja o problema do dia. Por assim dizer, "eles sabem exatamente como mergulhar fundo e permanecer no fundo". Mas - falando por experiência pessoal agora - é horrível perceber, tarde demais, que você não sabia que simplesmente mergulhou fundo no lugar errado pelo motivo errado e acabou de ser sugado por um furacão. "Se você apenas soubesse ..."
E assim, a questão fundamental é clara: uma vez que os desenvolvedores são - e devem ser - "mergulhadores profundos", quem está sempre sentado no barco, sempre seco, sempre observando o quadro geral? Procurando tubarões? Ajudando-os a saber, enquanto remam na superfície, onde e por que mergulhar em seguida? Isso seria você.
Agora - para completar o pensamento - às vezes esses mergulhadores voltarão à superfície com algumas novas descobertas importantes que você não poderia saber. Sempre deixe que os próprios desenvolvedores contribuam com "ingressos" para o seu mix.
Conforme mencionado por outros, o Guia Scrum não prescreve mais as 3 perguntas. E, para ser honesto, a maioria dos scrums diários baseados nas 3 questões contradiz o propósito do evento. Quando é orquestrado por um Scrum Master e os membros da equipe têm que relatar as últimas 24 horas que está em 0% de auto-organização. Isso não resultará em uma inspeção genuína do status da Sprint e no planejamento do dia com o espírito de atingir com sucesso a Meta da Sprint. Deve ser uma discussão interna da equipe de desenvolvimento onde os membros da equipe estão interessados em seu próprio sucesso.