Você está lendo este artigo e esperando que ao final dele eu te conte como escolher entre Scrum e Kanban? Sendo assim, preciso ser sincero e te informar que essa não será a resposta.
Te explico o motivo:
Escuto muito as pessoas colocarem Scrum e Kanban em uma batalha no mundo ágil em que precisa ter um vencedor, mas isso não é verdade.
Antes de compararmos a ferramenta (Scrum) e o conjunto de práticas (Kanban) responsáveis pelo desenvolvimento de software hoje, precisamos entender melhor sobre ambos. Para saber o que significa cada um deles e suas diferenças, continue lendo o artigo.
Framework Scrum vs Framework Kanban
Entendendo a duração e os objetivos de cada um deles
O Scrum é uma ferramenta time-boxed, com duração igual das sprints (por exemplo, duas semanas), onde as equipes definem qual objetivo daquela sprint e quais stories compõem aquele objetivo.
Durante esse período de tempo, a equipe ficará focada em desenvolver aqueles stories, para que ao final da sprint, algo de valor seja entregue.
Diferente do Scrum, o Kanban não possui um time-box fixo, no entanto, é realizado um planejamento do desenvolvimento para a semana. Dessa forma, o trabalho deve ser constante.
Priorizar a produtividade e a organização das entregas é o foco do Kanban. Ou seja, ajudar equipes a ajustar seu fluxo de valor, proporcionando um trabalho mais transparente e direcionado.
Planejamento Scrum e planejamento Kanban
Em times Scrum, o planejamento acontece sempre antes de cada sprint. Os stories que estão no backlog são estimadas pelo time utilizando Story Points (ou qualquer outro método de estimativa) e são selecionadas de acordo com o objetivo da entrega.
Já no Kanban, há um rito de planejamento e cadências estruturadas chamado “replenishment”, ou reabastecimento em português. Esse conceito está ligado a tomar decisões do que será feito naquele momento, relacionado ao ato de comprometimento com a próxima entrega.
Métricas & Gráficos
As principais métricas medidas em times que rodam o Scrum são Velocity (produtividade de cada sprint) e Projected Capacity (capacidade do time projetada – baseado no seu time atual). Por outro lado, para acompanhamento dos times, utiliza-se os gráficos de Burndown ou Burnup e também a Velocity Chart, como apresentado abaixo.
Já no Kanban, as métricas são diferentes. Entre as principais, estão o Lead Time, o tempo entre a entrada da demanda no board até a sua entrega e Cycle Time, uma parte do ciclo de Lead Time. Pode ser de desenvolvimento, teste, ou de qualquer outro recorte do tempo total de lead.
Além das métricas, os gráficos também são diferentes. Os times costumam utilizar o CFD (Cumulative Flow Diagram) para entender gargalos e métricas, da mesma forma que também faz análises de saúde do time, como por exemplo, Work In Progress (WIP) por coluna.
Como funciona o quadro e o acompanhamento
No Scrum, os times não possuem um padrão de status. O importante é o que vai funcionar para o projeto. Algumas pessoas sugerem começar com o clássico To do, In progress, Done. (Lembrou do Trello agora, né?)
Inclusive, temos esse artigo com dicas práticas para usar o Trello em equipes Scrum
Dessa forma, esses status são o termômetro para saber o trabalho que está sendo feito, o que está pendente e o que foi realizado.
O board é reiniciado toda vez que uma nova sprint é iniciada para que o seu controle seja apenas da sprint atual, o que torna seu controle muito mais simples e organizado.
Por outro lado, no Kanban, o board deve refletir a vida de uma demanda, do discovery / upstream a entrega. O board nunca é resetado (como no Scrum) e é alimentado com novos stories e, para uma melhor utilização do Kanban, deve ser sempre lido da direita para a esquerda (o que está mais próximo de ser finalizado, deve ter prioridade).
O fluxo de trabalho deve ser montado conforme contexto do time, geralmente com colunas de ação e colunas de fila que ajudam a identificar possíveis gargalos. Em outras palavras, cada nível de maturidade e de organização de time possui um tipo de quadro.
Um exemplo disso é quando usamos o fluxo chamado de Value Stream Map. Nele, as colunas no Kanban são To do, Prototyping, Developing, Testing, Done.
Lembrando que o pontapé inicial do Kanban são as colunas To do, In progress, Done.
Por conter cada estado do seu fluxo, é muito mais fácil enxergar gargalos no Kanban. Se você tem muitas tarefas na coluna de Prototyping, você pode fazer uma análise profunda para entender por qual motivo as tarefas estão demorando muito tempo para saírem dessa coluna.
Leia também Java vs Kotlin: Vantagens, Desvantagens e Performance
Para se informar
Antes de finalizar esse conteúdo, é interessante você conhecer dois episódios do Zup Open Talks, retratando os 20 anos do Manifesto Ágil:
Concluindo…
Por fim, é verdade que não existe um framework melhor que o outro em todas as situações, o importante é saber qual das metodologias ágeis te levarão na direção certa! Suas utilizações são situacionais e dependem muito do contexto.
Em suma, é importante que nenhum desses frameworks / práticas seja imposto por alguma liderança dentro dos times. Quem deve tomar a decisão do que é melhor para a organização do time é o próprio time. O processo de desenvolvimento pode, em outras palavras, sofrer um desconforto e ter o processo burocratizado por qualquer framework que seja inalado.
Para cada situação é preciso entender sua necessidade
Fato que o Scrum sai na frente do Kanban nos times que possuem as demandas mais organizadas e planejadas. Digo isso pois o Kanban é um framework que precisa de muita maturidade do próprio time para sua utilização.
O trabalho torna-se mais organizado com as sprints e a gestão da equipe, dessa forma, é mais fácil no Scrum. Contudo, em times que as demandas são mais voláteis, o Kanban larga na frente, pois a entrega é contínua e a repriorização também.
Além disso, vale lembrar que a adesão do time é o principal fator na escolha de um framework. Se a equipe não está feliz com a metodologia de trabalho adotada, tenho certeza de que a produtividade jamais será otimizada, qualquer que seja o framework.
A equipe precisa entender os benefícios da metodologia adotada, para que façam o melhor uso e possam evoluir seu dia a dia.
Pode-se concluir que evoluir e criticar o processo é o principal fator de sucesso das equipes. Dessa forma, não importa o framework que você utiliza! De acordo com feedback da sua equipe, procure sempre pontos de melhorias no seu processo,
Eles são a chave do sucesso, não o framework.
E você, qual sua experiência com esses dois frameworks? Conta pra gente nos comentários!
É profissional da área? Acessando este link você encontra as nossas vagas abertas! Vem pra Zup!
