Por que falam tanto que o ágil morreu?

Há alguns dias atrás, Dave Thomas escreveu um post intitulado “Time to Kill Agile“, ou “A Hora de Matar o Ágil”. Tenho visto muito esse tipo de discussão na comunidade e a pergunta é: por que elas estão aparecendo?

kanban

Apesar do crescente uso de métodos ágeis no Brasil e no mundo, muitas pessoas ainda dizem que, apesar dos esforços, seus projetos ainda continuam a falhar, prazos não são atendidos e o custo ultrapassa em muito o estimado. Isso significa, então, que métodos ágeis não funcionam, certo? Mas é claro que não.

O que está acontecendo com métodos ágeis pode ser generalizado. Acompanhe meu raciocínio:

  1. X é uma nova prática/ferramenta que surgiu na sua área de trabalho.
  2. X parece ser bastante interessante e útil.
  3. A indústria, por sua vez, começa a fazer uso de X.
  4. Algumas empresas fazem bom uso de X e resultados aparecem.
  5. Muitas pessoas blogam a respeito de sua experiência positiva com X.
  6. Outras empresas não fazem bom uso de X (interpretaram errado a ideia da prática) e não tem bons resultados.
  7. Consultores sobre X aparecem no mercado e tentam ajudar. Alguns consultores não tão bons assim.
  8. Muitas pessoas blogam a respeito de sua experiência negativa com X.
  9. A comunidade em torno de X fica chateada com o acontecido.

Substitua agora X por “métodos ágeis”, “TDD”, “programação pareada”, etc. Perceba. Isso é um padrão que acontece em torno de qualquer novidade. Como explicar então que essas práticas funcionaram para muitas empresas, mas não funcionaram para algumas outras?

As ideias ágeis (bem representadas pelo Manifesto Ágil) são como um guia. A equipe deve entendê-las e então desenhar o processo que melhor se adeque ao seu contexto. Não basta apenas pegar o Scrum e forçar a equipe a usar tudo o que está descrito lá. As pessoas, por má interpretação, acabam por seguir práticas sem nem saber o porquê delas existirem. Provavelmente vai fracassar.

Não existe certo ou errado em engenharia de software. Eu sei disso. Você sabe disso. Existem melhores e piores práticas para um determinado contexto. É isso que as pessoas esquecem: CONTEXTO. Cada equipe é diferente; cada projeto é diferente; cada cliente é diferente. Portanto, cada implementação de agilidade deve ser diferente. Cada prática descrita na literatura deve ser avaliada, levando em conta a sua atual situação.

Discutimos bastante sobre isso em nosso curso sobre agilidade. É interessante perceber que cada aluno chega com um contexto diferente e sai com uma ideia diferente de como implementar ideias ágeis à sua equipe. E isso é ser ágil: é pensar em melhoria contínua, processos leves, comunicação, etc. Ser ágil não é seguir as receitas de um livro.

Métodos ágeis funcionam. Métodos ágeis não funcionam. A prática X funciona. Ou X não funciona. Cair em um lado ou no outro, só depende de você.

26 Comentários

  1. Wanderson 22/04/2014 at 16:11 #

    Com toda certeza, as práticas de agilidade variam de projeto para projeto, por isso é extremamente importante fazer essa análise de qual metodologia seguir antes da implementação do projeto.
    Muito bom artigo, parabéns!

  2. Wanderson Macêdo 22/04/2014 at 16:16 #

    Com toda certeza, as práticas de agilidade variam de projeto para projeto, por isso é extremamente importante fazer essa análise de qual metodologia seguir antes da implementação do projeto.
    Muito bom artigo, parabéns!

  3. Jeremias 22/04/2014 at 17:51 #

    As praticas ágeis não resolverá todos os problemas da humanidade (projeto), mas desde o seu inicio o proposito é melhorar os processos e isto ele faz desde que seja aplicado analisando caso a caso como citado no artigo. Muito boa as observações. Parabéns.

  4. Arthur 22/04/2014 at 18:02 #

    O problema é que o brasileiro não sabe estudar. Se soubesse, hoje já nem sequer faria sentido falar de metodologia ágil sem falar em DDD.

  5. O que pode matar o agile (se é que pode ser morto) é o mesmo que destrói tecnologias em nossa área: o hype e a falta de um “posicionar-se do outro lado”.

    Eis o que vejo: empresas com um longo histórico de fracassos gerenciais, com o pessoal administrativo já em estado de desespero e que de repente, assim como uma espécie de messias, surgindo um guru agile, seguido de uma meninada (a palavra é esta mesmo: “meninada”) empolgada com uma nova maneira de trabalhar. Esta gestão se agarra a este caminho como se fosse sua salvação: o problema é que já estão em desespero.

    O desespero exige mudanças rápidas e normalmente o “guru ágil” tem uma visão teórica mas não humana. Claro que o agile irá falhar (excelente colocação do contexto neste post): o senso de urgência (normalmente irracional) irá prevalecer. Você quer sair do buraco rápido e não aos poucos. A principal falha na minha opinião é a ausência desta figura humana.

    E claro: há também a culpa em quem VENDE o Agile indiscriminadamente. Vemos por aí os princípios ágeis sendo vendidos como panacéia, raríssimas vezes vemos alguém criticando a coisa, apontando situações nas quais não se encaixa, etc. Para quem está de fora e se interessa pelo assunto, cai na situação que mencionei acima e acaba pensando nesta história toda como simples picaretagem ou deslumbramento de algum meninão sem experiência gerencial alguma.

    Há também um aspecto “arrogância” nesta história (gosto muito da definição de Bobbio de arrogância: uma confiança excessiva nas próprias habilidades). Já vi diversas vezes o “guru ágil” ignorar o fato de que se uma empresa trabalha de determinada forma por anos, possívelmente há uma razão para aquilo E talvez seja algo que precise ser mantido.

    Resumindo: o que mata (se mata) o ágil é o hype (http://www.itexto.net/devkico/?p=1148).

  6. Maurício Aniche 23/04/2014 at 13:24 #

    Excelente seu comentário, Henrique!

  7. Artur 23/04/2014 at 15:03 #

    “desenhar o processo que melhor se adeque ao seu contexto”

    Essa é a chave.
    Se, durante a implantação de um padrão de projetos, as soluções não fizerem muito sentido para sua empresa, PARE, algo errado está ocorrendo.
    Provavelmente a empresa não estava madura o bastante para entender a importância do que está sendo feito, ou os responsáveis pela implantação da metodologia não são profissionais bons o bastante para isso.

    Acompanhei uma empresa colocando o MPSBR em prática(eu sei que não é ágil, mas entre no X do exemplo), e cada nova solução soava como música clássica, pois tudo vinha e amarrava muito bem problemas de uma década que faziam a empresa sofrer. Muito disso foi devido a maturidade da empresa (que tentava padronizar seus projetos mesmo antes do MPSBR) e da qualidade dos profissionais envolvidos.

  8. Samanta Cicilia 23/04/2014 at 16:25 #

    Muito legal o texto. E tem surgido vários do tipo: “porque a área X vai acabar”, “porque a tecnologia X vai acabar” entre outras coisas. Mas o que vejo são pessoas que seguem um livro de receitas e esquecem da parte que envolve estudo e adaptação. Nenhuma empresa é igual, nenhum contexto é igual, sempre é necessário uma adaptação aqui e outra ali. Só que alguns profissionais não tem olhos pra isso e querem seguir as modinhas pra dizer que fazem o que a maioria faz. Não vai dar certo mesmo. =)

  9. Marcelo 24/04/2014 at 09:03 #

    Faltou acrescentar um item #10 na lista do raciocínio:

    10. Começam a aparecer posts explicando “(Por que) X morreu”?

    🙂

  10. Douglas 24/04/2014 at 09:25 #

    Maurício, muito legal o post, o que vc esta tratando de focar e a cultura organizacional o cultura da empresa, a verdade é que a maioria das metodologias utilizadas hoje não foram desenvolvidas dentro do Brasil , dentro da nossa realidade , dentro da nossa cultura, por este motivo , não podemos simplesmente implantar a risca uma metodologia , pois com certeza ele não vai se adaptar ao nosso modelo, o que devemos fazer tomar os aspectos que podem se adaptar a nossa cultura organizacional gerando melhorias em nosso processo

    um exemplo pratico legal:

    O processo de Qualidade 5s modelo japonês foi implantado em uma industria e em uma escola, na industria teve sucesso, melhorando a produção, na escola um fracasso total que só gero gasto de dinheiro

    isto deve se a que são organizações diferentes com culturas diferentes.

  11. Gildeon Muniz 24/04/2014 at 09:42 #

    Sou um entusiasta das relações humanas, fazer software é uma ação humana. Pessoas são diferentes e agem de maneira diferentes. Os gurus ágeis, após lerem o manifesto ágil, ignoram todas as relações humanas e simplesmente detonam todos os profissionais que não concordam com todas as práticas ágeis. Mas esses seres superiores, moral e intelectualmente por não terem sido contaminado pelo pecado da gerencia, não levam em consideração que até esse momento esses profissionais sempre trabalharam da maneira tradicional. Pela falta de paciência para mudar uma situação, trata os profissionais com um rigor exagerado, como verdadeiros tiranos, como gerentes na época da revolução industrial.
    Sou profissional de TI a mais de 18 anos, tenho projetos do qual participei rodando em empresas com faturamentos bilionários como HP, CVC, Elly Lilly, banco Real e Itau. Levei as práticas ágeis para a empresa Qualicorp com resultados fantásticos.
    Peço aos entusiastas e divulgadores das práticas ágeis que tenha mais paciência e não se tornem gerentes carrascos como tive a oportunidade de ver mais de uma vez.

  12. Fernando Franzini 24/04/2014 at 10:06 #

    Eu assino em baixo!!

  13. Thiago 24/04/2014 at 11:28 #

    Oi Maurício, generalizar é um pouco complicado. Só uma observação sobre o item 6:

    6 – Outras empresas não fazem bom uso de X (interpretaram errado a ideia da prática) e não tem bons resultados.

    Aqui você está partindo do pressuposto que o fracasso é responsabilidade da empresa. Você pode argumentar dizendo que não, mas pela lógica, você deveria incluir um item 6a:

    6a – Outras empresas não fazem bom uso de X (mesmo interpretando corretamente) e não tem bons resultados.

    Não é algo que pode acontecer? Esse é o problema da generalização. Digo isso porque senti, posso estar enganado, que você não foi isento na sua consideração. Foi? Eu confio mais é em dado empírico do que em generalizações, tipo: quem fez X e deu certo? Qual a razão? Quem fez Y e deu errado? Qual o motivo? São perguntas que na minha opinião expandem a questão e podem jogar uma luz sob o assunto.

    Fora isso, achei muito corajoso de sua parte e está de parabéns em abordar um tema que ainda mexe com o coletivo imaginário das pessoas (métodos ágeis).

  14. Luiz Ferreira 24/04/2014 at 11:57 #

    Em um passado beeeem remoto, certa vez ouvi:

    – Luiz você pode pesquisar sobre esse tal se Scrum , precisamos entregar uma demanda muito grande e precisamos acelerar o processo de desenvolvimento para poder entregar mais.

    =)

  15. Maurício Aniche 24/04/2014 at 13:41 #

    Marcelo,

    Hahaha, adorei!

    Douglas,

    Faz todo sentido!

    Gildeon,

    Espero que meu post ajude nisso!

  16. Rennan Paloschi 25/04/2014 at 05:32 #

    Caras vocês são bons, quando eu vejo discussões e raciocínios assim sinto um orgulho imenso de ser TI.

  17. José de Arimatéia 29/04/2014 at 08:59 #

    O que não dá é para fazer do manifesto ágil uma escritura sagrada, e falar “isso é ágil”, portanto faremos, ou “isso não é agil”, portanto não faremos.

    Pouco me interessa se é ágil ou não, quero resultados, independente do nome que seja dado.

  18. Yuri Tavares 29/04/2014 at 12:17 #

    Parabéns pelo post, bacana a linha de raciocínio.

  19. Alexandre Aquiles 29/04/2014 at 12:25 #

    Já fui um Agilista Chato [1], daqueles que fica nervoso e vocifera “no XP é assim”, “no Scrum é diferente”, “isso vai contra os princípios Lean”…

    Mas percebi (acho que até cedo), que estava afastando as pessoas da minha equipe com esse papo. E as fazendo odiarem “esse negócio de Ágil”.

    Jurei pra mim nunca mais falar sobre Ágil, XP ou Scrum. Apenas usar as ideias e deixar a equipe ir identificando e melhorando aos poucos.

    Demorou (uns 2 anos) pra atingirmos uma cultura mais ágil, mas deu certo! Claro, ainda há uma tonelada de problemas…

    Vale ler o “Juramento da Não Lealdade”[2] do Alistair Cockburn:

    “Eu prometo não desconsiderar nenhuma ideia baseada na sua origem, mas considerar ideias vindas de todas as escolas e tradições, com o objetivo de encontrar aquelas que melhor se encaixem em cada situação.”

    [1] http://alexandreaquiles.com.br/2010/09/25/nao-seja-um%C2%A0agilista%C2%A0chato/
    [2] http://alistair.cockburn.us/Oath+of+Non-Allegiance

  20. Fábio Henrique 29/04/2014 at 12:39 #

    “Nos não sabemos, mas o desenvolvedor saberá!” Agile é aquele método que deve ser estudado e que requer profissionais exclusivos onde ironicamente as responsabilidades são transferidas em cascata e terminam no rabo do desenvolvedor? Empolgados.

  21. Felipe Almagro 29/04/2014 at 12:42 #

    Um problema que sempre encontro em projetos é o citado pelo Luiz Ferreira:”Equipe, precisamos implementar tal metodologia ágil pra acelerar os projetos”. Porém isso geralmente é feito quando toda a especificação e entendimento dos projetos já foram feitos e, muitas vezes, a equipe responsável pelo entendimento e posterior implementação da tecnologia não tem tempo suficiente em entender TODA a documentação, implementar projetos menores de testes para exercitar o aprendido ( total ou parcial ), entender as limitações da tecnologia e assim saber se realmente atenderá todo o projeto ou se no meio do projeto a tal tecnologia ágil fará o projeto atrasar ou simplesmente parar. A pressa é inimiga do sucesso!!! Temos que reconhecer e respeitar esse FATO. Sem ter conhecimento ( teórico e prático ) da implementação da tecnologia ou prática para o projeto e suas limitações, o ideal é ir pelo básico mesmo, com aquilo que a equipe de profissionais estão preparados e já dominam.

  22. Alex Oliveira 29/04/2014 at 12:54 #

    A equipe deve estar bem focada em um ponto em comum, se olharmos para a história dos grandes projetos, veremos que não bastava apenas qualificação técnica, líderes, processos. Tem que haver o lado comportamental, entender qual seu papel dentro do grupo e até onde ele vai, ser aberto a novas idéias mesmo que vá de encontro a principal, ser patriota para com sua instituição, e ter em mente tudo aquilo que você ( e sua equipe ) fará, será marca registrada na sua carreira.

  23. Leonardo 29/04/2014 at 13:48 #

    Bom artigo, parabéns!!
    No meu ponto de vista não será o fim de uma metodologia, o que acontece e foi muito bem argumentado pelo Maurício, é que o manifesto ágil surgiu como um novo conjunto de técnicas voltada para o desenvolvimento de software que “bateu” de frente com os processos “adaptados” para a nossa realidade e que muitos gestores tomaram como verdade absoluta que a uma metodologia ágil iria resolver todos os seus problemas e seus produtos iriam começar a ser entregues com um menor prazo, maior qualidade e agregando valor ao cliente sem nenhuma outra mudança.
    Hoje empresas acumulam entregas fracassadas com um time ágil assim como acumulavam com um outro processo, os sinais são visíveis a todos e vai mais do feeling de um gestor saber ler e interpretar do que mudar todo o processo de desenvolvimento de uma empresa com base em sucesso de outras empresas e reviews do mercado.
    Acredito na eficiência das metodologias ágeis, porém uma avaliação, olhar para dentro de sua empresa, antes de tomar uma decisão é indispensável. Mudanças geram transtornos, custos e demanda muita qualificação, vejo como um caminho sem volta. Talvez um estudo melhor no seu processo interno, uma customização pra sua realidade é mais vantajoso do que uma aposta, processos customizados podem gerar os mesmos benefícios.

  24. Rogéiro 29/04/2014 at 14:57 #

    Em uma empresa que trabalhei utilizavam o rup, depois foram para o gohorse extremo e depois de ouvir falar do ágil e que tudo ficaria mais rápido ao utilizar resolveram mudar a metodologia. O que eu achei estranho logo de cara foi que o motivo para mudar para uma metodologia “ágil” era na verdade o significado de “ágil” na mente deles: algo mais rápido e com custo menor.
    Tudo bem, é uma das coisas que se tenta atingir utilizando este tipo de metodologia, porém para atingir isso você tem que utilizar o que a metodologia prega e se não funcionar tentar adaptar aquele processo para a sua realidade. Mas para eles nada disso importava… Na cabeça dos gerentes, esta palavra significava apenas custo e prazos menores.
    Eles não consideraram os valores de se utilizar a metodologia e que deveríamos pelo menos tentar aplicá-los no projeto. Acharam que ter uma equipe multidisciplinar significava ter todos os membros da equipe especialistas em todas as atividades, quando na realidade isso é apenas uma utopia, ainda que existam técnicas (como programação em par, por exemplo) que tentam ajudar nesse sentido, tentando por exemplo nivelar o conhecimento da equipe. Eles também acharam que programação em par era uma perda de tempo (pra que pagar duas pessoas pra fazerem uma atividade quando cada um deles poderia fazer algo diferente?), quando na verdade isso serviria
    para disseminar conhecimento e tornar a equipe mas experiente com o tempo.
    Ignoravam que os sprints iniciais deveriam ser utilizados para medir a média de pontos que a equipe podia entregar e sempre pressionavam para a equipe produzir mais pontos, o que vai contra o propósito de ter uma média de pontos, que é justamente para poder ajustar o projeto para ser entregue apenas o que for possível de acordo com o que a equipe pode produzir, ajustando o escopo do projeto se necessário. E acho que tudo já começou errado porque, até onde eu sei, a equipe deve ser auto gerenciável, não precisa ter este tipo de gerente sangue suga tão comum no gohorse.
    É lógico que a aplicação da metodologia ágil falhou, porque na verdade não aplicaram nenhuma metodologia ágil.A meu ver não adianta nada tentar aplicar esta ou qualquer outra metodologia se a mentalidade das pessoas não mudar. Neste projeto eu acredito que qualquer metodologia seria um fiasco. O que eu vi neste caso que comentei acima é que a metodologia “ágil” “falhou” porque ninguém que está acima entendeu direito o seu propósito e o porque das suas práticas, ou seja, são os mesmos comandantes que não conseguiam fazer a coisa funcionar com o rup, depois com o gohorse e agora com o ágil. E a conclusão que eles tiraram de tudo isso? Que a metodologia ágil é ruim, assim o processo anterior era e provavelmente o que vier depois será também. Neste caso específico, a meu ver, os objetivos não seriam atingidos pela utilização de nenhuma metodologia, seja ela ágil ou não, simplesmente porque todo o planejamento e as perspectivas do projeto eram irreais, como eu acredito que ocorra em muitos outros locais. E como sempre, em barco que não anda, a “solução” é trocar o remador, mesmo que quem esteja fazendo tudo errado seja o comandante…

  25. Jesse James 29/04/2014 at 15:48 #

    Maurício,

    O problema, mais uma vez, é a falta de um estudo verdadeiro. É necessário, na verdade, que se matem (no sentido figurado, é claro) os gurus. É preciso que se deixe de tratar engenharia de software como uma religião.

    Por exemplo: Gostaria de ver um estudo que comprove a eficácia de um método ágil. Não sou contra os métodos ágeis, acho a ideia muito interessante e faz sentido em alguns casos. Mas a verdade é que não vejo ninguém citar algo do tipo: Um estudo feito pelo Gartner ou pelo IPEA ou pelo fulano aluno de mestrado da universidade X comprovou que em equipes com características tais e tais os métodos ágeis X, Y e Z são mais eficazes que os métodos A, B, C.

    Se você conhecer algum trabalho desses ou estiver trabalhando nisso, por favor divulgue. Se já divulgou, poderia me indicar? Eu gostaria de colocar algo assim na minha próxima aula de Engenharia de Software.

Deixe uma resposta