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!

Custo de transação e custo de coordenação - Um exemplo simples

Vamos tratar aqui um exemplo simples para ilustrar o que é o custo de transação e custo de coordenação.

Existe um podcast que costumo usar para aprimoramento do meu inglês. Eles trabalhavam com um formato para o qual a minha rotina já estava ajustada: o episódio era liberado, semanalmente, com uma duração de cerca de 30m. Como eu estava com todos os episódios atrasados, eu os ouvia em sequência. Como sou adepto do transporte ativo e do transporte público, este formato estava encaixado na minha rotina de ida e volta do escritório. Entretanto, na série 3 deste podcast, eles mudaram o formato para cerca de 8 minutos por episódio.

Quais foram as consequências desta mudança:

Custo de transação

Como o aplicativo do podcast não passa automaticamente os episódios, eu precisei, agora de 8 em 8 minutos, pegar meu celular, desbloquea-lo, voltar do player do aplicativo para a lista das séries, baixar e tocar o próximo episódio, bloquear e guardar o celular. Parece pouco, mas eu precisei fazer este processo cerca de 4x a mais do que era feito antes. É chato. É muito chato. Numericamente, meu custo de transação para ouvir o podcast quadruplicou. Isso é muita coisa. Eu digo "pelo menos" porque ele não aumentou só pela quantidade de vezes a mais que eu preciso fazer as ações para mudar de episódio. Como o custo de transação deles é alto, esse aumento é exponencial.


O que é o custo de transação?

Pegar meu celular, desbloquea-lo, voltar do player do aplicativo para a lista das séries, baixar e tocar o próximo episódio, bloquear e guardar o celular. 

Então o custo de transação, neste exemplo dos podcasts, é o tempo e as atividades necessários para eu mudar de um episódio para outro.

Como diminuir este custo de transação? Seria só tocar automaticamente o próximo episódio da lista, até eu mandar parar. O iTunes faz isso. =)

Custo de coordenação

Além do custo de transação, o sistema do podcast tem um custo de coordenação alto. Este custo consiste na coordenação que preciso fazer, durante o tempo de transação, para eu não me perder na sequência dos episódios, eu preciso clicar no botão geral de edição, apagar o episódio e confirmar a exclusão. Esta ação faz com que o primeiro episódio baixado seja o próximo episódio a ouvir. Isso acontecia 4x menos, como vimos no custo de transação, no formato anterior.

O que é custo de coordenação?

clicar no botão geral de edição, apagar o episódio e confirmar a exclusão.

Então o custo de coordenação é todo custo usado para eu não me perder no sequenciamento dos meus podcasts, assim como a manutenção da bateria com carga suficiente para todo o meu trajeto, checklist para lembrar de levar o carregador (para a volta) e meu fone (para não incomodar as outras pessoas). Mas para esta análise, estamos considerando apenas o meu custo para eu não me perder no sequenciamento dos podcasts.

Como este custo poderia ser reduzido? Bastaria uma funcionalidade para marcar o episódio como "tocado" após o seu término. O iTunes faz isso. =)

Eu sei que você deve estar pensando: que aplicativo ruim você usa. Sim, já estou resolvendo isso, mas pelo menos serviu para este exemplo de mundo real de custos que vemos (quando vemos) muito em livros e palestras.

Conclusão

Aqui estamos analisando tamanho de lote. Um dos tamanhos do lote neste caso é o tamanho do episódio. Outro poderia ser o tamanho da minha fila de episódios para ouvir.

Muitos, até na gestão ágil, defendem o tamanho cada vez mais reduzido do lote para aumentar a fluidez do processo de trabalho. A princípio isso pode parecer uma certeza que todos devem buscar. Entretanto, como vimos, temos outros custos envolvidos nesta decisão: o custo de coordenação e o custo de transação.

Ahh Celso, então você está querendo me dizer que o tamanho de lote ideal para este sistema seriam episódios de 30 minutos? Não. Estou dizendo que com os custos atuais de transação e coordenação episódios maiores funcionam melhor que episódios menores. E como fazer para ter lotes menores, maior fluidez e melhor percepção de entrega? A Toyota já responde essa pergunta a mais de meio século: trabalhar para reduzir os custos de transação e coordenação. É este um dos papéis principais da gestão de fluxo. Nas subseções onde eu explico os dois custos, coloquei sugestões de como reduzir estes custos em um aplicativo de podcast. Ah é mais simples? Sim, ficou mais simples depois que eu esparramei os dados pelo post e o guiei para um pensamento e conclusão fora da caixa. O mesmo acontece dentro da sua empresa.

O problema é que a grande maioria das empresas não faz idéia do tamanho destes custos e tomam decisões completamente no escuro, com a convicção de que estão enxergando tudo, só porque vêem throughput e leadtime. Percebam que neste parágrafo abordamos apenas empresas que já estão no caminho da gestão moderna, que já estão a um passo de medir as coisas certas e de tomar decisões em cima de dados relevantes, de forma científica.

Outros, um pouco mais avançados, já tomam esta decisão em cima do custo de transação. Medem corretamente este custo e o levam para a mesa para discutir o tamanho dos lotes, repetindo isso frequentemente. E isso é lindo, pois permite aos decisores usar análise de dados relevantes e fatos para a tomada de decisão, como venho repetindo. Considero estas pessoas bem mais avançadas até que muita empresa ágil e de ótima cultura.

Entretanto, mesmo nestas empresas, o custo de coordenação pode ser negligenciado. Isso acontece por um problema de entendimento do que pode ser considerado custo de coordenação. No meu exemplo do podcast, meu custo de coordenação está embutido no custo de transação. Nem sempre isso acontece. E nem sempre esse custo é percebido.

O que você precisa fazer agora? Impossível adivinhar através de um post de blog. Medir, analisar e decidir sobre estas informações é algo muito sensível ao contexto. Não existe uma fórmula, diferente do já conhecido ciclo: observação, análise, experimentação, análise dos resultados, adaptação, observação...

Alguém reconhece esse ciclo em outro método, bem mais idoso?

Sim, está correto quem pensou no método científico.

O Custo Médio por Demanda

Há algumas semanas, coloquei em prática uma iniciativa que me martelava desde que li a primeira página do livro do Don Reinertsen - The Principles of Product Development Flow: Second Generation Lean Product Development - O Custo Médio Por Demanda.

O conceito em si é muito simples.

TL;DR: Defina o que você precisa medir de custo por semana (incluindo sempre o custo do time de desenvolvimento) e divida pela quantidade de demandas entregues naquela semana.

CMD = $ Semana / TH da Semana
$ Semana == Custo da Semana
TH da Semana == throughput == entregas na semana

Simples, hein?

Nos preparar para o estado em que calcular este valor se torna simples é onde reside a dificuldade. Outra dificuldade que costumo encontrar é mostrar às pessoas como usar essa ferramenta de forma eficiente.

Para chegarmos no estado em que essa fórmula será útil para a sua empresa, precisamos aprender e compreender a teoria dos sistemas, a teoria das restrições e, talvez o mais difícil, passar a olhar e metrificar as coisas certas, no momento certo. Infelizmente, no mundo corporativo de hoje, as pessoas teimam em dar maior foco a controle e a metrificar grandes batches, aka, requisitos funcionais. Vamos ver o que podemos fazer com relação a isso.

Don Reinertsen criou e evoluiu um excelente framework econômico no livro citado no início desse artigo. Ao nos presentear com essa obra ele nos diz: vamos parar de usar métricas proxy como pontos de alavancagem ou como justificativa para esses pontos de alavancagem no sistema. O que são métricas proxy? Lead time, cycle time e throughput. Métricas essas super valorizadas, de forma justa, pelo pessoal do Lean (faço parte "desse pessoal"). E pelo que pudemos observar no início deste post, que fala sobre uma métrica final, elas são muito importantes. A fórmula usa diretamente o throughput. O que está errado então no que as empresas Lean já fazem hoje? Parar no throughput.

E sobre as métricas da gestão 1.0? Não servem para nada aqui. Controle de horas e uma grande entrega em grandes lotes no final de grandes ciclos não nos ajudam em nada, não nos mostram pontos de alavancagem, não nos mostram oportunidades de otimização. Assim como o Gantt Chart, que também é inútil aqui. Chega no final do projeto, todos os gestores tradicionais ajoelham no milho com o cliente sobre os atrasos, sobre os bugs, sobre o que ficou para trás. Mandam um grande "UFA" depois dessa reunião e fazem uma festa para comemorar o "sucesso" do projeto. Isso geralmente dá certo, porque nesses casos, o cliente não está muito preocupado com o sucesso do produto, mas apenas em encontrar uma forma de mascarar os números e obter uma promoção ou aumento. E o ciclo vicioso recomeça no projeto seguinte.

Isso pode funcionar em grandes empresas, com diversas camadas de gestão, que pouco se importam com o resultado final. Empresas em que o grande objetivo é ser promovido e "crescer" na carreira. Mas isso é fatal para as empresas que precisam do resultado e que, principalmente, querem o resultado. Querem um produto de qualidade entregue, se possível antes do prazo. Querem estar dentro do processo e não apenas passar para frente e lavar as mãos. Empresas em que sua sobrevivência depende do produto e não onde o produto (ou números mascarados) servem apenas como alavanca pessoal. Se você está em uma empresa onde controle de horas, chicote e Gantt Chart são as ferramentas principais, definitivamente esse post e essa ferramenta não é para você. Peço desculpas por apenas agora ter dito isso. Um bom resto de dia para você.

Aos que ficaram, por que está errado parar no throughput? Por que medir lead time e throughput não é suficiente?

Agora é que a diversão começa.

Vamos começar pelo gráfico de uma das empresas onde eu já implantei o CMD.

Uma observação: Forjei essa ferramenta com o nome de Ticket Médio, fazendo um paralelo com a indústria do entretenimento, que foi de onde eu tirei a idéia. Apesar de dias depois tentar entrar com o nome mais compatível, Custo Médio por Demanda, o nome Ticket Médio já tinha pego com muita força e as minhas tentativas de mudar foram em vão. Então o mercado vai decidir esse nome. O conceito é mais importante, mas precisamos comunicar a ideia corretamente. Vamos decidir juntos se Ticket Medio é tão ruim assim. =)

Chega de bla bla bla.

Este gráfico mostra a variação do TM em uma das empresas onde foi implantado. A linha azul representa o TM por demanda. A linha vermelha é o TM por story points. O TM foi implantado na semana do dia 14/09. Como tínhamos os dados passados, fiz também um cálculo retroativo. Observem a forma errática das séries até a semana do dia 07. O gráfico acima é de um produto.

Nessa empresa, o impacto da visibilidade do nosso custo semanal foi imediato. Na apresentação da métrica, que ocorreu em uma quarta de uma semana com TH baixo, precisei explicar pouco as consequências de um alto TM. Isso criou um ponto de alavancagem de imediato e que se mostrou extremamente eficiente: o time passou a tomar melhores decisões no dia a dia. Aquele refactoring que no final vai agradar apenas ao desenvolvedor, passou a ficar para depois. Aquela tomada de decisão que levava dias, passou a ser realizada na dimensão de minutos. Agora, quando um desenvolvedor está a muito tempo em uma tarefa, com as ideias bloqueadas, ele quase imediatamente chama o time, em vez de esperar 1 ou 2 dias. Essa mudança de comportamento, nas decisões do dia a dia, no minuto a minuto, tiveram um impacto estrondoso na "quantidade de demandas entregues X dinheiro que está sendo investido". Muito mais que o ganho financeiro nos custos, teremos o nosso produto pronto muito mais rápido, reduzindo nosso custo de atraso e fazendo com que a empresa ganhe dinheiro mais rápido.

É possível perceber a teoria dos sistemas em seu estado mais puro aqui? Derivamos algumas fórmulas, falamos de custo e chegamos no lucro como objetivo principal. Como eu disse, nessa empresa não foi necessário discorrer por longos minutos sobre os impactos de um alto TM, e muito menos falamos algo parecido com: precisamos aumentar e estabilizar nosso throughput. Simplesmente aconteceu.

Outra característica que achei muito interessante nessa iniciativa foi que quase todos os números já estavam disponíveis. Os que não estavam, poderiam ser perguntados, como eu fiz para começar esse trabalho. Mas eles estavam invisíveis, portanto, eram inúteis.

Mas o que fazer quando a empresa não reage positivamente às primeiras explicações sobre as implicações financeiras das más decisões? Bem, nesse caso, precisamos nos aprofundar mais nos impactos.

Em outra empresa, outra iniciativa, outro contexto, o impacto não foi imediato. Tivemos uma semana de entrega ZERO e outra com o nível bem baixo. Como também sou pago para pensar problemas, depois de bastante reflexão, percebi que precisaria ir mais a fundo nos impactos. O time de desenvolvimento ainda não estava tomando boas decisões no dia a dia, no minuto a minuto. Desenvolvedores ainda estavam viajando em refactorings e generalização de soluções que não precisavam ser generalizadas. Ainda juntávamos grandes lotes em homologação, trocando transaction cost por holding cost. Ficou claro que a mensagem de fazer nossos clientes ganharem dinheiro rápido e fazer com que nós gastemos pouco não ficou clara. Isso não é demérito. Pessoas diferentes reagem de formas diferentes. Sistemas diferentes reagem de formas diferentes.

A solução imediata foi fazer uma reunião emergencial para nos aprofundar nos números. Vou pegar como exemplo o número de uma das semanas, onde o nosso TM bateu 2.500,00/demanda.

A reunião foi iniciada da seguinte forma: Pessoal, será que temos a noção do que significa 2.500,00/demanda? Vamos fazer uma conta rápida? Esse TM significa que custa para a empresa R$ 25.0000,00 para fazermos 10 demandas. Custa. Continuando, para o nosso comercial nos vender, ele vai precisar colocar 30% em cima destes números. O que nos faria custar R$ 32.500,00 para completar 10 demandas. O que conseguimos fazer com 10 demandas no nosso contexto? Vocês pagariam R$ 32.500,00 para uma empresa desenvolver 10 demandas? Todos disseram que daria para entregar pouca coisa com isso.

Infelizmente, como nosso fluxo de caixa era muito baixo, um dos impactos demonstrados seria iniciar um processo de demissão. Esse processo de demissão teria dois objetivos: a redução imediata do TM com o corte de custos do time e a oxigenação do mindset para o mindset financeiro.

O impacto foi imediato. Imediato!

Quais os resultados e as características que emergiram, que na verdade compõem a pedra fundamental dessa iniciativa?

1. Nas semanas seguintes, nosso TM baixou para a casa do 600.00 e não tivemos mais semanas zeradas. 
2. Passamos a ver pareamentos constantes (comprovando cientificamente o valor do pareamento);
3. Passamos a ter timeboxes bem definidos para as viagens de refactoring ou generalizações ou para as soluções de pedestal de praça pública; 
4. Aumentou o peer-pressure. As pessoas que já estavam dentro do mindset financeiro, ganharam uma ferramenta muito eficiente para realizarem auto-cobrança e cobrarem seus pares;
5. Ganhamos uma ferramenta eficiente de definição de metas. Definimos uma meta para o TM e acima dela estamos no vermelho e abaixo dela no verde. Não é incomum ouvir agora nessa empresa: quando estivermos no verde, faremos isso;
6. Ganhamos uma ferramenta de priorização: como implantamos o fluxo único - cinco projetos, um fluxo -, nós priorizávamos as demandas sem uma base sólida. Agora temos uma ferramenta financeira para definir essa priorização e ajudar na tomada de decisão do nosso Analista de Negócios.

Acho que não é pouca coisa. Acho que economizar dinheiro não é pouca coisa.

Voltando para a gestão 1.0, se fosse possível calcular o TM com grandes lotes, do que vai adiantar essa métrica a cada 6 meses? A cada 1 ano? Para o próximo projeto? Comparar dois projetos é como comparar banana com maçã. Ou pêra com maçã quando são parecidos. O importante é notar que ao comparar dois projetos, você nunca estará comparando maçã com maçã. Nunca.

O que é preciso?

• Medir o TH de forma prática, eficiente e estável;
• Para isso precisamos garantir a homogeneidade entre as demandas e que as coisas grandes sejam realmente excessões no fluxo;
• Se usa story points, meça o TM absoluto (por demanda) e o TM dos pontos. Coloque os dois no mesmo gráfico e acompanhe a evolução. Se a evolução das duas linhas estiver próxima, talvez seja um indício para remoção das story points. TM ajudando em uma tomada de decisão, mais uma vez de forma científica;
• Tenha os dados de cada semana como em uma fotografia semanal. Não perca os dados de outra semana. Não remova as informações pertinentes àquela semana. O motivo está nos dois próximos pontos;
• Mantenha estável a sua lógica para o cálculo do custo semanal até o fim do projeto. Isso quer dizer que se você considera só o salário dos desenvolvedores, mantenha assim até o final. Se você considera os custos completos (github, code climate, luz, água, telefone, gás...) faça assim até o final. Não vai fazer diferença para o propósito do TM se você considera essas dimensões ou não, porque o que importa é o fator comparativo entre as semanas. Se começou de um jeito, vá assim até o final;
• Considere sempre a variação no time. Em uma semana, entrou um novo dev em um dos times de uma das empresas (vago huh? =) ). Ele entrou na quinta, assim adicionei na planilha 2/5 do custo semanal dele. Na semana seguinte, o custo total semanal foi considerado.

E o propósito dessa ferramenta?

Ajudar as pessoas envolvidas em processo de desenvolvimento de software (ainda não sei se dá para portar para outras áreas) a tomar melhores decisões no dia a dia, da hora em que levanta a hora que vai se deitar. Uma consequência direta de melhores decisões, mais que entregar mais, é a estabilização do sistema. É impressionante como todas as decisões que emergiram dos desenvolvedores a partir da implantação fizeram o sistema caminhar para essa estabilização (vide o gráfico de exemplo). Isso eu pude perceber nas duas iniciativas usadas aqui como exemplo. Uma mais cedo e a outra um pouco mais tarde.

EDIT: Também emergiram decisões interessantes por toda a empresa, mas como possuem impactos de longo prazo, ainda estamos estudando os efeitos.

E estabilização traz previsibilidade.

Uma consequência inesperada foi o transporte do uso do TM para outras áreas de uma das empresas. Essa experiência se encontra ainda em estado embrionário e poderá ajudar na resposta se podemos ou não portar para outras áreas. Mas já adianto que parece que isso ajudou muito no comercial, fazendo as pessoas focarem nas vendas certas e reduzir a perda de dinheiro com clientes que não valiam a pena. Nada como a visibilidade do taxímetro. =)

Mas ainda existem dois propósitos secundários: Usar uma forma científica de encontrar pontos de alavancagem e extinguir o determinismo da gestão, a trazendo para o lado científico da coisa.

Celso, quando posso usar essa parada?

Assim que você achar necessário. Só deixe-me saber como está e como está evoluindo. Também pode gritar em caso de dúvidas. Estou estruturando consultoria em cima disso, então caso tenha interesse, me contacte também. Bora tornar o desenvolvimento de software no Brasil mais eficiente. Chega das rodas enferrujadas da engrenagem da gestão antiga.

Estarei no AgileBrazil na próxima semana e o meu propósito com esse post é fundamentar um monte de conversas que já estão marcadas para Porto de Galinhas. Se você estiver por lá, não deixe de me chamar para bater um papo. Vou adorar. =)

Essa é a primeira versão estruturada dessa ferramenta, portanto aceito feedbacks e debates. O que eu não vi? O que estou perdendo? Como podemos evoluir isso?

Há muito tempo, um grande amigo de olho puxado me disse: "Gestores dizendo que as coisas não fluem porque as pessoas não se esforçam é um diagnóstico simplista, preguiçoso e fora da realidade."

O nome desse amigo é Rodrigo Yoshima.

Essa frase está ultrapassando a barreira do tempo e continua muito válida hoje em dia.

Amplie suas capacidades de visão e de análise. Você não vai se arrepender e o sistema "Sua Empresa" colherá rapidamente os benefícios dessa mudança de mindset.

No exemplo que dei do TM alto, não era esforço que faltava, mas melhores decisões.

Saia do determinismo e entenda o seu sistema.

Existe vida no escopo fechado

e podemos ser ágeis....

Sim, depois de alguns anos atuando fortemente com o processo iterativo e incremental, com ciclos cada vez mais curtos e feedbacks cada vez mais contínuo, dentro de ambientes fortemente engessados, com processos certificados, percebi, na prática, que podemos sim ser ágeis com o escopo e prazo fechados. Talvez isso seja um dos golaços da inspeção e adaptação dos próprios métodos ágeis e das práticas encontradas nos milhares de contextos pelo mundo, que optou por processos mais enxutos, eliminio de desperdício, foco no valor e mapeamento de fluxo.

Os contextos que começaram uma mudança para o mindset Lean, perceberam que as práticas poderiam emergir do próprio contexto e direcionados, segundo os princípios e valores deste tipo de gestão. Com uma série de práticas identificadas, podemos avaliar o contexto e, pela nossa experiência, identificar rapidamente sugestões que possam melhorar aquele contexto particular. Continuamente, aplicando a inspeção e adaptação, identificamos e eliminamos práticas que não agregaram valor ou não serviu para reduzir os desperdícios, e inserimos novas, para mais um ciclo de avaliação de hipóteses.

Qualquer semelhança com o método científico, não é mera coincidência.

Mas como fazemos praticamente?

Quando mapeamos o fluxo e facilitamos a conversa do time de desenvolvimento com quem conhece do negócio, começamos a perceber algo muito interessante. A informação flui bidirecionalmente entre as duas partes e o aprendizado é aproveitado pelos dois.

Mas em que momento?

Bem, temos um documento bíblia de escopo com 250 páginas onde, Analistas de Negócio (AN) cascata, acham que conseguiram cumprir uma missão bem complicada e que durou longos 3 meses de muito trabalho, com muitas horas extras. Ao terminar, o AN acredita que gerou um artefato de muito valor e não "será mais incomodado" pelos desenvolvedores e pode ir feliz para mais 3 meses para escrever outra bíblia.

E o ciclo continua.

Quando rodamos este modelo sob a ótica da inspeção e adaptação contínuas, observando a teoria dos sistemas, olhando para o todo e com as atividades mapeadas, percebemos que a coisa não funciona desta forma.

Em equipes de alto índice de qualidade, com processos bem definidos que garantem esta qualidade, 99.9% dos bugs em homologação e produção, tem origem em um mal entendimento de uma regra, que poderia estar mal escrita. Quando analistas de negócios e desenvolvedores analisam este bug, a informação está tão envelhecida, que ambos levam dias e as vezes semanas para entender e resolver. Este processo só piora quando quem analisa e corrige são outras pessoas, o que acontece em quase todos os contextos tradicionais.

Só para evitar este desperdício, o trabalho do AN dedicado já se paga.

Não é só isso. Algo mais interessante acontecerá.

Quando sugerimos uma nova proposta, aumentando a disponibilidade do AN para o time durante o processo inteiro e, conseguimos um tempo diário do AN para realizar um breakdown do documento bíblia de escopo em épicos e histórias pequenas, autocontidas, testáveis..., não é raro o próprio AN encontrar problemas de entendimento e regras mal definidas por ele mesmo.

Não é incomum o AN afirmar que este breakdown e o mapeamento das histórias sobre a mesa, com post-its, absolutamente low tech, lhe deu uma visão que ele não conhecia até então. Neste momento, histórias são canceladas, outras aparecem, prioridades mudam. É impressionante ver o sistema ganhando vida.

Também é bastante normal percebermos este estado reflexivo do AN quando os desenvolvedores o chamam para tirar um dúvida complexa e crítica. Nestes casos, é muito comum esta reflexão ser promovida até em quem pediu aquela funcionalidade.

A causa raiz para estas historinhas é muito simples. Poderíamos chamar de grau de frescor da informação. Quanto mais fresca é a informação, mais qualidade ela tem. Como consequência temos uma alavancagem clara do processo de aprendizado e o desenvolvimento flui de uma maneira mais eficiente.

Não é o Scrum, XP, Lean, Kanban que resolvem o problema da sua corporação. O que vai resolver a maioria dos seus problemas são os ciclos curtos de inspeção e adaptação. Poderíamos chamar ciclos curtos de feedback e ação.

Neste contexto, o papel do AN é muito importante e requisitado. Visando acabar com os maiores desperdícios em um processo de desenvolvimento, não só paga a presença "full time" de um AN, como retorna lucros sobre a medida em um curto período de tempo.

O trabalho dele seria o detalhamento contínuo do backlog, fazendo de forma contínua, alimentando a entrada do fluxo, e a solução de dúvidas que possam (irão) aparecer no restante do time.

O resultado é um produto final com muito mais qualidade e, na grande maioria dos casos, mais barato e em menos tempo.

Acho que é fácil perceber o que acontecerá no mundo competitivo que vivemos....

As empresas que acordaram para este fato e estão se reinventando, olhando para dentro, entendendo os seus processos e os melhorando de forma contínua estarão anos luz a frente das empresas que ainda estarão dormindo e precisarão passar por todo processo de aprendizado.

Não acontece como uma virada de chave. Para a sua empresa deixar seus processos enxutos, exigirá um processo árduo de aprendizado e retroalimentação. Fundamental.

Isso não é verdade apenas no contexto de desenvolvimento de software. Já exemplifiquei como "leanizei" a minha criação de canários e temos estes princípios e valores aplicados nos líderes de todos os segmentos de mercado no mundo, tanto na indústria quanto na prestação de serviços.

Deixo abaixo, novamente, um vídeo da montagem final do Boeing 737, com as práticas fundamentadas na legenda.

https://www.youtube.com/watch?v=Ihtl-SZLU9o

Formação superior e certificações - O que mudou?

Hoje tive uma discussão interessante no facebook, onde participaram meus irmãos e alguns amigos. Revisitamos esse assunto e pude expor onde evoluímos, nesta necessidade que é essencial para termos um Brasil mais legal para se trabalhar.

Sinceramente, na área de certificações tivemos pouca mudança e eu continuo achando pouco relevantes. Passaram dois anos desde o lançamento do Accredited Kanban Training e a minha previsão não se concretizou. Realmente não sei se foi a forma do treinamento que não permitiu ou se de fato o mercado está despertando. Pelo menos a LKU assumiu o nome certificação. Estava ridículo.

Mas por que o mercado está despertando?

Talvez o mercado tenha percebido que a sopa de letras em um CV não quer dizer muita coisa. Quantas pessoas você conhece que vai sempre para um curso ou para a faculdade pesarosos? Como se estivessem fazendo algo por pura obrigação, apenas para aumentar o salário e ganhar status na empresa. São estas mesmas pessoas que odeiam a segunda-feira e amam a sexta-feira. Precisamos amar os dois dias, como todos os outros.

Seu dia de trabalho tem que ser um momento desejado, independente da sua função. Sempre encontramos propósito, nem que ele esteja "apenas" relacionado à nossa honra.

Se você odeia o seu trabalho ou o curso/faculdade, você está desperdiçando a sua vida em troca de um monte de papel no fim do mês.

Mas o problema não é apenas falta de paixão. A estrutura da maioria das certificações que temos é ruim. A avaliação de um CSM, na minha visão, deveria ser o cara atuar como SM de um time de verdade por uma semana ou mais. Mesma coisa para uma certificação Kanban, XP, Change Management, whatever. Em situações onde não existe a possibilidade de um contexto real, um contexto seria simulado - uma empresa cascata, por exemplo.

Nas faculdades e MBA parece que o cenário está mudando um pouco. Pelas informações que tenho, a academia começa a se preocupar um pouco em mostrar outras opções a este modelo ultrapassado de gestão de projetos e de produtos, principalmente de software.

É estranha essa demora de reação da academia a ideias como o Management 3.0 e ao Lean. As "ideias" do Appelo já estão aí há décadas, ele apenas fez uma compilação. Me digam onde "energizing people, empowering teams, aligning constraints, developing competence, growing structure, and improving everything" é novidade? A grande novidade foi envelopar tudo isso e usar a teoria da complexidade para tudo. O Sistema Toyota, surgiu logo depois da segunda guerra mundial e com o Japão se reinventando. Há quanto tempo Goldratt nos deu "The Goal"?

A academia precisa, pelo menos, falar sobre as alternativas e aprofundar no pensamento complexo e na teoria dos sistemas. Entender como um sistema se comporta e compreender que as relações entre as partes afetam mais este comportamento que as próprias partes em si.

Vejo estes assuntos como obrigação. Primeiro e segundo semestre e referências nos semestres posteriores, relacionando tudo.

Outro fator que me leva a estranhar bastante esta demora é o uso claro do método científico para avaliar hipóteses dentro de cada contexto específico e toda esta teoria estar fundamentada por números.

Este trabalho é todo baseado em princípios e valores. Não existe um manual de práticas escrito em pedra. Cada decisão é confrontada com os princípios e valores e cada transição toma uma forma própria, customizada para aquele contexto.

Isso quer dizer que devemos matar as faculdades e acabar com todos os cursos?

É óbvio que não. A ideia é que o processo de seleção das empresas sejam repensados. E os sinais indicam isso já começou.

A academia precisa também precisa se reinventar. Não adianta mais cuspir profissionais despreparados no mercado. Neste sentido, empresas boas que conheço, preferem ser coaches de um funcionário mais cru, sem os vícios que aparecem nas faculdades de TI e mostra-lo como adquirir conhecimento. Este funcionário tem que ter paixão. Este funcionário precisa amar a segunda da mesma forma como ama a sexta.

Poderíamos dizer que a faculdade poderia ser usada como um norte para pessoas que não conseguem estruturar um programa de estudos independente. Mas o problema novamente é o foco. Para este direcionamento, penso que os maiores eventos do mundo agregam mais valor. O networking é melhor e em bate papos descontraídos você encontra o seu direcionamento.

Normalmente, um livro bom puxa mais uma dezena de outros livros que valem a pena o estudo. Destes outros são puxados, e quando você notar, estará viciado e ciente do seu rumo.

E o PMI? Se eu fosse o PMI declararia a minha incompetência para ensinar a gerir projetos de software e pediria ajuda para também se reinventar neste sentido. Me parece que eles são bem competentes para definir e gerir outros tipos de projetos, como de navios.

Declaração:
Tudo que foi escrito aqui reflete apenas a minha visão sobre o assunto.
Não fui forçado a escrever isso. =P
Não existem verdades absolutas.

E quando o funcionário mente?

Em primeiro lugar, no topo deste texto, quero deixar claro que o sentido de funcionário é para toda a empresa, incluindo presidencia, diretoria e gerencia.

Sabemos que a mentira deriva de um ambiente onde a confiança está baixa ou sequer existe. Sabemos também que é uma característica existente no ser humano e até em outros animais. Nosso cérebro sente um certo prazer, pois ele é desafiado. Inclusive, seu cérebro mente para você várias vezes por dia.

Vamos refletir sobre agentes exteriores que contribuem para a propagação da mentira de uma corporação.

O primeiro agente, na minha visão, é a forma como é planejada e executada a distribuição de bônus. Da forma como é feita hoje em dia, (1) prejudica os relacionamentos internos; (2) prejudica a eficiencia da corporação, ao contrário do pensamento comum; (3) fomenta a competição nociva, em detrimento da colaboração; (4) favorece um ambiente fértil para a mentira. Existem outros.

O objetivo deste post é ser curto e não focar nestes quatro fatores que destaquei. Se surgir alguma dúvida sobre o parágrafo anterior, sinta-se a vontade para debatermos nos comentários.

Um segundo agente, já deixei uma pista, é o ambiente hostil à fomentação da confiança. Vários fatores contribuem para isso, (1) Cobranças públicas; (2) Prazos apertados; (3) Falta de visibilidade, dentre outros.

Mais uma vez, o foco não é esse. Deixo os comentários a disposição para um bate papo sobre isso.

A introdução foi longa por estarmos tratando de um assunto delicado. As pessoas não metem porque são más. Bem, algumas sim.

***

Uma máxima da gestão moderna é que você não melhora o que você não vê. Gestão moderna que está aí desde a decada de 70, pelo menos, com Demming, Ohno, Drucker e CIA.

Mas ver, de forma cristalina, todos os processos da sua empresa, detalhados em números, pode entrar em choque com uma necessidade de grande parte da empresa: mentir.

Sabemos como resolver o problema do ambiente nocivo à confiança, mas mais uma vez não é o foco aqui.

Como ver e mentir?

Através de números relativos. Ao relativizar você não mexe com um assunto delicado pré-existente. Lembre-se que o sistema é elástico. Ao introduzir um agente de mudanças, estamos gerando uma pressão interna. Precisamos de habilidade para lidar com essa propriedade elástica.

Boa parte da comunidade lean, sabe que a criação de um ambiente de confiança é fundamental para o aumento da eficiência. Entretanto, sabe que é muito importante medir. Se você não consegue introduzir mudanças, meça. Eu acredito muito nessa linha de pensamento.

Mas ao medir, você pode expor números e entrar em choque com muita gente. Se a sua empresa não está pronta para ver esses números, torne-os relativos.

Ex: Quando fizemos a mudança XPTO, reduzimos em X% a quantidade de bugs em produção. Reduzimos em Y% o leadtime médio. Z% das funcionalidades não retornaram para desenvolvimento. W% do nosso tempo agora é usado criando valor direto para o cliente.

É uma solução simples que pode salvar a aprovação de um trabalho que pode fazer toda a diferença para a saúde da empresa. Não apenas a saúde financeira, mas a saúde do organismo empresa.

E é uma abordagem natural para a maioria das empresas, que estão acostumadas a ver o seu retrato através das porcentagens.

Baseado nos processos de transição que eu vi acontecer, se eu tivesse que escolher uma ação indispensável, esta seria a metrificação. Metrificação de aspectos que ajudem a empresa a melhorar, evoluir. Alguns exemplos são o leadtime, throughput, takt time, touch time. Estes são números que, se melhorados, ajudarão a empresa a aumentar a eficiência. Ajudarão a empresa a poupar dinheiro.

Utilize métricas sempre, procure métricas do passado. Se o ambiente for hostil à metrificação, encontre uma forma de contornar e jogar com as resistências.

Afinal, essa não seria a maior qualidade de uma agente de transição?

Transição - E se não rolar?

Fishbowl durante o AgileTour em Maringá

Durante o fishbowl deste fim de semana, uma pessoa perguntou o que fazer quando a resistência está muito grande. O que fazer quando middle e top management começam a resistir ao norte da visão?

O primeiro ponto para refletir é que nada garante que a transição vai dar certo, mesmo lendo todos os livros do Kotter, Mary Lynn, Drucker, Demming e fazendo todos os cursos oferecidos pelo mercado. E o motivo para isso pode ser expressado na teoria da complexidade. A organização é um organismo vivo, que possui vontade própria, que pensa. Podemos prever algumas reações aos estímulos, mas a maioria é impossível. Nenhuma teoria e práticas anteriores podem garantir o sucesso de um processo de mudança organizacional.

O segundo ponto é que o senso de urgência pode estar baixo, a complacência pode ter se espalhado e o momento simplesmente não permite que você faça mais alguma coisa para tirar o projeto de mudança da inércia. E se o senso de urgência está baixo, pouca coisa poderá ser mudada. Existem alguns termômetros que devem ser utilizados para medir o senso de urgência.

Se você está conseguindo extinguir com facilidade pequenas picuinhas, problemas rasos, existe algum senso de urgência. Se não consegue, o senso de urgência é zero. Se consegue resolver com facilidade alguns problemas no nível gerencial, seu senso de urgência está elevado. Se não, o nível está baixo, mas ainda pode existir. Se você consegue resolver problemas envolvendo o top management e a empresa como um todo, o senso de urgência está elevadíssimo e se for mantido assim, existem grandes chances da transição fluir sem problemas até o fim.

Um exemplo deste último caso é a questão do bônus por meritocracia e a supervalorização das motivações extrínsecas. Se a transição estiver com senso de urgência suficiente na visão "se tornar a melhor empresa para se trabalhar no ramo que atuamos para assim atrair os melhores profissionais do mercado" a guiding coalition conseguirá mexer neste ponto tão delicado. Entretanto, se a visão estiver mal definida, mal comunicada ou nem existir, fica difícil elevar o senso de urgência. Sem senso de urgência, atividades lúdicas poderão ser vistas como palhaçada.

É difícil entrar neste assunto sem tentar analisar o que é falhar em um projeto de transição. Tecnicamente é não completar o projeto. Mas, filosoficamente, será que poderemos considerar uma falha, caso uma semente muito forte tenha sido plantada, que poderá germinar com força para completar o projeto um, dois anos depois?

Fica a reflexão.

Transição - Os efeitos sistêmicos

Muito tenho falado dos principais efeitos sistêmicos mas sem utilizar muito exemplos práticos. Isso acontece pois normalmente quando temos uma evidencia deste tipo de ocorrência, não seria ético divulgar. Entretanto nesta semana ocorreram, quase simultaneamente, dois exemplos que penso não ser anti-ético divulgar.

Transição - A cultura da liberdade

Todos os times, absolutamente todos, onde eu trabalhei a transição do modelo tradicional para o modelo ágil, se prenderam bastante na tal liberdade que os métodos ágeis prega para os trabalhadores do conhecimento. É comum você ouvir: não quero trabalhar neste work item, prefiro este. Estamos atrasados, mas isso não é problema meu.

[Vídeo] Pré Lançamento da Change Management Brasil

Criamos o vídeo de pré lançamento da Change Management Brasil. Assistam e, se gostarem, curtam e compartilhem. Estamos criando conteúdo de primeira e o próximo vídeo já está planejado.

Transição - Um exemplo de vitória de curto prazo

Bem, nesse caso considero de curtíssimo prazo.

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.

Transição - A importância da visão

Neste post examinaremos a importância de uma boa visão para a transição, para a gestão de mudanças. A definição de uma boa visão está diretamente relacionada ao foco da transição. Ela ajudará a manter as pessoas de olho no objetivo e auxilia ao mostrar como as pessoas vêem a organização após a transição. Como a empresa estará daqui a 5 anos? O que ela estará fazendo de diferente? Como chegaremos até lá? Neste post que escrevi no blog da Crafters abordei todos estes assuntos.

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.

Por que prefiro quadros físicos?

A pergunta é pertinente e me pego frequentemente explicando estes motivos. Então nada mais justo que surgir uma "curtinha" no blog. É óbvio que o quadro eletrônico tem suas vantagens, como facilidade para times distribuídos e geração automática de gráficos complicados, como um CFD, mas na minha experiência, sempre que possível, opte pelo físico. Por que?

1. Normalmente é mais barato. Até softwares gratuitos exigem um servidor, backup de dados, etc.;
2. Mais fácil de usar que um software, particularmente por pessoas menos técnicas e por aquelas que estão envolvidas esporadicamente;
3. Mais fácil de customizar. Escreva nele, adicione um post-it, adicione outros tipos de adesivos, etc. e pronto. A maioria dos pacotes de software são menos flexíveis ou necessitam de customização da empresa que fornece;
4. Mais visível. Um quadro em uma área comum é algo que as pessoas vêem todos os dias e o dia todo. Isso reforça as tarefas em andamento, comunica o processo e impressiona até quem está fora do time. Com isso, torna as dores mais visíveis e ajuda na argumentação para resolve-las. Age como um ponto focal - um campo de batalha do time, onde podem as pessoas podem se reunir e discutir possíveis problemas e riscos;
5. Um ponto menor, mas a maioria das pessoas gostam da satisfação do tato de mover o post-it de uma coluna para outra e da criatividade em desenhar figuras e símbolos para mostrar o status ou impedimentos, em vez de apenas olhar para colunas de texto;
6. Mesmo que optássemos por uma TV, para demonstrarmos toda as informações disponíveis em alguns quadros físicos, precisaríamos de pelo menos 4 TVs - uma para o fluxo principal, uma para o fluxo de issues da daily, uma para o fluxo das retrospectivas e uma para os gráficos.

Os quadros de vários projetos onde atuo como consultor são muito ricos e com a passagem destes quadros para o meio eletrônico perderíamos muita informação.

Bem, é isso. E você? Prefere o eletrônico? Por que?