Superar esses seis desafios é a chave para usar o Agile para uma implementação de ERP. Mas vale a pena o esforço
O Agile existe há muito tempo pelos padrões de TI e provou ser um sucesso para muitas empresas. À medida que as empresas evoluem e progridem no estágio pioneiro do agile, há uma tendência de assumir esforços cada vez maiores. Houve até avanços na aplicação do Agile para apoiar a implantação de ERP (projetos que são notoriamente complexos e com uma quantidade significativa de integração). Mas os benefícios do Agile que foram derivados de esforços em menor escala não foram naturalmente transferidos para projetos Agile em escala.
Por meio de experiência e pesquisa, identifiquei 6 desafios que devem ser superados para executar com eficácia o Agile para uma implementação de ERP e ações para resolvê-los.
Um fator significativo para um projeto ágil de sucesso é uma equipe pequena e comprometida de membros altamente qualificados e com poderes para tomar decisões importantes durante todo o projeto. À medida que um projeto é dimensionado, o volume de decisões entre as equipes aumenta e também o número de decisões “terrivelmente confusas” que devem ser tomadas. Essas decisões normalmente envolvem vencedores e perdedores da organização. É mais difícil e demorado garantir que todas as equipes estejam alinhadas quando há mais equipes e consequências envolvidas.
O escopo das partes interessadas também aumenta, o que pode prolongar ainda mais o tempo necessário para obter consenso. A mentalidade ágil não é propícia para tomar decisões grandes e multifuncionais, então isso se torna mais desafiador conforme o projeto aumenta.
Para abordar este ponto, os Release Train Engineers precisam assumir total responsabilidade na identificação de decisões-chave, socialização precoce e frequente e estabelecer uma estratégia de decisão que permitirá que essas decisões-chave sejam tomadas em tempo hábil.
Em um projeto ágil em escala, o gerenciamento do backlog é mais difícil do que em um pequeno projeto de desenvolvimento, pois o backlog consiste em muitas atividades não diretamente relacionadas ao desenvolvimento de software (ou seja, suporte da equipe de dados, suporte de treinamento, atividades de implantação, etc.).
O gerenciamento de testes integrados também pode ser desafiador, pois muitos dos testes de ERP requerem o envolvimento de várias equipes. Uma segunda dimensão da complexidade do gerenciamento do backlog é que muitos dos itens do backlog não são discricionários (especialmente no ERP) e são um requisito direto de outras equipes. Essas duas dimensões colocam uma demanda muito maior sobre o Product Owner (PO) para entender o escopo de todo o programa para efetivamente preparar um backlog que seja devidamente sequenciado e sincronizado com as outras equipes.
Para resolver esse problema, o desenvolvimento da estratégia de teste de ponta a ponta deve ocorrer na parte inicial do programa. Ao estabelecer essa estratégia, os Product Owners podem desenvolver um melhor entendimento das dependências e precedentes necessários para priorizar o backlog.
Os projetos ágeis dependem muito da calibração da velocidade entre as equipes scrum. Quando há desalinhamento na comunicação e no desempenho de todas as equipes, você acabará com uma equipe de recursos ociosa. Todas as equipes devem cruzar a linha de chegada ao mesmo tempo com o mesmo nível de completude.
Para conseguir isso, deve haver aceitação completa da mentalidade ágil de todos os membros e uma definição clara de “pronto” nas equipes. As equipes que operam em várias definições de pronto podem estender o tempo gasto em testes de ponta a ponta.
Para habilitar este alinhamento, os Release Train Engineers de liberação devem executar duas funções críticas:
Embora existam membros em tempo integral que estão completamente comprometidos com o projeto, eles provavelmente terão que compartilhar seu tempo com várias equipes. Alocar efetivamente seu tempo dependerá de mantê-los alinhados com a posição das outras equipes no projeto.
Os recursos de meio período fora da participação da equipe scrum também deverão ser gerenciados. Por exemplo, o responsável pela auditoria pode dedicar apenas 10% do seu tempo ao projeto ágil em geral. O gerente do programa terá que ajudar a coordenar seu tempo para garantir sua disponibilidade e compromisso com o projeto ágil quando a auditoria for necessária.
As previsões de recursos são uma boa ferramenta para abordar esse ponto. Os engenheiros do Release Train precisam manter uma previsão de demanda de recursos completa em todos os programas e atualizar regularmente todas as áreas de fornecimento. Os Product Owner ganharão o favor desses provedores de recursos externos gerenciando o backlog para alinhar com a previsão de demanda.
Para manter o projeto no caminho certo, é normal que os chefes estejam envolvidos nas revisões formais do Stage Gate e tenham o que precisam para apoiar a revisão. Normalmente, em projetos de grande escala, mais produção e documentação são necessárias para obter suporte total dos membros do conselho de revisão. Um paradoxo com a implementação do Agile é que haverá mais foco no desenvolvimento incremental ao longo do projeto e menos na documentação em geral. Isso complica a capacidade da equipe de fornecer transparência no nível do conselho de administração de gastos e riscos.
Para abordar esse ponto, os POs são aconselhados a desenvolver uma apresentação inicial para a alta diretoria e, em seguida, atualizar este material na conclusão de cada sprint como parte da retrospectiva. As apresentações do conselho e da alta administração não devem ser um evento, mas sim a entrega do estado atual e as projeções do estado futuro.
Em projetos ágeis, é mais difícil definir o compartilhamento de riscos entre a empresa e o fornecedor. Os contratos para programas de grande escala tendem a ser baseados em cascata ou entrega, com penalidades ou incentivos direcionando o custo e o desempenho do cronograma, o que permite que as empresas responsabilizem os fornecedores pela entrega do escopo completo. Por outro lado, o ágil assume que o custo e o tempo são fixos quando o escopo é variável. Essa situação contraria a crença padrão de que grande parte do escopo do ERP não é flexível. Uma área que isso complica é a definição e resolução do conceito de suporte de garantia. Esse é outro motivo pelo qual todos no projeto, tanto do lado do cliente quanto do fornecedor, devem ter a mesma definição de “pronto” para cada sprint.
Novas estruturas de contratação surgiram nos últimos anos que estão focadas nesta definição de feito com a aplicação de incentivos e penalidades no cumprimento da definição específica. As equipes que estão considerando a agilidade em escala para abordar o ERP devem procurar especialistas nesta área para aprender sobre essas novas estruturas.
