Como um agente de mudanças, devemos assegurar as pessoas de que vale realmente a pena seguir o caminho escolhido. Essa necessidade se torna aparente em críticas e perguntas difíceis. Vejo isso com frequência atuando como coach de equipes ágeis. O mesmo acontece ao se introduzir o Kanban. Porém percebi que a partir do momento em que as pessoas aprendem o básico e começam a explorar o assunto por conta própria, surgem questões muito mais difíceis, em níveis de gestão e liderança. Um exemplo: "Como podemos planejar já que medimos em vez de estimar?"
O tipo de perguntas levantadas pelo uso do Kanban parece ser difícil responder, sem cair em uma discussão prolongada. Talvez isso seja normal pelo fato do Kanban ser bem menos prescritivo que o Scrum, por exemplo. E, atuando como coach, para passar segurança ao responder cada questão, é preciso recorrer aos princípios do Kanban, os quais têm como base o pensamento Lean.
Com Kanban gasta-se mais tempo
Um argumento popular usado contra o Kanban é que, com seu uso, os produtos levarão mais tempo para ficar prontos. A lógica por trás disso está no nosso dia-a-dia; relaciona-se com nossa educação e com a forma que os negócios têm sido geridos há séculos. O Kanban dá ênfase em utilizar dados reais para as tomadas de decisões. Ao se medir o fluxo, gerenciamos nosso pessoal e nosso produto.
Isto é o oposto do que se costuma fazer. A gestão aprendeu a controlar seu pessoal atribuindo trabalho e monitorando seu desempenho; recebemos uma tarefa que deve ser terminada no prazo, caso contrário haverá necessidade de justificar o atraso. Isso também se vê nas escolas. Quantas vezes você recebeu uma tarefa sem um prazo associado? "Gostaria que você fizesse tal coisa; não se preocupe com o tempo, mediremos isso depois."
Vejamos como o Kanban faz uso de métricas como ferramenta fundamental de gestão, sem a perda de foco.
Lei de Parkinson
"O tempo que se tem para fazer uma tarefa é o tempo que a tarefa levará para ser concluída."
Existe uma ideia generalizada de que se não determinarmos prazos, as pessoas levarão muito mais tempo para concluir uma tarefa. A pessoa relaxaria e começaria a trabalhar só quando tivesse vontade. Quem permitiria isso?
Tem sido assim há décadas no mundo da gerência de projetos. Um plano de projeto é criado pelo gerente de projetos e pelo desenvolvedor sênior. Com base nas estimativas, um cronograma com prazos é criado e esses prazos tornam-se objetivos para a equipe de desenvolvimento, sejam eles realistas ou não. A lógica por trás disso é simples: a equipe precisa de um prazo para manter o foco. O gerente de projetos até adiciona tempo extra ao plano caso a equipe tenha dificuldades em atingir o prazo, mas o pensamento é que pelo menos a equipe terá atingido 90% do cronograma no tempo definido. De outra forma, não teria chegado sequer a 50%...
Trata-se de uma boa abordagem do ponto de vista de custos, mas não da perspectiva de valor gerado. Sob estresse, usamos atalhos, tentamos fazer mais em menos tempo e introduzimos problemas devido a trabalho desleixado. A abordagem também é negativa da perspectiva de recursos humanos, pois as pessoas ficam sobrecarregadas e acabam abandonando a empresa caso a pressão seja alta demais.
É claro que precisa haver um equilíbrio entre liberdade e controle. Um dos primeiros passos da gerência de projetos nesse sentido foi incluir a equipe para estimar o plano de projeto, o que deu voz à equipe e melhorou a motivação intrínseca. Depois, o desenvolvimento ágil avançou, ao adotar a prática de medir o que a equipe conseguia entregar em uma iteração e utilizar esses números para planejar em vez de forçar uma estimativa inicial. Isso levou a aumentos significativos na criação de valor e na qualidade.
Como o Kanban faz para manter um equilíbrio saudável entre controle e liberdade?
Um equilíbrio saudável no Kanban
Com o Kanban, os integrantes da equipe puxam novas funcionalidades de uma fila de entrada priorizada. É comum que essas funcionalidades sequer estejam estimadas anteriormente; quando muito, estão estimadas numa escala. O controle do fluxo é a principal ferramenta gerencial utilizada para controlar a eficiência. A monitoração contínua do tempo de ciclo (o tempo entre a escolha de um item para implementação e sua entrega), e do "Lead Time" (o tempo entre o recebimento de um pedido de implementação de um item até sua entrega) - esses tempos nos dão uma boa ideia sobre o andamento da equipe e se tornam o alvo para cada participante do fluxo. Se o tempo médio de ciclo é de cinco dias em algum momento, a equipe indiretamente focará nesse número, ao começar uma nova funcionalidade.
A beleza dessa abordagem é que se baseia em dados reais, não em otimismo. Se normalmente uma funcionalidade nova leva cinco dias para ser entregue, é bastante provável que outra funcionalidade também leve cerca de cinco dias. O foco evolui de dentro da equipe, não é criado de fora pela gerência. Desse modo, a equipe se sente mais motivada para buscar o objetivo. Como as pessoas estarão menos inclinadas a tomar atalhos, entregarão funcionalidades com mais valor e qualidade.
De um perspectiva de gerência, trata-se de uma mudança do comando-e-controle para um estilo com foco em melhorar a equipe. A gestão só está aceitando a realidade ao admitir que o sistema é capaz de entregar uma funcionalidade nova a cada 5 dias. A partir desse ponto, todos os envolvidos no fluxo Kanban podem começar a melhorar continuamente. Todos passam a ser responsáveis por pensar em como melhorar o fluxo, reduzir os gargalos e as variações. Não demora para que os tempos de ciclo e o "lead time" mudem, assim como o foco da equipe, que será mais realista, já que é apoiado por métricas e um fluxo melhorado.
É bastante útil levar em conta a teoria das restrições ao se trabalhar na melhoria do fluxo Kanban.
Teoria das restrições como ferramenta de melhoria do processo
A teoria das restrições (TOC, Theory of constraints) é uma filosofia gerencial criada por Eliyahy Goldratt em 1984, com o livro "A Meta", cuja ideia central é a de que "uma corrente nunca é mais forte que seu elo mais fraco". Se utilizarmos esta ideia no Kanban, veremos que o estágio mais fraco do fluxo é o que determina a taxa de criação de valor de todo o sistema. Por exemplo, se notarmos que a fase de aceitação do usuário não consegue manter o ritmo das outras fases, ela acabará deixando todo o sistema mais lento, de acordo com a sua capacidade.
A partir do momento em que o trabalho torna-se visível por meio do quadro Kanban, a TOC também torna-se visível como gargalos que travam o sistema. As equipes sentirão os efeitos da TOC com o uso dos limites de trabalho em progresso (WIP). Estes são números escolhidos para cada estágio no fluxo; indicam a quantidade máxima de itens de trabalho que pode estar sendo executada no momento.
Se decidíssemos, por exemplo, começar com um limite de WIP de três itens para a coluna de testes de aceitação, nenhuma funcionalidade nova poderia ser iniciada nos estágios anteriores caso essa coluna tivesse seu limite preenchido. Como costumamos estar ansiosos para começar novas tarefas, essa limitação costuma ser frustrante.
Este é geralmente o momento em que realizamos uma sessão de melhoria para discutir como evitar que o problema ocorra novamente. Nossos limites de WIP estão corretos? Qual a causa deste gargalo, podemos eliminá-lo? Esta sessão de melhoria do Kanban se parece com uma retrospectiva, porém tem um foco mais abrangente. A maioria das retrospectivas no Agile são realizadas apenas com a equipe de desenvolvimento, com a participação ocasional do product owner, enquanto no Kanban estas sessões incluem tipicamente muito mais pessoas de funções diferentes na organização - pois a ênfase é sobre o fluxo, da ideia até o lançamento em produção. Participam da sessão analistas de negócio, engenheiros de sistema e até a equipe de vendas.
O enfoque de todos na melhoria contínua cria uma pressão saudável e assim são criadas mais oportunidades de compartilhar o conhecimento. Limites de WIP revelam rapidamente os gargalos e facilitam a criação de um ambiente de melhoria contínua e ajuda mútua. O poder da melhoria contínua catalisada pelo Kanban ajuda a melhorar o fluxo. Também auxilia a transformar a percepção de que, no Kanban, os produtos levarão mais tempo para ficar prontos, em um sentimento de maior eficiência, que poderá ser comprovado com métricas.
Fluxo
O Kanban baseia-se nos princípios de um sistema puxado (pull system), originário da manufatura Lean. O objetivo é chegar o mais próximo possível ao que é chamado de "fluxo de peça única", na qual a organização trabalha apenas em produtos pedidos por um cliente. Por que isso e qual a relação disto com o desenvolvimento de software?
A razão pela qual queremos trabalhar apenas em pedidos de clientes é que desejamos eliminar desperdícios, ou seja, ações que não trazem valor para o cliente. Deixemos inovação de lado por um instante, pois não há pedido do cliente para iniciar o sistema puxado para isso. Trabalhar em itens não requisitados por um cliente é especular sobre o que os clientes pedirão no futuro e, portanto, está-se construindo um estoque, uma pilha de produtos esperando para ser vendida. Isso é desperdício por duas razões. É capital gasto em itens que não estão trazendo lucro, portanto estão nos custando financeiramente. Esses itens trazem também grande risco de não serem vendidos ou não atenderem aos desejos dos clientes, levando também a perdas financeiras. O mesmo se aplica ao desenvolvimento de software: funcionalidades esperando meses para ser lançadas têm custos financeiros e, como na manufatura, estão relacionados a um risco de não atendimento das expectativas dos clientes.
Limites de WIP reduzem o estoque e criam um sistema puxado para as fases anteriores. Se uma tarefa é concluída, uma nova é puxada do estágio anterior, liberando sua capacidade e possibilitando a propagação para os estágios anteriores até a fila de entrada.
A crítica mais comum sobre limites de WIP é a de que teria efeito negativo sobre a eficiência. É evidente que pessoas ocasionalmente ficarão ociosas se o limite de WIP for atingido. Mas o que aconteceria caso ignorássemos os limites de WIP? Estoques começariam a ser criados ou ampliados.
As pessoas não devem estar 100% ocupadas o tempo todo; a percepção de que deveriam remonta ao começo da revolução industrial, quando as fábricas começaram a se expandir e máquinas caras eram adquiridas para aumentar a capacidade. Estas máquinas eram tão caras que tinham que ser utilizadas continuamente para manter baixos os custos por unidade. Isso levou a um desequilíbrio na linha de produção e um crescimento dos estoques.
Naquela época, um produto não era customizado para o usuário, assim o risco de não atender às vontades dos clientes era inexistente, simplesmente porque estes não tinham opções. A empresa tinha apenas que garantir que venderia o estoque. Nos dias de hoje, e para muitas empresas, os produtos são customizados para os usuários finais, fazendo com que os estoques sejam um grande risco. Isto se aplica à área de TI também, já que a maioria dos sistemas é customizada para um cliente, segmento consumidor etc.
Um sprint contínuo
Devido ao fato de o Kanban tratar o trabalho como um fluxo contínuo, existe a ideia de que as equipes não têm mais oportunidade para parar e pensar, de que a equipe está em um sprint sem fim no qual é forçada a entregar cada vez mais rápido. Como sabemos, um ritmo sustentável é importante para a qualidade do produto e para a saúde da equipe. Um pouco de flexibilidade nos prazos e alguns descansos são necessários, para organizar as ideias e refletir sobre o futuro do produto, permitindo à equipe tomar decisões mais acertadas no decorrer da entrega.
Medir o fluxo pode levar à armadilha do microgerenciamento, forçando a equipe a trabalhar cada vez mais. É nesse ponto que é importante o papel de um coach, para ajudar os integrantes da equipe a entender que, para acelerar, precisam parar e pensar no processo, não apenas na velocidade do desenvolvimento. O Kanban dá ênfase no fluxo de ponta a ponta. Forçar para que uma etapa do fluxo produza mais rapidamente costuma causar problemas para as demais etapas do fluxo, na forma de defeitos, gargalos e decisões impensadas. Aqui aparece novamente a Teoria das Restrições, a qual afirma que problemas aparecerão em etapas posteriores caso forcemos uma etapa do processo a trabalhar mais rápido.
Uma equipe iniciante no Kanban começa com sua eficiência atual e inspeciona continuamente sua própria colaboração para desempenhar melhor - não trabalhando mais rápido, mas melhorando o fluxo, o que torna mais fácil garantir a continuidade, já que todos concordam que o sistema é mais importante que o indivíduo, e que podem realizar mais ao melhorar em conjunto.
Resumo
Pode parecer estranha a ideia de que medir o fluxo em vez de estabelecer prazos torna o trabalho mais eficiente. Mas o Kanban cria mais consciência quanto à importância de cada etapa do processo. Ao invés de se acelerar etapas individualmente, otimiza-se o todo - porque no final o que interessa são os usuários finais, que se importam apenas que o pedido seja entregue, não se nossos desenvolvedores estão cumprindo prazos.
Assim que o processo esteja sob controle, a equipe pode começar a buscar a melhora em sua eficiência; não localmente, mas de ponta a ponta; não fazendo com que as pessoas trabalhem mais, mas reduzindo gargalos e otimizando o fluxo. As circunstâncias nas quais as pessoas trabalham são ajustadas para melhor servir à necessidade de todos, produzindo um ritmo sustentável para os empregados, uma relação confiável para o cliente e um negócio rentável para os proprietários.
Ebook grátis
Veja mais sobre o Kanban neste e-book gratuito, em inglês, que discute quatro argumentos adicionais contra o Kanban.