Seis maneiras em que o Ágil pode se tornar estático

A transformação digital requer que as organizações de TI se tornem facilitadoras de negócios que entreguem experiências diferenciadas aos clientes, e que provenham retorno de investimento. Para se manterem atualizadas com inovação, e entregar resultados imediatos, muitas equipes de TI adotaram as metodologias de desenvolvimento ágil nas quais cadências de entrega são medidas em dias, não em trimestres, e a qualidade é garantida.

Este pode ser o Santo Graal, mas esse objetivo nem sempre é possível. Idealmente falando, desenvolvimento ágil tem todos os elementos corretos, mas não é aplicável a todos os projetos. Vamos considerar como ele funciona no melhor cenário possível.

O desenvolvimento ágil acelera a entrega de valor de negócio inicial por um processo de planejamento e feedback contínuos. Como resultado desses planejamentos iterativo e ciclos de feedback, as equipes são aptas a continuamente alinhar entrega de software às necessidades de negócio desejadas, se adaptando facilmente a mudanças de requisitos durante o processo, e medindo e avaliando a situação do projeto baseando-se numa visibilidade precisa do progresso atual de todos os estágios e com todos os envolvidos. Como resultado de processos ágeis, na conclusão de um projeto, o software atende melhor às necessidades do negócio e dos clientes.

Tudo pode soar lógico e racional, mas, geralmente, a realidade de projetos ágeis pode ser um pouco diferente. Metodologias ágeis nem sempre entregam os resultados esperados.

Aqui estão seis formas comuns que projetos ágeis podem falhar.

1. Arquitetura insustentável - O Manifesto Ágil diz: "Contínua atenção à excelência técnica e bom design, aumenta a agilidade." e há uma forte tendência a "arquiteturas adaptativas". O segredo de ser ágil é ter apenas o suficiente de design antecipado. O problema é saber quanto de design é o suficiente. Se o processo de design é minimamente alterado, sem um processo formal, código pode ser gerado em cima de código legado, e até o resultado final será um design inflexível. Diferente da arquitetura em cascata, em que sistemas são rigidamente definidos antecipadamente, o desenvolvimento é uma atividade com data definida de início e fim. A arquitetura ágil é um processo contínuo que possibilita mudanças na arquitetura quando necessário. Um design pode ser coerente em uma sprint planning, mas pode não ser suficiente em um modelo de arquitetura formal e sustentável a longo prazo.
2. Limitação das ferramentas - Metodologias ágeis são comumente limitadas a ferramentas existentes. Atualmente o mercado de ALM (Enterprise Application Lifecycle Management) é dominado por monolitos, na promessa de soluções com entregas em "cascata" e falta de elementos chave da metodologia ágil. Nesse meio tempo, a indústria de software foi pelo caminho das melhores abordagens com ferramentas ágeis como: Jenkins, VersionOne, e RallyDev, sendo que essas ferramentas não foram criadas para as necessidades de Corporações de TI. Elas foram desenhadas para serem usadas por engenheiros de software e não usuários de negócios que não são preparados, motivados, nem alocados em treinamentos formais para aprender como prover feedback de performance em testes funcionais. Além disso, esses sistemas podem ser custosos para aquisição ou manutenção, pois podem incluir funcionalidades que têm excessivos e desnecessárias demandas de computação e hardware.
3. Lacuna Cultural - Alguns desenvolvedores acostumados a trabalhar de forma autônoma podem achar que toda colaboração requerida pelo desenvolvimento ágil pode atrasá-los. Muitos irão resistir às mudanças na forma de trabalhar em uma metodologia altamente colaborativa se estão acostumados a uma grande liberdade. Indivíduos brilhantes e altamente motivados geralmente só querem de você as ferramentas que precisam, e ser deixados para fazer seu melhor. Porém, eventualmente todos em um projeto ágil precisam ser mais flexíveis. O Quadrante Mágico do Gartner para Serviços de Testes em Aplicações de 2016 estima que até 2020, 60% dos recursos em testes necessitarão de um conjunto de habilidades de testes, habilidades em desenvolvimento de aplicações, e habilidades em processos de negócio ou de indústria. Dado o nível que as mudanças acontecem em um projeto hoje, a ideia do desenvolvedor "lobo solitário" sentado em algum lugar sem se comunicar com ninguém não faz sentido - colaboração é um fator chave de sucesso. Há muitas evidências de que quanto mais diversificada uma equipe, melhores resultados ela produz. Não faria sentido "colocar as pessoas no programa" e criar alguma habilidade social?
4. Dificuldade em escalar - Metodologias ágeis são tradicionalmente mais populares em pequenas e médias organizações, mas recentemente têm se tornado padrão em grandes empresas. Comparado a pequenos projetos, onde o desenvolvimento ágil é o ideal, projetos grandes necessitam de coordenação adicional. Um problema particular em aplicar ágil em grandes projetos é como controlar a coordenação entre equipes. Ágil em larga escala envolve preocupações adicionais na comunicação com outras unidades organizacionais, como os recursos humanos, marketing e vendas, e gerenciamento de produto, pois a metodologia é amplamente dependente em relacionamentos de trabalho próximos e muito feedeback dos usuários. Conforme o projeto cresce a comunicação que flui deve aumentar exponencialmente. Além disso, conforme as empresas se expandem geograficamente, ou se fundem com outras organizações, projetos também são dispersos entre diferentes equipes em diferentes locações. Sem uma abordagem consistente nos locais e nas ferramentas de comunicação para visibilidade em tempo real dos ciclos de testes distribuídos por diversas equipes de desenvolvimento e testes, gargalos podem ocorrer e resultar em atrasos e custos adicionais ao projeto.
5. Não ser o tipo correto de projeto - Métodos tradicionais (como cascata) funcionam melhor em projetos que estão no final dos dois espectros; requisitos claros e imutáveis que são estabelecidos ou a abordagem de uma nova tecnologia sem usuários anteriores que podem prover feedback. Apesar de que projetos longos estão se tornando menos prevalentes. A natureza VUCA (volatilidade, incerteza, complexidade e ambiguidade) de ambientes de negócios significa que mais de 60% dos requisitos irão mudar em um projeto de 12 meses, portanto o fim "fixado" do espectro é um mito. Não existem "requisitos claros e imutáveis" em sistemas desenvolvidos hoje - a tecnologia muda rapidamente, as necessidades dos clientes são emergentes, a legislação muda frequentemente e "Vou saber quando chegar" - "I'll know it when I see it" (IKIWISI - do Rapid Application Development, 1986) - é a realidade da necessidade dos usuários. Gerentes de projeto precisam avaliar projetos para analisar se um pequeno grupo de desenvolvedores autônomos pode ser mais adequado e uma solução de custo mais efetiva para projetos que acabam na metade. Projetos que possuem muitos e diversos grupos de usuários em uma matriz estruturada podem também não se adequar a metodologias ágeis. Por exemplo, em pirâmides estruturais, é comum o número de equipes trabalhando juntas acabam sendo maior que o projeto realmente necessita. O problema pode piorar quando os membros dessas equipes estão parcialmente alocados gerando menos comprometimento.
6. Atolar-se em colaboração - Para as equipes de desenvolvimento se beneficiarem ao máximo das metodologias ágeis seus membros precisam ver, sentir e ouvir seus usuários numa base diária. Mas a realidade de muitos projetos hoje é que os diferentes membros não são tão próximos, ou não estão disponíveis para comunicação cara-a-cara. Depender de comunicação por e-mail pode retardar a comunicação e abrir a erros. Minha própria experiência com empresas mostra que mais de 50% das organizações estão utilizando Microsoft Office como Word ou Excel ou mesmo papel e caneta para gerenciar aspectos das entregas como testes. Quando equipes de diferentes localidades físicas, e geralmente geograficamente separadas usam ferramentas de comunicação para capturar todos os diferentes tipos de informação e acelerar o fluxo de informações, geralmente fazem melhoria no processo e resultado final, tornando as equipes mais fortes e produtivas. Ferramentas previnem processos de travarem, porque um único grupo de testes está responsável ou um usuário de negócios envolvido com testes de aceitação sai de férias sem se lembrar de executar os procedimentos. Uma vez que comunicação e coordenação - ambos, internamente e com clientes - é geralmente difícil devido a logística, localização e timing, um modelo de comunicação de ponta a ponta para colaboração de equipes ágeis é essencial para ajudar às pessoas a trabalharem juntas e mais efetivamente.

Desenvolvimento ágil no contexto correto permite que organizações disponibilizem software de alta qualidade, que muda rapidamente para avançar negócios. Só não funciona o tempo todo. Sucesso exige colaboração, transparência e visibilidade em tempo real dos riscos e qualidade do projeto.

Considere utilizar técnicas de mapeamento de histórias de usuário, mapas mentais e quebra de histórias de usuário para melhor divisão do que parecem soluções grandes e complexas em pequenas partes independentes que podem ser rapidamente implementadas para pegar feedback rápido do usuário. Você quer olhar para o futuro longe o suficiente para identificar e fazer o que for necessário para entregar valor agora e possibilitar entregar valor no futuro.

Mantenha as linhas de comunicação abertas e automatize a comunicação de todo feedback, incluindo resultados de testes, mudanças de prioridade, e retestes para fazer as coisas rodarem sem problemas. Ao mesmo tempo admita as limitações da metodologia e se seus especialistas insistem em trabalhar independentemente, e se uma matriz inchada torna todas as linhas de feedback ingerenciáveis, não há vergonha em admitir as limitações do Ágil e voltar à velha metodologia em cascata.

No final do dia estamos construindo produtos que nossos clientes podem usar e fazê-los felizes. Estar preparado para frequentemente adicionar novas funcionalidades baseadas no feedback dos clientes os tornará ainda mais felizes. Como cliente de software, não há coisa pior que investir em um produto que não funciona, não faz o que preciso fazer, e não posso ver um caminho para torná-lo melhor. Estou disposta a comprar a primeira iteração de um produto se sei que ele irá melhorar com o tempo. De fato, ao adotar metodologias ágeis, pode ser divertido ver o produto emergir conforme a equipe de desenvolvimento continuamente o melhora. Ágil nos ajuda a construir este tipo de parceria com nossos clientes, em que trabalhamos juntos para resolver problemas.

Apesar das complexidades das metodologias de desenvolvimento ágil, dadas as condições e ferramentas corretas, equipes de TI podem implementar metodologias ágeis que avançam negócios e solidificam relacionamentos duradouros com clientes.

Sobre a autora

Ronit Eliav é Diretora de Marketing de Produtos na Panaya, Reliav@panaya.com. Ronit é uma experiente líder pensadora em temas de transformação digital como Ágil e Entrega Contínua, DevOps, e otimização de processos de negócios, e uma líder de projetos na modernização de TI, em mobilização e integração de projetos. Da estratégia e análise ao lançamento em mercado, Ronit é a especialista e a proprietária de ponta a ponta do portfólio de Marketing da Panaya.