Por vários anos, muitas pessoas consideraram o Scrum como o ponto de partida ao se iniciar uma implementação ágil. De fato, muitos acreditam (de forma equivocada) que Scrum e Agile são a mesma coisa. Pela atual popularidade e extensa adoção, o Scrum tem sido a escolha ágil padrão de muitas organizações. Entretanto, com o recente crescimento da adoção do Kanban, alguns o veem como o próximo passo na evolução do Agile.
Abby Fichtner declarou em seu artigo que o Kanban é o novo Scrum:
Talvez seja pelo tempo que passei em startups, mas apesar de valorizar muito as ideias do Scrum como a auto-organização das equipes e do feedback contínuo, não posso deixar de pensar no Kanban como o próximo nível de agilidade, permitindo mais flexibilidade e aprendizado com as lições que temos extraído do Lean.
O maior problema que Abby identifica no Scrum é o sprint [com tempo fixo]:
Ao se trabalhar com startups, o conceito de sprint do Scrum é quase sempre considerado um intervalo de tempo muito longo para uma realidade imediatista. Quando os sprints são longos, as releases não são frequentes (postergando a entrada de receita) e a equipe é forçada a esperar muito tempo para poder se adaptar às novas necessidades do cliente. Isso se torna um desperdício, uma vez que se continua seguindo em frente com informações desatualizadas.
Por outro lado, se os sprints são muito curtos, funcionalidades grandes serão arbitrariamente divididas em partes menores, cujas partes, isoladamente, não serão úteis para o cliente e podem não deixar claro o que a equipe está tentando entregar como produto final.
Abby sugere que, uma vez que o Kanban não tem sprints e se preocupa em limitar o trabalho em progresso (Work In Progress - WIP), duas coisas acontecem ao ter uma funcionalidade concluída:
- A funcionalidade está disponível para implantação imediata em produção (caso a equipe entenda ser oportuno fazê-lo)
- A equipe pode começar a trabalhar na próxima demanda de maior prioridade, mesmo que a necessidade por esta demanda tenha sido descoberta no mesmo dia!
O resultado é mais feedback e a capacidade de se adaptar mais rapidamente às mudanças.
Erwin Verweij discorda, dizendo que no Scrum:
[A equipe] pode decidir como desenvolver a solução da melhor forma possível. Não existe pressão. A equipe estima o trabalho a ser desenvolvido e tem uma visão clara do que pode e do que não pode ser feito. Sei que a maioria dos gerentes de projeto gostam de ter o controle. E perder esse controle (mesmo que seja um falso controle) os faz sentir que estão sendo deixados de fora do processo.
E então tem-se o Kanban, que devolve o controle, definindo um fluxo de trabalho num formato visual que os gerentes de projeto entendem e amam. O Kanban não diz nada a respeito de velocidade ou o que pode ser feito em um período de tempo. Deste modo os gerentes de projeto podem começar a empurrar atividades para as equipes.
Os gerentes de projeto podem pressionar e começar a forçar a entrada de atividades (o que remete um pouco ao modelo Cascata (Waterfall)), ao usarem um quadro que representa o projeto dividido em colunas (design, desenvolvimento, testes etc).
Lisa Crispin, cuja equipe começou com Scrum e agora usa práticas do Lean, Kanban e XP, declara o seguinte:
O que nos tornou uma ótima equipe foi a habilidade genuína de se auto-organizar. A cada duas semanas nós temos uma retrospectiva e realmente queremos melhorar.
Acho que isso se deve ao fato da organização ter o foco na qualidade, deixando a equipe de desenvolvimento descobrir por si própria o que é preciso fazer para entregar software com a maior qualidade possível.
Derek Huether complementa:
Acredito que mais organizações precisem saber que o Kanban é uma alternativa viável ao Scrum. Ao continuarmos na capacitação de nossas equipes, mantendo uma boa cadência e tendo poucas cerimônias, mais equipes irão preferir o Kanban ao invés do Scrum.
George Dinwiddie parece ter encontrado um ponto de equilíbrio, entre os argumentos sobre Scrum e Kanban:
O Kanban tem foco em limitar o trabalho em progresso e sugere um intervalo curto de tempo entre a chegada da demanda e a entrega do produto final. Uma cadência regular é recomendada; o Scrum tem foco em cadências curtas e regulares e sugere também uma limitação do trabalho em progresso. Se você está aplicando estes modelos corretamente, ambos o levam para o mesmo objetivo.
Abby conclui:
Ainda acredito que o Scrum compreende excelentes ideias - como a auto-organização e feedback contínuo - que não deveriam ser menosprezadas. Mas essas mesmas ideias continuam funcionando sob a aplicação do Kanban.
Você acredita que o Kanban é o próximo passo depois do Scrum? Acredita que ambos, Scrum e Kanban, podem coexistir?