Ainda que não seja algo novo, a sensibilização para uso de Kanban agora está crescendo entre usuários de metodologias ágeis. Palestras, workshops e eventos inteiros estão surgindo e os instrutores de metodologias ágeis estão introduzindo Kanban em seus cursos. Agilistas na prática estão investigando o que este método, adaptado de Lean, tem a oferecer a suas equipes: os benefícios mais promissores são apresentados, desde tornar mais visíveis os gargalos possibilitando progressos ainda mais rápidos além de deixar as equipes mais felizes com uma visão clara do "fluxo". Neste ecossistema, o artigo A Filosofia do Kanban é a Criptonita do Scrum, de Simon Bennett, faz um alerta aos que estão considerando incorporar Kanban em seus processos Scrum. Os entusiastas de Kanban concordam com Bennet que a abordagem menos agressiva do Kanban com relação aos impedimentos é contrastante com o direcionamento do Scrum sobre removê-los imediatamente.
Em seu blog, no qual ele declara não ter um postura anti-Kanban mas também não ser um aficionado em "manter o Scrum puro", Bennet publicou um post dizendo
Se você estiver para usar Scrum, mas se ignora ou esconde os impedimentos (ou mesmo se não os ataca logo em primeiro lugar), então você deverá enfrentar muitos problemas pelo caminho e obterá um progresso menor do que o que seria capaz de ter. É sobre isto que Ken Schwaber e Martin Fowler querem dizer quando falam sobre “Scrum flácido“ (pelo menos da perspectiva de débito técnico).
Tanto Scrum quanto Kanban prezam pela transparência; mas ambos lidam com ela de formas diferentes – o Scrum faz um convite explícito à ação que precisa ser atendido para que o Scrum tenha sucesso.
Já o Kanban dá margem a que você e sua equipe simplesmente “aceitem” os impedimentos, medindo então seus efeitos oportunamente.
A posição de Bennet é que as filosofias são contraditórias: seu “projeto Scrum irá fraquejar quando a filosofia de Kanban estiver em curso”. No entanto, não é nosso objetivo ter filosofia pura aplicada: o objetivo é manter a qualidade do software em entregas frequentes. No fim das contas, o direcionamento de Bennet é que as equipes examinem o tipo de projetos que elas têm e que avaliem o grau de sucesso obtido com Scrum para então obter orientações sobre qual metodologia utilizar.
O artigo "Scrum-ban" (2008) de Corey Ladas descreve um processo evolucionário a partir de Kanban o qual, se seguido à risca, é capaz de substituir a maior parte do Scrum. A abordagem de Lada deve modificar ou mesmo trocar muitas das práticas do Scrum tradicional, tais como as reuniões em pé diárias e os gráficos burn-down. O interessante é que Anderson, que apresentou com Corbis um relato de experiência de implementação Kanban no Agile2007 e que parece agora estar fortemente focado na adoção de Kanban, menciona que sua intenção inicialnão era "converter as pessoas vindas do Scrum" mas sim ajudar àqueles que estivessem enfrentando problemas para adotar práticas ágeis. O post de Bennet sugere o que as equipes devem considerar com cuidado antes de incorporar Kanban: está-se obtendo retorno suficiente utilizando-se Scrum sozinho? Bennet completa: "se você realmente tiver dificuldades para quebrar a inércia dos momentos iniciais, então eu imagino que você possa ter problemas com Scrum."
Ainda que Bennet não seja uma das cabeças pensantes da Sociedade WIP Limitada (que se intitula "a casa do kanban para a comunidade de desenvolvimento de software"), muitas das coisas listadas aqui geraram vários comentários de incentivo em seu blog, incluindo os de Karl Scotland e David J. Anderson. Anderson concordou:
Sim, Kanban é uma evolução enquanto que Scrum é uma revolução. E estou muito seguro deste posicionamento.
É claro que pode-se fazer mal uso de qualquer ferramenta: o artigo Fluxos de trabalho de Kanban são de fato ágeis?, de Chris Sims, relembra aos leitores que se o quadro kanban está sendo usado para nos dar certeza de que cada uma das atividades necessárias está mesmo ocorrendo, ele está sendo usado para reforçar a definição de pronto, da equipe, ou seja, fazendo o papel de um simples checklist. E Mitch Lacey recentemente tratou de nos lembrar que "no fim das contas, não há respostas mágicas. Dizer que algo resolve muito mais os problemas do que qualquer outra coisa pode ser justamente o que parece: fogo de palha."
Veja mais sobre a filosofia Kanban no InfoQ: Artigos, Palestras.