O que é melhor: Scrum ou Kanban?

Na verdade o título que eu gostaria de usar neste artigo era “O que é melhor: desenvolvimento iterativo-incremental ou em fluxo contínuo?”, mas como os nomes dos processos são mais famosos que o conceito por trás deles, resolvi deixar como está. Além disso, a melhor analogia que eu poderia utilizar (eu adoro analogias!) para lhe poupar o trabalho de ler o artigo inteiro seria fazendo uma pergunta diferente “O que é melhor: a chave de fenda ou o martelo?”. Pense nisso.

E se estiver com preguiça de ler o artigo inteiro (depois só não vai fazer perguntas já explicadas no artigo), pule direto para as tabelas no final do mesmo.

Abordarei neste artigo:

• Alguns fundamentos
• Principais diferenças
• Entrega contínua vs Maturidade do projeto
• Processo Ágil vs Maturidade do Time
• Análise Final

Vamos lá!

Alguns fundamentos…

Antes de entrar nos argumentos do porquê da analogia é importante lembrar que Scrum, de 1995, é um framework empírico de desenvolvimento iterativo-incremental para projetos complexos e adaptativos. Ele foca no trabalho em equipe, melhoria contínua e muitos outros princípios que mais tarde originariam o Manifesto Ágil (2001). Sendo pouco prescritivo para os métodos de gestão de projetos à época, foi fortemente influenciado pelo artigo de Takeuchi e Nonaka, The New New Product Development Game (1986), de onde veio inclusive a ideia de comparar os times de desenvolvimento com os times de rúgby.

Já o Kanban do qual estamos falando é a versão de 2002, adaptada por David Anderson para gestão de atividades dentro de um fluxo de valor contínuo. Oriundo do sistema kanban de Taichii Ono (década de 50), criador do Sistema Toyota de Produção, ele foca no mapeamento e otimização do fluxo de valor de maneira que as pessoas que trabalhem no mesmo o façam com o maior eficiência possível (resumidamente: mantendo um lead time baixo com qualidade total). Ele toma para si uma abordagem evolucionária e colaborativa e é menos prescritivo ainda que o Scrum.

Você conhece mais sobre a essência destes métodos no meu artigo A Essência do Agile.

Principais Diferenças

A ideia aqui ainda não é falar qual é o melhor, apenas citar algumas diferenças (sem entrar no mérito se é uma vantagem ou desvantagem).

O Scrum tem um foco muito grande em ser um framework e não um método: uma estrutura mínima que te dê subsídios para avançar dentro do ágil, mas sem você ter de começar do zero. Suas cerimônias, papéis e artefatos constroem disciplina e tomada de consciência do time para a transparência, inspeção e adaptação.

Implementações de Scrum quebram silos ao criar times multidisciplinares, horizontalizam os times removendo a hierarquia e diminuem o achismo ao focar em ciclos rápidos de construir-medir-aprender tal qual no Lean Thinking (também derivado da Toyota).

Já o Kanban parte de uma filosofia “comece com o que você tem hoje”, onde o value stream mapping inicial é apenas o ponto de partida para a tomada de consciência com base no empirismo. Suas cerimônias, papéis e artefatos são praticamente emergentes e muitas vezes não são usados na sua plenitude pelos times.

Implementações de Kanban são evolucionárias e não costumam causar transformações desde o primeiro dia, embora possuam um forte apelo visual oriundo do uso quase onipresente do task board pelos times. Assim como o Scrum, mas ainda mais presente aqui, possui forte ligação com o Lean Thinking, principalmente no que tange o trabalho de Hansei e Kaizen (reflexão e melhoria) sobre os desperdícios do fluxo (Muda, Mura e Muri).

E por fim, as entregas. Enquanto no Scrum focamos em entregas iterativo-incrementais, ou seja, pequenas entregas em pequenos ciclos; no Kanban focamos em um ciclo único de entregas contínuas. E esta é, sem sombra de dúvida, a parte mais polêmica da discussão. Em um tempo que temos ferramental para Continuous Delivery, não seria óbvio que fluxo contínuo é melhor que entregas iterativo-incrementais?

Mais ou menos…

Entrega contínua vs Maturidade do Projeto

Scrum não fala nada contra Continuous Delivery. Tão pouco Kanban fala algo a respeito. Scrum inclusive se popularizou sobre o waterfall devido ao fato do número de entregas muito maior do que apenas uma durante todo o ciclo de vida de um projeto. Quebrar um projeto waterfall em vários ciclos menores não apenas permitiu que fizéssemos mais entregas do que antes como também permitiu que aprendêssemos mais rápido.

A confusão com Scrum vs CD é a mesma que o pessoal tem com as timeboxes do Scrum. Se uma planning tem uma timebox de 8h para 30 dias de sprint, NÃO quer dizer que ela tem de demorar 8h. O tempo MÁXIMO é 8h. Da mesma forma, na PIOR das hipóteses, você deve entregar um incremento de software a cada sprint, para garantir que o time está avançando e entregando valor. Agora, se seu time consegue entregar software diariamente, manda ver, só não esquece de alinhar com seu Product Owner, pois nem sempre jogar software em produção continuamente é uma boa ideia (mesmo testado).

Mas o que quero tratar aqui não é Scrum vs CD ou como Kanban ama CD, mas sim uma discussão mais importante que é: faz sentido para o seu time trabalhar focado em fluxo contínuo?

Vou te dar um exemplo: seu projeto está começando hoje. O backlog é imenso, tem uma série de questões estruturantes para serem feitas, o MVP está longe de poder ser usado por um cliente de fato (mas ainda é válido de ser testado por usuários-chave). Uma única tarefa ou história não agrega valor sozinha pois ainda é muito cedo, o software ainda não está minimamente maduro para que cada pedaço faça sentido ser colocado em produção.

Agora outro exemplo: seu produto está no ar há meses. O backlog continua a crescer, mas são sempre features complementares ao projeto original. Cada uma das features levam várias tasks para serem concluídas, mas garantem avanços e inovações para os clientes a cada semana ou quinzena (diferente da v1.0 que levou de 1-3 meses pra ser concluída). Tasks individuais ainda não geram valor per se, exceto no caso de correções de bugs. O software está amadurecendo cada vez mais rápido.

E um último exemplo: seu produto está no ar há mais de um ano (talvez vários anos). O backlog já não cresce mais tanto, geralmente entrando pro time (agora bem menor) uma série de ajustes, correções, melhorias pontuais e raramente alguma feature mais complexa. Diz-se que o software entrou em modo de sustentação, sendo que cada task já gera valor individualmente e os clientes tem acesso a melhorias (se seu pipeline estiver evoluído) diariamente. O software está completamente maduro e provavelmente já existe outro time pensando em um novo produto para substituí-lo.

Em quais destes três cenários você enxerga um bom uso de entregas organizadas em semanas (iterativo-incrementais) e em quais faz mais sentido as entregas diárias ou o mais próximo disso (em fluxo contínuo)?

A tabela abaixo mostra a minha resposta para este questionamento:

Entenda como verde o que recomendo que seja utilizado, amarelo use com cautela (entenda a situação, faça adaptações) e vermelho evite. E se nunca ouviu falar de ScrumBan, é a prática quase universal de usar Scrum com um board estilo Kanban para gestão visual de demandas e outras práticas de fluxo contínuo.

Vou ressaltar aqui apenas dois pontos: os vermelhos.

Rodar scrum “by the book” em times de sustentação de software é um tiro no pé. Você tem de adaptar para um ScrumBan ou outra adaptação qualquer, caso queira ser bem sucedido. Dependendo das classes de serviço que este time for trabalhar, nem mesmo faz sentido rodar métodos ágeis e apenas uma gestão de incidentes mais tradicional, no melhor estilo ITIL.

E por outro lado, rodar somente o sistema Kanban em times criando um software do zero não vai servir pra muita coisa, seu Lead Time não terá como ser baixo (um dos principais objetivos do Kanban se perde neste caso) e o sistema não ajudará no team building (na verdade Kanban pouco se importa com o time, e sim com o fluxo rodando rápida e perfeitamente).

Note que esta é apenas a minha opinião, mas criada a partir de mais de 8 anos rodando ambos em diferentes times.

No entanto, não querendo lhe dar uma equação tão simples e por vezes míope para essa discussão, eu agregaria ainda outro fator: o quão proficientes em métodos ágeis são os membros do seu time?

Processo Ágil vs Maturidade do Time

Maturidade de time é um tema sempre polêmico, mais até que Scrum vs Kanban, hehehe. Pretendo abordar este tópico em outro artigo. Por ora, estou dividindo aqui os times em apenas dois níveis: Agile Noobs (quem nunca trabalhou com métodos ágeis antes e/ou tem pouca experiência) e Agile Practioners, a galera que já roda métodos ágeis há tanto tempo que os 12 princípios do manifesto já estão no seu sangue, já o fazem independente do processo estabelecido.

Por que considerar isto é importante?

Por ser mais prescritivo (se comparado ao Kanban), o Scrum é quase que uma formação em métodos ágeis para o time. Ele trabalha toda a questão de disciplina, responsabilidade, trabalho em equipe. Torna concreto uma série de princípios ágeis mais abstratos. Inclusive, com o passar do tempo e com a tomada de consciência que ele traz, o próprio time vai entender por si só se o Scrum ainda está lhe ajudando ou não. Esse é exatamente o conceito ShuHaRi de aprendizado das artes marciais japonesas, que pretendo abordar em outra oportunidade.

Não quero dizer que começar com Kanban em um time Agile Noob não possa dar bons resultados, mas sim que, na minha experiência, se tornou muito mais eficiente começar com Scrum. Posto isso, segue outra tabela, agora considerando a experiência do time com métodos ágeis:

Vou ressaltar aqui apenas dois pontos: o amarelo e o vermelho.

Sim, eu não recomendo Kanban “puro” para times que estão começando agora com métodos ágeis. Note que me refiro aqui a times de software, em outros nichos às vezes faz sentido só usar Kanban a vida inteira do time.

E sobre Scrum puro em times mais avançados, deixo à critério do próprio time decidir, uma vez que já devem ter experimentado ambos e com base no entendimento do próprio time eles podem tomar esta decisão sozinhos (pensando aqui que você que está lendo seja um agilista).

Análise Final

E se você, assim como eu, está preocupado em cruzar as duas informações, vou poupar o seu trabalho com a tabela abaixo, onde cruzo ambas tabelas para fácil consulta.

Aqui novamente explicarei somente os dois extremos: o vermelho e o verde.

Em vermelho, quero dizer que times novos no ágil em projetos novos devem fortemente ser orientados a usar Scrum. Scrum é uma excelente “escola” quando o assunto é agilidade. O time deveria no mínimo tentar utilizá-lo por algumas sprints (geralmente leva-se de 2 a 3 para ter sucesso com Scrum) antes de descartar essa possibilidade.

Em verde, quero dizer que times ágeis trabalhando em software maduros devem estar livres para usar o processo que quiserem. Geralmente estes times acabam usando algum tipo de amálgama, dificilmente abandonando as raizes do Scrum e/ou do Kanban. Geralmente estes times não possuem mais lideranças prescritivas (como o Scrum Master), mas sim situacionais.

Ainda que existam pessoas que talvez venham comentar que times realmente ágeis deveriam ser livres para usar o processo que quiserem desde o primeiro dia de projeto, minha recomendação é não cair na armadilha do “não precisamos de processo, já sabemos tudo que deve ser feito e como deve ser feito”. Eu jamais cheguei em um time que, por mais que já trabalhassem juntos há um tempão, não tivessem margem para melhorar através de ajustes de processos e ferramentas bem ajustados.

No livro Extreme Programming do Daniel Wildt (e cia.) tem uma frase muito boa que diz: não existe a perfeição, apenas o aperfeiçoar. Curiosamente, a maioria dos times com os quais tive de lidar achavam que não precisavam da ajuda de um agilista, que já eram maduros…

Voltando à analogia que eu coloquei lá no início, Scrum e Kanban são ferramentas diferentes que em alguns momentos você vai querer usar uma das duas, em outros momentos as duas e talvez em um terceiro momento, nenhuma delas. Afinal, quem disse que para ser ágil tem de usar Scrum OU Kanban?

Sem contar o XP…onde ele entra nessa história? Tento falar disso nesse outro artigo.

E você, concorda ou discorda? Qual a sua opinião a respeito? Manda aí nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!