Agile Projeto

6 razões em que o Agile pode falhar

Hoje é um tema muito visado, mas existem maneiras em que o Agile pode falhar sabia disso? A transformação digital exige que as organizações de TI se tornem facilitadoras de negócios que ofereçam experiências diferenciadas aos clientes que proporcionem retorno sobre o investimento.

Para acompanhar a inovação e fornecer resultados imediatos, muitas equipes de TI adotam metodologias ágeis de desenvolvimento, nas quais as cadências de lançamento 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. Idealisticamente falando, o desenvolvimento ágil tem todos os elementos certos, mas não é adequado para todos os projetos.

Vamos considerar como isso funciona no melhor cenário.

O desenvolvimento ágil acelera a entrega do valor comercial inicial e através de um processo de planejamento e feedback contínuos. Como resultado desse ciclo iterativo de planejamento e feedback, as equipes podem alinhar continuamente o software fornecido com as necessidades de negócios desejadas, adaptando-se facilmente às mudanças nos requisitos durante todo o processo.

Medir e avaliar o status é baseado na visibilidade precisa do progresso real dos projetos em todos os seus estágios com todas as partes interessadas do projeto.

Como resultado de seguir um processo ágil, na conclusão de um projeto, o sistema de software trata melhor as necessidades dos negócios e dos clientes.

Antes de mais nada até a Agile Aliance mostra que o agile tem motivos para não funcionar

Tudo parece lógico e razoável, mas muitas vezes a realidade dos projetos ágeis pode ser um pouco diferente. Metodologias ágeis nem sempre entregam os resultados esperados.

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

1 – Arquitetura do sistema insustentável

O Manifesto Ágil afirma que “bom design e excelência técnica aumentam a agilidade” e há um forte impulso para “arquiteturas adaptativas”. O truque para se manter ágil é ter um projeto apenas o suficiente na frente.

Mas o problema é saber quanto design é suficiente. Se o processo de design for curto, sem um processo de design formal, o código pode ser colocado sobre o código antigo e, até o resultado final, é um design inflexível.

Ao contrário da arquitetura tradicional em cascata, onde a arquitetura do sistema é bem definida e o desenvolvimento é uma atividade única com datas de início e término definidas.

A arquitetura de software ágil é um processo contínuo que permite aos desenvolvedores aplicar alterações na arquitetura, se necessário, de forma contínua.

O design pode ser coerente durante uma reunião de planejamento de sprint, mas pode não ter um modelo arquitetônico formal que resulte em sustentabilidade a longo prazo.

2 – Limitações das ferramentas existentes

As metodologias ágeis são frequentemente limitadas pelas ferramentas existentes. O mercado atual de Gerenciamento de Ciclo de Vida do Aplicativo Corporativo (“ALM”) é dominado por soluções monolíticas, baseadas em premissas que foram projetadas com uma abordagem de entrega “cascata” em mente e carecem de elementos-chave da metodologia de entrega do Agile.

Embora a indústria de desenvolvimento de software tenha adotado a melhor abordagem com ferramentas ágeis, como Jenkins, VersionOne e RallyDev, essas ferramentas não foram projetadas para as necessidades da organização de TI corporativa.

Eles foram projetados para serem usados ​​por engenheiros de software profissionais e não por usuários de negócios que não estão dispostos, não podem e não devem ser obrigados a participar de treinamentos para aprender como fornecer feedback de testes funcionais.

Além disso, esses sistemas também podem ser caros de comprar e manter porque incluem muitos recursos que possuem requisitos excessivos e desnecessários de hardware e computação.

3 – Diferença de cultura

Alguns desenvolvedores que estão acostumados a trabalhar de forma autônoma podem achar que toda a colaboração necessária com o desenvolvimento ágil os atrasa.

Muitos resistirão a mudar seu estilo de trabalho para se ajustarem a uma metodologia altamente colaborativa, se estiverem acostumados com muita liberdade. Indivíduos altamente inovadores e inteligentes geralmente só querem que você lhes dê as ferramentas de que precisam e, em seguida, permita que eles façam o que fazem melhor.

Embora, eventualmente, todos em equipes de projeto ágeis precisem ser mais flexíveis. O Quadrante Mágico de 2016 para Serviços de Teste de Aplicativos do Gartner estimou que até 2020, 60% dos recursos de teste precisarão ter uma combinação de habilidades de teste, desenvolvimento de aplicativos e habilidades de processos de negócios ou habilidades do setor.

Dado o nível de mudança que acontece em torno dos projetos hoje em dia, a ideia do desenvolvedor “lobo solitário” sentado em algum lugar e não conversando com os outros não faz sentido – a colaboração é um fator chave para o sucesso.

Há muitas evidências de que equipes mais diversificadas produzem melhores resultados, por isso, não cabe aos indivíduos “entrar no programa” e desenvolver algumas habilidades sociais?

4 – Dificuldade de escalonamento

Agile é uma metodologia que tradicionalmente tem sido popular entre organizações de pequeno e médio porte, mas recentemente se tornou mais mainstream em grandes empresas.

Em comparação com pequenos projetos, que são ideais para o desenvolvimento ágil, os maiores requerem coordenação adicional.

Um problema específico na aplicação ágil de projetos maiores é como lidar com a coordenação entre equipes.

Agilidade em grande escala envolve preocupações adicionais na interface com outras unidades organizacionais, como recursos humanos, marketing e vendas e gerenciamento de produtos.

Como a metodologia é amplamente dependente de relacionamentos de trabalho próximos e de muitos comentários dos usuários, à medida que o projeto cresce, os fluxos de comunicação resultantes se multiplicam exponencialmente.

Além disso, à medida que as empresas expandem para novas geografias ou se fundem com outras organizações, os projetos também são dispersos por várias equipes em diferentes locais.

Sem uma abordagem consistente entre locais e ferramentas de colaboração, com visibilidade do status em tempo real dos ciclos de teste distribuídos em várias equipes de desenvolvimento e teste, podem ocorrer gargalos que podem resultar em atrasos no projeto e custos excessivos.

5 – Não é o tipo certo de projeto

Métodos tradicionais (como o waterfall) funcionam melhor em projetos que estão em ambas as extremidades do espectro; requisitos claros e fixos que estão bem estabelecidos ou uma nova tecnologia ou abordagem sem base de usuários anterior que possa fornecer feedback válido. Embora, na verdade, projetos longos estão se tornando menos e menos prevalentes.

A natureza VUCA (volatilidade, incerteza, complexidade e ambiguidade) do ambiente de negócios hoje significa que mais de 60% dos requisitos mudarão em um projeto de 12 meses, então o fim “fixo” do espectro é um mito.

Não há “requisitos claros e fixos” nos sistemas de negócios hoje – a tecnologia muda rapidamente, as necessidades dos clientes são emergentes, a legislação muda com frequência e “eu sei quando a vejo” (IKIWISI – da Rapid Application Development, 1986) é a realidade das necessidades do usuário.

Os gerentes de projeto precisam avaliar os projetos para analisar se um número menor de desenvolvedores trabalhando de forma autônoma pode ser uma solução mais adequada e econômica para projetos que estejam em algum lugar no meio.

Projetos que interagem com vários grupos de usuários diferentes em uma estrutura de gerenciamento de matriz também podem ser inadequados para metodologias ágeis.

Por exemplo, com estruturas em pirâmide, muitas vezes o número de equipes trabalhando juntas acaba sendo maior do que o que é realmente necessário para o projeto. O problema fica ainda pior quando esses membros da equipe são parcialmente atribuídos a projetos, pois há menos comprometimento.

6 – Encalhados pela colaboração

Para se beneficiar mais das metodologias ágeis, os membros da equipe de desenvolvimento de software precisam ver, sentir e ouvir o que está acontecendo com os usuários diariamente.

Mas a realidade da maioria dos projetos hoje é que os diferentes membros da equipe não estão muito próximos ou não estão disponíveis para comunicações face a face.

Confiar nas comunicações manuais por e-mail pode desacelerar as comunicações e pode ser propenso a erros.

Embora minha própria experiência com organizações empresariais mostre que mais de 50% das organizações estão usando produtos de escritório da Microsoft, como o WORD ou o Excel, ou até mesmo papel e caneta para gerenciar aspectos da entrega de aplicativos, como testes.

Quando equipes de diferentes locais físicos e, muitas vezes, diferentes geografias usam as ferramentas de comunicação para capturar todos os tipos de informações e acelerar os fluxos de informações, elas geralmente aprimoram o processo e o resultado final, tornando as equipes mais fortes e produtivas.

As ferramentas impedem que os processos fiquem presos porque um grupo de teste está atrasado ou um usuário empresarial envolvido no teste de aceitação do usuário saiu de férias sem se lembrar de executar procedimentos.

Como a comunicação e a coordenação – tanto internamente quanto com os clientes – costumam ser difíceis devido a logística, locais e prazos, uma estrutura de comunicação de ponta a ponta para a colaboração ágil da equipe é essencial para ajudar as pessoas a trabalharem juntas de maneira mais eficaz.

Considerando o Agile

O desenvolvimento ágil nas circunstâncias certas permite que as organizações liberem software de alta qualidade que muda rapidamente para impulsionar os negócios. Isso simplesmente não funciona o tempo todo.

O sucesso requer colaboração, transparência e visibilidade em tempo real do risco e da qualidade do projeto.

Considere o mapeamento de histórias de usuários, o mapeamento mental e as técnicas de divisão de histórias para dividir melhor o que parece ser soluções complexas em partes menores e independentes que podem ser implementadas rapidamente para obter um feedback mais rápido do usuário.

Você quer olhar o suficiente no futuro para identificar e fazer o que precisa fazer para agregar valor agora e possibilitar a entrega de valor no futuro.

Mantenha as linhas de comunicação abertas e automatize a comunicação de todos os comentários, incluindo resultados de testes, pedidos de alteração e retestes para fazer as coisas funcionarem sem problemas.

Ao mesmo tempo, admita as limitações da metodologia e se seus especialistas insistirem em trabalhar de forma independente, e o gerenciamento de matriz inchado fará com que todas as linhas de feedback sejam incontroláveis, sem vergonha e admitindo as limitações do Agile e voltando à velha metodologia testada, mas verdadeira.

Construindo pontes entre time e cliente no Agile

No final do dia, estamos construindo produtos que nossos clientes podem usar para torná-los felizes. A possibilidade de adicionar novos recursos com frequência com base no feedback deles os torna ainda mais felizes.

Como cliente de software, há algo pior do que investir em um produto que não funciona, não faz o que eu preciso, e não vejo um caminho a seguir para torná-lo melhor.

Estou disposto a comprar um primeiro produto de iteração se souber que vai melhorar com o tempo. De fato, usando metodologias ágeis, pode ser divertido ver o produto emergir à medida que a equipe de desenvolvimento melhora continuamente o produto.

O Agile nos ajuda a construir esse tipo de parceria com nossos clientes, um em que estamos trabalhando juntos para resolver problemas.

Apesar das complexidades das metodologias de desenvolvimento ágil, dadas as condições e ferramentas certas, as equipes de TI podem implementar metodologias ágeis de desenvolvimento que impulsionam os negócios e consolidam relacionamentos leais e duradouros com os clientes.

Lições aprendidas

  • Agilidade requer arquiteturas adaptativas. Se não houver um processo de design formal, o código pode ser colocado sobre o código antigo e, até o resultado final, é um design inflexível.
  • Nem todas as ferramentas são criadas iguais tanto para agilidade de software quanto de negócios, as duas necessidades precisam ser atendidas com uma ferramenta singular que direciona todos os usuários
  • O desenvolvedor de “lobo solitário” é coisa do passado, as evidências mostram que equipes mais diversas produzem um trabalho melhor com a colaboração como um fator chave para o sucesso
  • A ampliação de projetos ágeis de larga escala envolve colaboração inter-equipe e maior colaboração e visibilidade interfuncional
  • Como os projetos de hoje podem começar sem requisitos claros e fixos, os gerentes de projeto devem planejar um ciclo contínuo de planejamento e feedback
Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
CEO do portal, apaixonado por gestão de projetos, metodologias, minha família, professor, consultor de outsourcing de projetos com mais de 6 anos de experiência em projetos de TI e 18 anos de experiência em tecnologia da informação. Com experiencia trabalhando com supply-chain, e-commerce, e-procurement, compliance, agilidade e planejamento.

Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá.
Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC.

Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto.
Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos

Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Comentários

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *