11

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

Durante o ano passado fui bastante questionado sobre qual era a minha posição quanto ao uso do Kanban em projetos de desenvolvimento de software. Como naquele momento meu contato com este método ainda era pequeno, eu me reservei o direito de por várias vezes dar a simples resposta “Ainda não tenho uma posição totalmente formada sobre o assunto, a princípio algumas coisas fazem bastante sentido para mim e outras me deixam preocupados.”. Pois bem, depois de bons meses de pesquisa, estudo e algumas aplicações práticas, compartilho com vocês o que acho sobre o assunto.

Recapitulando

Conforme mencionado em recente post do Tiago Motta aqui no blog AdaptWorks, o Kanban que estamos falando aqui é uma espécie de derivação do modelo de cartões do Sistema Toyota de Produção para o desenvolvimento de software. Esta derivação, popularizada sob a liderança do David J. Anderson (aquele do time que criou a FDD – Feature-Driven Development), é formada principalmente por três princípios: fluidez, valor e pessoas. Estes princípios criam forma através de práticas bem interessantes, como a definição de um Limited Work-In-Progress nas filas de trabalho.

Talvez o ponto de maior diferenciação deste Kanban para os mais conhecidos métodos ágeis, como Scrum e Extreme Programming, seja o fato dele trabalhar com um fluxo cadenciado, enquanto os outros focam seu trabalho no conceito de time-box.

Caso você ainda não esteja familiarizado com a idéia do Kanban para desenvolvimento de software, sugiro fortemente a leitura do seguinte material:

Menos prescrição

Se você trabalha ou conhece bem os conceitos do Scrum, provavelmente ao ler sobre Kanban fará alguma das perguntas abaixo:

  • Cadê o Product Owner? E o ScrumMaster?
  • Meu time não é multi-disciplinar?
  • Não faço planejamento de uma Sprint? Como assim não há Sprint?
  • E a melhoria contínua? Não paro para pensar em como melhorar produto e processo?

Veja, essas perguntas não são tão diferentes das que muitos fazem quando estão partindo de um método waterfall-like para os ágeis:

  • Cadê o Gerente de Projetos?
  • Não há hierarquias nos papéis?
  • Não faço um planejamento detalhado no início do projeto? Como assim não há escopo fechado?
  • E meus artefatos? Cadê meu cronograma?

Essa reação sempre se repetirá quando você estiver de saída de um processo mais prescritivo para um mais leve, com menos coisas definidos. E da mesma forma que Scrum é menos prescritivo que muitos dos métodos waterfall-like, o Kanban é sim menos prescritivo que o próprio Scrum.

Hmmm, então significa que Kanban é uma evolução do Scrum? Não é bem por aí. Adaptabilidade é algo maravilhoso e que obviamente sempre será beneficiada  quando do uso de métodos menos prescritivos. No entanto o quão “adaptável” deve ser o seu processo é, na minha opinião, mais uma das decisões que você deve tomar empiricamente, projeto a projeto. Em algumas situações uma solução com mais processos definidos pode sim ser mais adequada que uma com menos. Já em outras isso pode travar as pessoas e burocratizar o trabalho. Scrum pode ser burocrático demais para alguns cenários? Não tenho dúvida que sim, mas também pode ser aberto demais para outros. O mesmo digo em relação ao Kanban.

Fluxo ou pacote?

Essa, na minha opinião, é a principal pergunta que você deve fazer quando da decisão de usar Kanban ou não. O conceito de time-box, rigidamente utilizado pela maioria dos métodos ágeis, dá lugar à procura por fluidez dentro de um processo baseado em fluxo unitário. O jogo funciona mais ou menos assim:

  • uma padaria waterfall planeja no início do dia a quantidade total de pães que precisará e então os produz faseadamente. Teremos todos os pães prontos de uma única vez, talvez, ao final do dia.
  • uma padaria Scrum define time-box’s rígidos e no início de cada “rodada de produção” estima quantos pães é capaz de fazer dentro daquele tempo. Teremos, por exemplo, pequenas fornadas de pão saindo a cada hora.
  • uma padaria Kanban trabalhará de forma fluída: planejando, construindo e entregando pão a pão continuamente. O primeiro pão pode ficar pronto em 02 minutos, e já estar disponível para o consumo, o outro pode vir 05 minutos depois, o outro 01 minutos, e por aí vai, fluindo.

Lógico que o pão aqui é apenas uma analogia, mas com ela espero que você consiga perceber que, dependendo do que você precisa, uma dinâmica pode parecer mais interessante que a outra. Um Product Owner pode muitas vezes se perguntar do por que dele precisar ficar esperando o fim da Sprint para receber uma funcionalidade X que já está pronta. Ele adoraria já ir recebendo cada funcionalidade quando esta estivesse pronta sem ter que esperar o “pacote” estar pronto. Já um outro Product Owner poderia achar isso péssimo, já que ele gostaria de poder programar melhor as entregas e não enxergaria valor em ter apenas uma daquelas funcionalidades na sua mão. Tudo depende.

Minha perspectiva

Depois de assistir algumas boas palestras de Kanban, das quais destaco a do Karl Scotland no Scrum Gathering de Amsterdam, participar do treinamento de Kanban aqui da AdaptWorks e ler muitas coisas a respeito, decidi então partir para a prática.

Nos últimos três meses me envolvi no trabalho com três times Kanban. Todos fazem parte de empresas que já estão há algum tempo fazendo algo relacionado à Agile, um exemplo disso é que todos os três times estavam vindo de Scrum. Abaixo compartilho um pouco desta experiência bem como minha percepção sobre ela.

Por que eu sugeri a transição de Scrum para Kanban?

Nestes casos específicos ficou evidente que o conceito de pacotes do Scrum tornava o ambiente “duro” demais. Algumas características deste cenário que me levaram a pensar sobre Kanban:

  • O Product Owner não conseguia ter uma quantidade de requisitos READY para o planejamento de uma Sprint, visto que muitas coisas “apareciam” e “eram descobertas” ao longo da sua execução.
  • O time estava extremamente “estressado” pois todo planejamento era mudado (!) ao longo da Sprint.
  • O tal “pacote” da Sprint era composto por coisas sem nenhuma relação, muitas vezes até de produtos ou áreas diferentes.
  • Sprints eram interrompidas frequentemente para fazer “algo urgente” e, veja, este algo não surgia por falta de planejamento ou incompetência das pessoas envolvidas. Ele surge porque a dinâmica do negócio daquela empresa é assim mesmo.

O que há de comum em todos os problemas que citei acima? Todos são derivados do conceito de time-box. E foi durante a busca da causa raiz destes problemas que me convenci que para aquele time uma outra dinâmica no fluxo de trabalho melhoraria diversos pontos.

E como ficaram as outras práticas do Scrum já que não eram mais obrigatórias?

Se você conversasse comigo há alguns meses atrás escutaria que um dos maiores medos que eu tinha em relação ao Kanban era o de que times poderiam “relaxar” com algumas das práticas essenciais de Agile que agora passariam a ser opcionais (percebe que este é o mesmo medo sentido pela turma do XP quando alguém fala de Scrum). Felizmente o que percebi na prática foi que, uma vez que um time ou uma organização aprende que multi-disciplinaridade e auto-organização – dentre outros conceitos – são benéficos para seus resultados, elas não mais abrirão mão deles.

Ainda tenho dúvidas quanto a este ponto quando penso em um time que nunca utilizou algum método ágil indo diretamente para Kanban.

E mudou tudo?

Em ambas as empresas nas quais pratiquei Kanban, o Scrum foi mantido para a maioria dos times. Em um dos casos, de um total de treze times ágeis, apenas dois fizeram a transição para Kanban. Por que? Porque o Scrum, seus timeboxes e outros conceitos continuou se mostrando a melhor opção, ou pelo menos a mais adequada para muitos deles.

Isto não é sobre ser mais fácil ou menos invasivo, isto é sobre escolher a opção mais adequada

Não gosto quando vejo alguém falando que irá começar a utilizar Kanban pelo fato de não ter conseguido utilizar Scrum, ou pelo fato de Kanban ser menos invasivo. Ora, se vou utilizar Kanban tem que ser porque, para aquele propósito, o considero melhor que Scrum, XP, Crystal, Waterfall, etc., e não simplesmente porque é mais fácil!

Para finalizar este post entenda que eu faço parte daquele grupo de pessoas que não acredita que há ou haverá um único processo correto, capaz de combater todos os tipos de problemas e se adequar à todos os cenários. Tenho adorado minhas recentes aventuras com Kanban, e continuo vibrando com o que Scrum pode fazer – e tem feito – por muitos times e empresas.

No nosso treinamento “Sistema Kanban para desenvolvimento de software” são abordados importantes detalhes sobre o uso deste método. Veja as datas de nossas próximas turmas.

Alexandre Magno

11 Comments

  1. Concordo principalmente com a dificuldade de implantar um processo menos restrito, como o Kanban, a uma equipe menos madura em de métodos ágeis. Com isso, de certo modo, me parece que há uma evolução de um para outro.

    Equipes com pouca experiencia em métodos ágeis precisam de mais restrições, assim o Scrum me parece mais adequado. Conforme a equipe ganha maturidade, podemos eliminar aos poucos as restrições e tentar um fluxo mais continuo, mais compatível com o Kanban. Dessa forma, pelo que já li sobre Lean, Scrum e Kanban, acredito que o Kanban seja “mais Lean” que o Scrum.

    O que acha?

    Abraços

  2. @André obrigado pelo feedback sobre o artigo! Ué..não aparece aí o nome do autor abaixo do título?

  3. @Celson Concordo, mas aí estamos falando de uma evolução da empresa, do time…e não de uma evolução dos processos. Como sempre digo, o Scrum é como uma dieta tentando melhor seus “hábitos processuais”, ele lhe dá a disciplina necessária para começar a fazer isso. Após adquirir essa disciplina é natural você ter maturidade para evoluir e tomar suas decisões de forma independente ao que um processo lhe diz.

  4. Oi Alexandre,
    Fiz o curso de CSM com você aqui no Rio, e no curso montamos um quadro que para mim era semelhante ao Kanban, o quadro kanban e scrum não podem ser usados em conjunto?
    Percebo que cada equipe tem uma necessidade diferente e com isso o quadro sofre adaptações para atender essa necessidade, no meu caso aqui na empresa tem uma equipe que usa o quadro para inluir o planejamento de coisas que são tickets de alteração em diversos sistemas, e o trabalho deles está fluindo bem assim.
    Abs,
    Gabriela

  5. Oi Gabriela, perceba que o Kanban que estou me referindo no post é o método Kanban de desenvolvimento de software, e não apenas o quadro. É comum times Scrum utilizarem uma espécie de taskboard, que não deixa de ser um quadro kanban, mas este taskboard é montado de acordo com o processo Scrum (Sprint Backlog, Impedimentos, Metas, etc.). Já no cenário que abordo no post, o método sob o qual o quadro é montado é o próprio Kanban.

  6. Oi Alexandre,
    Imaginei que fosse isso, não conheço o método Kanban, vou procurar mais a respeito.
    Obrigada pela resposta, e parabéns pelo artigo.

  7. Excelente artigo. O paralelo que você fez entre o que as pessoas que saem de um processo para outro pensam, deu outra perspectiva sobre o assunto para mim.

    Parabéns!

    Ahh, o nome do autor realmente não está aparecendo não. 🙂

  8. Fala Magno, gostei do artigo no geral. Minha experiência com Kanban iniciou assim como você (altamente imerso no mindset Scrum), porém, com a experiência, novos insights surgiram, então, logicamente, não concordei com a última parte e vou escrever sobre isso no Débito Técnico.

    Kanban não é um processo, não é algo que se compare com Scrum, XP, RUP, DSDM ou Waterfall. É possível usar Kanban com Scrum, XP e até Waterfall. Kanban não julga o quão ágil você é. Assim como o seu cliente, o Kanban não liga se você usa Scrum, se faz planning ou se faz testes.

    Kanban não muda inicialmente a forma das pessoas trabalhar e isso é a sua maior características: não se implanta Kanban. Kanban parte do princípio que para mudar um sistema (veja sistemas não são processos) inicialmente você precisa compreende-lo. Isso é ciência, ninguém consegue compreender o sistema de antemão e prescrever Scrum, XP ou FDD (isso é princípio do CAS, certo? O Cynefin model pode ajudar nessa conclusão).

    Não existe qualquer tipo de preparação inicial para começar a usar Kanban, numa empresa. Nesta segunda e terça estive no Rio e com um treinamento de 4 horas e mais 4 montando o quadro foram suficientes para iniciar o trabalho. Kanban não importa, Kaizen sim. Kanban é uma resistência pacífica gerencial. Kanban assim como o Scrum não resolve, mas mostra. Kaizen é que resolve, não importando sequer se você é waterfall.

    Kanban pode ser um conjunto pequeno de práticas, porém, seu corpo de conhecimento é muito, muito maior que o Scrum, e transcende o Agile. Assim, apesar de já ter pensado isso, não é conceitualmente correto dizer que ele é menos prescritivo…

  9. Alexandre,
    Muito interessante o seu ponto de vista, pois me faz pensar (mais uma vez) que realmente não existe o método “matador”, e sim o que melhor se adapta ao estilo de cada time trabalhar.
    Só um detalhe, pensar desta forma (na minha opinião) é melhor do que descartar todas as outras, como várias pessoas da comunidade tem discutido.
    Scrum para mim não é o melhor método, é o mais natural em relação aos que eu estudei e pratiquei. Hoje não consigo pensar em trabalhar de outra forma que não seja, pelo menos, com as práticas dele. Evoluir o seu time e identificar uma maneira mais natural ainda é fantástico.
    Parabéns pelo post e até breve

    Fabio A. Dalonso

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *