Reuniões no Scrum e Kanban, semelhanças e diferenças

Compartilhe

Reuniões no Scrum e Kanban, semelhanças e diferenças

18/12/23 - 9 minutos de leitura

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. 

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.

Um quadro de fluxo de trabalho. Começa com o ponto de recebimento da demanda com uma quantidade grande de itens de trabalho. Após isso segue o fluxo do trabalho nas etapas Pedidos / ideias, Análise de viabilidade (4 itens), Refinamento (3 itens), Priorização (7 itens), Ponto de Comprometimento, Comprometidos (3 itens), Construção (3 itens), Avaliação (2 itens), Entrega (2 itens), Ponto de Entrega e Entregue com 5 itens.
Exemplo de Quadro de 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.

Texto Alternativo: A imagem apresenta as cadências (reuniões do Kanban). É uma imagem 3D com cada cadência representada por um cartão. No lado esquerdo estão as cadências relacionadas ao conjunto de entregas e estão sobrepostas em subconjuntos. O primeiro subconjunto é composto de 3 itens um em cada nível. Nível 1 Reunião de Interna de Reabastecimento do Time; nível 2 o Reabastecimento do Fluxo de Trabalho e nível 3 Reunião de Reabastecimento. Outro subconjunto composto por dois itens: nível 1 Reunião Kanban do Time e nível 2, Reunião Kanban do Fluxo de Trabalho. Ainda no conjunto voltado para entrega, um subconjunto unitário composto apenas pela Reunião de Planejamento da Entrega no nível 3. Do lado direito, temos as cadências dos conjuntos de melhoria. Começando por um conjunto composto pela Reunião de Retrospectiva do time no nível 1, Revisão do Fluxo no nível 2 e Revisão da Entrega de Serviço no nível 3. O segundo subconjunto de melhoria é composto por 2 itens que são a Revisão das Sugestões de Melhoria no nível 3 e Revisão de Operações no nível 4. Mais um subconjunto com dois itens: Agrupamento de Bloqueadores no Nível 2 e Revisão de Riscos no nível 4.
As cadências para cada Nível de Maturidade da adoção de Kanban pela organização.

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.

Quadro comparativo entre reuniões de planejamento do Scrum e Kanban
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.
Quadro comparativo entre reuniões de retrospectiva do Scrum e Kanban
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.
Quadro comparativo entre reuniões de retrospectiva do Scrum e Kanban
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.

Um quadro de fluxo de trabalho. Começa com o ponto de recebimento da demanda com uma quantidade grande de itens de trabalho. Após isso segue o fluxo do trabalho nas etapas Pedidos / ideias, Análise de viabilidade (4 itens), Refinamento (3 itens), Priorização (7 itens), Ponto de Comprometimento, Comprometidos (3 itens), Construção (3 itens). A etapa de Avaliação foi substituída pela etapa de Coleta de Feedback (2 itens). Após ela, temos a Entrega (2 itens), Ponto de Entrega e Entregue com 5 itens.
Exemplo de fluxo de trabalho com etapa explícita de coleta de feedbacks.

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).

Compartilhe

Escrito por

Avelino Ferreira Gomes Filho

Trainer na K21


Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21
Esta postagem se encontra sob a licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Artigos relacionados

Projetos com Agilidade teriam 268% mais chance de falhar. Será verdade? 
08/06/24
4 minutos de leitura
Dicas para Reuniões Mais Produtivas e Menos Estressantes
05/06/24
2 minutos de leitura
Estruturas para Inovação: 6 opções para acelerar a disrupção
08/05/24
10 minutos de leitura
O que é o Refinamento do Backlog?
17/04/24
3 minutos de leitura

    Receba mais conteúdos K21

    Deixe seu nome e email que nós te deixamos por dentro de tudo que rola por aqui.

    Ao informar meus dados, eu concordo com a Política de Privacidade.