Elementos em comum entre Scrum, XP e Kanban

No artigo de hoje eu quero te mostrar algumas semelhanças entre três dos principais frameworks/métodos de agilidade adotados pelas empresas em seus times de desenvolvimento de software: Scrum, XP e Kanban. Minha ideia não é te convencer de que não há diferenças, mas sim te mostrar que a maior transformação que você pode fazer pelo seu time não está na troca de um método pelo outro, mas sim na adoção dos valores e princípios ágeis do Manifesto, que são justamente a causa desses três métodos terem tantas semelhanças.

Pronto, isso já concluí o artigo. 😀

Scrum, XP e Kanban

Scrum foi criado por Ken Schwaber e Jeff Sutherland na década de 90. Eles juntaram suas experiências liderando projetos de software de todos os tamanhos ao redor do mundo com as teorias popularizadas por Takeuchi e Nonaka no famoso The New New Product Development Game, publica na década de 80 na Harvard Business School. É um framework iterativo-incremental para desenvolvimento de soluções complexas e inovadoras por times auto-gerenciáveis.

Já o Extreme Programming (XP) foi criado por Kent Beck, Ward Chunningham e Ron Jeffries também na década de 90. Eles juntaram suas experiências com engenharia de software para criar uma metodologia ágil que lidasse bem com requisitos vagos que mudavam frequentemente, times pequenos e que colocasse mais disciplina nos desenvolvedores ao invés de mais processos formais. É um método muito focado em qualidade de código, testes e outras boas práticas de engenharia.

E por fim, o Kanban, foi originado no chão de fábrica japonês na década de 50, mas posteriormente adaptado por David Anderson nos anos 2000 para ser usado em corporações, visando gestão do fluxo de valor das empresas, dentre elas as de software. Ele trabalha em cima dos conceitos da manufatura Lean e promove uma postura evolucionária de adoção do método, através de necessidades emergentes.

Note que as três surgiram em meio ao boom dos métodos ágeis, cujo ponto focal foi a criação do Manifesto Ágil em 2001. O quanto o Manifesto influenciou elas ou o contrário, é difícil saber, mas é fato de que existem muitas semelhanças, que é o que vou mostrar agora.

Agilistas do Scrum, XP e Kanban

Começando pelo mais óbvio papel dos métodos ágeis, o agilista, o profissional responsável pela adoção e melhoria contínua de processos ágeis no time.

No chão de fábrica japonês, conforme relata Mike Rother no seu Toyota Kata, já havia se entendido a necessidade de ter uma pessoa focada na melhoria contínua do time (kaizen), observando o fluxo de produção, identificando gaps e ajustando processos. Embora os próprios profissionais de produção também enxergassem gaps nos seus processos, eles não tinham a visão do fluxo de valor completo e muito menos tinham tempo para promover melhorias.

A versão moderna deste profissional é o Scrum Master no Scrum, o Coach e o Tracker no XP e o Service Delivery Manager no Kanban. Note que no XP temos dois papéis exercendo atividade semelhante e ao mesmo tempo com particuliaridades uma vez que o Coach XP é geralmente muito mais técnico do que um Scrum Master moderno e o Tracker XP é focado em métricas do time. Já o Service Delivery Manager foi criado mais tarde como um papel opcional pelo próprio David Anderson, uma vez que ele deve ter percebido que o ditado “cachorro com mais de um dono morre de fome” também se aplica a processos desenvolvimento.

Note que não entro aqui na filosofia por trás de cada papel e me perdoem os mais puristas por isso. Do ponto de vista de atividades, a semelhança é incrível.

Profissionais de Produto do Scrum, XP e Kanban

Outro grande gap identificado nos métodos tradicionais de desenvolvimento de software foi o distanciamento do cliente ao longo do projeto. A falta de comunicação com o mesmo durante todas as fases de desenvolvimento do software faziam com que o resultado fosse um desastroso telefone sem fio (lembra da brincadeira?). Assim nascia a função do profissional de produto dentro dos times ágeis. Seja o cliente ou alguém representando o mesmo no dia a dia, estes líderes de produto tinham como missão garantir o ROI e otimizar o esforço de desenvolvimento rumo ao que o cliente realmente deseja.

No Scrum temos o Product Owner, no XP temos o Cliente e o Gerente e no Kanban temos o Service Request Manager. Todos estes papéis são responsáveis por priorização de backlog, comunicação com o cliente, ROI do projeto/produto, etc. Curiosamente é comum que eles trabalhem com o formato de User Stories para os itens de backlog, que é um formato originário do XP. Também é muito comum que eles trabalhem com o backlog corrente exposto em um quadro de atividades, oriundo do Kanban. Ou seja, é muito comum uma amálgama destas práticas no dia a dia dos times de software.

No XP eu citei os papéis de Cliente e Gerente como sendo comparados ao Product Owner do Scrum e ao SRM do Kanban pois depende da natureza do projeto e das características da sua empresa. Eles são papéis distintos no XP, mas podem acabar sendo aglutinados dependendo do cenário.

Novamente me perdoem os puristas.

Cerimônias do Scrum, XP e Kanban

Ao contrário do que muitos times novatos pensam, passar a utilizar uma metodologia ágil não quer dizer que você vai ter mais reuniões do que já tem. O que acontece é que sim, haverá uma disciplina maior na facilitação e recorrência das mesmas, para garantir o alinhamento e a comunicação, consequentemente aumentando a chance de sucesso do projeto.

O Scrum possui cerimônias muito famosas, logo pegarei as mesmas como exemplo de comparação. No Scrum temos a Sprint Planning, marcando o início de uma iteração (a propósito, Scrum e XP possuem iterações, Kanban não, ele possui cadências). Da mesma forma, no XP teremos o Jogo de Planejamento, sendo que existe o Planejamento de Iterações (tal qual Sprint Planning) e o Planejamento de Releases (semelhante a um Product Increment Planning do SAFe).

Extreme Programming Project
Extreme Programming Project

Já no Kanban é mais parecido com o XP do que o Scrum, pois se quebrou a cerimônia de planejamento em duas. Aqui as cerimônias se chamam cadências e temos a Replenishment ou Commitment Meeting e a Delivery Planning Meeting.

E depois de planejado, mantemos a sincronia do time através da famosa e polêmica reunião diária. Se tem uma coisa que gera polêmica e que ao mesmo tempo é unânime entre os métodos ágeis é a necessidade de reuniões frequentes e rápidas enfatizando a comunicação. No Scrum temos a Daily Scrum, no XP a Daily Stand Up Meeting e no Kanban a Standup Meeting (também com frequência diária).

Curiosamente, no Scrum também se faz esta cerimônia em pé, mas esta é uma regra do XP e do Kanban, e não do Scrum.

Ciclo Scrum
Ciclo Scrum

Findo o desenvolvimento do incremento de software, é hora de revisar o que foi feito e entregar ao cliente. No Scrum chamamos este momento de Sprint Review e no Kanban temos duas cadências para revisar a entrega, denominadas Service Delivery Review e Strategy Review. No XP não temos nada específico para este momento até onde pude estudar, talvez até pelo própria ênfase em entrega contínua (Continuous Delivery), o que obviamente não invalida pequenos pacotes com review do cliente.

E para finalizar, quando o assunto é revisar como o time está trabalhando, o Scrum tem as famosas Sprint Retrospectives, o XP menciona retrospectivas, mas não define algo mais concreto e no Kanban temos uma mescla entre Service Delivery Review (métricas), Operations Review (otimizações no fluxo de valor) e Risk Review (ajustes no processo visando mitigar riscos). Note que apesar do Kanban aparentar ter mais cerimônias, é super comum a mescla entre elas ou a periodicidade assíncrona.

Cadências do Kanban
Cadências do Kanban

Artefatos do Scrum, XP e Kanban

Quando o assunto são os artefatos, aí é que temos uma enorme confusão. Ninguém se lembra qual artefato é de qual método.

Primeiro, usar um board de atividades é muuuito comum em qualquer time ágil, mas ele é originário do Kanban.

Kanban
Kanban

Segundo, escrever os requisitos em formato de histórias de usuário é outra prática comum, mas ele é natural do XP.

User Story Card
User Story Card

Terceiro, métricas como Lead Time e gráficos como o Cumulative Flow Diagram são artefatos do Kanban, embora largamente utilizados em diversos times Scrum e XP.

Lead Time
Lead Time

E por fim, estimar usando pontos em escala de Fibonacci, através de um baralho de cartas não é de nenhum dos três métodos, mas simum artefato inventado pela Mountain Goat Software chamado Planning Poker. Eu sei, no Kanban é mais comum contar atividades do que estimá-las, mas nada lhe impede de estimar em Kanban exceto o radicalismo de alguns agilistas. XD

Planning Poker
Planning Poker

Logo, aqui não temos semelhanças, mas sim um compartilhamento de ferramental que chega a tornar confuso saber o que é oficial de cada framework.

Por hoje é só pessoal. Como já disse no artigo O que é melhor: Scrum ou Kanban, acredito no uso combinado destes métodos para alcançar os melhores resultados com os times.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

O que é melhor: Scrum ou Kanban?

Na verdade o título que eu gostaria de usar neste artigo era “O que é melhor: desenvolvimento iterativo-incremental ou em fluxo contínuo?”, mas como os nomes dos processos são mais famosos que o conceito por trás deles, resolvi deixar como está. Além disso, a melhor analogia que eu poderia utilizar (eu adoro analogias!) para lhe poupar o trabalho de ler o artigo inteiro seria fazendo uma pergunta diferente “O que é melhor: a chave de fenda ou o martelo?”. Pense nisso.

E se estiver com preguiça de ler o artigo inteiro (depois só não vai fazer perguntas já explicadas no artigo), pule direto para as tabelas no final do mesmo.

Alguns fundamentos…

Antes de entrar nos argumentos do porquê da analogia é importante lembrar que Scrum, de 1995, é um framework empírico de desenvolvimento iterativo-incremental para projetos complexos e adaptativos. Ele foca no trabalho em equipe, melhoria contínua e muitos outros princípios que mais tarde originariam o Manifesto Ágil (2001). Sendo pouco prescritivo para os métodos de gestão de projetos à época, foi fortemente influenciado pelo artigo de Takeuchi e Nonaka, The New New Product Development Game (1986), de onde veio inclusive a ideia de comparar os times de desenvolvimento com os times de rúgby.

Já o Kanban do qual estamos falando é a versão de 2002, adaptada por David Anderson para gestão de atividades dentro de um fluxo de valor contínuo. Oriundo do sistema kanban de Taichii Ono (década de 50), criador do Sistema Toyota de Produção, ele foca no mapeamento e otimização do fluxo de valor de maneira que as pessoas que trabalhem no mesmo o façam com o maior eficiência possível (resumidamente: mantendo um lead time baixo com qualidade total). Ele toma para si uma abordagem evolucionária e colaborativa e é menos prescritivo ainda que o Scrum.

Você conhece mais sobre a essência destes métodos no meu artigo A Essência do Agile.

Principais Diferenças

A ideia aqui ainda não é falar qual é o melhor, apenas citar algumas diferenças (sem entrar no mérito se é uma vantagem ou desvantagem).

O Scrum tem um foco muito grande em ser um framework e não um método: uma estrutura mínima que te dê subsídios para avançar dentro do ágil, mas sem você ter de começar do zero. Suas cerimônias, papéis e artefatos constroem disciplina e tomada de consciência do time para a transparência, inspeção e adaptação.

Implementações de Scrum quebram silos ao criar times multidisciplinares, horizontalizam os times removendo a hierarquia e diminuem o achismo ao focar em ciclos rápidos de construir-medir-aprender tal qual no Lean Thinking (também derivado da Toyota).

Já o Kanban parte de uma filosofia “comece com o que você tem hoje”, onde o value stream mapping inicial é apenas o ponto de partida para a tomada de consciência com base no empirismo. Suas cerimônias, papéis e artefatos são praticamente emergentes e muitas vezes não são usados na sua plenitude pelos times.

Implementações de Kanban são evolucionárias e não costumam causar transformações desde o primeiro dia, embora possuam um forte apelo visual oriundo do uso quase onipresente do task board pelos times. Assim como o Scrum, mas ainda mais presente aqui, possui forte ligação com o Lean Thinking, principalmente no que tange o trabalho de Hansei e Kaizen (reflexão e melhoria) sobre os desperdícios do fluxo (Muda, Mura e Muri).

E por fim, as entregas. Enquanto no Scrum focamos em entregas iterativo-incrementais, ou seja, pequenas entregas em pequenos ciclos; no Kanban focamos em um ciclo único de entregas contínuas. E esta é, sem sombra de dúvida, a parte mais polêmica da discussão. Em um tempo que temos ferramental para Continuous Delivery, não seria óbvio que fluxo contínuo é melhor que entregas iterativo-incrementais?

Mais ou menos…

Entrega contínua vs Maturidade do Projeto

Scrum não fala nada contra Continuous Delivery. Tão pouco Kanban fala algo a respeito. Scrum inclusive se popularizou sobre o waterfall devido ao fato do número de entregas muito maior do que apenas uma durante todo o ciclo de vida de um projeto. Quebrar um projeto waterfall em vários ciclos menores não apenas permitiu que fizéssemos mais entregas do que antes como também permitiu que aprendêssemos mais rápido.

A confusão com Scrum vs CD é a mesma que o pessoal tem com as timeboxes do Scrum. Se uma planning tem uma timebox de 8h para 30 dias de sprint, NÃO quer dizer que ela tem de demorar 8h. O tempo MÁXIMO é 8h. Da mesma forma, na PIOR das hipóteses, você deve entregar um incremento de software a cada sprint, para garantir que o time está avançando e entregando valor. Agora, se seu time consegue entregar software diariamente, manda ver, só não esquece de alinhar com seu Product Owner, pois nem sempre jogar software em produção continuamente é uma boa ideia (mesmo testado).

Mas o que quero tratar aqui não é Scrum vs CD ou como Kanban ama CD, mas sim uma discussão mais importante que é: faz sentido para o seu time trabalhar focado em fluxo contínuo?

Vou te dar um exemplo: seu projeto está começando hoje. O backlog é imenso, tem uma série de questões estruturantes para serem feitas, o MVP está longe de poder ser usado por um cliente de fato (mas ainda é válido de ser testado por usuários-chave). Uma única tarefa ou história não agrega valor sozinha pois ainda é muito cedo, o software ainda não está minimamente maduro para que cada pedaço faça sentido ser colocado em produção.

Agora outro exemplo: seu produto está no ar há meses. O backlog continua a crescer, mas são sempre features complementares ao projeto original. Cada uma das features levam várias tasks para serem concluídas, mas garantem avanços e inovações para os clientes a cada semana ou quinzena (diferente da v1.0 que levou de 1-3 meses pra ser concluída). Tasks individuais ainda não geram valor per se, exceto no caso de correções de bugs. O software está amadurecendo cada vez mais rápido.

E um último exemplo: seu produto está no ar há mais de um ano (talvez vários anos). O backlog já não cresce mais tanto, geralmente entrando pro time (agora bem menor) uma série de ajustes, correções, melhorias pontuais e raramente alguma feature mais complexa. Diz-se que o software entrou em modo de sustentação, sendo que cada task já gera valor individualmente e os clientes tem acesso a melhorias (se seu pipeline estiver evoluído) diariamente. O software está completamente maduro e provavelmente já existe outro time pensando em um novo produto para substituí-lo.

Em quais destes três cenários você enxerga um bom uso de entregas organizadas em semanas (iterativo-incrementais) e em quais faz mais sentido as entregas diárias ou o mais próximo disso (em fluxo contínuo)?

A tabela abaixo mostra a minha resposta para este questionamento:

Scrum vs Kanban - Tabela 1
Scrum vs Kanban – Tabela 1

Entenda como verde o que recomendo que seja utilizado, amarelo use com cautela (entenda a situação, faça adaptações) e vermelho evite. E se nunca ouviu falar de ScrumBan, é a prática quase universal de usar Scrum com um board estilo Kanban para gestão visual de demandas e outras práticas de fluxo contínuo.

Vou ressaltar aqui apenas dois pontos: os vermelhos.

Rodar scrum “by the book” em times de sustentação de software é um tiro no pé. Você tem de adaptar para um ScrumBan ou outra adaptação qualquer, caso queira ser bem sucedido. Dependendo das classes de serviço que este time for trabalhar, nem mesmo faz sentido rodar métodos ágeis e apenas uma gestão de incidentes mais tradicional, no melhor estilo ITIL.

E por outro lado, rodar somente o sistema Kanban em times criando um software do zero não vai servir pra muita coisa, seu Lead Time não terá como ser baixo (um dos principais objetivos do Kanban se perde neste caso) e o sistema não ajudará no team building (na verdade Kanban pouco se importa com o time, e sim com o fluxo rodando rápida e perfeitamente).

Note que esta é apenas a minha opinião, mas criada a partir de mais de 8 anos rodando ambos em diferentes times.

No entanto, não querendo lhe dar uma equação tão simples e por vezes míope para essa discussão, eu agregaria ainda outro fator: o quão proficientes em métodos ágeis são os membros do seu time?

Processo Ágil vs Maturidade do Time

Maturidade de time é um tema sempre polêmico, mais até que Scrum vs Kanban, hehehe. Pretendo abordar este tópico em outro artigo. Por ora, estou dividindo aqui os times em apenas dois níveis: Agile Noobs (quem nunca trabalhou com métodos ágeis antes e/ou tem pouca experiência) e Agile Practioners, a galera que já roda métodos ágeis há tanto tempo que os 12 princípios do manifesto já estão no seu sangue, já o fazem independente do processo estabelecido.

Por que considerar isto é importante?

Por ser mais prescritivo (se comparado ao Kanban), o Scrum é quase que uma formação em métodos ágeis para o time. Ele trabalha toda a questão de disciplina, responsabilidade, trabalho em equipe. Torna concreto uma série de princípios ágeis mais abstratos. Inclusive, com o passar do tempo e com a tomada de consciência que ele traz, o próprio time vai entender por si só se o Scrum ainda está lhe ajudando ou não. Esse é exatamente o conceito ShuHaRi de aprendizado das artes marciais japonesas, que pretendo abordar em outra oportunidade.

Não quero dizer que começar com Kanban em um time Agile Noob não possa dar bons resultados, mas sim que, na minha experiência, se tornou muito mais eficiente começar com Scrum. Posto isso, segue outra tabela, agora considerando a experiência do time com métodos ágeis:

Scrum vs Kanban - Tabela 2
Scrum vs Kanban – Tabela 2

Vou ressaltar aqui apenas dois pontos: o amarelo e o vermelho.

Sim, eu não recomendo Kanban “puro” para times que estão começando agora com métodos ágeis. Note que me refiro aqui a times de software, em outros nichos às vezes faz sentido só usar Kanban a vida inteira do time.

E sobre Scrum puro em times mais avançados, deixo à critério do próprio time decidir, uma vez que já devem ter experimentado ambos e com base no entendimento do próprio time eles podem tomar esta decisão sozinhos (pensando aqui que você que está lendo seja um agilista).

Análise Final

E se você, assim como eu, está preocupado em cruzar as duas informações, vou poupar o seu trabalho com a tabela abaixo, onde cruzo ambas tabelas para fácil consulta.

Scrum vs Kanban - Tabela 3
Scrum vs Kanban – Tabela 3

Aqui novamente explicarei somente os dois extremos: o vermelho e o verde.

Em vermelho, quero dizer que times novos no ágil em projetos novos devem fortemente ser orientados a usar Scrum. Scrum é uma excelente “escola” quando o assunto é agilidade. O time deveria no mínimo tentar utilizá-lo por algumas sprints (geralmente leva-se de 2 a 3 para ter sucesso com Scrum) antes de descartar essa possibilidade.

Em verde, quero dizer que times ágeis trabalhando em software maduros devem estar livres para usar o processo que quiserem. Geralmente estes times acabam usando algum tipo de amálgama, dificilmente abandonando as raizes do Scrum e/ou do Kanban. Geralmente estes times não possuem mais lideranças prescritivas (como o Scrum Master), mas sim situacionais.

Ainda que existam pessoas que talvez venham comentar que times realmente ágeis deveriam ser livres para usar o processo que quiserem desde o primeiro dia de projeto, minha recomendação é não cair na armadilha do “não precisamos de processo, já sabemos tudo que deve ser feito e como deve ser feito”. Eu jamais cheguei em um time que, por mais que já trabalhassem juntos há um tempão, não tivessem margem para melhorar através de ajustes de processos e ferramentas bem ajustados.

No livro Extreme Programming do Daniel Wildt (e cia.) tem uma frase muito boa que diz: não existe a perfeição, apenas o aperfeiçoar. Curiosamente, a maioria dos times com os quais tive de lidar achavam que não precisavam da ajuda de um agilista, que já eram maduros…

Voltando à analogia que eu coloquei lá no início, Scrum e Kanban são ferramentas diferentes que em alguns momentos você vai querer usar uma das duas, em outros momentos as duas e talvez em um terceiro momento, nenhuma delas. Afinal, quem disse que para ser ágil tem de usar Scrum OU Kanban?

Sem contar o XP…onde ele entra nessa história? Tento falar disso nesse outro artigo.

E você, concorda ou discorda? Qual a sua opinião a respeito? Manda aí nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

Como ensinar Scrum na prática #2

Em 2010 eu fiz um curso em SP de Scrum onde eu aprendi uma dinâmica para ensinar Scrum a outros times muito simples e divertida que consistia em, após estudar o básico da metodologia, em sintetizar o aprendizado em um folder, daí o nome da dinâmica que eu chamo de Agile Folder. Esta dinâmica pode ser conferida neste artigo aqui.

No artigo de hoje, vou falar de outra dinâmica que pode ser utilizada para ensinar Scrum na prática, oriunda de um treinamento de Agile Coach que fiz em 2018 com o Andy Barbosa, onde aprendemos alguns princípios em cima de uma Fábrica de Aviões. Obviamente estamos falando de aviões de papel. 🙂 Eu já fiz esse treinamento algumas vezes com times variados no Agibank, incluindo pessoas de áreas que não são de TI como Gestão de Pessoas, Backoffice, Marketing e tive excelentes resultados.

Dinâmica da Fábrica de Aviões
Dinâmica da Fábrica de Aviões

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 10 por pessoa) e tudo o que você encontrar para rabiscar: canetas, lápis, giz de cera, etc. É importante que as pessoas tenham mesas para trabalhar.

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.

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 e os papéis 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.

Se o seu time não é composto por profissionais de projeto, talvez apresentar o conteúdo do Scrum Guide diretamente não fará sentido. Neste caso, sugiro introduzir os conceitos aos poucos, se baseando mais fortemente na essênca da agilidade, usando este meu outro artigo como apoio.

Explicando a Prática

A prática envolve o desenvolvimento de um produto que, em teoria, não é complexo: aviões de papel.

Diga para que se organizem em times de 4-5 integrantes, deixe os materiais de papelaria à disposição, mas não distribua nada, os times tem de ser auto-organizáveis. Explique que iremos simular a construção de aviões 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 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 Agile Coach, ensinando o time a utilizar o Scrum corretamente e provocando as discussões. Sempre que algum time quiser falar com o Agile Coach ou com o cliente, deverá chamá-lo adequadamente para que você coloque a gravata ou boné e aja de acordo com sua persona.

Cada time deverá ter um Product Owner, que é quem fará a interface com o cliente e dará o aceite nos aviões, pois ele representa os interesses do cliente no dia a dia do projeto.

Cada time deverá ter um Scrum Master também, que pode ter mais de um papel caso o time seja muito pequeno (4 ou menos pessoas). Ele só não pode ser o P.O. e S.M., mas pode ser S.M. e Desenvolvedor. O Scrum Master dará o ritmo pro time, removerá impedimentos, cuidará dos materiais e do fluxo de trabalho combinado.

Os demais membros do time (2 a 3 pessoas) serão os desenvolvedores, responsáveis pelas atividades de confecção dos aviões: dobras, pintura, testes, etc. Deixe que se organizem os papéis antes de prosseguir e opcionalmente peça que criem nomes para seus times.

Executando a Prática

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 as cerimônias e consequentemente a duração das sprints e que devem respeitá-lo quando disser que a sprint 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.

Iremos rodar mais de uma sprint de construção de aviões e, para que tudo caiba dentro do tempo disponível, sugiro usar a seguinte divisão:

  • 10 minutos para a primeira Sprint Planning, sendo 5 para a explanação do cliente e 5 para o time entrar em acordo de como vão trabalhar e o quanto vão entregar;
  • 5 minutos para a construção dos aviões (e propositalmente pequeno e não faremos daily nesta dinâmica, pois teremos mais de uma retrospectiva);
  • 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 com a presença do cliente (você de gravata). Será feito apenas uma Sprint Planning geral, com todos os times escutando e fazendo perguntas. Você deve explicar que deseja um lote de 10 aviões em um tempo de 5 minutos, mas que todos eles devem ser iguais, devem voar e devem respeitar o modelo que você vai apresentar em um slide (escolha um modelo minimamente complexo, como o abaixo, em que a traseira possui um ângulo não tão óbvio de fazer e cujas dobras ficam escondidas na parte inferior do avião, ao invés da superior).

Avião de Papel
Avião de Papel

Avise que está buscando estes lotes com estes times mas que o contrato final só vai ser realizado com um deles, o que se sair melhor na dinâmica como um todo. Isso deve dar uma esquentada nas expectativas, mesmo sendo uma brincadeira bem simples.

Dê tantos detalhes quanto julgar necessários, mas tente deixar com que os participantes lhe questionem os detalhes mais importantes, como o tamanho do avião, adicione uma logomarca se quiser complicar, cores diferentes na fuselagem, que todos devem ser testados, etc. Uma das lições desse treinamento é que sempre o time tem de se comunicar com o cliente 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 avião final e deixe um pronto como referência, mas não mostre a eles ainda, 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 o projeto do avião, o lote a ser feito, planejar as atividades dos membros, a ordem que farão 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 cliente para mostrar 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.

Rode os 5 minutos da sprint 1 com o timer visível para todos, bem como o modelo do avião (geralmente eu imprimo este último). Não faremos a Daily neste treinamento pois as retrospectivas serão bem próximas para gerar aprendizado e o tempo da sprint é muito curto. O Scrum Master, enquanto facilitador do processo deve avisar a todos quando os minutos estiverem terminando, deve controlar o tamanho do lote e auxiliar coordenando as atividades conforme combinado. Deixe em aberto a possibilidade de chamarem o cliente (coloque a gravata quando isso acontecer) ou o Agile Coach (boné) quando quiserem tirar dúvidas do produto (cliente) ou do processo (Agile Coach).

É comum que nesta primeira sprint os times façam aviões diferentes, não testem todos aviões, não façam validações com o cliente nem mesmo novas perguntas. Caso algum time tente renegociar prazos com o cliente não aceite, mas com muita relutância permita alteração no escopo por exemplo, mas sem exageros, como reduzir em algumas unidades o lote ou mudar algum padrão estético (pintura somente). 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.

Quando os 5 minutos terminarem (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 seu trabalho para o cliente (coloque a gravata) avaliar.

Para cada um dos times, analise criteriosamente o lote. Verifique se todos aviões seguem o modelo combinado, se fizeram todo o lote combinado, se todos estão iguais, etc. Se você reparou problemas na fabricação, como a ausência de testes, pergunte se alguém voaria em um avião que não foi testado. Se você reparou mudanças estéticas não acordadas, questione porque não lhe perguntaram se isso era permitido. E principalmente, se o time não entregou todo o lote, reclame, pois eles disseram que iam entregar.

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. Use 4 minutos para avaliação e 1 minuto para reflexões com o grupo (quase uma retrospectiva coletiva, onde vai haver trocas de aprendizados).

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, com a mediação do Scrum Master) vai expor o que considerou que fluiu legal no desenvolvimento deste lote (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 de toda prática e ele. Como todo bom erro, é na falha em que mais aprendemos e geralmente os times falham nessa prática.

Reserve 5 minutos para que eles decidam entre si como vão se organizar para a próxima sprint e passeie como Agile Coach pelos times para ajudar a tirar dúvidas do processo, instigá-los a melhorar o que está com problema (uma vez que os Scrum Masters de cada time não terão experiência pra isso) e cobre ao menos uma melhoria no processo de cada time.

Sprint #2

A segunda sprint vai começar e a dinâmica será muito parecida, com algumas poucas exceções.

Primeiro, o tempo de Sprint Planning será de 5 minutos ao invés de 10, uma vez que eles já se conhecem mais e tem pouca variação em relação à sprint anterior.

Segundo, introduza um novo modelo de avião ou uma variação no modelo anterior, como uma mudança de cor, uma dobra diferente, etc. Peça um lote de 10 aviões, mas sendo um número específico de cada modelo, pra complicar um pouco a vida dos times.

Desta vez espere muito mais perguntas e tentativas de negociação, pois eles estarão mais espertos e entenderão que o time tem mais poder do que estão acostumados. Seja teimoso, mas saiba ceder quando fizer sentido os argumentos e sempre explore a competição entre os times de uma maneira saudável, pois se um time entregar apenas um avião com qualidade top e outro time entregar cinco, você vai fechar contrato com o outro.

Após formalizar as entregas previstas com cada time, rode nova sprint de 5 minutos, faça nova review e finalize esta sprint com outra retrospectiva.

Quando acaba?

Você pode rodar tantas sprints quanto julgar necessário, mas no mínimo duas, para que tenham a oportunidade de aprender com seus erros e melhorar. É importante que a cada sprint sejam adicionadas novas complexidades, como por exemplo:

  • novos modelos de avião;
  • lotes variados;
  • que tal um avião extra solicitado no meio da sprint?
  • que tal uma mudança de requisito na confecção de um modelo no meio da sprint?
  • que tal a saída de um membro ou troca de membros entre os times?

A grande sacada não é ser simplesmente sádico, mas provocar diversas situações que acontecem no dia a dia dos times e que o treinamento já vai lhes preparar para reagir adequadamente.

Se tiver tempo, você pode introduzir no treinamento o conceito de Scrum Board também (um kanban bem simples), para gerenciar o fluxo de construção de múltiplos aviões, de múltiplos modelo oriundos de pedidos de múltiplos clientes (!!!). Uma sprint com esse grau de complexidade requer uma gestão mais eficiente e o kanban é uma ótima ferramenta para isso.

Tive a oportunidade de aplicar este mesmo treinamento em algumas dezenas de times do Agibank 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.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!