Ágil, de volta às raízes

Durante todo o tempo em que eu estudei, debati e implantei métodos ágeis para áreas ou empresas de TI, sempre percebi um certo sofrimento que eu não conseguia definir exatamente de onde vinha. Algumas coisas eram óbvias demais para mim e ver que meus clientes ou alunos não conseguiam absorver certos conceitos me deixava angustiado.

O que eu pensava, e vejo muita gente justificando hoje é que isso é apenas “resistência a mudança”, e que “as pessoas deviam ser mais abertas a transformação”, que “a única certeza da vida é que tudo vai mudar” e coisas desse tipo. Eu particularmente acreditava que a mudança na forma de trabalho afetava profundamente a percepção das pessoas sobre seu próprio valor, e esse era o problema. Quando alguém tinha construído uma crença de que o seu valor, como profissional, estava ligado a uma determinada forma de trabalho, seria muito difícil convencer aquela pessoa a trabalhar de outra forma. Com o tempo, eu consegui ir juntando experiências e percebi que o problema não era algum tipo etéreo de resistência, mas sim o fato de que os princípios daquilo que comumente chamamos de Agilidade, Métodos Ágeis, ou algo assim, tinham como base um modelo mental que era fundamentalmente diferente do a maioria das pessoas estava acostumada, e isso tinha a ver com hierarquia, desnecessidade de autorresponsabilidade (juro que não vou dizer “senso de dono”) e um modo de produção intrinsecamente industrial.

Uma empresa que buscava aplicar, de alguma forma, Scrum, Extreme Programming ou qualquer abordagem que apareça debaixo do guarda-chuva dos métodos ágeis, fazia isso pois tinha alguns problemas bem específicos para resolver, ainda que quase sempre não tivesse clareza desses problemas. No entanto, o que acabava acontecendo era uma tentativa pegar uma receita de bolo e aplicar, quase que cegamente, ao seu contexto. Alguns métodos, como o Scrum por exemplo, eram bem adequados para isso, com um conjunto simples, ainda que aparentemente robusto, de regras e toda uma estrutura de cursos, certificações e consultores para fazer acontecer.

Esse sistema tinha um efeito rápido e muito visível, o que ajudava a vendê-lo cada vez mais. Após um treinamento as pessoas começavam a fazer reuniões de forma diferente, apareciam uns quadros esquisitos nas paredes e todo mundo ganhava títulos muito descolados como Scrum Master e Product Owner. Em alguns lugares até mesmo a hierarquia (olha ela aí) de Guerra nas Estrelas aparecia, com padawans, jedis e mestres jedis. Quem havia comprado a ideia da Agilidade podia rapidamente respirar aliviada, tendo a certeza de que seu investimento tinha sido um sucesso. Mas as mudanças paravam por aí e rapidamente regrediam.

O foco tornava-se seguir as cerimônias, papéis e outros artefatos do método e esperar que as coisas se resolvessem. Só que o tempo passava e nada se resolvia. Como a escolha era pelo caminho da execução, não havia uma preocupação com a adaptabilidade. O processo tornava-se rígido e sua execução, mecânica e industrial. A ideia fundamental era de que se o processo original, e considerado falho, fosse modificado para algo melhor, como Scrum, e executado rigidamente, os resultados apareceriam. Mas raramente isso acontecia.

Mas empresas de muito sucesso usavam Scrum, métodos ágeis, ágil escalado e coisas do gênero! Como isso podia estar errado? Mais um nó desse ciclo vicioso era esse, de que se o Google, que é o Google, usava métodos ágeis, você também deveria usar. Afinal, quem não quer ter o sucesso do Google, não é mesmo? O que ficava nos textos de rodapé é que ninguém sabia se Google, Yahoo e outras grandes empresas, tinham sucesso por usar métodos ágeis ou apesar de usá-los.

O ponto de falha que eu observava não eram os métodos ágeis, pelo menos não intrinsecamente. Vi muitos clientes que aferiram melhorias reais usando Scrum, SAFe e outros sabores de agilidade. Mas normalmente esses bons resultados estavam conectados a um fator comum: clareza de objetivos, problemas e contexto. Havia outros fatores que influenciavam, obviamente. Mas para o escopo deste texto, vou me ater a esse.

Quando olhamos para o Manifesto Ágil, seu contexto e os problemas que aquele grupo de engenheiros estava tentando resolver, tudo faz sentido. A complexidade dos sistemas de tecnologia estava (e continua) crescendo. Digo isso tanto em relação a complexidade ciclomática dos sistemas como a complexidade do ambiente de negócios em que esses sistemas de informação estavam inseridos. Por conta desse aumento de complexidade os métodos de gestão de projetos tradicionais herdados das outras engenharias, não davam conta.

Existem enormes diferenças entre um projeto de engenharia civil e um de engenharia de software. Ninguém muda um projeto de uma ponte para um túnel no meio da sua execução. Num projeto de engenharia civil é possível concentrar e dirimir as incertezas na parte inicial do projeto e depois concentrar os recursos apenas na execução. Em engenharia de software é razoavelmente comum começarmos com o projeto de uma ponte, mudar no meio para um túnel e descobrir, no final, que a necessidade do mercado era um prédio de apartamentos. Quem já trabalhou numa start-up sabe do que eu estou falando.

Os problemas que o Manifesto Ágil tenta resolver tem essa origem, e para isso seus princípios funcionam muito bem, se bem aplicados. E não precisamos de grandes métodos ou receitas de bolo, basta aplicar os princípios, num contexto conhecido. O contexto em que agilidade faz sentido é quando as necessidades mudam muito rapidamente, quando não se tem muita certeza dos requisitos envolvidos, quando o desenvolvimento precisa ser tanto um processo de aprendizagem quanto uma boa execução de planos. E é isso que costuma ser esquecido na primeira semana após os treinamentos.

Com isso, ao invés de acrescentar mais e mais camadas de conhecimento para conseguir explicar e aplicar métodos ágeis proponho o caminho inverso. Voltar ao básico. A começar pelo sentido do que é ser ágil, que não é ser, necessariamente, rápido. Ser ágil, no sentido mais básico da palavra, é conseguir mudar de direção rapidamente. Isso sim é útil num contexto de incerteza, onde estamos aprendendo enquanto fazemos, onde seguir um plano é menos importante do que perceber mudanças no contexto e reagir rapidamente a elas.

Uma sugestão prática seria observar em quais processos a sua organização precisa ser ágil e em quais ela não precisa. Assim evita-se corrigir problemas que não existem. Em quais processos as etapas e os itens de trabalho são mais estáveis, conhecidos, costumam ser muito parecidos? Esses são os processos nos quais não é necessária tanta agilidade, e talvez sejam processos onde uma simples gestão visual pode ajudar muito a encontrar gargalos e ter insights sobre melhorias.

Um aspecto muito difundido sobre métodos ágeis é a forma de fazer reuniões. Reuniões diárias, retrospectivas, dias de planejamento concentrado aparecerem rapidamente nas agendas de todo mundo, e tão rápido quanto aparecem, começam a ser ignorados ou ter seus propósitos sequestrados para outros fins. Novamente, a ideia é voltar às origens e entender o motivo que deu origem a esse conjunto de reuniões. As reuniões diárias foram pensadas como pausas de 15 minutos para manter a equipe alinhada e evitar várias reuniões e conversas ao longo do dia. Em uma conversa rápida e estruturada, todos podem entender o que estão fazendo, onde podem ajudar e quais são os principais desafios para o dia. O problema é que rapidamente essas reuniões transformam-se em status reports de 30, 40 60 minutos, com diferentes stakeholders e sem nenhuma estrutura.

Para combater esse desperdício, ao invés de seguir à risca o manual, tenha clareza das necessidades de comunicação da sua equipe e da sua organização. Quais assuntos precisam ser comunicados? Com que frequência? Quem deve ser envolvido para tomar decisões? Quem deve ser apenas comunicado? Qual a melhor estrutura para cada reunião? Com isso é possível criar um rol enxuto de reuniões estruturadas, que podem ser continuamente evoluídas, para as necessidades específicas da sua organização.

Outro desvio bastante comum é quanto ao uso de estimativas e previsibilidade. Não entender os princípios por trás de métodos como “planning poker” e estimativas “t-shirt size” faz com que se busque um alto grau de acerto nas estimativas ou se vilanize qualquer esforço de estimar datas para entregas. Cansei de ouvir “Vai ficar pronto quando acabarmos! No Ágil não existem estimativas” o que causa resistência imediata de pessoas que precisam coordenar entrega entre diferentes áreas da organização ou partes de um projeto. Não importa que método seja usado, estimar é necessário em qualquer projeto que envolva mais de uma pessoa.

Voltando aos princípios, entendemos que não há uma restrição contra estimativas, o que há é uma aceitação da realidade. Se não entendemos profundamente as nossas entregas, e todo o contexto que pode afetá-las, não é possível fazer estimativas precisas. Especialmente em cenários como o de desenvolvimento de software, onde o grau de similaridades entre as entregas é bem menor do que na indústria e o contexto dos requisitos pode mudar rapidamente.

Para superar esse tipo de desvio e voltar aos princípios da agilidade, entenda o contexto em que as suas entregas estão inseridas. Existem diferentes categorias que dentro de si guardam alguma similaridade entre as entregas? Quão parecidos esses itens de entrega são similares entre si? Existem dados históricos que possam ser usados para fundamentar as estimativas? Outros pontos que podem influenciar as entregas estão ligados às consequências de acertar ou não as estimativas. Por exemplo, se a equipe sabe que consegue entregar algo entre 5 e 10 dias com 80% de certeza, mas está inserida em uma cultura onde atrasos tem consequências para a carreira das pessoas e “datas firmes” precisam ser definidas, provavelmente vai passar uma estimativa de 12 ou 15 dias. Aliás, talvez a estimativa seja ainda mais conservadora se a equipe sabe que vai ter que que negociar para baixo o prazo.

Estimativas são um assunto extremamente sensível e complexo, com literalmente centenas de livros escritos, e a ideia aqui não é esgotar o tema, mas dar uma ideia de como voltar aos princípios fundamentais pode ajudar em qualquer aspecto de uma jornada para a Agilidade Organizacional.

Em 2003 foi descoberta uma nova categoria de vírus que desafiou as definições que conhecíamos até então. Vírus são tão simples que não existe um consenso no meio científico sobre se eles são seres vivos ou não. Um vírus como o famoso Sars-COV-2, tem cerca de 15 genes, envoltos em uma pequena cápsula protéica, e é isso. Uma célula humana pode ter 20.000 genes. Porém vírus dessa nova categoria podiam ter centenas ou até milhares de genes, incluindo alguns típicos de atividades de metabolismo celular que não fariam nenhum sentido em algo que não é um ser vivo.

Tudo isso para provar um ponto, de que a natureza está sempre um passo à frente das nossas definições. Quando a humanidade tenta classificar o ambiente e as criaturas ao seu redor, podemos cair no erro de pensar que tudo deve caber nas nossas classificações. Sempre haverá exceções que nos desafiam a mudar a forma como criamos nossos modelos. George Box disse, no século passado, que “todos os modelos estão errados, mas alguns são úteis”. Esse é o ponto de voltar às raízes da agilidade.

Não importa muito se a sua organização é ágil ou não. Pare de se preocupar com as definições e olhe para os princípios, aplicando-os ao seu contexto. Dá mais trabalho do que seguir uma receita de bolo, mas os resultados serão muito melhores e mais duradouros.