Lei de Little - Sobre as taxas e buffers

Eu juro que eu não planejava escrever sobre a Lei de Little novamente quando fui deitar no sábado e eu não planejava um texto domingo de manhã, antes de sair para comprar a carne do churrasco para ver o meu Flamengo massacrar o São Paulo pelo Campeonato Brasileiro. Mas o twitter ficou pequeno novamente, então vamos lá.

Como vocês já repararam na introdução, não esperem nada muito formal, de métricas, palavras chaves, SEO para blog and so on. Se algo ficar confuso, senta o dedo nos comentários. =)

Eu iria usar o meu texto anterior sobre o assunto, pois ainda concordo com cada linha do que está lá, mas percebi que faltava algo.

As taxas. Lá eu comento sobre a inexistência do equilíbrio entre as taxas de entrada e de saída de um sistema complexo. Entretanto, por incrível que pareça, parece que uma das confusões está no termo taxa. Taxa é:

Uma taxa é uma relação entre duas grandezas. Trata-se de um coeficiente que exprime a relação existente entre uma quantidade e a frequência de um fenómeno. 

Exemplos de fenômenos: clientes querendo comer (restaurante), clientes querendo falar com o gerente (banco) ou idéias sendo desenvolvidas (desenvolvimento de produto). A Lei de Little foi estabelecida para casos semelhantes aos dois primeiros fenômenos. Nos tempos atuais, as pessoas transferiram e adaptaram a Lei de Little pra o terceiro fenômeno. Só se esqueceram de um detalhe. No desenvolvimento de produtos (onde fluem idéias e/ou demandas), não existe o equilíbrio entre a taxa de entrada e de saída. Um restaurante ou um banco possui horário de funcionamento. Você consegue facilmente fechar a frequência do fenômeno dentro deste espaço. Além disso, esta previsibilidade de funcionamento faz com que as taxas diárias possam facilmente ser replicadas para uma taxa semanal, mensal, semestral ou anual, permitindo o estudo do sistema por diferentes perspectivas. Eu gostaria muito que me trouxessem dados provando que em desenvolvimento de produtos é sequer possível fechar a frequência do fenômeno, assim como dados que provem que dentro deste fechamento de frequencia, a entrada foi igual a saída. Está lançado o desafio.

Desprezar isso ao adaptar a Lei de Little é possível, como era possível desprezar o atrito com o solo e a resistência do ar nas equações durante o ensino médio. Acontece que, depois que entramos na faculdade, não fica mais tão simples desprezar atrito. Na vida real, desprezar o atrito pode ser fatal. Onde eu quero chegar? Não acho que desprezar o atrito "sistema em equilíbrio" possa ser tão catastrófico para a adaptação da Lei de Little aos sistemas complexos. O que eu acho perigoso é esquecermos desta adaptação e usarmos a lei como verdade absoluta nas nossas análises e decisões.

Como diz um grande amigo, realidade é briga de rua!

Além disso, para fechar e eu poder ir comprar a matéria prima do meu churrasco, a comunidade Kanban hoje está discutindo se realmente temos filas dentro de um sistema Kanban. O argumento principal é de que não temos disciplina de fila, portanto temos buffers. E aí eu pergunto:

É possível ter Little sem filas, apenas com buffers? Como Little se aplicaria a um sistema sem disciplina de fila?

Juro que eu acabei de pensar nisso, relacionando Little ao questionamento atual da comunidade Kanban. Em uma primeira análise, juntando o que eu sei de teoria das filas, lei de little e de comportamento de buffers, eu diria que a Lei de Little não faz mais o menor sentido. Novos fatos tendem a modificar a minha opinião e tenho certeza de que novos fatos surgiram depois deste despretensioso post.

E aí? Já pensou nisso? A área de comentários é toda sua!

A Little's Law, O Kanban e os Sistemas Complexos

Já venho discutindo e analisando esse assunto a pelo menos dois meses. Quando eu me detive um pouco mais para entender a Lei de Little percebi pelo menos duas coisas: é perigoso nos basearmos tanto em algo que foi provado por negação - não ser verificado nenhum caso onde a lei não se aplica; e sua adoção em sistemas complexos e, consequentemente, para justificar algumas práticas do Kanban, é questionável. Pelo menos eu estou questionando.

Transição - Não existem métodos porta de entrada

Tenho visto uma onda de pensamentos modernos sobre como iniciar uma transição ágil. Modernos se estivéssemos na década passada. Parece que voltou a "moda" de que o Scrum seria uma boa porta de entrada dos métodos ágeis nas empresas. Apesar de respeitar quem pense dessa forma, eu tenho as minhas dúvidas. Para esse post, chega de rapidinhas.

Os passos para uma transição ágil

Muito se fala sobre agilidade, principalmente desde o manifesto. As pessoas já vinham há uma década buscando formas diferentes de desenvolver software, como Scrum e a Extreme Programming. Mas em 2001, o conhecimento da época foi "verbalizado" pelo manifesto, na forma de 4 valores e 12 princípios.

Não, esse não é mais um texto sobre agilidade e seus princípios. Percebi que muito barulho foi feito em cima dessa nova forma de desenvolver software, muitas empresas nasceram ágeis, mas muito pouco foi falado sobre como realizar uma transição do modelo tradicional para o modelo ágil.

Especialistas não servem para transição

O Kanban parece estar se direcionando para outra estrada que considero perigosa: os níveis de maturidade/profundidade no sistema. O perigo nessa abordagem reside, na minha visão, na facilitação para o aparecimento do xiitismo, além de ter pouca eficiencia. Mas isso é assunto para outro dia.

É interessante termos especialistas, como sempre foi interessante em todas as áreas e em todos os tempos. O problema é que esse tipo de mindset simplesmente não serve para uma transição. Disso estou convencido.

Vamos inicialmente deixar claro quem estou chamando de generalistas, especialistas e o que é essa transição.

• Generalistas: Pessoas que conhecem diversos métodos/sistemas/processos/frameworks para desenvolvimento de software ágil, saindo do waterfall que teve a sua importância na sua época, mas que hoje é reconhecidamente ultrapassado e ineficiente;
• Especialistas: Pessoas que conhecem apenas um método/sistema/processo/framework para desenvolvimento de software ágil;
• Transição: Processo onde uma empresa quer mudar do waterfall para outra forma mais eficiente de desenvolvimento de softwares, comumente próximo do Lean.

Quando começo um trabalho de change agent em uma empresa, um dos maiores princípios da abordagem dos sistemas complexos, norteia as minhas ações: observar como o sistema se comporta para então sugerir mudanças. Esse "detalhe" é tão importante que pode significar o sucesso ou o fracasso de uma transição. Precisamos entender que o sistema está acostumado a se comportar daquela forma. As pessoas estão acostumadas a se comportarem daquela forma. Uma ruptura imediata, vai gerar stress no sistema. Uma transição já gera stress demasiado e não precisamos de change agents gerando mais stress. Na verdade, o papel dessa figura é justamente aliviar a tensão que toda a mudança naturalmente gera. 

O sistema é elástico, está sofrendo tensão e está ansioso para voltar ao seu estado inicial. Se tentarmos gerar uma ruptura logo de início, vamos obter como resposta uma resistência (natural) e a tendencia é de tudo voltar a ser como era antes. Entretanto, se tentarmos a abordagem do sapo fervido, temos uma chance muito maior de que a ruptura aconteça sem o sistema perceber. E o melhor: com as pessoas que antes eram resistentes, vendendo as novas idéias como se fossem delas.

Isso quer dizer que não precisamos mais de especialistas no mundo? Não, precisamos de especialistas. Mas especialistas não podem atuar como change agents. Os especialistas não terão independência suficiente das suas especialidades para se afastar do sistema (como nos afastamos de um desenho ou quadro) e buscar a melhor opção. Em uma transição, os generalistas chegam primeiro e os especialistas depois.

Entretanto, neste contexto, os generalistas precisam ser especialistas em uma área de atuação: o pensamento sistêmico e sua derivação, os sistemas complexos. Esse cara precisa saber como analisar o comportamento do sistema e que tipo de mudança será mais eficiente e gerará menos impacto. A consolidação dessas pequenas mudanças e, principalmente, os seus resultados, serão responsáveis por fortalecer o processo de transição e dará aos responsáveis estratégicos da empresa a percepção de que esse processo está indo no caminho certo.

Estou convencido que esse mindset contribui sobremaneira para a implantação dos princípios do Lean, com uma cadência adequada ao contexto, sem rupturas bruscas que poderiam levar uma grande empresa a falência.