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.
Nos tempos atuais, cada vez mais temos muitos projetos para iniciar, sem ao menos terminarmos aqueles que já começamos. Parece que o conceito de “multitasking” está cada vez mais enraizado nas corporações, desenvolvedores trabalhando em vários projetos em paralelo, cada um com uma natureza de negócio diferente, gerentes de projetos conduzindo 4 ou 5 projetos ao mesmo tempo, enfim, um verdadeiro caos que não é gratificante nem para esses profissionais e muito menos para as empresas. E como ficam os múltiplos projetos emergenciais tratados integralmente como de alta prioridade? Quantos débitos técnicos estamos gerando nas entregas, em decorrência da falta de foco ou até mesmo porque os próprios desenvolvedores não têm tempo de atuar? Os clientes não estão preocupados com a quantidade de projetos que você está conduzindo, mas por outro lado estão cuidando de seus próprios produtos, então qual é a estratégia a ser adotada?
