Como ensinar Scrum na prática

Imagino que se você está lendo este post é porque está interessado em disseminar o conhecimento de como aplicar metodologias ágeis de desenvolvimento de software à sua equipe, certo?

Mais do que isso, se você está querendo ensinar é porque provavelmente entendeu o valor que isso tem para os times de desenvolvimento e está preparado para assumir a bronca de se tornar um Scrum Master e ajudar seu time a entregar software com mais qualidade e mais rápido do que fazendo, e isso é ótimo.

Passei por esse mesmo período em 2010, quando tive a oportunidade de participar da implantação de método ágeis em uma equipe de 12 desenvolvedores que se dividiam em 3 times. Mais tarde, em questão de pouco mais de 1 ano, éramos 24 desenvolvedores em 4 times e o Scrum foi decisivo para o sucesso que obtivemos nos produtos que criamos e para manter uma cultura uniforme de desenvolvimento mesmo dobrando o tamanho do time. Espero que este post possa ajudá-lo a obter o mesmo grau de sucesso ou até mais do que tive.

Se preparando

Reserve uma manhã ou tarde inteira, no mínimo, para realizar essa prática. Eu costumo fazê-la em uma manhã, em uma segunda-feira de preferência, que é para que eles tenham o restante da semana para aplicar o que foi aprendido.

Você precisará de um projetor digital ou televisor grande, uma sala que caiba toda sua equipe (ou faça turmas), um quadro branco ou mural para colar/fixar post-its/cartões (se não tiver, vai na parede mesmo), muitas folhas A4 (no mínimo 1 por pessoa) e tudo o que você encontrar para rabiscar: canetas, lápis, giz de cera, etc. Leve para o treinamento algumas cópias do Scrum Guide impresso, no mínimo 1 cópia para cada 3-4 pessoas que irão participar.

Instale algum software de cronômetro (como o CoolTimer) ou use algum Countdown Timer online ou em última caso tenha o seu celular carregado para usá-lo como cronômetro. E por fim, leve uma gravata com nó pronto e um boné e/ou apito. Se não tiver uma gravata, um blazer, jaleco ou paletó já resolve. Explicarei mais adiante.

A teoria

Crie uma apresentação de slides ou alguma outra dinâmica qualquer que lhe permita dar um overview do Scrum e de alguns artefatos que você pretende utilizar na equipe para melhorar os processos de desenvolvimento. Caso não tenha ideia alguma para a apresentação, use esse meu exemplo do Slideshare. Note como estruturei apenas tópicos e poucas frases, isso faz com que o palestrante tenha de ter mais domínio sobre o assunto e passe mais confiança de que você sabe do que está falando. Aqui no blog tenho dois posts que podem te ajudar a se preparar para esse momento, este e este e no meu canal tem o vídeo abaixo, que inclusive você pode passar aos seus alunos com antecedência ou mesmo no dia do treinamento, já que tem apenas 10 minutos.

A sua apresentação de slides deve abrir o treinamento e não deve demorar mais de 1h. Peça que sua audiência leia o Scrum Guide antes de vir para o treinamento e que tragam dúvidas e questionamentos. Use cada uma dessas dúvidas para iniciar debates e facilitar a colaboração de todos, visando que fique claro que somente terão sucesso se todos tentarem. Após a teoria, diga que farão uma prática para que eles vejam como funcionam as reuniões, os artefatos e até mesmo os problemas que o Scrum não vai resolver e que eles terão de buscar soluções por conta própria.

A prática

A prática envolve o desenvolvimento de um produto que, em teoria, não é complexo: um folder, o que faz com que eu chame esta dinâmica de Agile Folder.

Diga para que se organizem em times de 3-4 integrantes, distribua as cópias do Scrum Guide, as folhas A4, as canetas, e guarde o “cronômetro”, a gravata e o boné para você. Explique que iremos simular o desenvolvimento de um produto para entender como funciona a metodologia Scrum na prática e que quando estiver de gravata (coloque a gravata para mostrar) você estará no papel de Product Owner e falará como sendo o cliente, autoridade sobre as prioridades do projeto e sempre preocupado com o ROI (retorno do investimento).

Agora, quando estiver de boné (tire a gravata e coloque o boné), você estará no papel do Scrum Master, “cobrando” do time a utilização do Scrum corretamente e removendo os impedimentos que estejam impedindo o projeto de prosseguir. Sempre que algum time quiser falar com o Scrum Master ou com o Product Owner, deverá chamá-lo adequadamente para que você coloque a gravata ou boné e aja de acordo com sua persona.

O próximo passo é entrar em acordo com todos de quanto tempo demorará a prática. Se você reservou a manhã inteira como eu mesmo faço, você terá 3h totais para o treinamento, sendo 1h para a teoria e 2h para a prática (já fiz prática em menos de 2h, mas ficam meio corridas demais). Explique que usará um cronômetro para contabilizar os dias e consequentemente a duração das sprints e que devem respeitá-lo quando disser que o dia acabou e coisas do tipo. Se você tem 2h, será possível fazer um bate papo ao final da sprint para conversarem sobre o que acharam.

Para organizar a sprint dentro do tempo disponível, sugiro usar a seguinte divisão:

• 10 minutos para um Sprint Planning geral, sendo 5 para a explanação do Product Owner e 5 para o time entrar em acordo
• 40 minutos para o desenvolvimento do produto, em 4 dias de 10 minutos
• 5 minutos para o Sprint Review de cada time
• 5 minutos para um Sprint Retrospective geral

A prática começa com os primeiros 10 minutos de Sprint Planning, que nesse caso serão facilitados pelo Product Owner (você de gravata). Será feito apenas uma Sprint Planning geral, com todos os times escutando e fazendo perguntas.

Você deve explicar que deseja aplicar o Scrum na sua empresa, que já tem profissionais preparados para isso e que está na fase de começar a disseminar esse conhecimento e interesse no framework por toda organização (conforme comentei no post anterior). Para isso vai contratar uma equipe de artistas gráficos para criar um panfleto bacana com um resumão do Scrum Guide que caiba em uma folha A4. Ou seja, a prática envolve aplicar os conhecimentos sobre Scrum que foram aprendidos no Scrum Guide e na palestra em um material escrito ao mesmo tempo em que terão de seguir o processo Scrum.

Dê tantos detalhes quanto julgar necessários, mas tente deixar com que os participantes lhe questionem os detalhes mais importantes, como o formato do panfleto, se será em cores, se é frente e verso, se eles tem de entregar a versão final, se é apenas esboço, etc. Uma das lições desse treinamento é que sempre o time tem de se comunicar com o Product Owner para que a “magia” aconteça. Então se eles não perceberem a necessidade de fazer as perguntas certas, o fracasso logo adiante vai ensinar isso a eles. Pense no produto final que deseja e anote, mas não diga pra eles como será, deixe que eles tenham de interagir com você para descobrir.

Não tome mais do que 5 minutos nessa explanação inicial e diga que eles devem deliberar sobre a viabilidade do projeto, planejar as atividades do mesmo e com o que se comprometem a entregar. Dê a eles 5 minutos para conversarem entre si (somente os membros do mesmo time) e conforme forem terminando, diga para chamarem o Product Owner com o resultado do seu planejamento. Lhes responda as últimas perguntas e anote o que cada time se comprometeu a entregar, isso é muito importante, pois você cobrará essa entrega mais tarde. Geralmente o excesso de confiança faz com que digam que entregarão tudo, mesmo sem terem muita ideia de como dividirão as tarefas e executarão o trabalho.

A cada dia de 10 minutos que se passar os integrantes do time terão que realizar uma Reunião Diária (Daily Scrum) de no máximo 2 minutos. O Scrum Master, enquanto facilitador do processo deve avisar a todos quando o dia “virar” e cobrar que todos estejam fazendo a reunião diária dentro do prazo estipulado e sendo bem objetivos. Você pode inclusive sempre terminar a reunião diária com a pergunta clássica, de equipe em equipe: “Vamos conseguir entregar time? Alguém tem algum impedimento pra que eu resolva?”. Deixe em aberto a possibilidade de chamarem o Product Owner (coloque a gravata quando isso acontecer) ou o Scrum Master (boné) quando quiserem tirar dúvidas do produto (PO) ou do processo (SM).

É comum que os times percam muito tempo nos primeiros um ou dois dias e comecem a correr depois da metade da sprint, quando estiverem faltando apenas uns 20 minutos (2 dias hipotéticos). Caso algum time tente renegociar prazos com o Product Owner não aceite, mas com muita relutância permita alteração no escopo por exemplo, mas sem exageros. A tendência é de falha nessa primeira tentativa, mas não avise eles disso, esse é o principal insumo para a retrospectiva que é feita ao término da sprint.

O aprendizado

Quando os 4 dias de 10 minutos terminem (o CoolTimer adiciona um efeito dramático à isso pois você pode escolher um MP3 bem barulhento para quando isso acontecer), diga a todos para pararem o que estão fazendo e que será feito agora a Sprint Review, onde os times apresentarão suas criação para o Product Owner (coloque a gravata) avaliar.

Faça com que o time se levante e esteja visível para os demais times quando estiver demonstrando seu panfleto. A dinâmica exata dessa apresentação depende do seu sadismo, você pode interromper a apresentação conforme ela for sendo realizada para tecer comentários sobre o que faltou ou o que não gostou, por exemplo, bancando o cliente ruim. Ou então dizer o que achou do produto pronto ao término da apresentação, que não deve durar mais que 5 minutos por equipe. O ponto que não deve ser esquecido aqui é comparar a entrega da equipe com o que ela havia prometido. No Scrum, o time define o tempo que irá levar para desenvolver as tarefas, e portanto, deve ser cobrado se não entregar o que o próprio time havia prometido.

Ao término das reviews, e consequentes frustrações de quem não entregou o que o cliente esperava, é hora da retrospectiva. Eu não vou falar aqui em detalhes dessa dinâmica porque já fiz isso em outro post aqui do blog, que falo somente de como conduzir retrospectivas de sprint que realmente funcionam.

Em linhas gerais, aqui é onde o time (e somente o time, apenas com a mediação do Scrum Master) vai expor o que considerou que fluiu legal no desenvolvimento deste produto (deixe que eles falem), o que não fluiu tão bem assim e as ações que o time se compromete a executar na próxima sprint para que os mesmos erros não voltem a acontecer. Esse é o momento de maior aprendizado e toda prática. Como todo bom erro, é na falha em que mais aprendemos e geralmente os times falham nessa prática.

Feedbacks finais

Ao fim, depois que todos colaboraram, dê a sua opinião. Isso é extra-oficial, não faz parte do Scrum, mas sim do treinamento. Explique o propósito disso tudo novamente, dê a sua opinião do que foi bom, do que pode melhorar, incentive o time a aplicar as melhorias sugeridas logo na próxima sprint de verdade que irão fazer com um produto de verdade que será desenvolvido. Aproveite esse momento de emoção e empolgação como um impulso para definitivamente colocar em prática essa metodologia (por isso que disse que tinha de ser numa segunda-feira).

Tive a oportunidade de aplicar este mesmo treinamento em meia-dúzia de empresas da Grande Porto Alegre sempre com um excelente grau de sucesso. Espero que você consiga usá-lo ou adapte-o às suas necessidades, mas que tenha sucesso também em melhorar os processos da sua empresa.

Outra ideia de treinamento de Scrum é transmitida pelo Jonas Salengue em seu livro Scrum em times de Infra, uma dinâmica baseada em construção de uma casa. Bem interessante também é esta outra dinâmica que eu aplico com times “crus” em Scrum.

Uma última ideia é esta do vídeo abaixo em que o instrutor pede que as pessoas desenhem uma casa (a galera sempre se esquece de manter contato com o cliente para saber o que ele espera da casa e só mostram depois de pronta):

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!