Outra base para a teoria contrária a relação Lei de Little x Limited WiP

Analisando os contextos onde estou inserido nos dias atuais e onde trabalhei no passado tentando a transição para o modelo ágil, falhando, tendo sucesso, me deparei com mais um fato que justifica a teoria de que a lei de Little não serve como embasamento para a relação WiP limitado X Lead Time. Já disse isso outras vezes, mas não custa repetir: Eu não tenho dúvidas que manter o WiP limitado e uma política rígida coibindo o estouro deste limite e fomentando a colaboração vai reduzir o seu lead time. Mas mais uma vez: não vejo lógica em usar uma equação matemática que foi provada por negação usada como base para essa verdade.



Percebam que até aqui ficou difícil manter o limite do WiP sozinho como "motivador" da redução do lead time. Mais uma vez, aqui aparece o que de fato pode ajudar na redução do lead time: uma política rígida para a manutenção deste limite. Fórmulas matemáticas são muito secas se formos pensar em termos de números. Para tentar provar este tipo de teoria matematicamente, você precisa de premissas muito fortes.

A tentativa de relacionar a lei de Little com a redução de work in progress aparece no livro do David quando ele diz que tem uma "relação de causalidade" para o que ele observou empiricamente. Então, empiricamente, temos que a redução da quantidade de trabalho em andamento, reduz a quantidade de tempo para alguma coisa ficar pronta. Este pensamento leva a outro (causalidade): se eu reduzir o meu WiP vou reduzir meu lead time. Mas devido a variabilidade, a ciência de gestão de projetos de software não é uma ciência exata. Vamos examinar os motivos.

O segredo é a colaboração

Como eu disse, hoje atuo em uma grande empresa de telefonia e já atuei por quase meia década em outra gigante do mesmo ramo. Estas empresas possuem um parque de sistemas na casa das centenas. Estas empresas, também, trabalham com um nível muito alto de especialistas, especialistas em CRM, billing, integração, engenharia, etc, especialistas estes que precisam de anos de formação. Outra característica bem interessante deste contexto é que os sistemas utilizados em telecom, normalmente só são utilizados em telecom.

Não adianta você ter WiP limitado se na sua empresa a colaboração não é fomentada. Certa vez, fui conversar com um desenvolvedor sobre a importância da colaboração. Em cinco minutos de conversa, percebi pelo menos três padrões de comportamento: comportamento tribal (1), receio da entrega (2) e receio do mercado (3).

Este desenvolvedor me disse o seguinte: Celso, se eu tiver alguém me ajudando, a necessidade do meu conhecimento vai diminuir (1), além disso, eu não quero ser cobrado por algo que eu não entreguei (1 e 2) e que não era a minha obrigação entregar (1) e, mesmo que eu concorde com você, esse novo conhecimento que vou adquirir só poderá ser usado aqui ou em outra telecom (3).

Adiantaria limitar o WiP com este mindset? E sem apoio da gerência? E com pressão da diretoria e da vice presidência para acabar com a ociosidade e entregar o projeto?

Então aqui, não adiantaria limitar o WiP. É preciso primeiro realizar um trabalho de mudança de cultura, fomentando a colaboração e convencendo as pessoas de que isso é bom, que fará diferença para a carreira delas. Já é uma máxima da gestão de mudanças dizer que as pessoas não tem resistência a mudanças, mas elas resistem a mudanças para as quais não associam crescimento e valor pessoal diretamente.

Aqui percebemos que a questão mais urgente não é limitar o WiP mas quebrar a cultura destes três padrões de comportamento. Aqui pressionamos o sistema para aumentar o senso de urgência para a colaboração. Se você limitar o WiP sem quebrar estes três padrões de comportamento, o lead time continuará alto.


E os problemas de infra?

Um ambiente virtualizado para realização de testes integrados para empresas de telecom custam algumas centenas de milhares de dólares. Não existem testes automatizados ainda. Colaboradores de QA que executam os testes são limitados e compartilhados entre vários projetos. Recursos de QA são limitados e compartilhados. Uma solução bem simples adotada pela maioria das empresas é a criação de janelas. A criação destas janelas, por si só, já quebra o fluxo contínuo e cria timeboxes naturais. A simples ideia de automatizar a execução de testes provoca uma reação grande na área de QA, quando eles pensam que a sua área perderá a importância perante à empresa (1). Líderes, coordenadores e gestores costumam reagir de forma muito mais forte que os analistas de teste. Mais uma vez, aqui o problema é a cultura e a solução, como era de se esperar, não é simples. Nesse caso, envolvemos diretamente três grandes áreas da empresa: financeiro, infra e QA. Como fazer? Uma solução direta e bem óbvia é adquirir mais servidores e manter uma equipe de gestão de configuração que manteria todos os servidores atualizados com todos os sistemas. Lembrem que estamos falando de ambientes integrados. Não sou radicalmente contra a esta solução, mas não acredito ser a melhor opção por alguns motivos. Uma delas é envolver uma enorme soma de dinheiro para infra e para as pessoas com skill de gestão de configuração, sem termos a certeza do retorno. Além do fator dinheiro, temos um aumento considerável da variabilidade do sistema, pois estamos introduzindo mais pessoas, além de merge de pacotes e tantos outros problemas de bastidores que esta solução traz.

Outra solução, indireta mas que envolve uma utilização menor de recursos, é a automatização do processo. Mexendo alguns pauzinhos podemos, enviar o código já com o merge para o repositório, onde terá um script que verificará outras alterações, rodará os testes unitários, os testes de sistema, integrados e de regressão e avisará sobre quaisquer problemas encontrados. Em ambientes mais maduros, se todos os testes passarem, um script pode gerar o pacote integrado e realizar o deploy em homologação ou em produção, dependendo da natureza do negócio. Percebam que reduzimos a concorrência nos ambientes integrados, reduzindo a quantidade de tempo que cada sistema depende destes ambientes. O processo manual que era executado em um mês, agora é executado em poucas horas (no caso de uma suite de testes muito complexa) ou em poucos minutos (no caso de uma suite de testes mais simples). Realizar uma mudança em sistemas com muitas partes interdependentes é mais difícil que realizar uma mudança em um sistema com muitas partes independentes. O que fizemos aqui foi uma adaptação sistêmica para reduzir a interdependência entre as partes do sistema. Modificando um dos nós da rede fazemos com que a nossa mudança impacte positivamente mais partes da rede (sistema).

Mais uma vez aqui o problema não é limitar o WiP, mas aumentar o senso de urgência para compra de mais servidores, montagem de uma equipe de gestão de configuração ou para a automatização de processos manuais, como geração de pacotes e execução de testes. Mais uma vez, sem a mudança de cultura, o limite de WiP será apenas mais um número no quadro.

Na última release de um dos projetos que acompanhei, ficamos com cerca de 100 work itens na coluna de "Aguardando Teste Integrado". Não tínhamos limite de WiP, mas tínhamos certeza de que tínhamos um problema. O senso de urgência estava alto. Aquilo incomodava. Entretanto, só foi possível resolver três meses depois. As pessoas foram realocadas, recursos foram realocados e a coluna continuou acumulando. Como dizer para o gerente desta equipe para deixar os desenvolvedores ociosos por três meses por que a coluna tinha atingido o limite? Você poderia parar o projeto (parando de puxar mais work itens para dentro do sistema) que o lead time médio continuaria alto, pois remover o gargalo dependia de um fator externo.


Conclusão

Limitar o WiP é um meio para atingir um objetivo maior. Não é simplesmente limitando o WiP que conseguiremos a redução do lead time. Conseguiremos a redução do lead time com a mudança da cultura das pessoas, fomentando a colaboração e aumentando o senso de urgência para problemas que estejam gerando o gargalo. É claro que entendo a proposta do Sistema Kanban, mas a relação direta entre WiP e lead time só existe onde a variabilidade é baixa ou em estruturas organizacionais onde seja possível resolver rapidamente os problemas que apontei acima. Isso quer dizer que no tipo de empresa que usei de exemplo a agilidade não é possível? Não. Isso quer dizer que não existe uma relação matemática entre WiP e lead time, principalmente a Lei de Little. Baixo WiP significa baixo lead time, sim concordo, mas depende. Na maioria dos casos observados, percebemos que a redução do lead time aconteceu quando reduzimos o limite do WiP, pois conseguimos fomentar a colaboração e sustentar o senso de urgência para problemas externos, com o apoio do middle e do top management. Aí sim. Fica muito mais fácil de acreditar na sentença anterior. E sinceramente, vocês acham que esta definição poderia se expressada em uma fórmula matemática? Eu acho que não.

A gestão de projetos de software é uma disciplina subjetiva, sujeita a altos índices de variabilidade e, consequentemente, a baixos índices de previsibilidade. Portanto, não é uma ciência exata e a maioria de suas várias dimensões não pode ser expressada através de uma fórmula matemática.

Além dos motivos que apresentei anteriormente, aqui estão outros que deixam claro, pelo menos para mim, que a Lei de Little não é base para "reduziu o WiP, reduziu o lead time".

Deixe-me saber o que você pensa.