A prisão do Timebox – Por que um processo de decisão centralizado é nocivo
O Problema
Você deveria estar extremamente envergonhado caso esteja em uma reunião cheia, não sendo uma palestra ou treinamento, e vou explicar o porquê.
É muito comum encontrarmos fotos nas redes sociais de selfies de Agile Coaches, tendo uma multidão de pano de fundo, com um belo sorriso e acompanhado dos dizeres “iniciando mais uma release planning” ou “mais uma revisão de roadmap pronta, obrigado Deus”. Orgulho muito comum entre a nova geração de Agile Coaches, este fato deveria na verdade gerar vergonha, já que trata-se de um crime contra o tempo das pessoas envolvidas, contra o serviço envolvido e contra a eficiência financeira.
Isso não significa que você deve se livrar imediatamente das reuniões super populadas, mas que deve ter vergonha delas, pois são mamutes de ineficiência jogando no ralo e na lixeira recursos da empresa que deveriam estar sendo aplicados no seu aprimoramento, melhorando o posicionamento e reconhecimento da organização perante o mercado.
Esta cultura, muito disseminada pelo péssimo entendimento do que é de fato ser uma empresa horizontal, foi muito disseminada com a popularização do Scrum e de seus frameworks de escala que tentam resolver os problemas que o próprio Scrum cria. Aqui podemos perceber um contra-senso, já que em um ambiente onde a auto organização é pregada, estas soluções aumentam o custo de coordenação criando restrições – como data, hora, local, pauta – prejudicando assim a emergência, propriedade fundamental que faz de fato um sistema complexo se organizar.
Os defensores deste modelo tentam justificar com o velho conhecido escudo do “contexto”, repetindo o mantra que “na empresa deles é diferente”. Parte disso é fato e parte é ficção, pois existem princípios universais, principalmente no estudo da complexidade, que são transversais a qualquer contexto, da biologia à economia.
O ponto aqui é que não podemos chamar de auto organização de um sistema complexo uma reunião com hora e locais marcados, apenas mudando o nome do condutor para “facilitador”. Longe de fomentar a auto organização, este mindset acorrenta a complexidade dificultando o maravilhoso fenômeno da emergência.
Ao tentar lidar com isso, frameworks de escala populares como o SAFe, criam mais amarras da mesma natureza, tentando desesperadamente reduzir o tamanho do lote crescente em estruturas ferroviárias, em detrimento da liberdade tão requerida aos sistemas complexos. Matam a emergência.
Já me vi em diversas situações onde precisava “facilitar” uma reunião com 10, 20, 30 ou mais pessoas, com microfone e palco. Pode soar absurdo aqui e agora, mas acredite, dentro de alguns projetos gigantes, em empresas gigantes, tentando seguir os passos da agilidade, parecia “fazer bastante sentido”.
Mas definitivamente não fazia, e nunca fará. Não é esse o jeito de resolver as coisas.
Mas eu tinha vergonha. Eu tinha vergonha da quantidade de dinheiro investido para resultados tão baixos. Poucos envolvidos saem com alguma ação concreta, poucos envolvidos ajudam no processo decisório.
Se você soltar a coleira do timebox, deixando o sistema se organizar em seu ambiente natural, colherá os frutos dos resultados que aparecerão do tempo sobrando no dia útil das pessoas.
A Solução
O fato de me sentir envergonhado me levou a algumas ações na direção de tentar resolver o problema da efetividade das reuniões, tais como medir o custo da reunião e esboços de novas estruturas de governança, que permitissem a maximização do resultado com menos investimento.
Uma Estrutura Fractal
A governança do portfólio sugerida aqui está assentada sobre uma estrutura fractal, isto é, em cada nível de visão e análise olhamos apenas para o que é importante para decidir naquele nível. Esta organização nos permite acessar rapidamente as informações necessárias naquele momento, naquela tomada de decisão, agilizando todo o processo. Cada nível possui um histórico bem definido e organizado dos dados medidos, facilitando o retorno, sempre que necessário para análise, à algum estado do passado.
A solução sugerida está baseada em canais de distribuição de informações e decisões. Com isso tentamos organizar o processo decisório, fazendo com que apenas um pequeno e bem selecionado grupo esteja com o seu tempo dedicado ao que está sendo discutido.
A imagem abaixo usa as cadências do Kanban e os níveis de vôo do Klaus Leopold para mostrar como organizar a governança mirando a efetividade das reuniões.
Este modelo não vai contra qualquer horizontalização e democracia das empresas com ideias mais modernas, pois estimulamos que representantes de todos os níveis estejam presentes em todas as cadências, com exceção da alta gestão, que deve estar com a sua visão concentrada no alto nível, nos direcionamentos estratégicos. Este modelo acredita que um bom c-level só entra no detalhe em casos muito específicos, confiando que o sistema está fazendo o seu melhor em todos os níveis.
Aqui pegamos o gancho para a palavra chave deste modelo: confiança. Por acreditar que as decisões serão tomadas sem a necessidade de um “facilitador”, este modelo tende a reduzir o custo e maximizar o resultado de reuniões, cerimônias e revisões.
Tenha somente quem é necessário para tomar a decisão e para propagar as informações, mantenha os canais de informações desobstruídos, faça com as políticas e narrativas mantenha a cola de tudo.
É importantíssimo notar que todos os canais de comunicação são de “mão dupla” e qualquer decisão tomada em qualquer nível pode ser desafiada por qualquer um. Este desafio a uma decisão ou ideia pode gerar uma reunião, que também contará apenas com as pessoas necessárias.
Os defensores das “big rooms” podem alegar que aí reside a necessidade deste tipo de reunião, pois se quem desafiou a ideia estivesse na reunião original a empresa teria economizado um encontro. Isso seria verdade, se não fossem dois pontos principais: a baixa frequência com que isso acontece; e não termos a menor garantia de que essa pessoa teria a mesma idéia de forma síncrona, dentro da reunião, sem o tempo que ela teve para pensar no assunto.
Temos aqui a grande inteligência deste modelo, pois usa as reuniões para o que elas devem ser usadas, isto é, para refinar ideias e possibilidades, disparando os resultados para a empresa como um todo, que pode trabalhar assincronamente nos pontos e sugerir melhorias e evolução destes resultados, criando de fato uma organização que aprende. Os colaboradores não precisam estar sob a batuta de facilitadores e timeboxes para decidir, aprender e evoluir. Este é um dos motivos que me faz considerar o SAFe um peso desnecessário.
Este modelo está fundamentado na ideia de descentralização do Don Reinertsen, no livro Flow:
In contrast, many companies compartmentalize information, insisting that important information be closely held. This approach is dangerous because it undermines the ability of decentralized actors to support the overall mission. If the locus of control is decentralized, then decision-making information must be available at the decision-making point.
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development (pp. 260-261). Celeritas Publishing. Kindle Edition.
O livro possui um capítulo inteiro sobre os benefícios econômicos da descentralização e sugerimos fortemente a leitura.
Veremos agora uma lista de algumas reuniões que consideramos ineficientes e a forma de otimizar custo e resultados:
- Release planning
Na visão deste modelo, esta reunião deve ser realizada pelo analista de negócios, o gestor de fluxo, cliente (caso possível) e um ou dois representantes do time. Na Taller substituímos esta cerimônia pela “revisão do roadmap do produto”. Os resultados desta reunião são distribuídos na revisão da operação.
Sugerimos fortemente a participação do cliente aqui, mas sabemos que em muitos contextos isso não é possível, infelizmente. Entretanto, a ausência do cliente não é motivo para que esta revisão não aconteça, pois ela é importante para o cliente e para quem está trabalhando a governança.
- Sprint planning e backlog grooming
Na Taller acreditamos no just in time e as demandas são refinadas e planejadas ao longo de um processo de upstream bem definido. Aqui novamente o problema é o lote. Envolvem várias pessoas com demandas que não sabem se serão feitas naquele momento, envolvem desenvolvedores em demandas que não serão executadas por eles.
Envolver todo o time nestas cerimônias e refinamento é um crime.
Os defensores deste crime argumentam que sem o envolvimento do time nestas cerimônias corremos o risco de perder a visão do todo. Bullshit. Mais uma vez o problema aqui é confiança, pois simplesmente não acreditam que o time seja capaz de alcançar a visão do todo sem um messias facilitador.
Aqui acreditamos que o time se fala, seja durante o dia, seja na daily, seja no café, seja pelo quadro. Na operations review, em formato de apresentação, discutimos a visão do todo, quando se faz necessário.
Com este modelo refinamos a demanda conforme caminhamos no cone da incerteza até o ponto em que ela está preparada para o ponto de comprometimento. Incentivamos nossos desenvolvedores a evoluir habilidades de análise de negócio, análise do problema e design de soluções e frequentemente eles são incentivados a participar do upstream, mas perceba que a diferença principal está em não ser uma reunião/cerimônia obrigatória para todo o time, em hora e local pré-determinados. É simplesmente fluxo, e fluxo facilita o entendimento e colaboração.
Assim, ao puxar a história, o desenvolvedor faz uma micro planning em cima daquela demanda onde iniciará o trabalho, olhando os critérios de aceite e a definição. Tira ali qualquer dúvida que apareça. Note que a certeza de que essa demanda será executada, neste momento, é a mais alta possível. Não é simplesmente alta, mas a mais alta possível, porque o desenvolvedor está puxando a demanda para fazer.
Com estas pequenas mudanças visando a descentralização economizamos milhares de reais por mês, evitando jogar no lixo o precioso tempo de força de trabalho valiosa.
- Planning e grooming para estimativa de entrega
Se o ponto anterior já era um crime, esse aqui é um crime passível de pena de morte.
Além de todos os problemas apontados anteriormente, aqui ainda temos o agravante de parar o time inteiro, muitas vezes por vários dias, para refinar e estimar (por esforço de desenvolvimento) um backlog inteiro para responder uma data para o diretor ou para o cliente.
As pessoas se reúnem por dias, quebram em tasks (na ilusão de aumento da certeza), estimam esforço de desenvolvimento, consultam a sua velocidade e aparecem com a data mágica. Refinam e estimam demandas com um alto grau de incerteza de negócio e técnica.
O primeiro erro aqui é estimar a fase desenvolvimento (pior ainda quebrando em tasks) e usar essa estimativa para projetar o comportamento de um fluxo. Perceba que uma estimativa de uma fase do fluxo é usada como estimativa do projeto. As filas são ignoradas, os feedbacks são ignorados.
O segundo erro está em, mais uma vez, parar a sua força produtiva para fazer algo inútil que a matemática de fluxo, em poucos minutos, pode te fornecer com muito menos esforço e maior precisão, pois considera todo o sistema de trabalho e não apenas uma pequena porção dele.
Um dos pontos positivos do uso da matemática do fluxo para projeções e acompanhamento está no uso de um método científico (repetível) que pode ter sua variância acompanhada, semanalmente. Opções de ação podem ser imediatamente testadas em um modelo, pois só precisamos de uma pessoa rodando uma simulação em alguns minutos.
Projetando e avaliando melhor o resultado das opções, seremos mais assertivos nas decisões.
Um ponto negativo é a ausência de dados em início de projeto, produto ou até de empresa. Ainda assim aconselhamos que use dados do passado, de outros projetos, de outros produtos similares, de tecnologias similares que ainda sim serão bem mais precisos que um chute de esforço de desenvolvimento.
Se não possuir nada disso, tente os chutes dos desenvolvedores, mas tenha em mente que o comportamento das filas são difíceis de estimar e que você estará no pior nível do cone da incerteza, isto é, incerteza máxima.
As idéias deste modelo já foram aplicadas, separadamente ou em conjunto, no auxílio na reestruturação da governança de empresas pequenas, médias e grandes, do setor privado ou governo. Seus princípios são independentes de contexto.
Estamos preparando um livro que contará em detalhes este modelo de governança que visa maximizar os resultados e minimizar os custos. Fique ligado nas nossas redes e se inscreva na nossa newsletter!
Para receber, basta deixar seu nome e e-mail nos campos abaixo:
