O que você ganha quando cruza um departamento de TI, uma revisão, determinação e pizza incorretas da Sprint? Grandeza, é isso.
Nossa primeira tentativa de introduzir
resenhas de sprint na Dodo Pizza falhou espetacularmente. Você poderia pensar que uma cadeia de pizzas não precisa de práticas de Scrum. No entanto, por mais estranho que possa parecer, uma das principais vantagens do
Dodo Pizza é o seu próprio sistema de TI que controla todos os processos de trabalho de 430 pizzarias em 11 países.
Mais de 60 programadores e analistas trabalham em nosso sistema agora e planejamos aumentar esse número para
mais de 200 . Como qualquer empresa em rápido crescimento, estamos buscando a máxima eficiência, por isso usamos muito as estruturas Agile, incluindo Scrum, LeSS e programação extrema. Mas como você emprega o Scrum sem revisões de sprint? Essa é a pergunta que você pode fazer - e você teria razão.
Como sabemos, uma revisão do sprint define o ritmo de trabalho de uma equipe e o motiva a concluir a tarefa até o final do sprint. Mais importante, uma revisão do sprint ajuda a criar um produto valioso para os negócios, não apenas para resolver problemas do backlog. Pelo menos, é o que dizem os livros.
Mas, de alguma forma, essa abordagem nunca funcionou para nós. Por exemplo, em uma de nossas primeiras revisões de sprint, apresentamos um novo site (dodopizza.kz) a nossos franqueados no Cazaquistão. O feedback foi inspirador, nossos parceiros nos disseram que o site estava ótimo e, comparando com os concorrentes, era praticamente uma obra-prima. Mas após o seu lançamento, descobriu-se que estava faltando seriamente. Por isso, perdemos tempo em uma revisão de sprint, mas não obtivemos nenhum feedback útil.
Em breve, paramos completamente essas revisões de sprint.
Vários meses se passaram e eu decidi tentar novamente. Nesse ponto, tínhamos oito equipes trabalhando em um backlog na estrutura do
LeSS . Tentamos aderir a todas as regras do Scrum de grande escala, e o cancelamento das revisões do sprint foi uma violação.
Eu me preparei para maus resultados iniciais - ficou claro que teríamos que encontrar o formato correto por tentativa e erro. Após cada revisão, pedi aos participantes para avaliá-lo em uma escala de 1 a 10. Inicialmente, nossas notas eram muito baixas, mas não desistimos e continuamos a experimentar; portanto, em alguns meses, as revisões começaram a mova para a parte superior da balança.
Foi isso que fizemos de maneira diferente.
Fazendo nossa lição de casa
Tornou-se claro que a preparação da revisão do sprint exige menos tempo do que a própria revisão do sprint, ou até mais. Uma revisão leva duas horas e passo três horas me preparando para isso. Existem metas de revisão para discutir e concordar com a equipe, parceiros, gerentes da empresa-mãe, funcionários e outros convidados com quem conversar, salas de conferência para reservar, um cartaz para fazer, facilitadores para encontrar e instruir, um cronograma para montar , flip charts de feedback para travar etc. E sem tudo isso, o caos se inicia.
Se não terminar, não mostre
Inicialmente, mostramos recursos semi-prontos nas revisões do sprint. Ocorreu-nos que isso significava enganar nossas equipes e, pior ainda, nossos clientes. Mostramos ao CEO um serviço de mapeamento que armazena dados cartográficos em cache uma vez. Na próxima revisão, mostramos novamente, com bugs corrigidos. Quando o trouxemos pela terceira vez e o mostramos no site ao vivo, ele tinha uma pergunta muito legítima: por que diabos ele tem que olhar a mesma coisa repetidamente? Agora, nas revisões do sprint, mostramos apenas os recursos que já estão em um site ativo. Se algo está quase pronto e precisamos apenas corrigir bugs, testá-lo e lançá-lo, simplesmente não o mostramos ainda.
Salas de conferência em vez de um espaço aberto
Os criadores de LeSS recomendam realizar uma revisão de sprint como um "bazar", onde todas as equipes demonstram seu trabalho em uma sala grande e as pessoas visitam as estações nas quais estão interessados. Tentamos isso várias vezes, e foi muito barulho e confusão.
As telas dos laptops são pequenas e desconfortáveis, você não consegue se concentrar muito bem por causa do barulho em outras estações e fica caótico quando as pessoas estão constantemente perambulando. Então agora todos nos reunimos em uma grande sala de conferências apenas no início e no final da revisão. A ação principal ocorre em pequenas salas de conferências, onde cada equipe apresenta seu trabalho. É mais confortável, há todo o equipamento necessário, telas grandes e acesso à Internet para participantes remotos, e você pode obter feedback em paz.
Vaguear não é permitido
No começo, as partes interessadas andavam livremente entre as equipes, mas era irritante. Imagine que você está fazendo sua apresentação, fala há dez minutos e então alguém aparece e faz perguntas sobre as coisas que você acabou de abordar.
Se você responder, todo mundo está entediado. Caso contrário, essa pessoa poderá se ressentir. Por isso, decidimos não permitir vaguear entre grupos. Se você escolheu um assunto, sente-se em uma sala de conferências e aguarde 20 minutos até o próximo intervalo.
Caros Convidados
Percebemos que a lista de convidados é muito importante. Nada motiva um desenvolvedor mais do que o CEO de uma empresa visitando uma revisão de sprint, especialmente quando você mostra alguma coisa técnica, como hospedar um microsserviço no Kubernetes ou migrar um componente Auth para o .Net Core. Então você tem que explicar por que você fez tudo isso em primeiro lugar.
Fyodor Ovchinnikov, CEO da Dodo Pizza , pode cobrar energia do público, animar seu ânimo em três minutos e delinear as amplas perspectivas de desenvolvimento da empresa, mas ao demonstrar recursos de front-end, como um recurso do tipo “construa seu próprio pizza” em nosso aplicativo para dispositivos móveis, convidamos convidados externos, principalmente conhecidos e amigos do Facebook.
Um apresentador engraçado e um boné
Acontece que o apresentador representa metade do sucesso de uma revisão interessante e emocionante do sprint. Muitas pessoas desempenharam esse papel; Eu tentei primeiro, com a ajuda de nossos mestres do Scrum.
Então Sergey Gryazev, nosso proprietário de produto para aplicativos para dispositivos móveis, se tornou um apresentador e agora não podemos imaginar esses eventos sem suas piadas. E, recentemente, adquirimos um artefato ritual, o Chapéu do Orador. O alto-falante deve colocar uma tampa. Não significa nada de especial, é apenas um ritual, mas anima todo mundo.
Participantes remotos
É fácil realizar uma revisão de sprint quando todos estão sentados na mesma sala. Mas temos muitos funcionários remotos em Syktyvkar, Nizhny Novgorod, Kazan e Goryachy Klyuch, e é importante que eles também estejam envolvidos.
No início, eles reclamaram que não podiam ouvir ou ver praticamente nada, mas aprendemos a nos preocupar com eles e com nossos participantes off-line. Na lista de verificação de preparação da revisão do sprint, existem lembretes de que precisamos verificar a conexão com a Internet e ajustar o equipamento. Nós postamos atualizações de eventos via Slack e, recentemente, começamos a transmitir nossas reuniões no
canal do
Dodo Pizza no Youtube .
Não obtenha feedback
Quando já começamos a pensar que estava tudo bem e não precisávamos melhorar mais nada, nos perguntamos se realmente estávamos fazendo a coisa certa. Uma revisão do sprint é um assunto bastante caro, levando em consideração o número de participantes, seus salários e o tempo gasto. Usamos essas duas horas com a máxima eficiência? Como resultado, decidimos não coletar feedback nas revisões do sprint. Nessas condições, o feedback nunca é abrangente ou de boa qualidade (a revisão do site do Cazaquistão é um exemplo disso). Além disso, reunimos muitos comentários úteis e significativos durante o sprint, questionando todas as partes interessadas, de clientes internos a usuários.
Você ficaria surpreso, mas mesmo no Guia Scrum, não há uma palavra sobre como obter feedback em uma revisão de sprint. "Durante a Sprint Review, a equipe Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint." A equipe Scrum e as partes interessadas, não os usuários. E eles colaboram, não obtêm feedback. Não é nada disso.
Bem-vindo aos bastidores
Nem todas as partes interessadas participam ativamente do processo de desenvolvimento, mas todas elas querem ser mantidas informadas sobre o que está acontecendo lá. E esse é o nosso objetivo de revisão do sprint agora. Ainda mostramos o que fizemos, mas, além disso, nossas equipes falam sobre a gênese de novos recursos. Qual foi o nosso objetivo? O que estava acontecendo durante o sprint? O que nos distraiu ou nos impediu? Que medidas adotamos para alcançar nosso objetivo? E isso ajuda; Dessa maneira, os gerentes podem entender, por exemplo, por que ocultar o endereço de e-mail de um cliente em um recibo com asteriscos não é uma tarefa trivial e não apenas “meia hora de programação”, como pensavam anteriormente. E esse diálogo ajuda nossos desenvolvedores de software a pensar em termos dos problemas dos clientes, sem se deixar levar pela solução em que estão trabalhando.
Essas são as principais coisas que mudamos em nossa abordagem às revisões de sprint. Definitivamente, há progresso, mas ainda há espaço para melhorias, por isso continuamos nossos experimentos.
Acima de tudo, entendemos uma coisa - você não precisa ficar obcecado com as recomendações do Guia Scrum. Você deve passar por tentativa e erro. Não há soluções universais; você deve procurar aqueles que trabalham para você.
Então, em conclusão, eu só quero avisar. Não copie nosso formato. Funciona para nós, pois nasceu das experiências. Procure sua própria abordagem e obterá sucesso. O que de pior pode acontecer?