Do Scrum ao Kanban e de volta ao Scrum

Este artigo conta um pouco sobre a migração da minha equipe para Kanban, os problemas encontrados e o porquê de voltarmos a usar Scrum. Me refiro à Kanban como fluxo contínuo das histórias, ao invés de usar lotes através de iterações/sprints. Ainda usamos e gostamos de outros conceitos associados ao Kanban como limite de WIP.

Um pouco sobre o projeto

Handover O projeto em questão era relativamente grande e legado. Ele sofria de alguns problemas de má estruturação do código, over-engineering e falta de testes (nenhum na verdade).

Mas decidimos aceitar o desafio. A equipe analisou o projeto durante um tempo e fizemos uma retrospectiva para definir as ações seguintes. Pegamos um pacote básico de práticas: TDD, programação em par, integração contínua, retrospectiva, refatoração, etc.

Conseguimos melhorar vários aspectos do projeto com o tempo. Porém os problemas abaixo eram persistentes...

Falta de previsibilidade

Iceberg Dada à natureza do código, frequentemente algumas histórias aparentemente simples se mostravam complexas de implementar. Isso tornava nossos sprints inconstantes. Às vezes não conseguiamos completar as histórias planejadas, ou pior acumulávamos débito técnico para entregar alguma coisa. Porém, mais débito técnico era a última coisa que desejávamos para aquele projeto.

Isso também afetava a confiança no cliente na capacidade de entrega da equipe.

Entregas no meio do sprint

entrega O projeto já estava em produção e era de missão crítica. Em função disso, algumas correções ou alterações não poderiam esperar para serem entregues. Assim, com uma certa frequência eram geradas entregas no meio da iteração (às vezes em horários inconvenientes), o que acabava atrapalhando o ritmo e o foco da nossa equipe.

Do Scrum ao Kanban

Dados as questões acima, Kanban parecia ser uma boa idéia. Convidamos o cliente, apresentamos a proposta para ele, e ele topou. Nos 4 meses seguintes usamos Kanban. Foi bem interessante experimentar a metodologia, conseguimos resolver a maior parte dos problemas acima, contudo alguns efeitos colaterais começaram a aparecer.

Fragilização do sentimento de equipe e colaboração

Um dos ingredientes importantes para fomentar o sentimento de equipe e colaboração é um objetivo comum. Como no Kanban ele não existia ou não estava muito claro (as histórias simplesmente moviam de um lado para o outro indefinidamente) o sentimento de equipe e a colaboração no dia a dia ficaram fragilizados.

Costumo analisar esse problema comparando um time de futebol com várias pessoas participando de uma corrida de velocidade. Em um jogo de futebol existe um objetivo comum claro, a equipe precisa colaborar para atingir esse objetivo e pode comemorar quando ele é atingido assim como precisa refletir quando ele não é. Já na corrida de velocidade não existe este objetivo comum, a idéia é cada um chegar o mais rápido possível.

Em uma boa equipe, certamente o todo é maior que a soma das partes, sendo a colaboração e integração um fator fundamental. Não existe espaço para corridas de velocidade, mas sim para um bom time de futebol :).

Queda de produtividade

A fragilização do sentimento de equipe e colaboração impactaram diretamente a produtividade da equipe. Algumas pessoas relataram que conseguiam produzir melhor com um objetivo claro, mesmo que definido por eles mesmos. No Kanban usávamos o conceito de que a história deveria sair o mais rápido possível, mas isso era vago demais.

Perda da visão do todo

Visto que as histórias poderiam chegar a qualquer momento surgiu uma dúvida: Qual a melhor forma de comunicar as histórias para quem fosse implementar? Testamos várias maneiras. Devido à proximidade do cliente, o que funcionou melhor foi o desenvolvedor conversar diretamente com o ele. Em alguns casos o líder do projeto já sabia do que se tratava e fazia esse papel.

Porém, isso gerou um efeito colateral. Como cada história era explicada apenas para quem fosse implementá-la a equipe aos poucos foi perdendo a visão do todo. As informações compartilhadas nas reuniões diárias eram muito superficiais e as pela programação em par apenas para poucas pessoas.

Daí percebemos que as reuniões de planejamento periódicas eram importantes para que todos pudessem estar sincronizados sobre o produto, algo que estava deixando de acontecer. Além do mais tínhamos dificuldade de passar prazos para o mundo externo. À medida que esses problemas se intensificavam, concluimos o inevitável: Estávamos em uma cilada.
Cilada

De volta ao Scrum

Em uma retrospectiva extraordinária sobre a situação do projeto, a equipe optou pela volta do Scrum. Porém, uma questão ainda permanecia em aberto: Como resolver os problemas inicialmente levantados? A tendência era termos os mesmos problemas. Com o tempo a equipe incluiu uma série de práticas que ajudaram a resolver essas questões.

Folga (slack)

Esta é uma prática descrita por Kent Beck no xP segunda edição. Ela causou bastante polêmica na comunicade na época [1], mas foi útil no nosso caso. Basicamente, consiste em deixar uma folga na pontuação planejada para eventuais problemas. Caso eles não ocorram a equipe pode puxar mais histórias ou trabalhar em melhorias. Isso permitiu uma previsibilidade maior no planejamento da iteração e melhorou o relacionamento com o cliente.

Iterações maiores

Iterações maiores permitiram tempo hábil para responder à problemas que iam surgindo durante o sprint e fazer possíveis melhorias na estrutura do código para incluir uma nova funcionalidade, ao invés de simplesmente remendar o código.

Equipe SWAT

Uma prática adotada por algumas equipes ágeis que consiste em separar um grupo de pessoas (no nosso caso uma) para cuidar dos problemas de produção e correções emergenciais. Isso permite que a equipe mantenha o foco na iteração, mesmo no surgimento de problemas externos.

Conclusão

É claro que o sucesso de uma prática ou metodologia depende inteiramente do contexto no qual ela está inserida. Acredito que Kanban ainda possa funcionar bem em outros contextos, claramente onde o fluxo de demandas seja inconstante e onde uma demanda não tenha relação com a outra. Um caso típico são as equipes de manutenção, que fazem alterações em projetos distintos.

Um ponto importante a se ter em mente é que iterações ensinam lições importantes sobre a agilidade que podem ser perdidas caso venha-se a adotar Kanban logo de início.


[1] http://tech.groups.yahoo.com/group/extremeprogramming/message/116977,http://tech.groups.yahoo.com/group/extremeprogramming/message/115992