Se você ainda acredita que Kanban é apenas um quadro e Scrum é uma metodologia cheia de estruturas e regras, algo precisa mudar.

O Scrum e o Kanban são dois métodos de trabalho que têm como objetivo melhorar a entrega de valor para os clientes.

 

Ok, ambos têm objetivos semelhantes. Então seria o Kanban uma evolução do Scrum?

 

Não! Não é porque o Kanban foi criado depois do Scrum que é necessariamente uma evolução. As duas ferramentas possuem objetivos semelhantes porém características e foco específicos, não excludentes e que muitas vezes se tornam complementares.

Afinal de contas, por quê eu teria de escolher entre um ou outro se posso ter os dois? 😉

Por mais que existam empresas que se adaptam melhor ao Scrum, outras ao Kanban, não é necessário escolher por uma ou outra. Você pode usar ambas em conjuntos e trazer uma melhora de performance ainda maior para o seu time, colhendo o melhor de cada abordagem.

Em uma aula da Agile School, o Rodrigo Pinto conversou com o André Suman, especialista em Kanban. Eles desmistificaram alguns mitos e trouxeram as diferenças e semelhanças entre eles.

 

Assista ao vídeo completo:

O que é quando surgiu o Scrum e o Kanban?

Para entender melhor as diferenças entre Scrum e Kanban é necessário voltarmos um tempo atrás, na origem histórica. Assim fica mais fácil de entender os principais conceitos e por quê foram criados.

 

Quando surgiu o Scrum

O Scrum foi criado pelo Ken Schwaber e Jeff Sutherland na década de 90 e por conta da dificuldade das entregas com a metodologias tradicionais, para os seus clientes na indústria de Software, eles desenvolveram uma maneira própria de aprimorar essas entregas.

Com pequenas iterações (ou pequenos ciclos) eles conseguiam mapear de forma otimizada os desejos do cliente, o que poderia ser diferente, dando mais agilidade às entregas.

Após algum tempo, os criadores do Scrum se juntaram a mais algumas pessoas para fundar esse movimento conhecido como Agilidade.

 

Para que serve o Scrum

O Scrum é uma framework, que vai servir para criação de produtos e soluções em ambientes complexos.

Importante: Ambientes complexos são aqueles que possuem um certo grau de incerteza. Por exemplo, incerteza no que a gente irá fazer, em como será feito e etc.

O Scrum foi feito para ser utilizado em ambientes com incertezas, pois ele possui uma maneira específica de lidar com essas variáveis e assim melhorar os resultados das entregas de valores.

 

Se interessou pelo assunto Scrum e como ele pode ser aplicado na sua empresa? Assista essa masterclass do Rodrigo Pinto.

Papéis do Scrum

No Scrum, existem papéis que são utilizados para definir responsabilidades. Para cada um deles existem atribuições e compromissos, sem que haja uma hierarquia entre eles, mas sim um empoderamento e uma responsabilidade sobre determinada atividade.

Os papéis do Time Scrum são:

• Product Owner (PO)
• Scrum Master (SM)
• Desenvolvedores

 

Origem do Kanban

Inspirado no Sistema de Produção da Toyota e na gestão da manufatura no Japão, o Kanban é uma abordagem para o trabalho do conhecimento criada por volta do ano de 2006. Esse primeiro case surgiu em uma equipe da empresa Corbis, que começou a implementar práticas de gestão do fluxo das demandas para melhorar a eficiência do suporte aos clientes.

 

Para que serve o Kanban

Kanban é uma estratégia para otimizar o fluxo de valor por meio de um processo que usa um sistema de trabalho puxado e visual (inspirado no Kanban da manufatura). Para isso, o Kanban compreende três práticas de trabalho:

• Definir e visualizar um fluxo de trabalho
• Gerenciar ativamente os itens num fluxo de trabalho
• Melhorar o fluxo de trabalho

 

Ponto central para a definição do Kanban é o conceito de fluxo. Fluxo é o movimento de valor potencial através de um sistema de trabalho. Como os fluxos de trabalho existem para criar valor, a estratégia do Kanban é otimizar valor por meio da otimização do fluxo. Otimização de valor significa se esforçar para encontrar o equilíbrio certo entre eficácia, eficiência e previsibilidade em como o trabalho é feito:

• Um fluxo de trabalho eficaz é aquele que entrega o que os clientes desejam, quando desejam.
• Um fluxo de trabalho eficiente aloca os recursos econômicos disponíveis da forma mais otimizada possível para agregar valor.
• Um fluxo de trabalho previsível significa ser capaz de prever com alguma precisão a entrega de valor dentro de um grau aceitável de incerteza.

 

Como o Kanban funciona com praticamente qualquer fluxo de trabalho, sua aplicação não se limita a nenhum setor ou contexto. Trabalhadores do conhecimento como os de finanças, marketing, saúde e software (para citar alguns), têm se beneficiado das práticas do Kanban.

Leia com detalhes sobre todo o método de Kanban aqui.

 

Papéis do Kanban

Diferente do Scrum, o Kanban não prescreve cargos ou papéis específicos. Todavia, a comunidade passou a adotar um certo padrão e sugestão que você e o seu time pode adotar ou não.

O Service Delivery Manager é um papel focado no fluxo, entende das métricas que precisam ser avaliadas, é aquela pessoa que cuida da gestão do fluxo de demandas.

Outra sugestão é o Service Requests Manager, um arquétipo de Product Owner, responsável por tudo que entra no fluxo de demandas do nosso quadro Kanban.

 

Reuniões Scrum x Reuniões Kanban

Da mesma maneira que as práticas, origem e objetivo do Scrum e Kanban são diferentes, as reuniões também não seriam iguais.

Primeiro que no Scrum, para cada etapa interna, existem eventos com objetivo, participantes, tempo e regras específicos.

 

Eventos – Reuniões do Scrum

No Framework Scrum, existe um nome técnico para cada uma das reuniões (o que entendemos por reunião na verdade é chamada de evento). No próprio Scrum Guide não existe a palavra “reunião” somente são nomeados os “eventos”.

E a ideia de chamar evento é porque eles podem acontecer sem a necessidade de uma reunião específica. Você pode iniciar uma Revisão da Sprint sem precisar ter uma reunião formal marcada para isso.

Existem 5 tipos de eventos no Scrum e eles são:

• Sprint;
• Planejamento da Sprint;
• Reunião diária;
• Revisão da Sprint
• Retrospectiva da Sprint

 

Para cada evento citado acima existe um objetivo específico e uma oportunidade para inspeção e adaptação.

 

Reuniões do Kanban

No Kanban, não existem reuniões prescritas como no Scrum. Podemos considerar que no Kanban as cadências são contínuas e em sua maioria sob-demanda. Ou seja, não existe um tempo programado para certos eventos acontecerem.

Por exemplo, para o abastecimento de novas demandas é sugerida uma cadência chamada de Replenishment (Replanejamento). Não há a obrigatoriedade de replanejar a cada X tempo, a exemplo da Sprint Planning do Scrum. Havendo a necessidade (pelo número de demandas), o time executa a cadência de abastecimento, seja por uma reunião, ação direta de um Request Manager ou algo semelhante.

Um ponto semelhante das duas abordagens é a Kanban Meeting, que é uma cadência diária, assim como no Scrum, na qual os participantes do Kanban farão a gestão ativa das demandas e do fluxo de trabalho.

 

A diferença está no Timebox

O Timebox é um conceito muito comum no Scrum e nada mais é do que o tempo máximo estipulado para cada evento interno acontecer.

 

Timebox no Scrum

A toda Sprint, o Time Scrum determina um objetivo a ser cumprido e então estabelece quais as demandas cumprem com aquele objetivo. O timebox na Sprint é você determinar uma data final para algo acontecer, nesse caso, o cumprimento do objetivo estipulado para uma Sprint.

Já no caso dos eventos, o timebox se materializa como o tempo máximo (em horas) que o time possui para executar aquele evento e cumprir o objetivo proposto.

Se por exemplo, estamos falando da Daily Scrum, o time possui o máximo de 15 minutos (timebox) para construir um plano de trabalho para aquele dia, em como vão colaborar para atingir o objetivo da Sprint.

Esse conceito de timebox é muito poderoso para promover foco e até um senso de urgência. O time possui um objetivo a atingir e um tempo limite para fazê-lo.

 

Timebox no Kanban

Assim como papéis e reuniões, no Kanban também não existe Timebox. A ideia é termos um fluxo contínuo das ações sem um tempo limite (timebox).

Porém uma prática que acaba mimificando (de mímica) o timebox é a utilização das métricas de cycle time e work item age, que acabam dando um suporte para o time compreender se deve focar numa demanda, se ela está “atrasada” ou até determinar um tempo limite/alvo para que algo ocorra.

 

Estimativas e Velocidade no Scrum e no Kanban

Estimativa e velocidade são comumente utilizadas por Times Scrum, porém são conceitos não descritos pelo framework, se tornando opcionais.

Em geral, na ação de planejar a Sprint (numa Sprint Planning) os membros do Time Scrum irão estimar os itens de trabalho e utilizarão sua velocidade nas Sprints passadas para melhor planejar a que se inicia.

A velocidade nada mais é que a performance histórica da equipe. Um exemplo seria a quantidade de Story Points que um time executa por Sprint. Esse conceito não está no Scrum Guide, ou seja, é uma prática complementar que não faz parte do Scrum, cabe ao time escolher se vai utilizá-la ou não.

 

“No Scrum não existe a obrigatoriedade de ter que trabalhar com estimativas.”
Rodrigo Pinto

 

Porém sem os conceitos de estimativa e velocidade, como eu vou planejar a Sprint?

A resposta está justamente na utilização conjunta do Kanban e suas métricas padrão. O Throughput é a métrica de vazão do Kanban que determina quantas demandas um time é capaz de executar num determinado tempo. Ao conectar as métricas do Kanban no Scrum, podemos utilizar a média do Throughput (quantidade de itens executados nas Sprints) para nos ajudar a planejar as Sprints futuras.

 

Work In Progress (WIP)

O WIP em sua tradução livre significa quantidade de trabalho em progresso. O seu objetivo é promover o fluxo, ou seja, o time limita a quantidade de coisas que faz ao mesmo tempo e trabalha de forma dedicada, mais focada em terminar a demanda atual antes de começar uma nova.

O Scrum não aborda o conceito de WIP, o que torna-o pouco utilizado por seus times. Na real, numa implementação do Scrum o conceito do limite de WIP está no tamanho do Sprint Backlog. Essa é uma prática muito precária de gerenciamento de trabalho em progresso e cabe ao Time Scrum otimizar esse controle.

Já no Kanban, essa métrica é um conceito vital para a eficiência do fluxo de trabalho e passa a ter um foco e importância desde o primeiro momento.

Consegue ver aqui, novamente, a integração entre as abordagens?

 

Conclusão

Em diversos momentos deste artigo, podemos ver que o Scrum apresenta um conceito que o Kanban não segue, depois o Kanban apresenta uma métrica que o Scrum não observa. Ou seja, ambas as abordagens com seus focos específicos, trazem benefícios que em sua maioria não conflitam, muito pelo contrário, se complementam.

Logo, não temos aqui uma questão de evolução do outro, muito menos uma escolha binária. É possível entender que existem diferenças óbvias entre o Kanban e o Scrum que é possível (pra não dizer aconselhável) utilizá-los em conjunto para potencializar ainda mais suas entregas de valor.

Mas, para que você se torne realmente um especialista em Kanban e Scrum é necessário muito mais estudo e aprofundamentos que vão além desse texto.

Na Agile School, temos os treinamentos formulados por grandes nomes do mercado, o APK (Applying Professional Kanban), que é específico para quem deseja melhorar sua capacidade de agregar valor e ser mais eficaz através do sistema Kanban e o APS (Applying Professional Scrum), para quem deseja aprender de forma sólida e, ao mesmo tempo, prática e rápida a criar um produto digital do zero utilizando Scrum!

Saiba mais sobre o treinamento Aplicando Kanban e Aplicando Scrum clicando aqui!

Lembrando que todo ex- aluno Agile School possui desconto de 5% em todos os cursos que disponibilizamos. Para resgatar o seu cupom é só clicar aqui e falar com o nosso especialista.
Caso tenha alguma dúvida sobre qualquer treinamento da Agile School, entre em contato com a gente através do Whatsapp.