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.
Fico feliz de fazer parte disso, to aprendendo bastante! Valeu pela oportunidade rapaz!
ResponderExcluirAgora quero ver o próximo post sobre o git
Olá, por aqui utilizamos o Scrum e em alguma fase mais "go horse" onde a entrega esta próxima precisamos adotar um kanban "but".
ResponderExcluirAbraço pro Hotimsky, que já integrou nossa equipe. Mundo pequeno :]
Oi Odécio,
ResponderExcluirDesculpa, mas não entendi o que você quis dizer com "go horse" e "kanban but".
Só para ficar claro, fluxo continuo != go horse.
abraços
Agora te desafio a apresentar esta história completa e com mais fotos nas reuniões da RioAgile. Excelente aprendizado.
ResponderExcluirQue tal fazer o segundo post sobre o feedback que o Kanban dá, com relação ao valor a ser entregue?
Parabéns
Valeu Sidney!
ResponderExcluirVamos bater um papo no próximo encontro da RioAgile sim. Vai ser legal compartilhar essa experiência com o pessoal.
Só não deve ter mais fotos, pois não vai ter nada muito diferente, só um pilha de cards onde estamos acumulando os "feitos". =)
Obrigado e abraços.
Eu discordo sobre a parte do Scrum by the book.
ResponderExcluirO Scrum oferece um início a você, depois vc decide o que é bom ou não para o seu processo.
Não existe isso de seguir um processo à risca. Vc o implementa como for melhor.
[]s
Oi Anonimo, obrigado por participar.
ResponderExcluirAcho que a palavra chave é contexto. Tudo depende. Normalmente adaptações para a sua empresa são importantes e o by the book não será bom, mesmo em uma situação inicial.
Como eu disse, existem contextos que precisam do choque do "scrum by the book", outros não. Talvez possamos ver como um remédio. Quem não está doente, não precisa de remédio. Quem está só com um resfriado, precisa de doses menores.
Na verdade não entendi muito o seu comentário, onde você discorda com o scrum by the book ou se realmente discorda. Tentei colocar de outra forma como eu penso.
Abraços.