Entre o meio e fim de 2022, participei de dois eventos relevantes que trouxeram novidades e tendências sobre desenvolvimento ágil e o futuro das organizações. Em Nashville, nos Estados Unidos, o Agile 2022 abordou principalmente tópicos como empatia e cultura organizacional. Já o Agile Brazil 2022 seguiu a mesma linha e priorizou pontos como organização, cultura e gestão. Em ambas senti que as questões técnicas relacionadas ao desenvolvimento de software tem sido cada vez mais deixadas de lado.

Mas por que isso aconteceu? Por que estamos deixando de falar de desenvolvimento de software para falar de gestão, especialmente de gestão humanizada? E quais são os impactos dessas mudanças?

Apesar de ter começado dentro do mercado de tecnologia, com o Manifesto Ágil, o conceito de agilidade já se expandiu para os diferentes setores e isso é uma realidade. Isso acontece porque a agilidade é capaz de auxiliar os desafios e demandas diárias, mirando em fazer as mudanças de táticas e estratégias serem mais rápidas, na velocidade que o mercado do mundo atual tem imposto. Consequentemente, empresas de diferentes indústrias e diferentes portes têm se atentado mais às vantagens proporcionadas pela agilidade, como dinamismo, maior produtividade e flexibilidade como facilitadores para a gestão de projetos e especialmente de produtos.

É uma questão cultural e não dá para “instalar”

Porém é necessário se atentar que agilidade é uma CULTURA. É algo que precisa estar enraizado na mentalidade das pessoas que trabalham na empresa e que estas entendam o que significa ‘ser ágil’. O não entendimento desse princípio e a busca por ‘atalhos’ para ‘se tornar ágil’ por parte de muitas empresas acarretou num grande avanço de frameworks e processos que trazem uma falsa promessa de um caminho mais curto para a agilidade. Devido a isso, acredito cada vez mais que é necessário termos uma volta ao básico.

Esse erro em focar nos grandes frameworks e consultorias buscando algo pronto para ser ágil mas sem entender a cultura de agilidade, fez com que empresas buscassem velocidade (diferente de agilidade) sem dar o embasamento necessário para tal. Isso acabou gerando ambientes de trabalho tóxicos com falta de segurança psicológica, o que os torna ambientes obviamente não preparados para serem ágeis. Tornar os locais psicologicamente seguros para as pessoas, é importante para que agilidade e inovação possam florescer. As pessoas precisam de um ambiente onde elas saibam que podem se arriscar para poder ter em suas entregas a mesma agilidade que o mercado impõe.

Na Agile Brazil, a impressão que ficou é que estamos cada vez mais falando de organizações, cultura e gestão (seja de produtos, seja de pessoas ou gestão 3.0) do que coisas mais técnicas. E quando falamos de Business Agility, ponto extremamente importante para empresas que buscam essa agilidade citada anteriormente, particularmente acredito que estamos aproveitando muito mal o assunto e não falando exatamente o que se espera dele, dando brecha para a dominância de frameworks que prometem escalar agilidade para as empresas, como SAFE e Agile @ Scale.

Tudo é software e agilidade é meio, não fim

Para fugir da cilada do “modelo Spotify” – modelo de squads, tribos e chapter adotado pela empresa que foi copiado indiscriminadamente por outras corporações como se isso fosse resolver todos os problemas, mesmo quando a Spotify falava para não se fazer isso – estamos cada vez mais discutindo design organizacional, voltando a discutir Lei de Conway (estruturas dos sistemas de software são reflexos das estruturas das organizações que os desenvolvem) e a se falar de Team Topologies, fractais e estágios de evolução organizacional de Laloux, entre outros. E apesar desses assuntos serem ótimos e de extrema relevância, a preocupação fica com o distanciamento de pessoas desenvolvedoras dos temas e das discussões em eventos que são voltados para essa área.

Vemos constantemente o crescimento de participação de pessoas focadas no nível de gestão, com cada vez mais cargos e papéis que foram inclusive criados para se alcançar essa agilidade, como Scrum Master, Agile Coach, Agile Chapter Leader, etc. Mas sem o envolvimento de pessoas desenvolvedoras e engenheiras nas conversas sobre agilidade, corre-se o risco de termos todas essas discussões encaradas como burocracia, justamente pelas pessoas responsáveis pelas entregas de software e que deveriam estar mais engajadas no processo.

Falar sobre gestão humanizada, ambientes psicologicamente seguros e sobre design organizacional e como isso afeta a entrega e qualidade dos softwares é algo extremamente importante para garantir a existência de agilidade. Porém, se não voltarmos ao básico, falando de cultura ágil e voltando a incluir as pessoas desenvolvedoras no processo, faremos com que a agilidade entre numa espécie de vórtex onde ela fala sobre ela mesma para se resolver, enquanto vemos os problemas das empresas acontecendo do lado de fora.