Ricardo Fernandes Luiz

Nos últimos meses as discussões entre as comunidades Kanban* e Scrum tem ficado bastante acirradas.  Esta discussão pegou ainda mais fogo com um post polêmico do Ken Schwaber, um dos criadores do Scrum.

Em seu post no site http://www.controlchaos.com/ Ken afirma que Kanban irá falhar para desenvolvimento de software, pois é recomendável para processos onde há mais regularidade que irregularidade assim como chamadas de serviço, e que Scrum é o processo correto para trabalhos complexos como desenvolvimento de software.

Pior ainda, afirmou que Kanban é uma boa distração,  e que o trabalho dele (com Scrum) era para pessoas sérias.

Mais tarde o trecho que mencionava críticas ao Kanban foi retirado, porém o texto completo (como postado na primeira vez) pode ser visualizado abaixo:

Kanban vem ganhando popularidade, pois pode partir do processo atual de sua empresa, sem grandes mudanças iniciais que são necessárias ao implementar Scrum. Kanban pode inclusive ser usado juntamente com um processo não iterativo e incremental como waterfall. Este é um dos pontos que causa grande discussão na comunidade.

Alguns acham que ao oferecer uma solução que não exija uma grande mudança na empresa de antemão a empresa poderá se acomodar e não experimentar os benefícios que Scrum e XP podem proporcionar.

Seria como um personal trainer dizer a uma pessoa que quer ganhar músculos que ela não precisa ficar horas na academia logo de cara, pois irá doer… No lugar disso ela pode fazer pequenas evoluções, treinando menos e avaliando se para chegar a ganhar mais massa a dor que ela vai sofrer vai valer a pena. Pode chegar um momento em que uma pessoa que queria ganhar inicialmente 10 kg de músculos, perceba que para isso terá que treinar 2 horas por dia,  que o benefício que terá não valerá a pena, então ela poderá preferir ganhar apenas 5 kg que para ela já seria suficiente.

Pensar no suficiente para cada situação é a base do modelo lean, de onde o Kanban é derivado.

Ganhar 10kg ou 5kg de músculos pode não parecer relevante, mas e se disséssemos que cada kilo ganho estaria diretamente ligado a qualidade de vida e representaria 1 ano de vida a mais?

As empresas devem tomar muito cuidado,  portanto, pois a tendência a inércia podem faze-las  jamais experimentar os benefícios que os modelos ágeis como scrum e xp trazem para o desenvolvimento de software no dia-a-dia.

No entanto devem ter claro o benefício que querem ter de cada método.

Se seu personal trainer indicar para você um treino de 2 horas, sem que você tenha claro os benefícios disso, ficará difícil suportar as dores no dia seguinte de cada treino. Agora se você visualizar um benefício palpável a longo prazo como 1 ano a mais de vida ou até estética, isto poderá motivar a sentir as dores, se você considerar que o benefício vale a pena.

O mais importante como disse Alistair Cockburn em seu “Juramento da não-lealdade” é “considerar ideias vindas de todas as escolas e tradições com o objetivo de encontrar aquelas que melhor se encaixem em cada situação”.

*Note que quando falamos de Kanban nos refirimos ao sistema Kanban para desenvolvimento de software, adaptação do sistema de monitoramento e melhoria de processos de produção da Toyota para software, feita pelo David Anderson em seu livro: “KANBAN, SUCCESSFUL EVOLUTIONARY CHANGE FOR YOUR TECHNOLOGY BUSINESS“.

Referências

Kanban e Scrum – obtendo o melhor de ambos

O mito da Cultura Ágil

Dizer sim ao Kanban não significa dizer não ao Scrum

Dizer sim ao Lean torna o resto irrelevante

Kaikaku – Kaizen