Pilar Sanchez Albaladejo, escreveu o seu artigo em conexaoagile de que os cavaleiros do apocalipse garantem que o fim está próximo…
Esta semana alguns alunos vieram assustados me perguntar se é verdade que a “Agilidade” morreu. Tive que acalmá-los dizendo que a “Agilidade” não vai morrer, o que deve acontecer agora é que, talvez, seja colocada em prática da forma correta!
E vamos combinar, heim? É impressionante como tem pessoas que gosta de gerar pânico em um mercado de trabalho que já está desesperado.
Por isso, a seguir, discorro um pouco sobre minha percepção sobre o “Fim da Agilidade”.
O termo “Agilidade” se tornou popular na área de desenvolvimento de software com o advento do Manifesto Ágil. Esse manifesto enfatiza a importância de entregar valor para o cliente, a capacidade de lidar com mudanças e a colaboração entre equipas.
E com a recente onda de demissões nas BigTechs, algumas pessoas argumentam que a “Agilidade” está se tornando obsoleta e que é hora de procurar novas abordagens.
Diante destes factos, apresento meus argumentos:
1º Uma das principais críticas é que a “Agilidade” se concentra excessivamente em entregar pequenos incrementos de valor, em vez de ter uma visão mais ampla do projecto. Isso pode levar a um acúmulo de pequenas tarefas sem sentido, em vez de trabalhar em direcção a um objectivo maior.
Dividir o projecto em tarefas menores mais facilmente gerenciáveis não é exclusividade da “Agilidade”. Isso vem lá dos primórdios da gestão de projectos com suas WBS (Work Breakdown Structures). A questão aqui, é como essas tarefas estão sendo decompostas e se fazem sentido serem entregues em uma determinada Sprint.
A ideia de entregas recorrentes é perfeita em projectos que não temos certeza de como vão evoluir, mas se o Product Owner não sabe como decompor o produto em entregas “decentes”, talvez seja o caso de treinar melhor o PO e não culpar a tal da “Agilidade”.
2º A ênfase na capacidade de lidar com mudanças pode levar a uma falta de planeamento adequado e a uma sensação constante de incerteza e instabilidade.
Dizer que não existe planeamento no Scrum, por exemplo, beira à mentira (a não ser que o Scrum Master e o Product Owner estejam deixando o projecto navegar sem rumo).
Se o cliente muda tudo de uma Sprint para outra, realmente é impossível ter o mínimo de planeamento. O PO e o Scrum Master têm autonomia para dizer “não”? Ou ainda, pensou-se em incluir uma cláusula do tipo “changes for free”?
Essa é uma cláusula de opção “mudanças gratuitas”. Ela permite que o cliente peça mudanças de escopo sem precisar pagar a mais por elas. Mas, o cliente só pode usar essa cláusula se estiver trabalhando activamente com a equipa de desenvolvimento em cada iteração. E ele deve trocar uma funcionalidade prevista pela nova sugerida. Assim, garantimos que o escopo vai ficar dentro de um prazo e custo relactivamente controlados.
3º Outra crítica é que a “Agilidade” se concentra excessivamente na equipa de desenvolvimento, em vez de levar em conta as necessidades do cliente e do negócio. Isso pode levar a soluções que não são realmente relevantes para o cliente e que não contribuem para o sucesso do negócio.
Esse problema vem de equipas que se dizem ágeis, mas continuam com a mentalidade “cascateira” em que a presença do cliente não é necessária. E vamos combinar que em um projecto tradicional de construção de uma ponte, o cliente não precisa estar todo dia no canteiro de obras, concorda?
Mas se estamos construindo um produto que nem o cliente sabe exactamente como quer, nada mais óbvio do que envolvê-lo constantemente durante todo o processo. Então, talvez o problema não seja dessa tal de “Agilidade” e sim do baixo envolvimento do cliente. Product Owners e Scrum Masters deveriam ajudar aqui. Mas será que a empresa dá autonomia para eles entrarem em contacto com o cliente?
4º Algumas pessoas argumentam que a “Agilidade” também está se tornando obsoleta devido à evolução da tecnologia e dos métodos de trabalho. Novas abordagens, como o design centrado no usuário e a automação de testes, estão se tornando cada vez mais populares e podem ser mais eficazes do que a “Agilidade” em algumas situações.
Este é o argumento Darwiniano que até faz sentido. Quem não se adapta, morre. Nada mais natural.
Veja o PMI, que passou a adoptar métodos ágeis em suas publicações, porque esse era um caminho sem volta. E a Scrum.org que passou a oferecer treinamento sobre Kanban associado ao Scrum. Se esse pessoal aí já percebeu isso, quem sou eu para falar o contrário?
Assim, não é a “Agilidade” que vai morrer, ela vai se adaptar. Nada mais justo para um movimento que prega a Adaptação, não é mesmo?
Ser ou não ser ágil?
Vejo que muitos dos problemas que acontecem por aí é porque a tal da “Agilidade” está sendo mal-entendida e mal-empregada.
Você não é “ágil” só por rodar uma reunião diária. Você é “ágil” se entende a importância dessa reunião, quais os benefícios que ela traz e se faz sentido para o seu projecto.
Você não é ágil só porque tem uma certificação como Scrum Master (ou qualquer outra da área). Você é ágil se: sabe facilitar eventos, ajuda o time a resolver impedimentos, incentiva as pessoas a terem mais maturidade e independência em suas actividades, promove o autogerenciamento etc etc etc.
Então, ser ágil é muito mais do que aplicar o Scrum, Kanban, XP ou qualquer outro modelo da moda à risca. Ser ágil é eliminar desperdícios, entregando o produto que o cliente quer e sem matar o time nesse processo.
E como fazer isso? Sendo um profissional mais completo que compreende o problema a ser resolvido e emprega a ferramenta correta no momento certo.
E para vocês, cavaleiros do apocalipse
Sundar Pichai, CEO da Google, comentou que a onda de demissões é resultado da drástica mudança de cenário econômico que o mundo vive desde o ano passado. “Nos últimos dois anos, vimos períodos de crescimento dramático. Para acompanhar e alimentar esse crescimento, contratamos para uma realidade econômica diferente da que enfrentamos hoje”, avaliou Sundar, no comunicado. Assim, obviamente, não é tudo culpa da “Agilidade”…