Agilizando: faça menos para entregar mais

Na primeira vez que ouvi que seria possível entregar mais se fizemos menos coisas simultaneamente, eu estava cético. Não faz sentido, pensei.

Se você tem tempo agora, tente fazer: escreva a sequência A, B, C, D, E, F, G, H três vezes, cada uma em uma linha diferente. Repita uma vez, mas na sua segunda tentativa, escreva primeiro todas as letras A, depois, as letras B, e assim por diante. Se você mediu ambos os testes, provavelmente o primeiro terminou mais rápido que o segundo. No meu caso, dois segundos a menos.

Eu sei: o tempo de descoberta é só 7% menor. Mas imagine o que poderia acontecer quando desenvolver características complicadas em produtos digitais, por exemplo. Ou tente realizar o mesmo desafio escrevendo múltiplos de 3, 6 e 7 em cada linha até o décimo valor. Também fiz isso: 21% a menos (59 e 75 segundos).

Mas também temos outra questão importante: no primeiro teste, entreguei o escopo dividido em três partes, talvez em nove segundos cada. Certo valor logo foi fornecido, e pude coletar feedback e melhorar minha segunda entrega (segunda linha). Se você entregar todas as linhas juntas (escrevendo todas as letras A, depois as letras B etc.), seu feedback será mais lento, os riscos são mais consideráveis e o tempo de entrega (tempo de espera) será maior.

Conceitos semelhantes foram explorados desde a metade do século passado. Taiichi Ohno, considerado pai do Sistema de Produção Toyota, escreveu sobre um limite máximo de trabalho em progresso como uma das propriedades do kanban em seu trabalho para melhorar a eficiência de fabricação. John Little (MIT, 1961) desenvolveu a Lei de Little para explicar a relação entre a quantidade média de itens em um sistema de fila com duas outras variáveis. Ambos são bons exemplos.

Nos últimos anos, no desenvolvimento de software, tive a experiência de entender melhor a relação entre o que fazemos simultaneamente com o tempo para entregar e o volume de entrega. David Anderson relatou um caso interessante em seu livro chamado Kanban (2011). No estudo de caso apresentado, ele afirma que há uma relação linear de causa e efeito entre a quantidade de trabalho em progresso e o tempo de espera médio.

Como estamos tentando?

No Nubank, estamos melhorando continuamente nossos métodos e práticas de trabalho. Tivemos um resultado impressionante no exemplo de uma equipe de engenharia de software abaixo:

no primeiro gráfico, a linha verde mostra a média móvel do tempo de espera (para dias úteis), considerando as últimas cinco histórias de usuário concluídas. A linha cinza é só uma projeção. Os pontos vermelhos são as demandas atuais.

O segundo gráfico mostra a quantidade de demandas concluídas por semana (com as cores separando por tipo de problema). Essa é nossa produtividade.

Tempo de espera e produtividade são duas variáveis importantes para medir no desenvolvimento de software. Como podemos observar no exemplo, a média móvel é mais estável a partir da metade do primeiro gráfico à direita. Na mesma faixa do segundo gráfico, a quantidade de entregas é maior. Como reduzimos o tempo necessário para entregar nossas demandas (tempo de espera) e aumentar a quantidade de itens concluídos por semana (produtividade)?

Fizemos duas coisas “simples”:

• Começamos a gerenciar melhor nosso trabalho em progresso (itens atuais) Tínhamos 4 do limite máximo das demandas na etapa “Pronto para Desenvolvimento” e 6 em todas as outras etapas antes de “Pronto” no nosso kanban (etapas “Em Desenvolvimento”, “Revisão de Código” e assim por diante). Usando um quadro simples, limitamos uma parte inicial do fluxo, para impedir que nossas demandas ficassem obsoletas, e etapas de desenvolvimento, para evitar que fizéssemos muitas coisas ao mesmo tempo, estimulando os membros da equipe a se ajudarem. Essas ações provavelmente ajudaram a estabilizar a média móvel do tempo de espera.
• Reduzimos o tamanho das demandas. Coisas menores são mais fáceis de entender e refinar, talvez mais rápidas para entregar, com um alto potencial de fornecer valor aos nossos clientes e coletar feedback sobre a entrega ou novas características mais rapidamente  Isso poderia explicar o aumento de produtividade. É importante dizer que estamos entregando coisas menores, e não programando mais rapidamente.

Por que fizemos isso?

Talvez seja uma boa ideia gerenciar melhor seu fluxo de trabalho se precisar de certa previsibilidade. Por exemplo, você pode alinhar melhor as expectativas sobre as datas de entrega se tiver um fluxo de trabalho mais estável e previsível.

Também fizemos isso para melhorar a visibilidade do nosso fluxo de trabalho para verificarmos algum possível gargalo e melhorar nossos métodos ágeis usando dados baseados no nosso comportamento de trabalho. Você também pode fazer isso para eliminar a sensação de entrega lenta, penso eu.

Por fim, como escrevi antes, essas práticas podem ajudar você a conseguir feedback mais rapidamente, os riscos podem ser mais fáceis de gerenciar e o tempo de entrega será mais curto (esperamos).

Se começarmos a fazer algo, qualquer outra coisa que fizermos ao mesmo tempo provavelmente competirá com a primeira coisa. Atenção: não precisamos necessariamente fazer apenas uma coisa por vez, porque às vezes podemos começar uma segunda ou terceira demanda enquanto esperamos que algo indireto aconteça com a primeira (por exemplo, migração de dados de quatro horas no seu Banco de Dados, ou uma revisão de um colega no seu pull request).

Entretanto, quando aquela primeira coisa indireta terminar, você terá duas ou três coisas para fazer simultaneamente, e as demandas competirão entre si. Isso pode aumentar o tempo de espera, reduzir a produtividade… Está bem. Você já conhece a história.

Lembre-se dafilosofia Lean: Pare de começar e comece a terminar.