Scrum ou Kanban? Qual é o melhor para o seu time?

Quando a metodologia Scrum surgiu, houve uma interpretação equivocada por parte do público de que o Scrum seria voltado apenas para projetos pequenos. Coincidentemente, nos seus primeiros anos, o Kanban também foi difamado através da ideia equivocada de que ele seria um sistema exclusivo para times de sustentação de software.

Com o passar do tempo, tanto o Scrum quanto o Kanban mostraram serem metodologias versáteis, que podem atender tanto a projetos grandes quanto pequenos. Ambas as metodologias podem ser utilizadas tanto para projeto quanto para sustentação (sim, é possível usar Scrum para sustentação, fazendo sprints de 1 dia, por exemplo), apesar de que o Kanban ainda é considerado o framework mais indicado para contextos onde as demandas chegam numa frequência imprevisível e possuem pouco tempo para solução.

Mas será que só isso é suficiente para definir qual metodologia escolher para o seu time?

Primeiro você precisa entender a aplicabilidade de cada um desses frameworks.

O Scrum

Note que o Scrum é um método criado para resolver o problema de que, no desenvolvimento de software, é comum que não saibamos exatamente qual produto devemos construir. Isso acontece porque na maior parte dos casos o cliente não sabe expressar o que realmente deseja e assim precisa ter a experiência de utilizar o sistema, para assim conseguir dizer avaliar o que realmente atende as suas necessidades.

Então, como o Scrum resolve esse problema? Através do empirismo, a estratégia de tomar decisões com base na observação da realidade em vez de decidir com base em suposições sobre o que o usuário deseja. Neste sentido, o Scrum utiliza a abordagem iterativa (implementação em ciclos num PDCA) e incremental (desenvolvimento de incrementos do sistema).

Portanto, o Scrum é uma estratégia voltada para lidar com a complexidade do produto.

O Kanban

Antes de falar sobre o Kanban, eu preciso fazer uma ressalva: o framework a que me refiro aqui é a adaptação por David Anderson do método Kanban original do Lean. Isto é, não estou falando do método original, mas sim da versão adaptada para o contexto dos times ágeis.

Contudo, a palavra Kanban também pode ser utilizada para representar o cartão visual utilizado na Toyota para passar instruções de produção entre os processos. E, para aumentar a confusão ainda mais, ainda existe o quadro Kanban, que é uma ferramenta de gestão visual, comumente utilizada com o Kanban de Anderson. Como você já sabe, também não estou falando de nenhuma das duas coisas, certo?

Dito isto, entenda que o Kanban de Anderson foi criado para gerenciar o fluxo de trabalho dos times, tendo como preocupação principal evitar a formação de filas entre os processos.

Logo, o foco do Kanban é no fluxo de trabalho do time.

O veredito: Scrum ou Kanban?

Acredito que você já tenha notado o que eu queria dizer com esse texto: o Scrum e o Kanban possuem objetivos complementares!

A estratégia iterativa e incremental (o empirismo)  com a presença constante de um PO focado em aumentar o valor é uma excelente estratégia para times ágeis lidarem com a complexidade do produto.

Por outro lado, o foco na otimização do fluxo de trabalho permite que o time diminua o lead time das entregas e assim ganhe agilidade.

Em outras palavras, o Scrum ajuda o time a descobrir qual o produto deve ser construído para entregar mais valor para os clientes, enquanto o Kanban auxilia o time a trabalhar eficientemente para realizar as entregas desse produto!

Portanto, as metodologias podem e devem ser utilizadas em conjunto. E que saber de mais? Pois tanto o Scrum quanto o Kanban são baseados no Lean. Afinal, o Kanban de Anderson, como falei, é uma adaptação de um dos métodos do Lean e o Scrum guide diz que o Scrum é baseado no empirismo e o lean thinking.

Então, a melhor coisa que você pode fazer é aprender sobre o Lean.