"Deitamos, acendemos luzes, no Universo somos os únicos." Parece que esta linha da música do grupo Splin pode ser reconhecida com segurança como a trilha sonora da introdução da prática da Sprint Review na Dodo Pizza.
Isenção de responsabilidade: em um artigo, Anton descreve a primeira versão de uma revisão viável do sprint. Já temos um mais avançado, mas sobre isso na próxima série.
A primeira tentativa de lançar a prática de revisão de sprint na Dodo Pizza falhou miseravelmente.
Talvez você pense que as práticas da cadeia de pizza scrum geralmente são inúteis. No entanto, uma das principais vantagens do Dodo Pizza é, curiosamente, seu próprio sistema de TI, que gerencia todos os processos em 495 pizzarias da rede em 12 países.
Mais de 80 desenvolvedores e analistas estão trabalhando neste sistema hoje (e mais de duzentos virão com o tempo). Como uma startup em rápido crescimento, buscamos a máxima eficiência, portanto, usamos muitas das estruturas de "desenvolvimento flexível": Scrum, LeSS, programação extrema.
Mas o que é esse scrum, você pergunta, sem a revisão do sprint? E você estará certo.
Como você sabe, a revisão do sprint define o ritmo da equipe e motiva a concluir o trabalho até o final do sprint. Mais importante, ele ajuda a criar um produto valioso que a empresa precisa, e não apenas executar tarefas de backlog. Então, de qualquer forma, eles escrevem em livros.
No entanto, por algum motivo, essa abordagem não funcionou para nós. Por exemplo, em uma das primeiras revisões de sprint, mostramos aos franqueados Dodo Pizza do Cazaquistão seu novo site - dodopizza.kz. O feedback foi inspirador: os parceiros disseram que o site é lindo e, no contexto dos concorrentes, geralmente parece uma obra-prima.
Quando o lançamos, descobrimos que muitas coisas estavam faltando nele. Ou seja, passamos algum tempo na revisão do sprint, mas na verdade não recebemos um feedback útil dos parceiros.
Em geral, logo paramos silenciosamente essas revisões de sprint.
Depois de alguns meses, decidi tentar novamente. Naquela época, já tínhamos oito equipes trabalhando na mesma lista de pendências na estrutura do LeSS. Tentamos seguir todas as regras do Scrum em larga escala, e a falta de revisão do sprint foi uma das violações.
Eu me preparei antecipadamente para o fato de que no começo tudo vai ficar ruim e você precisará procurar o formato correto usando o método de tentativa e erro. Após cada revisão, pedi aos participantes que classificassem o evento em uma escala de 1 a 10 (Bottom - Omnische). No início, as classificações eram muito baixas, mais próximas do "fundo". No entanto, não desistimos, experimentamos, e em alguns meses eles começaram a mudar para o Ognist.
Foi isso que mudamos
Fazendo lição de casa
Percebemos que você precisa dedicar menos tempo à preparação do que na própria revisão do sprint - ou até mais. O evento todo leva duas horas e eu me preparo por três horas. Afinal, você precisa coordenar metas com as equipes, organizar com parceiros, gerentes da empresa de gerenciamento, funcionários de pizzarias e outros convidados, agendar conversas, fazer um pôster, encontrar facilitadores, instruir, elaborar e desenhar um cronograma, desligar bate-papos para obter feedback, etc. Sem tudo isso, simplesmente haverá caos.
Não mostrar inacabado
Inicialmente, mostramos recursos semi-acabados. Mas percebemos que é assim que enganamos as equipes e, mais importante, os clientes. Uma vez, mostramos o CEO de uma empresa de serviços geográficos que armazena em cache os dados do mapa. Então, na próxima revisão, foi mostrado novamente - apenas com bugs corrigidos. Quando chegamos pela terceira vez e mostramos o mesmo serviço, mas já no site de combate, o CEO tinha uma pergunta natural: "O que diabos você está mostrando a mesma coisa pela terceira vez?"
Agora, na revisão do sprint, mostramos apenas o que é publicado no site de combate. Se algo estiver quase pronto - existem apenas bugs para corrigir, testar e distribuir bugs - nós não mostramos.
Negociações em vez de espaço aberto
Os autores do LeSS recomendam uma revisão de sprint na forma de um "bazar". Todas as equipes devem mostrar seu trabalho em uma sala grande, e os interessados podem ir às estações que lhes interessam. Tentamos várias vezes, ficou barulhento e exigente.
As telas dos laptops são pequenas, nada é visível nelas, o ruído das estações vizinhas dificulta a concentração e o movimento constante das pessoas cria caos. Portanto, agora, na sala de conferências, todos se reúnem apenas no início e no final. A ação principal ocorre nas salas de reunião, onde cada equipe apresenta seu trabalho. Lá, equipamentos, telas grandes, você pode sentar-se confortavelmente, participantes remotos são conectados e há um local para a coleta de feedback.
Transições são proibidas!
No início, nossos stakeholders se movimentavam livremente entre as equipes. Mas foi irritante. Imagine que você começou a contar alguma coisa e em dez minutos uma nova pessoa se junta ao grupo e faz perguntas sobre o que você acabou de falar.
Comece a responder - o resto está entediado. Ignorar - a pessoa está chateada. Portanto, decidimos proibir o movimento entre grupos. Eu escolhi o tópico que lhe interessa - sente-se na sala de reuniões por vinte minutos até o próximo intervalo.
Caros convidados
Percebemos que a composição dos "convidados" é de grande importância. Nada motiva um desenvolvedor como aparecer em um CEO de revisão de sprint. Especialmente quando você precisa mostrar algum truque técnico, como um serviço em um cubo ou transferir Auth para .Net Core. Temos que explicar por que estamos fazendo isso. Fedor Ovchinnikov, CEO da Dodo Pizza, energiza e sabe como animar a todos e delinear os horizontes do desenvolvimento da empresa em três minutos. Bem, quando mostramos recursos do cliente, por exemplo, um construtor de meia pizza em um aplicativo móvel, agora chamamos convidados externos, via de regra, conhecidos e amigos do Facebook.
Membros excluídos
É fácil realizar uma reunião quando tudo está em uma sala. Mas temos muitos funcionários remotos em Syktyvkar, Nizhny Novgorod, Kazan e Goryachy Klyuch. Também é importante que eles participem.
A princípio, os "trabalhadores remotos" reclamaram que eram difíceis de ouvir e quase não viam nada. Agora, cuidamos deles e dos participantes offline. Existem itens na lista de verificação de preparação da revisão do sprint que nos lembram de verificar a conexão e configurar o equipamento. Estamos transmitindo no Slack e, mais recentemente, transmitimos o evento em nosso canal no YouTube, Dodo Pizza .
Isenção de responsabilidade de comentários
Quando começou a parecer que tudo estava bem e não havia lugar para melhorar o formato, nos perguntamos: não estamos fazendo lixo? Uma revisão de sprint é um evento bastante caro (se você a considerar cinicamente - em termos de número de participantes, salários e horas gastas). Estamos usando essas duas horas da maneira mais produtiva possível? Como resultado, decidimos recusar completamente a coleta de feedback durante a revisão do sprint.
No formato de um evento como esse, não pode ser realizado de maneira profunda e qualitativa (lembre-se de um caso com o Cazaquistão). Além disso, coletamos a maioria das análises significativas e de alta qualidade durante o sprint, atraindo todos os interessados, de clientes internos a usuários ... Você ficará surpreso, mesmo o Guia Scrum não diz que o feedback deve ser coletado na revisão do sprint: "Durante a revisão do sprint , a equipe Scrum e as partes interessadas colaboram com o que foi feito no Sprint ". Equipe e partes interessadas, não usuários. Interaja, não colete feedback. Um significado completamente diferente.
Abra a "cozinha"
Nem todas as partes interessadas estão profundamente imersas no processo de desenvolvimento. Mas todo mundo quer saber o que está acontecendo lá. É para esses propósitos que decidimos reorientar a revisão do sprint.
Ainda mostramos o trabalho realizado, mas, além disso, as equipes contam a história por trás dos novos recursos. Qual foi o propósito? O que aconteceu durante o sprint? O que nos distraiu ou nos impediu de alcançar nosso objetivo? Que medidas foram tomadas para salvar a meta? Isso ajuda: dessa maneira, fica claro para os gerentes, por exemplo, por que "ocultar o e-mail do cliente com estrelas de verificação" é uma tarefa muito difícil ("meia hora de trabalho de um programador", como pensavam os gerentes). Por outro lado, esse diálogo ajuda os desenvolvedores a pensar em termos de "clientes" e seus problemas, e não em termos das soluções específicas em que estão trabalhando.
Essa talvez seja a principal coisa que mudamos em nossa abordagem. O progresso é evidente, mas como sempre, ainda há algo a melhorar. Os experimentos estão em andamento.
O principal que entendemos é que não precisamos nos desligar dos formatos propostos nos manuais do Scrum. Você precisa tentar, cometer erros e experimentar. Não há soluções universais - você precisa procurar as que funcionam na sua situação.
Portanto, no final, quero avisar: não copie nosso formato. Ele trabalha bem conosco porque nasceu como resultado de muitas experiências. Procure sua abordagem - e você terá sucesso. Certamente não será pior.