10 mentiras que os CIOs contam a si mesmos sobre suas práticas agile

A maioria das organizações agora usa modelos de entrega agile de software, com o objetivo número 1 de entregar novos recursos o mais rápido possível.

Considere os números: o 14º relatório anual State of Agile, lançado em maio de 2020 pela Digital.ai, descobriu que 95% dos entrevistados dizem que suas organizações praticam o agile e que os principais motivos para isso são acelerar a entrega de software, para melhorar a capacidade de gerenciar prioridades em mudança e aumentar a produtividade.

Apesar de tais objetivos ambiciosos, no entanto, especialistas em agile e praticantes de agile dizem que muitas organizações não estão atingindo a velocidade que procuram porque fecharam os olhos para problemas persistentes em suas práticas.

“Todo mundo diz que está agindo com agilidade, mas muitos não estão ou não estão fazendo tanto ou tão bem quanto desejam”, diz Dave West, CEO da Scrum.org.

Então, onde as organizações estão fracassando sem perceber? Aqui estão 10 auto-ilusões comuns que ainda retardam a entrega de software.

Somos agile porque usamos os termos

West viu equipes de TI adotarem a nomenclatura de metodologias agiles, renomeando gerentes de projeto como Scrum masters e chamando grupos de trabalho de squads. Usar os termos certos pode ser importante, mas muitas vezes é apenas uma mudança superficial. Essas medidas devem ser apoiadas por um trabalho mais substancial de reestruturação da organização, de modo que o trabalho que está sendo feito corresponda aos novos títulos distribuídos.

“Muitas vezes as pessoas estão fazendo a mesma coisa, apenas chamando de uma coisa diferente. Eles podem ter mudado os nomes, mas não os elementos. E a maioria das pessoas apenas afirma isso da boca para fora”, diz West.

Christine Hales, vice-Presidente de Tecnologia da Capital One, concorda.

“Esta é realmente uma mudança cultural. Se você abordar isso como um monte de processos e ferramentas, você está perdendo o que é realmente possível”, diz Hales. “As pessoas precisam trabalhar de forma diferente como equipes; isso é uma transformação cultural”.

Os tecnólogos não precisam de treinamento em ferramentas e mudanças de processo

A instituição financeira alemã DZ Bank trouxe uma gama de tecnologias ao longo dos anos para apoiar suas práticas de DevOps de longa data, mas Henning Ehm, Chefe de DevOps no banco com sede em Frankfurt, Alemanha, descobriu que a adoção de tais ferramentas foi atingida ou perdida.

“Eu estava pensando: ‘Estou fazendo algo de bom para ajudar as pessoas, vou construir a tecnologia e eles vão usá-la de maneira adequada’. Mas o que vimos foram muitos casos de resistência”, diz ele.

Não é incomum que os líderes de TI presumam que seus próprios tecnólogos se apoderarão automaticamente das ferramentas mais recentes e aumentarão rapidamente o uso delas. Mas, como Ehm aprendeu, os tecnólogos precisam de treinamento e também se beneficiam das estratégias de gerenciamento de mudanças.

“As pessoas da engenharia gostam de brincar, mas tirar o verdadeiro potencial das ferramentas e introduzi-las em nossos processos é um trabalho árduo. Você precisa se esforçar muito no processo de mudança”, diz Ehm. “Agora me concentro mais nas pessoas e em como levá-las aonde usem a tecnologia em [todo o seu potencial]”.

As equipes manterão as reuniões breves

As práticas ágeis abandonam as longas reuniões formais em favor de breves encontros e outros compromissos, mas é difícil perder os velhos hábitos. Por exemplo, Ehm diz que viu reuniões Scrum que deveriam durar 15 minutos e duram três vezes mais tempo, com os participantes usando o tempo para abordar todos os tipos de preocupações e tópicos.

“As reuniões devem ter um propósito muito específico, e muitas pessoas não estão acostumadas com isso”, diz ele, citando a necessidade dos gerentes educarem as equipes sobre como as reuniões devem funcionar ao adotar o agile, bem como a necessidade dos gerentes para fazer cumprir os limites de tempo e tópicos.

“Agora discutimos uma coisa e apenas essa coisa em nossas reuniões”, diz Ehm.

A liberdade de escolher ferramentas e processos sempre permite velocidade

Embora as práticas modernas incentivem as equipes a escolher maneiras que funcionem para elas, Amit R Bhandarkar, Diretor de Engenharia da American Express Global Business Travel, viu o lado negativo dessa abordagem.

Ele diz que suas equipes acabaram com diferentes ferramentas de CI/CD, algumas usando soluções de código aberto e outras usando ofertas de vários fornecedores. “Eles estavam alcançando o mesmo resultado, mas de maneiras diferentes, e isso estava afetando a agilidade; algumas equipes estavam batendo forte, outras estavam lutando”, diz Bhandarkar.

Em resposta, as equipes de desenvolvimento padronizaram, mudando para um ambiente único e consistente que oferece suporte a taxas de sucesso mais uniformes e também reduz a carga de manutenção dos desenvolvedores.

Bhandarkar acredita que há uma lição nisso. “Você deve ser prescritivo em sua abordagem em todos os lugares onde houver opções; seja a metodologia específica que você deseja ou a duração de seus sprints, você deseja ser prescritivo e consistente para que todos estejam em sincronia uns com os outros”, diz ele.

Minhas equipes são flexíveis o suficiente

Steve Berez, Sócio da Bain & Co. e co-Autor de “Doing Agile Right”, certa vez trabalhou com uma companhia aérea que precisava de seus engenheiros para criar novos recursos para suas operações de voo, ao mesmo tempo em que precisava de menos trabalho nos sistemas do cliente; mas o número de engenheiros capazes de trabalhar nas operações de voo era limitado, tornando o departamento de TI menos responsivo às mudanças nas necessidades de negócios.

É um problema comum, diz Berez, acrescentando que “engenheiros não são fungíveis o suficiente”.

Ele diz que os CIOs podem resolver esse problema aumentando o uso de tecnologias comuns em diferentes partes da empresa, juntamente com um maior treinamento cruzado de seu pessoal para que os funcionários possam trabalhar em várias tecnologias.

“O que geralmente significa é fazer um novo desenvolvimento usando microsserviços e usando a mesma linguagem de desenvolvimento para esses microsserviços, mesmo nas diferentes áreas funcionais”, explica ele.

Essa regra não se aplica a nós

Como todas as metodologias, os frameworks ágeis defendem o uso de uma lista de melhores práticas.

Mas West viu muitas organizações dispensar a necessidade de seguir alguns processos prescritos, vendo-se como isentos – apenas para depois se perguntar por que não estão vendo tantos benefícios do agile quanto previam.

Ele viu, por exemplo, que as organizações excluem um grupo de negócios específico – como o marketing – das equipes ágeis, raciocinando que em sua empresa isso simplesmente não funcionará porque seus processos são muito únicos quando na realidade é apenas uma batalha territorial que ninguém quer lutar.

“O ‘eu sou especial’ é uma ótima desculpa para ‘eu não posso consertar isso’”, diz ele.

West continua: “Todo mundo é único, mas a realidade é que são e não são. É verdade que cada situação é única e que um modelo não se aplica a tudo e a todas as situações, mas os princípios subjacentes sim. Então, se você vai quebrar [um princípio agile], você precisa ser explícito sobre por que está fazendo isso e entender as consequências de fazer isso”.

Mudança de processo é suficiente

“No momento, há tanto foco em métodos agiles e cerimônia que todos ignoram a estrutura”, diz Prashant Kelker, Sócio da ISG, uma empresa de consultoria e pesquisa em tecnologia.

Ele diz que os defensores do agile dentro da empresa também precisam considerar como eles reestruturam seus departamentos e seus produtos, determinando, por exemplo, se tais elementos estão centrados em clientes ou processos.

É uma área difícil de resolver, Kelker admite. “Uma vez que você começa a falar de estrutura, então você se concentra em egos, cargos, carreiras das pessoas e avanço na carreira”, diz ele, mas enfatiza a necessidade de abordar a estrutura, no entanto.

Nosso processo de orçamento não nos atrasa

Embora a maioria das organizações tenha adotado metodologias agiles, os especialistas em gerenciamento dizem que muitos deles não reconhecem a necessidade de atualizar as práticas orçamentárias de longa data.

“O que vemos em muitas organizações é que demora muito para iniciar o processo de busca de uma nova oportunidade de negócio. E leva muito tempo para parar de trabalhar em algo quando o valor que eles [anteciparam] acaba não existindo”, diz Berez. “Isso geralmente ocorre porque muitas organizações ainda financiam projetos anualmente”.

Berez diz que as organizações ágeis mais bem-sucedidas mudaram de decidir quais iniciativas financiar anualmente para um processo de orçamento que distribui quantias menores com mais frequência conforme o trabalho avança e prova seu valor – um processo semelhante ao financiamento de capital de risco. Outros usam um processo em que proprietários de produtos com poderes usam fundos estendidos por um período de tempo para entregar resultados de negócios específicos.

Essas abordagens de orçamento, diz Berez, “criam mais flexibilidade e agilidade”.

Meus parceiros e fornecedores não precisam ser agile também

Os líderes de TI geralmente acreditam que fazer mudanças em suas próprias equipes e processos internos lhes dará a velocidade e agilidade de que precisam para fornecer novos recursos com a rapidez que suas unidades de negócios e o mercado exigem.

Isso, no entanto, não é suficiente, diz Kelker. Eles devem ter seus parceiros a bordo também.

Ele acrescenta: “E se os contratos com seus fornecedores só permitirem cascata? E se a forma como você está comprando for planejar-construir-administrar? E se o seu fornecimento não permitir DevOps?”.

Kelker diz que as equipes de TI corporativas não podem maximizar todos os benefícios do agile a menos – e até – que façam com que seus fornecedores e parceiros sigam o exemplo, observando que os contratos de TI com seus fornecedores terceirizados devem ser escritos para garantir que todas as partes estejam usando o metodologias agile para entregar rapidamente novos recursos e funções, bem como melhorias incrementais – com pagamentos estruturados para suportar essa mudança.

Implementamos o agile, por isso estamos bem

West estava trabalhando com uma empresa de software para escalar suas práticas agiles quando perguntou a um dos executivos sobre a eficácia das práticas Scrum da empresa. O executivo desdenhou, dizendo que a empresa já havia implantado essas práticas. O executivo considerou as práticas do Scrum (como os outros princípios agiles que a empresa adotou ao longo do tempo) um negócio fechado; ele não considerou nada errado com essa linha de pensamento, mesmo quando sua empresa falhou em entregar produtos após vários sprints separados.

“Eles acham que o agile pode ser feito e acabado: esse é o melhor elefante na sala. Eles esquecem completamente o elemento de melhoria contínua”, diz West. “E se você tirar os olhos disso, se você não tem um plano para construir uma melhoria contínua para suas práticas ágeis, você acaba com um problema”.