Um breve comentário sobre o guia politicamente incorreto da agilidade
Olá!
Recentemente me deparei com esse material aqui e gostaria de compartilhar alguns insights que tive durante a leitura.
Peter Drucker, considerado o pai da administração moderna, em seu livro “The Effective Executive”, disse o seguinte (tradução minha):
Todo trabalhador do conhecimento na organização moderna é um “executivo” se, em virtude da sua posição ou conhecimento, for responsável por uma contribuição que afete materialmente a capacidade da organização de executar e obter resultados. (Pág 5)
A versão popular dessa citação é a seguinte:
Todo trabalhador do conhecimento é um gestor.
Ou seja, partindo dessa premissa, é possível extrapolar essa ideia aplicada ao mundo da agilidade: todo mundo é responsável, de uma forma ou de outra, por melhorar o processo em que está inserido. Portanto, como podemos fazer isso de forma que cause impactos reais?
Ao se analisar o trabalho exercido por pessoas desenvolvedoras, é possível afirmar o seguinte:
Seres humanos não conseguem pensar em duas coisas ao mesmo tempo.
Logo, não é possível de fato paralelizar o trabalho intelectual de uma pessoa de forma eficaz. Além disso, o trabalho de desenvolvimento para ser efetivo requer que alguém pense sobre aquilo a ser desenvolvido e estruture uma solução de fato para aquele problema, ao invés de somente sair fazendo, na base da tentativa e erro. Ao executar múltiplas tarefas ao mesmo tempo, ocorre uma ilusão de competência, mas tem muitos efeitos negativos ocultos.
O que nos leva ao segundo problema:
É impossível fazer um ser humano pensar mais rápido.
Só um parêntese: o material não menciona explicitamente LLMs (como o chatgpt) ou assistentes (como o github copilot) como auxiliares ao trabalho de desenvolvimento nessa etapa de “pensar mais rápido”. Embora eu tenha sentido um aumento na velocidade que eu consigo gerar código usando ferramentas dessa natureza, será que de fato, elas fizeram eu pensar mais rápido ao utilizá-las?
Somente material para você refletir, porque algumas vezes eu acho que sim, outras que não, ao usar esse tipo de ferramenta. Honestamente não tenho uma boa resposta para isso.
Quiçá, às vezes eu penso se deveríamos de fato tentar fazer isso ou se isso é apenas mais uma pressão do capitalismo por mais produtividade, sendo apenas mais um incentivo perverso sobre o trabalhador médio.
Mas, retomando o ponto do livro. Com base nesses dois “axiomas”, por assim dizer, como melhorar a produtividade de trabalhadores do conhecimento de uma forma que realmente funcione?
É agora que entra de fato as técnicas da agilidade no auxílio a tudo isso.
Nassim Nicholas Taleb, em seu livro Skin in the Game, disse algo mais ou menos assim:
Você jamais convencerá completamente uma pessoa de que ela está errada: somente a realidade é capaz disso.
Essas ideias são muito mais profundas do que parecem. Dado que gastar energia argumentando com as pessoas virtualmente para tentar fazê-las mudar de ideia é inútil (a prova está aqui), como podemos mostrar os problemas para as pessoas de uma forma que realmente funcione?
É aqui que entra um dos pilares da agilidade: gestão visual.
Por isso que existem cartões em quadros, marcação de bloqueios, separação por colunas indicando qual status o trabalho se encontra, visualização do acúmulo de filas e demais técnicas.
Somente com o uso desse tipo de técnica é que é possível “escancarar a realidade” na cara das pessoas. Sendo assim, mantenha sempre seu board atualizado, não negligencie a higiene desse tipo de ferramenta.
Um outro ponto que achei interessante é o Efeito Zeigarnik, que diz que costumamos lembrar mais de tarefas não completadas do que das completadas. Isso não é novo, inclusive. A ideia original é de um paper de 1927!
Em um time comum, o efeito se dá da seguinte forma:
A cada nova tarefa que se recebe, o estresse aumenta. A cada tarefa concluída, ele diminui.
O que você acha que acontece quando só iniciamos as tarefas sem um foco em terminá-las?
O óbvio: o estresse do time só aumenta descontroladamente.
Portanto, aqui vale a máxima do Rodrigo Yoshima (um dos escritores do guia): Se o seu negócio não é economicamente viável com o trabalho em progresso (WIP) sob controle, certamente ele também não é viável com o trabalho em progresso fora do controle.
Isto posto, controlar o WIP é, de certa forma, inegociável. Ou seja, não ceda a pressão de sair fazendo tudo na loucura só porque alguém disse que tinha que ser assim, você está fazendo mais mal do que bem ao agir dessa forma.
A busca pela previsibilidade em meio a essa dinâmica corporativa só é possível mediante a implementação de um sistema estável, onde o controle do WIP e a minimização de variações abruptas na demanda são priorizados (através de critérios claros para expedites, por exemplo). Somente assim se pode alcançar uma maior consistência e confiabilidade nos resultados obtidos.
Pois, não se consegue ser mais previsível buscando uma bola de cristal melhor, certo?
Para melhorar a previsibilidade, podemos usar a Lei de Little, uma ferramenta fundamental na análise de gargalos, que oferece uma equação simples, para entender a relação entre o trabalho em progresso (WIP), vazão (TH) e o tempo de espera (LT). Essa fórmula proporciona insights valiosos para otimizar o desempenho operacional e reduzir os tempos de resposta.
Usando a fórmula, temos:
Tempo de Espera = Trabalho em Progresso / Vazão
O insight é totalmente contra-intuitivo: quer ser mais produtivo? Controle o WIP de uma forma que o time trabalhe com menos interrupções, por exemplo. Com isso, a vazão aumenta e o tempo de espera diminui.
O motivo disso é que o gargalo sempre existe em qualquer sistema. Em times de desenvolvimento, geralmente, os ofensores são as filas de espera, que geralmente ocorrem em passagens de bastão entre áreas ou pessoas. Seja na espera por code review, testes ou deploy, só para citar os mais comuns.
No entanto, vale replicar essa citação do W. Edwards Deming mencionada no guia:
Apagar incêndios não é uma melhoria do processo. Nem a descoberta e remoção de uma causa especial detectada por um ponto fora de controle. Isso só coloca o processo de volta onde deveria ter estado desde o início.
Ou seja, se você não causar mudanças reais no método de trabalho, não vai adiantar nada. Vai ser um trabalho de Sísifo. Não é a toa que os gregos enxergavam isso como uma espécie de inferno.
Existem duas formas famosas de se fazer mudanças em processo (Kaizen, mais incremental) e o Kaikaku (mais abrupto e revolucionário). Ambos os termos foram popularizados pelo TPS.
Em linhas gerais, temos um comportamento parecido com esse:
Perceba que demora muito tempo para conseguir o mesmo patamar de capacidade usando métodos revolucionários (além de gerar um vale de desperdício considerável). Enquanto o método incremental é bem menos abrupto e efetivo no longo prazo.
Neste ponto, eu cito o guia integralmente:
Essa mudança abrupta, repentina e que abandona o passado é uma Revolução do Processo, ou, nos termos da Toyota (TPS), um Kaikaku — um tipo de mudança que ocorre apenas pela força ou por uma alucinação coletiva, que invariavelmente gera abusos psicológicos nas pessoas e que não respeita a condição humana. (Pág 105)
Se você já participou de alguma mudança de processo top-down, provavelmente já experienciou esse desgaste. A mudança “milagrosa” só acontece na cabeça do executivo que a impôs, geralmente, com um custo humano altísssimo.
Para gerar mudanças em direção a um processo melhor, vale ser estratégico, usando das mesmas técnicas discutidas até agora: o gargalo da transformação organizacional sempre será engajar as pessoas emocionalmente na mudança.
Por fim, a recomendação do livro de como fazer isso é relativamente simples: é necessário colocar estressores no sistema para sensibilizar os envolvidos sobre o problema (gestão visual e métricas), ter mecanismos de reflexão para avaliar o andamento da solução (controlar o wip, retrospectivas e similares) e por fim, injetar liderança.
Portanto, se você é gestor(a), a responsabilidade é sua também.
Espero que este texto seja útil para você de alguma forma.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
