A batida de tambor para implementar o Agile está cada vez mais alta. Veja como evitar certas falhas
Agile deveria ser notícia do passado. Realmente, notícias da década passada. O Manifesto Agile apareceu há quase vinte anos e, ao contrário de Atenas, que nasceu totalmente crescida e protegida da cabeça de Zeus, muitos de nós tínhamos praticado ou encorajado técnicas ágeis muito antes de o manifesto torná-las oficiais.
E, no entanto, alguns resistentes destemidos conseguiram manter a agilidade, com suas taxas mais altas de sucesso e satisfação nos negócios, sob controle. Se você está entre eles e está sob pressão para “ser ágil”, é hora de parar de se sentir como um dinossauro esperando o asteroide bater. Aqui estão sete maneiras comprovadas de tomar a ofensiva e certamente evitar que o Agile aconteça com sua organização de TI sem que você ganhe a reputação de ser uma areia na engrenagem de progresso de sua empresa.
Ao lançar seu próximo projeto, insista para que o gerente de projeto o execute da “maneira ágil”, com todos na equipe descobrindo todas as manhãs o que podem fazer naquele dia para mover o projeto em qualquer direção que eles acham que é o futuro.
Testando? Quando a equipe estiver pronta para testar um recurso, informe o product owner hoje que você precisará de uma equipe de negócios para testar o recurso amanhã. Se eles não estiverem disponíveis amanhã, tudo bem. Significa apenas que esse recurso terá que deslizar para o próximo sprint.
E se o product owner reclamar que o projeto não está cumprindo o cronograma, bem, esta é a parte da beleza: apenas explique que “projetos ágeis” não têm cronograma.
Afinal, agile significa “sem plano”, não é?
Não perca tempo no início do projeto definindo a arquitetura do aplicativo. Se agile significa que os requisitos evoluem continuamente, a arquitetura do aplicativo não deveria evoluir continuamente também?
Portanto, não restrinja a criatividade do desenvolvedor insistindo na conformidade com um monte de princípios abstratos. Em vez disso, capacite seus desenvolvedores. Deixe-os desenvolver como quiserem, estruturando seus módulos e interfaces como quiserem. E se diferentes módulos de diferentes desenvolvedores não se conectam e funcionam juntos, ou se diferentes desenvolvedores escrevem código que depende de diferentes bibliotecas, não se preocupe com isso. É para isso que serve a refatoração.
Caramba, se diferentes desenvolvedores desejam desenvolver em diferentes linguagens, bem, é para isso que os contêineres existem, não é?
Agile não é uma metodologia. É uma família de metodologias, cada uma adequada a um tipo diferente de projeto. O Scrum emergiu como o mais popular, não porque é a “melhor prática”, mas mais provavelmente porque é a variante agile mais rigidamente estruturada, tornando-o mais próximo da zona de conforto de uma loja de waterfall do que qualquer outra.
Especialmente, o Scrum é pouco adequado para as implementações de off-the-shelf software (COTS) e software como serviço (SaaS) que constituem a maioria dos projetos de TI. Uma variante Agile diferente, o conference room pilot (CRP), ou seu close relative acceptance test driven development (ATTD) são alternativas melhores.
Mas quem já ouviu falar deles? Com toda a probabilidade, ninguém é importante. Mesmo seus oponentes políticos mais fortes não irão criticá-lo por escolher a variante agile mais popular, e isso se eles souberem que existem outras variantes agiles para escolher.
Então, quando as coisas vão de lado com a sua implementação COTS orientada pelo Scrum, não será porque você deveria saber melhor. Bem, será, mas você pode alegar que o projeto falhou porque Agile nunca foi uma boa ideia, para começo de conversa, e você pode sugerir com segurança que qualquer pessoa que argumentar o contrário está apenas fazendo picuinhas para se proteger.
O charme do Agile, e sua maior força, é sua simplicidade. Sua maior fraqueza é que ele não escala muito bem.
Negócios inteligentes se mantêm ágeis – tanto que estendem os princípios do Agile para abranger não apenas a implementação de software, mas todas as mudanças nos negócios. Visto deste ângulo, os planos estratégicos de grande escala são intrinsecamente em cascata por natureza e falham pelos mesmos motivos pelos quais os projetos em cascata de TI falham: eles são lineares, com muitas interdependências e pontos únicos de falha potencial; e eles são construídos sobre suposições sobre o futuro que mudarão pelo menos duas vezes quando o futuro chegar.
Mas isso tudo não importa. O trabalho do CIO não é tornar o negócio mais ágil. É para apoiar a estratégia de negócios, quer a estratégia tenha ou não alguma chance de realmente funcionar. E como o agile não se adapta a planos de tamanho de programa estratégico, a TI precisa adotar uma metodologia que pareça ágil, mas se dimensione como se fosse uma cascata.
Bem-vindo ao SAFe – o chamado Scaled Agile Framework (de onde vem o “e” é um mistério duradouro). Mas, enquanto o agile em si é bem-sucedido por meio da simplicidade metodológica, o SAFe é terrivelmente complicado, com tantas partes móveis, pontos potenciais de falha e suposições sobre o futuro quanto o waterfall, com a vantagem adicional de não ser familiar.
Entenda, o SAFe não é intrinsecamente ruim. Mas requer profissionais experientes e bastante infraestrutura de programa.
Se SAFe é o que a empresa precisa, SAFe é o que a TI fará, saltando sobre o abismo do waterfall para SAFe em um único salto, não importando os riscos.
O programa falhará, mas suas mãos estarão limpas. Você já avisou que o Agile não escala.
Claro que eles precisam usar o Agile. É melhor, não é? Além disso, você está ensinando cada gerente da empresa a trabalhar com TI de maneira ágil.
E, claro, as ofertas do fornecedor devem ter um preço fixo. Essa é a única maneira de manter a lealdade com os fornecedores. Caso contrário, eles teriam um “incentivo perverso” para escapar do orçamento e do cronograma do projeto.
E se um fornecedor tiver a temeridade de apontar que começar com um escopo fixo e apenas alterá-lo por meio de uma governança de controle de mudança rígida é a antítese do agile, bem, é bom que você aprendeu como seria trabalhar com esse fornecedor se não o tivesse feito começar sob a assinatura de uma declaração de trabalho.
Em teoria, os planejadores de negócios definem metas de receita, custo, risco e cumprimento da missão empresarial. Na prática, na maioria das empresas, os projetos aprovados para execução efetiva são os que reduzem os custos.
Qual o melhor lugar para começar do que as taxas que você paga pelas horas do desenvolvedor?
Portanto, quando você contratar um parceiro de desenvolvimento, certifique-se de que a maioria dos membros da equipe more e trabalhe em 11 fusos horários distantes.
Sim, o princípio agile nº 6 enfatiza a importância das conversas face a face – entre desenvolvedores, e entre desenvolvedores e usuários de negócios. Não, os desenvolvedores offshore não participarão deles.
Tudo bem. Ignore isto. É apenas teoria. Tendo a escolha entre economizar dinheiro e princípios abstratos, aqueles que economizam dinheiro são os empresários obstinados de que precisamos por aqui.
E quando a ágil “equipe” entrega módulos que, quando acertam um alvo, acertam um que está no centro do alvo errado, tudo bem também. Esses módulos terão custado muito menos, e a TI sempre pode recorrer à explicação testada e comprovada de que “o negócio” não era claro sobre seus requisitos.
O fato de os requisitos não estarem claros por causa da pouca comunicação face a face nem ocorrerá a quem importa.
Sim, sim, sim, todos nós sabemos que o Manifesto Agile premia “… indivíduos e interações sobre processos e ferramentas”.
Mas se há uma coisa que a administração aprendeu nas últimas décadas é que o sucesso nos negócios depende da instituição de processos repetíveis bem definidos. O sucesso não vem de relacionamentos ou de funcionários colaborando para descobrir melhores soluções juntos.
Não, o sucesso vem dos funcionários que seguem os processos, passo a passo, conforme prescrito pelos diagramas de raia.
E como todo designer de processo sabe, um bom processo não deixa nada ao acaso. Cabe a você garantir que seu processo ágil, como todos os outros bons processos, descreva como o processo flui de um bloco para outro, com cada ponto de decisão descrito como um ramo do processo, enquanto todos os envolvidos transformam suas entradas em saídas que se tornam as entradas do próximo funcionário.
Adicione complexidade suficiente ao fluxo do processo Agile e, eventualmente, a TI estenderá o alcance da polícia de execução do processo de gerenciamento de projetos do EPMO para que eles fiquem de olho em seus coaches ágeis, assim como eles têm mantido seus gerentes de projeto em cascata alinhados o tempo todo.
Se as sete estratégias descritas aqui lhe parecem pouco atraentes, você tem mais uma alternativa.
Você pode se render ao inevitável.
Isto é, você poderia reconhecer que o Agile realmente funciona melhor do que o Waterfall e dar uma chance honesta.
Vai doer, mas pense assim: a cirurgia de substituição do joelho também dói.
Mas em ambos os casos, a longo prazo, evitar dói mais do que fazer acontecer.
