Surgida em 2001, após divulgação do Manifesto para o Desenvolvimento Ágil de Software, o Agile reúne um conjunto de fundamentos voltados a tornar a criação de sistemas mais rápidas, sem comprometer a qualidade do produto final.
Seu sucesso, contudo, fez com que essa metodologia fosse adaptada para outros cenários. A metodologia Agile pode não ser uma novidade, mas ainda pode ser um desafio encará-la e colocá-la em prática.
No entanto, a não ser que você queira aparecer no retrovisor de seus concorrentes, é preciso se adaptar às transformações cada vez mais rápidas do mercado. Elas exigem agilidade e flexibilidade nas operações organizacionais.
Para você obter sucesso, conheça 7 formas de falhar na mudança para o Agile – e fuja delas!
Dica antes de você começar: este texto contém uma pitada de ironia.
1. Não tenha planos, mas chame de Agile
Isso mesmo, para ter agilidade você precisa ter liberdade. Portanto, comece a mudança para o Agile pedindo à sua equipe que atue na base do improviso.
Mesmo quando chegar o momento de testar, faça isso sem planejar: ficou pronto hoje? Teste amanhã!
Se houver alguma reclamação pela falta de planejamento ou demora, lembre ao seu interlocutor que a mudança para o Agile é assim mesmo: sem planos ou cronograma!
2. Ignore a arquitetura
A agilidade não combina com projetos engessados, mas com a liberdade para que os requisitos evoluam constantemente. Assim, o Agile dispensa definição de arquitetura no início do projeto.
Para que perder tempo com isso ou inibir a criatividade do desenvolvedor com um monte de orientações abstratas?
Na mudança para o Agile, deixe a equipe estruturar os módulos e interfaces que desejarem e, se depois, os diferentes módulos, criados por pessoas diferentes, não puderem ser integrados, é só juntar o time e descobrir uma forma de corrigir o problema.
Não é para absorver linguagens diferentes que os contêineres existem, poxa?
3. Opte sempre por usar Scrum
É certo que o Agile é uma família de metodologias, cada uma com suas características próprias e indicadas para um projeto específico. No entanto, se Scrum é a ferramenta mais popular, deve ser porque é a melhor opção a ser usada sempre.
Na verdade, Scrum não vai bem com implementações de software comercial de prateleira (COTS) ou SaaS (software como serviço), os mais comuns nos projetos. Até tem alternativas melhores para esse casos, como as variantes Agiles CRP e ATTD, mas para que mudar?
E se algo não sair muito bem porque você está usando Scrum e você receber críticas, ignore. Só pode ser intriga da oposição.
4. Desconsidere a fraqueza do Agile
Se Agile fosse o Superman, sua criptonita seria o fato de não escalar muito bem. Portanto, estender os princípios do Agile para mudanças em softwares e nos negócios como um todo, pode falhar.
Por que? Simples: planos estratégicos de grande escala, assim como projetos de TI em cascata, são lineares e possuem muitas interdependências.
Tendo ou não chances de dar certo, é preciso adotar um método e o SAFe (Scaled Agile Framework), muito complexo e, portanto, pouco ágil.
Além disso, exige profissionais experientes e considerável infraestrutura de programa, mas se é o que sua empresa precisa, é o que você vai oferecer, não importa os riscos.
Você não será o primeiro na história a lavar as mãos, não é mesmo? Quem mandou insistirem? Você alertou que o Agile não escala.
5. Exija o uso de Agile
Na mudança para Agile, insista para que seus parceiros de desenvolvimento usem essa filosofia para obter mais agilidade.
Para que mudar se Agile é o melhor e você precisa ensinar todas as lideranças a trabalharem com TI de modo ágil?
Também insista para que os lances do fornecedor tenham um preço fixo para evitar que eles fujam do orçamento e do cronograma iniciais do projeto.
E atenção: se um fornecedor alertar que um escopo fixo que precise de alteração no meio do caminho, exigindo novas negociações, vai afetar a agilidade do projeto (e pode aumentar os custos), acenda o alerta vermelho. Provavelmente, deve ser daqueles difíceis de trabalhar!
6. Economize sempre
De modo geral, as empresas aprovam projetos que colaboram para reduzir custos. Por isso, na hora de contratar parceiros de desenvolvimento opte pelo preço mais baixo, mesmo que isso signifique que os desenvolvedores não terão contato uns com os outros para discussão de ideias ou que não são os parceiros mais habilitados para o projeto.
E se na entrega do projeto os resultados não forem os esperados, tudo bem. Não custou tanto assim, afinal, sempre haverá o argumento de que a solicitação não era clara o suficiente – quem vai saber que a comunicação deixou a desejar?
7. Não tenha flexibilidade
Todos sabem que o sucesso dos negócios se baseia em processos bem planejados, seguidos à risca pelos colaboradores. A ideia de que ele é flexível e cresce com a colaboração coletiva, é falsa.
A mudança para o Agile, prevê que você torne o fluxo de processos o mais complexo possível, mostrando que só você e sua equipe têm condições de oferecer a agilidade que os negócios hoje necessitam.
Como você pode ter notado, essas 7 dicas são infalíveis, caso você deseje que a mudança para o Agile seja um estrondoso fracasso.
Mas se você deseja o oposto, conquistando todos os benefícios que a metodologia Agile tem a oferecer, inscreva-se em nossa newsletter e receba dicas exclusivas em tecnologia da informação.
