Enquanto lia o livro de Womack e Jones, comecei a questionar alguns aspectos do Scrum, como as cerimônias e time-boxes. Comecei a perceber que o Scrum gera filas que, para alguns ambientes, podem ser desnecessárias. A fila de funcionalidades prontas aguardando o fim do sprint, pode ser muda em alguns contextos.
E por que esta formação de fila pode ser considerada um desperdício? Porque existem funcionalidades prontas, que poderiam estar gerando valor para o cliente, mas estão esperando o fim de 2/4 semanas para estar disponível. Outro ponto que comecei a questionar foi o fato de termos uma retrospectiva que pretende ser um processo de melhoria contínua. Todo e qualquer processo que acontece dentro de um período pré-definido é temporal e não contínuo.
Com isso, comecei a questionar os sprints, colocando-os como origem de todo o mal do scrum. Os sprints retiram do scrum uma das características que acho mais importante no Lean, o fluxo contínuo. As retrospectivas retiram do scrum outra característica importante dos sistemas Lean, a melhoria contínua.
Isso deve-se ao fato do scrum ter uma certa precrição, definindo uma série de regras que os "guardadores do scrum" insistem serem importantes para o sucesso de um projeto. Criaram certificações, e com isso o scrum by the book. Com a criação de certificações, são criados mestres daquele processo, que apontam o dedo quando notam quaisquer tentativas de adaptação. Assim, pergunto: onde a inspeção e adaptação? Onde o framework?
Na verdade, ainda não vi nenhuma alteração no scrum que os seus guardadores considerem como uma "adaptação" do "framework". Normalmente o rotulam com o tal do "scrum but". Bem, se alguma coisa é um framework, não vejo como termos "alguma coisa but".
Os últimos parágrafos não querem dizer que eu ache que o scrum não sirva ou esteja me posicionando nesta guerra de métodos 2.0. Não tenho dúvidas de que existem empresas que precisam do choque, da dor que o scrum proporciona. Só estou dizendo que existem contextos que não precisam. E como algumas conversas com o Yoshima me fizeram perceber, "não precisar desta dor" não tem nada a ver com a maturidade da empresa ou da equipe, mas com a cultura.
Em cima deste comentário, começo a narrar o cenário onde estou tentando o Kanban pela primeira vez.
Um amigo, que está abrindo a sua empresa, me contratou para desenvolver o seu sistema core. A equipe era formada de duas pessoas que estão geograficamente distribuídas, além do cliente. Na última semana surgiu um problema: a necessidade de apresentação, na segunda-feira, de alguma coisa pronta para o primeiro cliente.
Com isso, no último sábado, transformei minha sala em uma sala de guerra (já que meu escritório virou quarto do meu filho) e pedi para que meu amigo (meu cliente) e o outro desenvolvedor viessem para cá. Analisamos a situação e resolvemos convocar outro desenvolvedor, também um amigo de minha confiança. Assim, a equipe ficou com três desenvolvedores e o cliente no QA. Com esta formação e com o objetivo definido, iniciamos a nossa maratona de sábado.
Percebemos que sprints nessa maratona não seria uma boa ideia, e que precisaríamos de alguma forma mais contínua e menos invasiva para controlar o projeto. Não cabiam as cerimônias e time-boxes do scrum. Assim, sugeri que tentássemos o Kanban.
O cliente escreveu as estórias e as priorizou.
 |
| Cliente criando priorizando as estorias |
Com os cards prontos, montamos o nosso quadro.
 |
| Kanban com o WIP limitado |
Com a equipe preparada, começamos a maratona.
 |
| Equipe de desenvolvimento sem esse que vos escreve |
É claro que nem tudo foram flores, mas cumprimos o objetivo que foi proposto, já que entregamos estórias suficiente para que o nosso cliente tivesse uma apresentação na segunda.
Nossos principais problemas foram relacionados a infra, pois com a minha conexão com a internet instável, precisamos adaptar o meu desktop para que se tornasse um servidor de QA para este projeto. Tivemos muitos problemas também com o GIT, dada a minha pouca experiência com esta ferramenta.
Um dos pontos interessantes foi que o Kanban deixou claro os problemas e o andamento do projeto, sempre informando ao cliente o ponto exato.
Mesmo sendo menos invasivo, encontramos alguma resistência para que os desenvolvedores participassem do quadro. Como estávamos em uma maratona, resolvi não insistir. Com isso, por hora, eu e o cliente ficamos responsáveis pela atualização do kanban. Esta decisão nos gerou um problema na atualização, o que também ficou claro. Com o passar da madrugada, todos os desenvolvedores se acostumaram com a necessidade de atualização e, assim, a visualização do andamento do projeto deixou de ser um problema.
Outro problema foi a atomicidade da estórias. Quebramos em tarefas menores (os post-its) e, com isso, o limite do WIP foi em cima dos post-its, impossibilitando o cliente puxar do "done" para iniciar o QA. Assim, cada tarefa (post-it), mesmo pronta, precisou ficar em "doing" até que toda aquela funcionalidade estivesse pronta.
O efeito deste problema foi que um desenvolvedor terminava a sua tarefa antes dos outros, não podendo puxar mais tarefas, por já termos atingido o limite proposto. Pensamos em aumentar o limite, mas não nos pareceu uma boa ideia, já que formaríamos uma fila em "done" ainda sem sentido para o cliente.
Isso nos trouxe um aprendizado: a atomicidade dos cards já era a correta e não era necessário quebrar em tarefas (post-its). Os cards faziam sentido para o cliente, não os post-its.
O quadro continua montado na minha sala, pois o projeto ainda está em desenvolvimento. O estado do quadro, sem sombra de dúvidas, vai nos ajudar a retomar o trabalho. Os cards que ainda não entraram no quadro nos ajuda a verificar o que ainda falta para terminar. Nada mais está na "cabeça de alguém", mas sim muito bem definido e disponível para todos.
A experiência está sendo muito interessante e a flexibilidade e dinâmica do Kanban tem ajudado a melhorarmos o nosso processo, buscando uma forma que seja mais adequada ao nosso contexto. Kanban não é perfeito. Talvez o que mais se aproxime da perfeição seja o que o Manoel Pimentel chamou de AgileMMA.
