Limite de Wip e lei de little

Nesse texto vou explicar sobre como melhorar a performance de um time focando nas entregas ao invés de focarmos em puxar atividades.

Qual problema queremos atacar?

Em uma squad é comum observar várias atividades sendo atuadas ao mesmo tempo, e que elas não são resultantes em qualidade ou quantidade de entrega, podendo gerar um sentimento de frustração ou baixa produtividade do time. Irei explicar como limitar o WIP pode resolver esses problemas, e auxiliar na efetividade, produtividade e previsibilidade.

Contexto

Dentro da Magnetis, trabalhamos com squads multidisciplinares atuando com Scrumban, ou seja, atuamos através de sprints com suas metodologias e cerimonias provenientes do Scrum, em simultâneo, empregando a visão da entrega através de um board de Kanban. Sabendo desses pontos, vou tentar lhe explicar qual a aplicabilidade do limite de WIP e como fizemos para performamos melhor.

O que é WIP?

Mais conhecido como work in progress, ou seja, de uma forma simples, WIP é a quantidade de atividades que estão sendo atuadas pelo time no momento em que se observa a métricas.

Abaixo temos um WIP de 5 atividades

Ou graficamente, podemos observar a linha verde em cada sprint.

Lei de Little e limitando o WIP

Não irei me aprofundar na teoria matemática de filas de John Little, porém irei mostrar a sua aplicabilidade em processos de produtos, mas sim irei explicar na usabilidade da lei quando se trata de uma squad.

A lei de Litte traduzida para processos expõe que a quantidade de WIP em um squad é a resultante da multiplicação entre a quantidade de atividades entregues vezes a tempo médio por cada uma das atividades, em outras palavras WIP = throughput x lead time.

Ok, mas qual a relação disso com a quantidade de atividades a serem entregues, probabilidade de acerto e como podemos dimensionar nossas entregas, bom, com isso vamos exemplificar com alguns exemplos.

Exemplo 1.

Nossa squad tem 4 pessoas desenvolvedoras, atuando em 10 atividades em simultâneo, sendo elas divididas dentro do board de work in progress composto por "Doing", "Review", "QA", toda vez que uma atividade é entregue, puxarmos outra de "To Do", com isso, nosso WIP sempre é 10, cada uma das atividades demora em média 4 dias para finalizar todas as etapas de "doing".

Exemplo 2.

Nossa squad tem 3 pessoas desenvolvedoras, atuando em 3 atividades em simultâneo independente do estado de "doing" dela, quando uma é finalizada, um de nossos desenvolvedores puxar uma nova para ser finalizada, cada uma das atividades demora em média 4 dias para finalizar todas as etapas de “doing”.

As duas equipes atuam em atividades com o mesmo peso ou tamanho.

Observando esses exemplos, minha dúvida é:

Qual você considera a squad que mais entrega no final de uma sprint?

Observando a lei de little:

Exemplo 1, a cada 2,5 dias teríamos uma entrega, pois lead time = 10/4

Exemplo 2, a cada 1 dia teríamos uma entrega, pois lead time = 3/3.

Ou seja, durante uma sprint, o exemplo 1 consegue entregar 2 atividades em uma semana, já no exemplo 2 é entregue 5 atividades em uma semana, dessa forma podemos constatar que mesmo uma squad com menos pessoas atuando em menos atividades em simultâneo pode ser mais performática que uma equipe com mais pessoas limitando a quantidade de atividade que atua em simultâneo.

Transição no time

Após proposto para o time, a transição para limitarmos a quantidade de atividades que seriam atuadas em simultâneo, houve alguns questionamentos como: estamos cientes que diminuiremos nossa produtividade e vamos deixar de puxar atividades para "doing", porém após pouco tempo de mudança na squad o pensamento do time foi alterado para forcar nas atividades que estão mais próximas "done", com isso aumentamos nossa produtividade e melhoramos a previsibilidade de entregas.

Esse texto foi baseado em experiências dentro da Magnetis e com base em artigos de Paulo Caroli.