5 formas sistêmicas de reduzir seu time to market (lead time)

Antigamente, o importante era manter o segredo de um produto enquanto passávamos meses ou anos o desenvolvendo. Hoje, o objetivo das empresas é colocar o produto no mercado o quanto antes para ser experimentado e avaliado pelos consumidores. Dessa forma, reduzir o tempo de concepção, desenvolvimento e entrega de um produto (time to market) tornou-se imperativo.

Lead Time

Quando falamos de Métodos Ágeis, o time to market recebe o nome de lead time, isto é, o tempo decorrido desde o momento em que o time se compromete a construir uma ideia até que o produto ou funcionalidades do produto estejam disponíveis para utilização dos consumidores e possamos coletar métricas de uso e negócio.

Quadro Kanban com múltiplas colunas: Backlog, Estudando, Estudado, Priorizando, Priorizado, Construindo, Construido, Testando, Testado, Em aprovação do Gestor, Aprovado pelo Gestor, Homologando, Homologado, Implantando, Implantado, Em aceite pelo cliente e Em Produção. No meio do quadro há uma grande seta que vai de Backlog até em produção. Abaixo da seta um relógio indicando o lead time.

Exemplo de lead time. O ponto de compromisso é o backlog e após o aceite está entregue para o consumidor final.

Há diversas maneiras de reduzir o lead time, todavia abaixo apresentamos 5 formas sistêmicas de fazer essa redução e como ela é refletida no Quadro de Tarefas:

  • limitar a quantidade de trabalho em andamento;
  • fatiar melhor os itens de valor;
  • adiantar o seu ponto de entrega para o consumidor;
  • atrasar o seu ponto de compromisso;
  • e remover etapas do processo.

Limitar a quantidade de trabalho em andamento

O primeiro movimento que falaremos neste artigo é a compressão horizontal do Quadro de Tarefas. Quando utilizamos o Método Kanban, aprendemos que quanto mais trabalho temos em paralelo, menos eficientes nós seremos, pois, cada item individualmente demorará muito mais tempo para ser entregue. Há inclusive uma prova matemática (Lei de Little) que apresentamos nos treinamentos de Kanban e Métricas ágeis.

WIP não limitado

A figura abaixo apresenta um quadro em que o WIP não está limitado. Muitos itens começando, porém poucos acabando.

Quadro Kanban com múltiplas colunas: Backlog, Estudando, Estudado, Priorizando, Priorizado, Construindo, Construido, Testando, Testado, Em aprovação do Gestor, Aprovado pelo Gestor, Homologando, Homologado, Implantando, Implantado, Em aceite pelo cliente e Em Produção. Não há limitações, logo há muito trabalho começando e nenhum acabando.

Quadro sem limitação de trabalho em andamento. Muitas coisas começam e poucas terminam.

Abaixo apresentamos um gráfico de acompanhamento que demonstra o que acontece com o lead time quando não utilizamos a limitação do trabalho em andamento. Nele são apresentados: a quantidade de trabalho em andamento (WIP); Vazão (throughput); Lead Time; A taxa de eficiência do fluxo (flow efficiency); e Uso da Capacidade do time (capacity utilisation)

Duas métricas que não são comuns aparecem nesse gráfico. Primeiramente, a taxa de eficiência. Ela é o resultado da divisão do tempo em que as coisas estão em execução (por exemplo, construindo, testando, homologando, etc.) pelo Lead Time. Quanto maior a taxa de eficiência, menos tempo os itens ficam em filas de espera. Por fim, o uso da capacidade do time é quanto o time está ocupado trabalhando nos itens de valor.

O gráfico possui 5 linhas. O eixo X é o tempo em dias e o Y a quantidade de itens em andamento. A primeira linha mostra o WIP começa com zero, porém em 90 dias chega em 156 itens andando em paralelo. A Vazão permanece estavel durante todos o tempo. Pouco maior do que 0,5 itens por semana. O lead time começa pequeno, porém em 90 dias chega a 40 dias para entregar 1 item. A taxa de eficiência do fluxo começa alta, porém cai abruptamente por volta do dia 15. Isso indica que as coisas estão ficando cada vez mais em uma fila de espera e cada vez menos em execução. A utilização das pessoas está absurdamente alta, acima de 200%.

Gráfico de um time trabalhando durante 90 dias sem limitação do Trabalho em Andamento (WIP)

Em síntese, podemos ver o que acontece quando um time não utiliza a limitação de trabalho em andamento após 90 dias de trabalho. Existem 156 itens de valor em alguma etapa do processo (WIP). Todo o time está ocupado trabalhando,  entretanto, o lead time é de quase 40 dias. A taxa de eficiência do fluxo é muito baixa, o que significa que há muita coisa em filas de espera.

WIP limitado

No quadro abaixo fazemos a limitação do trabalho em andamento. Ela é representada pelos números em vermelho entre colchetes. A forma de lermos o quadro é: na coluna Priorizado podem existir até quatro itens de valor. Na coluna Construção podemos ter no máximo cinco itens. Esses cinco itens podem estar espalhados nas duas sub colunas (Construindo e Construído) de qualquer forma, desde que a soma de itens de valor não ultrapasse o limite do WIP que no caso é cinco.

Quadro Kanban com múltiplas colunas: Backlog, Estudando, Estudado, Priorizando, Priorizado, Construindo, Construido, Testando, Testado, Em aprovação do Gestor, Aprovado pelo Gestor, Homologando, Homologado, Implantando, Implantado, Em aceite pelo cliente e Em Produção. Dessa vez com limitação de trabalho em andamento em todas as colunas. Há muita coisa em andamento, porém muitas terminando. É um exeplo de compressão vertical. Menos trabalho em paralelo e mais eficiência.

Quadro com limitação de trabalho em andamento.

Olhando agora para o gráfico de acompanhamento do mesmo time após aplicar a limitação da imagem acima.

O gráfico possui 5 linhas. O eixo X é o tempo em dias e o Y a quantidade de itens em andamento. A primeira linha mostra o WIP começa com zero, porém em 90 dias chega em 156 itens andando em paralelo. A Vazão permanece estavel durante todos o tempo. Pouco maior do que 0,5 itens por semana. O lead time começa pequeno, porém em 90 dias chega a 40 dias para entregar 1 item. A taxa de eficiência do fluxo começa alta, porém cai abruptamente por volta do dia 15. Isso indica que as coisas estão ficando cada vez mais em uma fila de espera e cada vez menos em execução. A utilização das pessoas está absurdamente alta, acima de 200%.

Comportamento após a limitação do WIP

Noventa dias após limitar o trabalho em andamento, em todas as etapas do fluxo de valor é possível perceber que o Lead Time caiu de 40 para 3 dias. A quantidade de itens andando em paralelo no quadro caiu de 156 para 13 itens. A taxa de eficiência do fluxo cresceu significativamente. Já a ocupação com picos e vales demonstra que há intervalos em que as pessoas podem fazer melhoria contínua.

Limitar a quantidade de itens em andamento favorece seu time a parar de começar e começar a terminar, promove a movimentação dos membros em outras etapas do fluxo de valor e ajuda a dar transparência e proteção ao gargalo do processo.

Fatiar melhor os itens de valor

O segundo movimento é a compressão dos itens no Quadro de Tarefas. O objetivo primário de um Product Owner é justamente olhar para problemas, imaginar qual produto ou serviço resolveria esse problema e fatiar a entrega deste em partes que agreguem valor para seu cliente e para a sua empresa.

O fatiamento é um grande desafio, pois quando mal feito, o time de desenvolvimento terá que construir partes enormes do produto antes de colocar na mão dos consumidores. Fatias grandes são problemáticas pois demoram muito para ser desenvolvidas, possuem muita incerteza e a alta complexidade. Consequentemente, ampliam o lead time. Reduzir o tamanho das fatias e mantê-las entregando valor para consumidores e empresa fará com que tenhamos o efeito diametralmente oposto.

Fatiamento. Uma pessoa tentando carregar uma pedra pesada e quase caindo e outra que conseguiu fatiar bem carregando um diamente.

O bom fatiamento ajuda na eficácia da entrega e eficiência do time.

Adiantar o ponto de entrega para o consumidor

O terceiro movimento é a compressão vertical das etapas finais do Quadro de Tarefas, também conhecidas como etapas de delivering. Em muitos cenários é comum a etapa final do desenvolvimento se caracterizar por um conjunto enorme de autorizações, verificações, assinaturas e muito trabalho manual. Uma forma simples de resolver esse problema é justamente eliminar a parte burocrática, removendo autorizações desnecessárias e automatizar o fluxo de entrega. Quando falamos especificamente de software, estamos falando em substituir os velhos scripts de implantação por práticas de DevOps e ferramentas de entrega contínua.

Algumas perguntas que podem auxiliar seu time a verificar se é possível adiantar o ponto de entrega para o consumidor:

  • As pessoas que autorizam a entrega do produto estão realmente envolvidas com ele ou estamos apenas tentando transferir a responsabilidade?
  • Tudo o que fazemos realmente precisa do mesmo nível de autorização?
  • Estamos fazendo um trabalho procedimental (seguindo um roteiro) que poderia ser automatizado?
Quadro Kanban com múltiplas colunas: Backlog, Estudando, Estudado, Priorizando, Priorizado, Construindo, Construido, Testando, Testado, Em aprovação do Gestor, Aprovado pelo Gestor, Homologando, Implantando, Implantado e Em Produção. O estágio de implantando passou a ser executado por um robô e deixou de ter o aceite pelo cliente, adiantando o ponto de entrega.

Quadro após a remoção de etapas desnecessárias na etapa de entrega e automação de processos.

Atrasar o seu ponto de compromisso

O quarto movimento é também uma compressão vertical, porém nas etapas inicias do Quadro de Tarefas e acontece durante o discovering. Como o lead time começa a contar quando o time se compromete a entregar algo, uma forma de reduzi-lo é quando atrasamos o momento em que o compromisso acontece. Muitas empresas ainda trabalham com escopo fechado para desenvolvimento de produtos. Para elas, o lead time começa a contar quando o contrato é assinado. A partir daquele momento o cliente já tem a expectativa de receber tudo o que foi pedido. Ao adotar o escopo flexível conforme descrito no Manifesto Ágil, automaticamente atrasamos o ponto de compromisso de cada entrega.

Outra situação em que podemos atrasar o ponto de compromisso é justamente quando o time de desenvolvimento recebe ideias ainda muito incipientes. Ao invés de nos comprometermos com algo que não pode ser totalmente compreendido, o melhor é criar um conjunto mínimo de restrições antes de começarmos a contar o nosso lead time.

  • o problema do consumidor deve estar descrito na ideia (porque);
  • o consumidor ou persona representando um grupo de consumidores que sofre do problema deve ser definido (quem);
  • a proposta de solução deve estar descrita (o quê);
  • e as métricas que iremos utilizar para validar se a fatia do produto realmente resolveu o problema do consumidor foram estabelecidas (resultados).
Quadro Kanban com múltiplas colunas: Backlog, Estudando, Estudado, Priorizando, Priorizado, Construindo, Construido, Testando, Testado, Em aprovação do Gestor, Aprovado pelo Gestor, Homologando, Homologado, Implantando, Implantado, Em aceite pelo cliente e Em Produção. O ponto de compromisso deixa de ser quando o item está no backlog e passa a ser quando entra na coluna priorizado.

Para esse time, o ponto de compromisso deixou de ser o momento em que o item entra no backlog. Consequentemente, passou a ser o momento em que o Product Owner priorizou o item para ser entregue.

Remover etapas do processo

O quinto movimento é outra compressão vertical. Esta acontece no meio do Quadro de Tarefas (mid stream). Quanto mais etapas temos no nosso processo, maior será o nosso lead time. No Kanban, chamamos essas etapas de Handoffs (passagem de bastão). Normalmente é quando temos a necessidade de especialistas diferentes no nosso fluxo de valor ou etapas de autorização intermediárias. Se os handoffs forem para pessoas externas ao time de desenvolvimento, o lead time sofrerá um impacto ainda pior. Algumas formas de remover as etapas intermediárias são:

  • internalizar especialidades fundamentais ao time e torná-lo realmente multidisciplinar;
  • promover aprendizagem a fim de que cada membro do time possa se movimentar no fluxo de valor e realizar o trabalho necessário
  • em outras etapas do processo sem a necessidade de especialistas;
  • remover etapas que não agregam valor ao produto (burocracias);
  • juntar etapas em que o sequenciamento não é mandatório.
Quadro Kanban com múltiplas colunas: Backlog, Estudando, Estudado, Priorizando, Priorizado, Construindo, Construido, Testando, Testado, Implantando, Implantado, Em aceite pelo cliente e Em Produção. Removendo as colunas de aprovação do gestor e homologação.

Remoção de etapas desnecessárias. A homologação do Product Owner passou a ser feita em conjunto com os testes.

Conclusão

Essas são cinco formas sistêmicas que podemos utilizar para reduzir o nosso lead time e aumentar a eficiência dos nossos times e empresas. Entretanto, não é necessário adotar todas de uma única tacada, mas quanto mais pudermos fazer, melhor será o nosso time to market.

Quadro com as colunas: Backlog, Estudando, Estudado, Priorizando, Priorizado (passou a ser o ponto de compromisso), Construindo, Construído, Testando, Testado. A coluna Entregando é executada por um robô e depois a coluna final é entregue.

Quadro aplicando todas as formas sistêmicas para reduzir o Lead Time.

Não tente fazer todas as mudanças de uma vez, por mais que seja convidativo. Prefira uma visão sistêmica e boa leitura de cenário para saber qual será o seu próximo ponto de alavancagem.

Esperamos que este artigo o ajude a fazer a melhoria do seu time. Para saber mais sobre o tema, participe dos nossos treinamentos de Kanban Management Professional I, Kanban Management Professional II e Métricas Ágeis para produtos, times e organizações.

Autor(es)

Avelino e Rodrigo de Toledo
Avelino e Rodrigo de Toledo
Avelino é formado e mestre em Ciência da Computação. Teve uma longa trajetória na T.I. começando como programador e chegando à gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis desde 2008. A partir de 2015 se dedicou a auxiliar outras empresas a adotar tais métodos. Atualmente é Agile Coach e Trainer na Knowledge 21. Rodrigo, fundador da K21, é instrutor internacional da Scrum Alliance (CST), Kanban Coaching Professional (KCP), instrutor internacional da Lean Kanban University e facilitador certificado de Management 3.0. Com doutorado na França, possui diversos artigos internacionais e lecionou por doze anos na PUC-Rio e na UFRJ.

Comentários

Deixar um comentário