A Lei de Little vem do professor do MIT John D. C. Little (1928 – 2024). Ele publicou o conceito inicial em 1954 sobre a Teoria das Filas e o comprovou em 1960 no artigo que pode ser lido na íntegra neste link. Nele o matemático propõe o seguinte teorema: L= λ x W. De uma forma muito simples, ele explica por que você fazer muitas coisas em paralelo é pior do que fazer coisas sequencialmente. Vamos à explicação.
A Fórmula de Little
L= λ x W
Onde,
L: número médio de itens no sistema (em processo ou fila)
λ: taxa média de chegada (itens por unidade de tempo)
W: tempo médio de permanência de um item no sistema
Exemplo de Aplicação direta da Lei de Little
Digamos que o seu time recebe 3 novas demandas por dia. Além disso, em média ele demora 3 dias para entregar a solução da demanda. Aplicando a Lei de Little teremos:
L= λ x W
L = 3 x 3
L = 9
Esse time tem em média 9 demandas em andamento no seu fluxo de trabalho.
Implicações Matemáticas da Lei de Little
O formato apresentado é o formato padrão que temos da Lei de Little. Entretanto, matematicamente, podemos fazer algumas inversões. Por exemplo, se quisermos calcular o tempo podemos fazer:
Pegando o exemplo acima. Digamos que a quantidade de itens no fluxo AUMENTE de 9 para 12 (L = 12) indicando que estamos paralelizando mais coisas. Porém, vamos manter a taxa média de chegada em 3 itens por dia. Vamos ver como o tempo de entrega se comporta.
L= λ x W
W = L ÷ λ
W = 12 ÷ 3
W = 4 dias para entregar cada demanda.
Perceba que as coisas pioraram em 1 dia.
Vamos tentar o contrário. Ao invés de paralelizar, vamos sequenciar mais reduzindo a quantidade de itens no fluxo de trabalho de L = 12 para L = 6. Mantendo a taxa de chegada para 3 itens por dia.
L= λ x W
W = L ÷ λ
W = 6 ÷ 3
W = 2 dias para entregar cada demanda.
Mudança de Reinertsen
Don Reinertsen, em seu livro The Principles of Product Development Flow, altera a definição de λ de taxa média de chegada (itens por unidade de tempo) para taxa média de processamento. Isso é importante porque em trabalhos baseados no conhecimento, a taxa de chegada de novos itens pode ser variável, pois depende do tipo de serviço prestado pelo time. Por exemplo, um time que desenvolve software tem demandas planejadas e demandas emergenciais. Essas últimas podem acontecer a qualquer momento e também podem tomar a prioridade das planejadas.
Entretanto, isso não muda a lógica da Lei de Little. Quanto mais coisas seu time fizer em paralelo, mais tempo demora para seu time realizar cada coisa.
Trocando para Termos Kanban
Para quem lida com agilidade, os termos da Lei de Little podem ser confusos, mas eles podem ser expressos em termos que conhecemos melhor.
L: número médio de itens no sistema (em processo ou fila), ou seja, o WIP (Work In Progress), quantidade de itens em progresso no seu quadro.
λ: taxa média de processamento (itens por unidade de tempo, segundo D. Reinertsen). No Kanban damos o nome de Vazão (throughput), embora o mais correto fosse a Taxa de Entrega.
W: tempo médio de permanência de um item no sistema. Esse é o nosso bom e velho Lead Time, mais especificamente o Cycle Time.
Agora, podemos colocar as coisas em termos Kanban:
Se quisermos ser mais corretos com relação a nomenclatura, a fórmula fica:
Caso você não esteja familiarizado com os nomes, segue a imagem de um exemplo de mapeamento de fluxo de trabalho em um quadro Kanban e onde você encontra cada uma das métricas presentes na fórmula apresentada.
A Constância da Taxa de Entrega
Quando estamos trabalhando em um time e este é estável, a nossa taxa de entrega tende a ser constante. Faça um teste aí na sua ferramenta de gestão. Extraia a vazão* do time nos últimos dois meses. Você verá que ela tende a ser estável. Por exemplo: 3 itens entregues na semana 10, 4 itens entregues na semana 11, 3 itens entregues na semana 12 e por aí vai. Caso o seu time utilize Scrum com Pontos de História (Story Points) essa taxa de entrega será algo como 50 pontos por Sprint na Sprint 10, 52 pontos por Sprint na Sprint 11…
Para aumentar essa taxa de entrega, no geral só existem 2 meios. O primeiro é aumentar a quantidade de pessoas no time, o que, entretanto, pode causar alguns impactos negativos. Inicialmente é esperado que haja uma queda de performance no time, pois alguém terá que cuidar da chegada e ambientação desse novo membro do time. A expectativa é que essa chegada seja uma Curva J onde inicialmente há uma queda de performance para depois aparecer o ganho que a pessoa traz. Outro efeito é que há um limite para pessoas no time. Se aumentar muito, o custo de coordenação piora tanto que ao invés de melhorar a performance, ela irá piorar.
Outra forma de aumentar a taxa de entrega é através de automação. Por exemplo, se os testes são feitos de forma manual, é possível passá-los para execução automática. Ou então, começar a utilizar agentes de Inteligência Artificial para dar celeridade para algumas atividades do time.
* Boa parte das ferramentas chamam de throughput, porém algumas utilizam a nomenclatura mais adequada de taxa de entrega (depende da nomenclatura utilizada pela ferramenta). Se o seu time utiliza Scrum, é possível que apareça com o nome Velocity ou Velocidade do time.
Consequência da Constância da Taxa de Entrega
Logo, a forma pela qual temos de reduzir o tempo que levamos para entregar valor para o nosso cliente é justamente reduzir a quantidade de itens em que estamos trabalhando. Em outras palavras, reduzir o WIP.
A Lei de Little de forma visual
O cateto é a quantidade de trabalho em progresso (WIP), o outro cateto é o tempo que leva para processar um item de trabalho (Cycle Time) e a Taxa de entrega (i Entrega) é o ângulo, que tende à estabilidade, logo, ele não altera.
O que acontece quando você aumenta a quantidade de trabalho em progresso (WIP)
O que acontece quando você reduz a quantidade de trabalho em progresso (WIP)
Custo de Troca de Contexto
A Lei de Little por si só já nos mostra que, quanto mais coisas fazemos simultaneamente, maior será o nosso tempo de entrega. Ela deixa claro que excesso de trabalho em progresso (WIP) leva a ciclos mais longos e menor fluidez no sistema. Mas essa não é toda a história. Afinal, nós somos seres humanos, não máquinas. E seres humanos não conseguem focar plenamente em várias coisas ao mesmo tempo. Se você estiver imerso no Projeto A até as 13h, não consegue simplesmente parar e começar o Projeto B às 13h01. Existe um custo invisível e inevitável: o custo de troca de contexto (context switching cost). É preciso tempo para:
- Finalizar e registrar o que foi feito no Projeto A;
- Se desconectar mentalmente daquele fluxo;
- Retomar o fio da meada no Projeto B (ou entender o que foi feito na sua ausência).
Se você já viveu o famigerado “part-time” entre dois ou mais times, sabe o quanto isso pode ser desgastante. Manter o Time 1 atualizado sobre sua parte, e ao mesmo tempo entender o que aconteceu no Time 2 enquanto você estava fora. É uma dança difícil.
Gerald M. Weinberg no seu livro Quality Software Management, Volume 1: Systems Thinking, p. 284 sugere:
Em outras palavras, quando trabalhamos com 4 ou mais coisas simultaneamente perdemos mais tempo trocando de contexto do que efetivamente trabalhando em cada coisa.
A Lei de Little explica a física do sistema, mas a troca de contexto revela a biologia do trabalhador.
Conclusão
A Lei de Little é uma ferramenta poderosa para entendermos como o trabalho flui dentro de sistemas e, consequentemente, nos nossos times. Ela nos mostra, de forma matemática, a inevitável realidade dos fatos. Quanto mais coisas fazemos ao mesmo tempo, maior será o tempo de entrega de cada uma delas. É um convite direto ao foco, limitação de WIP e entrega contínua.
Todavia, o trabalho do conhecimento vai além da matemática. Somos pessoas, não processos. E, ao contrário das máquinas, não alternamos tarefas instantaneamente. Existe um custo humano e cognitivo associado a cada mudança de contexto, e ele se soma silenciosamente ao nosso lead time, drenando energia, foco e eficiência.
Quer se tornar mais eficiente? Faça menos coisas ao mesmo tempo.
Quer se aprofundar mais nesse tema veja o artigo: 100% de ocupação: A grande mentira da gestão. Se quiser ainda mais, veja o nosso treinamento de:
Treinamento de Kanban System Design (KSD)
Nos vemos em breve!!!
