O Kanban está se popularizando por vários bons motivos. Contudo, quanto mais pessoas o adotam, mais haverá implementações feitas de maneira errada, cujo fracassoàs vezes será atribuído simplesmente ao uso do Kanban. Neste artigo, apresento algumas situações que vivenciei e que podem contribuir para uma má reputação do Kanban. Esperamos que alguns exemplos citados aqui possam ajudar o leitor a evitar armadilhas parecidas.
Dê importância à cadeia de valor
A cadeia de valor é um conceito importante nas práticas do desenvolvimento Lean. Em resumo, é constituída dos vários estágios pelos quais passa o trabalho, desde a concepção até a entrega. É analisada por meio de um exercício chamado Mapeamento da Cadeia de Valor (MCV, ou VSM na sigla em inglês). Com o MCV busca-se visualizar como o trabalho progride pelo sistema, ajudando a identificar possíveis desperdícios e gargalos.
Com o uso desse mapeamento, geralmente grandes filas ou acúmulos ficam evidenciados, trazendo à tona gargalos do sistema utilizado. Ou se pode identificar que partes do sistema encontram-se ociosas, aguardando por trabalho de outras fases. Há também outros tipos de desperdício, e é fundamental identificá-los o mais breve possível.
Um exemplo típico de cadeia de valor para o desenvolvimento de software seria: Pronto para desenvolvimento -> Desenvolvimento -> Revisão de código -> Testes -> Demonstração para o cliente.
Em um projeto de que participei, tivemos a ideia de acrescentar os estágios da análise de negócio no quadro Kanban, antes da fase de desenvolvimento. O problema foi que não analisamos corretamente a cadeia de valor de Análise de Negócio. Na montagem do quadro agimos rápido demais, com pouco planejamento. Quando terminamos tínhamos cerca de cinco estágios anteriores ao "Pronto para o Desenvolvimento". Conforme o projeto progredia, no entanto, percebemos que os itens passavam por apenas dois desses cinco estágios previstos.
A correção foi simples. Paramos o que estávamos fazendo, juntamos toda a equipe e refizemos o mapa de valor com base no que havíamos aprendido nas primeiras semanas de trabalho. Foi um exercício de uma hora; ao final tínhamos uma visão muito melhor da cadeia de valor, especialmente do lado do analista de negócio. Corrigimos a primeira metade do quadro e conseguimos visualizar melhor nosso processo de desenvolvimento, podendo ainda fazer melhorias nele.
Não coloque todo seu processo no quadro
É grande a tentação de afixar na parede um quadro gigante e colocar nele cada pequeno passo do processo. Aconteceu conosco e acabamos com um quadro complicado demais (veja a figura abaixo). Na parte superior, estavam os cartões de história; embaixo ficavam os itens de trabalho. Estes últimos se juntavam aos itens de cima no momento dos testes e de demonstração para o cliente.
Era muito mais do que o necessário. Trazer um novo integrante para a equipe e explicar para ele o funcionamento daquele quadro exigia uma sessão de treinamento. Tínhamos acabado com a facilidade de uso do Kanban.
Como era complicado entender como um item deveria ser movido dentro do quadro, as pessoas simplesmente não o moviam. Perdíamos, assim, o efeito psicológico positivo obtido ao se andar até o quadro e mover um item para o próximo estágio. Ia-se por terra um dos principais benefícios do quadro, que é a visibilidade do projeto e da equipe.
O dimensionamento é fundamental
No projeto citado, tínhamos também dimensionado incorretamente nosso trabalho, o que não é um problema raro no desenvolvimento ágil de software. Havia histórias muito grandes no quadro, por simples falta de coragem de parar o trabalho e dizer: "Esta história é grande demais; precisamos quebrá-la."
Na linha superior do quadro estavam as funcionalidades para as "funcionalidades mínimas" (MMF; Minimum Marketable Features), mas na verdade estas não atendiam ao critério "mínimo", pois representavam grandes partes do sistema. Em alguns casos, deveriam ter sido criadas funcionalidades exploratórias, com o objetivo de responder a questões sobre como proceder para entregar o que o cliente precisava.
Além disso, estávamos medindo nosso tempo de ciclo a partir dos cartões de MMF; mas como estávamos deixando-os com escopo muito grande, havia algumas funcionalidades desconhecidas e nosso tempo de ciclo variava muito de uma funcionalidade para outra.
Deveríamos ter nos esforçado mais para responder a algumas questões, e ter uma ideia melhor sobre as funcionalidades desconhecidas; ou seja, poderíamos ter gerenciado melhor o tamanho de nosso trabalho e, em consequência, o tempo de ciclo.
Trabalhe com um objetivo comum
Outra lição aprendida no projeto foi relacionada à quebra de nossas funcionalidades em tarefas. Como já citado, na parte superior do quadro estavam nossas funcionalidades maiores e na parte de baixo ficavam as tarefas de desenvolvimento.
Mas as tarefas de desenvolvimento estavam particionadas horizontalmente, por exemplo, tarefas de interface gráfica, de banco de dados etc. Com isso, ao terminar uma tarefa, não estávamos entregando ainda valor para o cliente. Além do mais, para passar a aparência de "mais trabalho feito", a equipe às vezes puxava uma nova funcionalidade para a fase de desenvolvimento e atacava suas tarefas, sem antes concluir outra funcionalidade já iniciada e assim entregar valor para o cliente.
A equipe como um todo queria entregar valor, mas o foco de curto prazo em entregar o maior número possível de tarefas estava prejudicando os resultados.
Não se esconda atrás de filas
Outro princípio fundamental do Lean e do Kanban é a ideia de limitar o trabalho em cada fila, como uma forma de garantir que não haverá trabalho demais no sistema. Às vezes isso pode parecer tentador, mas permitir que sua equipe despreze os limites, ou que simplesmente os ignore, leva a mudanças de contexto e outros tipos de desperdício que diminuem a velocidade em que funcionalidades são entregues aos clientes.
Os limites de trabalho em progresso são uma das ferramentas mais poderosas do Kanban, mas é importante usar essa técnica com critério. Desprezar um limite para "fazer mais" é enganar-se a si mesmo. Afinal, uma funcionalidade só está pronta quando está nas mãos do usuário. É fácil falar em uma palestra ou em um livro que devemos respeitar os limites, mas na prática, em um projeto sob pressão, é difícil resistir de passar um cartão a mais para uma coluna de "Pronto para testes", por exemplo. No final das contas, somos pagos para escrever código, e estamos falando de um "simples pedaço de papel" em um quadro branco.
Este exato problema estava acontecendo com uma equipe em que trabalhei. Nosso primeiro passo na busca de uma solução foi adicionar mais uma coluna ao quadro, dedicada a testes, onde ficavam as funcionalidades que não haviam passado pelos testes. Mas com isso não tínhamos aumentado a capacidade na realização de testes, nem identificado uma forma de diminuir a fila de testes. O que fizemos foi simplesmente aumentar a quantidade de itens que poderiam ficar aguardando naquela fase. Em vez de melhorar, pioramos o nosso gargalo.
Havíamos adicionado a coluna pelas razões erradas (ego, política, vontade de ter mais código escrito), mas acabamos permitindo que as funcionalidades esperassem mais tempo no sistema antes que ficassem de fato prontas. Havíamos adicionado desperdício.
No final, sentamos e nos perguntamos por que as funcionalidades não estavam sendo demonstradas para o cliente. Constatando a existência do gargalo, alocamos um profissional para trabalhar nos testes e assim aumentar a vazão nessa fase.
Algo a destacar aqui é que já sabíamos do começo que teríamos um gargalo em testes, devido à estrutura e formação da equipe. A solução definitiva foi a contratação de mais uma pessoa com a função correta. Aprendemos uma lição valiosa em Kanban: que devemos aumentar a capacidade do sistema, em vez de simplesmente aumentar a capacidade da equipe, sem critério.
Conclusões
Neste artigo foram analisadas algumas formas em que apliquei o Kanban de forma errada. Todos os projetos citados, no entanto, foram bem sucedidos para nossas equipes e clientes. Incluímos retrospectivas em vários momentos, para obter uma visão do que estava sendo feito corretamente e o que precisava ser mudado.
Se estiver usando Kanban agora e alguma coisa não estiver indo como esperado, pare, analise a situação e faça mudanças. O problema pode estar apenas na forma de usar a técnica.