Tanto o Scrum quanto o Kanban têm um conjunto de reuniões que auxiliam a definir em que trabalharemos, quais os nossos objetivos, se podemos melhorar nosso trabalho e quais resultados estamos alcançando. Este artigo busca discutir semelhanças e diferenças entre as reuniões do Scrum e Kanban.
Neste artigo
Antes de começarmos eu gostaria de definir um glossário mínimo. Em especial o Quadro de Fluxo de Trabalho. Se eu ganhasse $1,00 para cada nome de quadro que eu já ouvi, eu teria uns $20,00 😀. Alguns nomes que seu time pode estar utilizando: Quadro Kanban, Quadro Scrum, Quadro do Time, Quadro de Tarefas, Quadro Nível 1, Quadro, Quadro de Agilidade, Quadro de Gestão Visual e muitos outros além das variações em inglês. Aqui utilizarei o nome Quadro de Fluxo de Trabalho por ser mais genérico e porque ele deve mapear o seu fluxo de trabalho.
Semelhanças e diferenças entre as reuniões no Scrum e Kanban.
Vejamos agora alguns pontos importantes antes de começarmos a detalhar cada uma das reuniões.
Nomenclatura
Já começamos com uma “semelhante diferença”. Nenhum dos dois chama reunião de reunião. O Scrum adotou o nome evento, porém é comum que algumas pessoas chamem de cerimônias. Embora esse nunca tenha sido o nome oficial no guia do Scrum, era o nome utilizado pelo Jeff Sutherland em suas apresentações durante os anos 90 – 2000. Já o Kanban adotou o nome de cadências. Com a ideia de que acontecem com regularidade. Semelhante às batidas de um bumbo marcando o compasso.
Obrigatoriedade
Talvez a principal diferença entre as reuniões Scrum e Kanban estejam na questão de sua obrigatoriedade. Quando um time adota o Scrum, ele passa a ter um evento chamado Sprint que é um período de 1 mês ou menos, podendo ser inclusive menos do que 1 semana (Guia do Scrum 2020, p.7). Todos os demais eventos do Scrum acontecem no entorno da Sprint. São quatro e todas devem ser realizadas.
Já o Kanban não torna obrigatório a utilização de uma Sprint dando preferência a criação de um fluxo contínuo ao invés do trabalho cíclico. Além disso, não há obrigatoriedade em nenhuma reunião. O time poderá adotá-las se acreditar ser necessário. Normalmente a adoção acontece como a solução de problemas. Por exemplo, percebo que no time cada um está fazendo a “sua parte” sem se importar com o resultado e quando tentamos integrar o trabalho de todos, vira um caos. Agora que temos um problema explícito, vamos buscar uma possível solução que poderia ser a Reunião Kanban de Time.
Reuniões ao escalar a agilidade na organização
O Guia do Scrum é escrito com o objetivo de ser simples (Guia do Scrum 2020, p.3). Um time, com um backlog e reuniões que atendam a essa necessidade. Se for necessário escalar para tratar diversos times com diversos backlogs, provavelmente será necessário outro método, por exemplo o Large Scale Scrum (LeSS).
Já o Kanban prevê em seu corpo principal a possibilidade de escala envolvendo mais de um time ou até mesmo mais de um nível na hierarquia organizacional. Conforme a empresa ganha maturidade na adoção do Kanban, outros tipos de reuniões poderão ser utilizados.
Por exemplo, imagine que temos uma empresa com apenas um time e todo trabalho para atender às necessidades do cliente esteja dentro deste time. Com exceção de algumas reuniões pontuais com clientes e gestores, no geral, esse time não precisará interagir com mais ninguém. Logo, todas as cadências serão internas. Agora se para atender a necessidade do cliente é necessário o trabalho integrado de dois times, é natural que tenhamos algumas reuniões entre eles.
O Quadro acima faz parte do material da Kanban University, traduzido pelo autor do presente artigo. Nele temos as cadências (reuniões) do Kanban por nível de maturidade. No canto superior esquerdo de cada quadro é apresentado o nível de maturidade em Kanban. Abaixo, temos o nome da cadência.
Cada nível de maturidade que a empresa consegue galgar poderá exigir novas cadências ou a substituição de cadências de níveis mais baixos. Sendo extremamente sucinto, pois há um treinamento de 16 horas para tal, resumo o que seria cada nível de maturidade apenas para dar continuidade a esse artigo:
Nível de Maturidade 1: estamos trabalhando com o nível de um time apenas. Pelo mais que a organização possua mais times utilizando Kanban, ainda não conseguimos ou não tivemos a necessidade de integrar os fluxos de trabalho.
Nível de Maturidade 2: Já há a integração entre fluxos de trabalhos complementares e coordenar a interação entre os times é importante para que consigamos atender às necessidades dos clientes.
Nível de Maturidade 3: começa a olhar a empresa como um todo. Agora não só olhamos o fluxo de trabalho como também o cliente e se aquilo que produzimos é adequado ao seu propósito (fit-for-purpose).
Nível de Maturidade 4: Além de trazer o cliente para a discussão, também busca trazer robustez para o negócio e tratar os riscos aos quais a empresa está exposta.
Como esse artigo é um comparativo entre as reuniões de ambos os métodos, vamos apenas utilizar as cadências do Nível de Maturidade 1. Também é importante mencionar que vamos nos ater às definições apresentadas no Guia do Scrum de 2020 e no material disponibilizado pela Kanban University.
Planejamento da Sprint e o Reunião Interna de Reabastecimento do Time
Ambos os métodos possuem uma reunião de escolha de próximos itens. A ideia primária em ambos é olhar para o backlog (lista de itens de coisas que temos para fazer) e escolher quais itens serão feitos em seguida. O evento de Planejamento da Sprint (Sprint Planning) tem algumas especificidades, pois ela começa formalizando o porquê da Sprint, a Meta da Sprint (Spring Goal). Os itens que serão escolhidos devem derivar desse objetivo.
Uma pequena diferença entre os métodos, além da não obrigatoriedade do Kanban, é quanto a quem participa. No Scrum, todo o Time deve participar e todos os seus papéis: Scrum Master, Product Owner e Desenvolvedores (anteriormente chamados de Time de Desenvolvimento). Já no Reabastecimento do Time (Team Replenishment) não precisa que todos participem da cadência.
| Scrum | Kanban | |
|---|---|---|
| Reunião | Planejamento da Sprint | Reunião Interna de Reabastecimento do Time |
| (em inglês) | Sprint Planning | Internal Team Replenishment Meeting |
| Objetivo | Definir o Meta da Sprint | Escolher os próximos itens que o time desenvolverá |
| Escolher os próximos itens que o time desenvolverá durante a Sprint | ||
| Entradas Primárias | Product Backlog | Backlog / Piscina de Opções |
| Saídas Primárias | Meta da Sprint | Itens selecionados |
| Sprint Backlog (itens selecionados) | ||
| Participantes | Time Scrum (Scrum Master, Product Owner e Desenvolvedores) | Líder de equipe; contato com o cliente; parte da equipe ou equipe completa (lista não exaustiva) |
| Periodicidade | No início de cada Sprint | Semanalmente ou quando necessária |
| Duração Máxima | 8h para Sprint de 1 mês | 20 até 30 minutos |
Scrum Diário e Reunião Kanban do Time
Uma vez que escolhemos o que faremos, é necessário acompanhar se estamos conseguindo construir os itens. Ambos têm uma reunião para tal.
As três perguntinhas da reunião diária
Sobre o Scrum Diário (Daily Scrum) é importante relatar um fato importante. Normalmente as pessoas dizem que é o momento de responder três perguntas: 1) O que eu fiz ontem desde a última reunião? 2) O que farei até a próxima reunião? 3) Há algum obstáculo / impedimento no meu caminho? Essas eram três perguntinhas sugeridas no Guia do Scrum de 2010 (p.15).
Na atualização de 2013 (p. 10), essas perguntas foram alteradas, pois as pessoas não faziam uma conexão entre o Scrum Diário com o Planejamento da Sprint. Ken Schwaber e Jeff Sutherland, criadores do framework Scrum, definiram que a Meta da Sprint (Sprint Goal) seria esse elo. As perguntas então ficaram: 1) O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a Meta da Sprint? 2) O que farei hoje para ajudar o Time de Desenvolvimento a atingir a Meta da Sprint? 3) Vejo algum impedimento que impeça a mim ou ao Time de Desenvolvimento de atender a Meta da sprint?
Na versão de 2017 (p. 12) as três perguntas se tornaram opcionais e em 2020 (p. 10) as perguntas deixaram de ser utilizadas. Primeiro porque há outros modos de conduzir a reunião diária, segundo estava tornando-se apenas uma reunião de status report e não um momento de colaboração. Para mais informações sobre isso, veja o vídeo de lançamento do Scrum Guide de 2020 (em inglês).
O Kanban nunca se utilizou de perguntas. O modelo de uma cadência de Reunião Kanban do time é:
- Ande no Quadro de Fluxo da direita para a esquerda (dos itens mais pertos da entrega para os mais distantes);
- Gerencie o trabalho, não os trabalhadores!
- Concentre-se em concluir itens de trabalho e resolver problemas.
- Discuta as prioridades e as decisões dos membros da equipe.
- Discuta itens de trabalho prontos para serem iniciados.
| Scrum | Kanban | |
|---|---|---|
| Reunião | Scrum Diário | Reunião Kanban do Time |
| (em inglês) | Scrum Daily | Team Kanban Meeting |
| Objetivo | Inspecionar o progresso rumo ao Sprint Goal | Observar e rastrear o status e o fluxo do trabalho. |
| Adaptar o Sprint Backlog conforme necessário | Descobrir como podemos entregar os itens de trabalho mais rapidamente. | |
| Definir se temos capacidade disponível para puxar outros itens de trabalho | ||
| Entradas Primárias | Quadro de Fluxo de Trabalho | Quadro de Fluxo de Trabalho |
| Saídas Primárias | Quadro de Fluxo de Trabalho atualizado | Quadro de Fluxo de Trabalho atualizado |
| Participantes | Desenvolvedores. O Product Owner tem uma participação secundária | Todos os envolvidos no trabalho |
| Facilitador | Scrum Master | Normalmente alguém facilita |
| Periodicidade | Diária | Normalmente diária |
| Duração máxima | 15 minutos | 15 minutos |
Retrospectiva da Sprint e Retrospectiva do Time
Essa talvez seja a reunião com mais similaridades entre ambos os métodos. O Guia do Scrum 2020 define que o evento de Retrospectiva da Sprint tem como objetivo “planejar maneiras de aumentar a qualidade e a eficácia” (p.11). Já o material de Kanban diz que o objetivo da cadência da Retrospectiva do Time é fazer com que eles reflitam sobre como a equipe gerencia seu trabalho e como pode melhorar.
Em ambos os casos, a entrada pode ser resumida como tudo o que aconteceu desde a última retrospectiva até a próxima. A saída é pelo menos uma ação de melhoria para aperfeiçoar o trabalho do time.
Cabe aqui uma ressalva interessante. Como o Scrum é um framework, ele não descreve como o time fará a retrospectiva, porém o Kanban, por ser um método, apresenta guias gerais que devem ser utilizadas:
- A Cadência de Retrospectiva do Time deve ser feita na frente do quadro de fluxo de trabalho, com foco nos itens de trabalho concluídos.
- O time deve coletar observações / ocorrências. Por exemplo, itens que ficaram faltando, itens que o time ainda pretende fazer, ideias que valem a pena explorar mais, eventos que foram irritantes ou agradáveis e questões relacionadas às políticas atuais.
- Por fim, categorize o feedback coletado e defina ações de melhoria.
| Scrum | Kanban | |
|---|---|---|
| Reunião | Retrospectiva da Sprint | Retrospectiva do Time |
| (em inglês) | Sprint Retrospective | Team Retrospective |
| Objetivo | Aperfeiçoar a eficiência, eficácia, ecossistema e excelência técnica do trabalho. | Aperfeiçoar a eficiência, eficácia, ecossistema e excelência técnica do trabalho. |
| Entradas Primárias | O que aconteceu na sprint | O que aconteceu desde a última retrospectiva de time |
| Saídas Primárias | Ações de melhoria | Ações de melhoria |
| Participantes | Todo o time Scrum | Todo o time |
| Facilitador | Scrum Master | Normalmente alguém facilita |
| Periodicidade | Ao final de cada Sprint | Regularmente |
| Duração máxima | 3h para Sprint de 1 mês | 1 hora |
Revisão da Sprint e …?
No quadro apresentado no início do texto talvez você tenha sentido a falta de algo. O Kanban não tem nada similar à Revisão da Sprint (Sprint Review). No Guia do Scrum, esse evento tem como objetivo inspecionar o resultado da Sprint (incremento do produto) e determinar as adaptações futuras. Nela o Time Scrum apresenta os resultados do que foi construído para os stakeholders do produto e recebe feedback deles.
O Kanban não tem uma cadência que possamos comparar à Revisão da Sprint. Se você puxar pelo nome, pode achar que a Reunião de Entrega de Serviço (Service Delivery Meeting) do Nível de Maturidade Kanban 3 seria essa reunião, mas isso não é verdade, pois esta está focada em melhorar a integração entre os diversos fluxos envolvidos na entrega do serviço. Então, como faz?
Se o time achar relevante ter um momento de coleta de feedback com o cliente, ele poderá colocar essa etapa no fluxo de valor e incorporá-las de vez às atividades do time.
Reunião de Refinamento
Bem, essa não existe nem no Scrum e nem no Kanban. O Guia do Scrum 2020 afirma apenas que você deve refinar o item antes de incorporá-lo ao Product Backlog, mas não diz como e não cita a necessidade de um evento para tal (pp. 9, 10, 12).
Já o Kanban trata o refinamento através do seu Upstream que é o conjunto de etapas em que o time analisa uma opção para avaliar se ela deve ser descartada ou tornar-se um item de trabalho. Tratei esse assunto com mais detalhe no artigo: Fluxo de Trabalho: o upstream, midstream e downstream.
Conclusão
Espero ter ajudado a compreender que o Kanban também tem as suas reuniões e como podemos olhar para o Scrum e vermos as semelhanças e diferenças que existem entre elas.
Se quiser aprender mais sobre o Scrum veja o nosso treinamento de Certified ScrumMaster® (CSM). Se quiser saber mais sobre o Kanban e suas cadências, veja o nosso treinamento de Team Kanban Practitioner (TKP).
