Por que Ágil (quase) não acontece

Vamos conversar um pouco.

Adoções, aderência, aceitação ou seja lá o que for que você chame o processo de começar a viver com a Filosofia Ágil é um processo muito doloroso na maioria das empresas. E quanto maior a empresa (ou maior a mentalidade legada como diria Rodrigo Yoshima) mais arduo é o fardo.

Como sabemos, Ágil está ligado a pessoas e aqui começa a dificuldade. O choque da Filosofia Ágil é muito grande mediante ao modus operandi. Empresas de ISV, Software Houses tem um ambiente quase “hóstil” para se receber uma nova Filosofia, quanto mais uma que na visão gerencial/administratvia aumenta o poder e autonomia do “chão de fábrica” de forma quase revolucionária.

Porém, não só a Gerência tem dificuldades com esta nova cultura. O pessoal que vive no Gemba tem dificuldade no entendimento do Ágil.

Vamos tentar entender o ambiente de desenvolvimento de Software e ver os impactos gerados por cada aspecto, nas dificuldades de ser Ágil!

A Cultura
As pessoas não são preparadas, instigadas, inspiradas para mudanças de culturas, exploração dos seus valores, reconhecimento de erros e da melhoria contínua. Não somos incentivados a retrospectivas, somos reprimidos a nunca poder falhar e devemos de preferência aprender apenas com o erros dos outros. Errar dói. Errar é sinônimo de fracasso.

O Sistema
Nosso sistema educacional não tem os mesmos valores da Filosofia Ágil na sua essência. Nossas faculdades infelizmente não acompanham a evolução do mercado, estando defasadas não só sobre tecnologias mas também sobre as atitudes e competências que um profissional de TI deve ter.
Logo, poucos querem aprender além do aprendizado. Poucos querem saber o “por quê?” além do “como?”. Vários gurus do Agile tem ultimamente repetido uma frase de Deming “Um sistema ruim vence uma pessoa boa” (cuidado com a persepção de ruim e bom).

A paixão
Muitos também não tem paixão pelo que fazem. O “boom” da decada de 90 e 00 na área de TI fez com que o Mercado de vagas estivesse em alta com bons sálarios. Porém não foram atraídos apenas os que já tinham apreço pelo desenvolvimento de software. Vieram aqueles que aproveitaram a onda e estão aí por estar. Aprenderam um paradigma de programação, uma linguagem e um ciclo de vida de software e estão tocando a vida. O amor e a melhoria contínua não existem. A cooperação que se espera de um grupo de pessoas motivados em busca de um objetivo é raro.

A metáfora
A comparação com Engenharia Cívil ou Linha de Montagem criou uma geração de profissionais com um modelo mental que não condiz com a realidade de desenvolvimento de software. Seja nos anos 80, 90 ou 00. Esta metáfora se perpetuou por muito tempo e enraizou-se no Desenvolvimento de Software.

O PMI
O modelo de gerenciamento também foi copiado. Não sou injusto e reconheço todo o valor do PMBOK, porém, entre o PMBOK ter bom conteúdo e um PMP gerenciar de acordo com seu ambiente e buscar o melhor, são outros quinhentos. A metáfora do chão de fábrica se fez presente e logo o modo de gerenciar igual a uma Linha de Montagem foi a resposta as necessidades. Cooperação e pressão raramente coexistem. O trabalhor do conhecimento é diferente.

O CMM
Logo, como garantir que um projeto, grupo de pessoas, uma empresa realmente sabe fazer software? Um modelo de maturidade parece uma flecha no alvo. Mas não é. Óbivo que devemos buscar a melhoria contínua, mas devemos ir de encontro as nossas necessidades e em prol de gerar valor. Um modelo de maturidade baseado no que você DEVE ter e não no que você precisa ter foi absorvido. Quanto uma software house gasta para atingir um nível de maturidade 5? Será que este valor é revertido em lucro pra ela? Será que os projetos e produtos desenvolvidos reverteram valor aos clientes e usuários? O modelo de maturidade garante isto?

O RUP
O mal compreendimento do RUP pelos profissionais e empresas tornou extramemente, na maioria dos casos, travado os processos de desenvolvimento de software. Papéis, aterfatos, processos que para muitos não faziam sentidos, eram gerados ou realizados pelo simples fato de estar no RUP. Poucos questionavam as necessidades reais. Será que não fazemos o mesmo com Ágil? Será que esta mentalidade persiste?

O Mercado
O sistema opera de forma a consolidar-se. Logo, não demorou para CMM ser parte do sistema de compra e venda de Software. Bem como gerentes PMPs, manutenção da mentalidade “chão de fábrica”. Terceirizações, selos de qualidade, contratos, profissionais baratos e assim o mercado perpetuou-se. O famoso mal necessário, que cada vez mais virou mal.

O modelo de transição
Sabiasse que precisava mudar o cenário do Desenvolvimento de Software. O Manifesto Ágil foi o pontapé inicial. Porém neste caso, o “como” dificultou mais do que o “por que”. O Scrum foi alçado como o grande arauto da Agilidade. Porém, uma adoção ao Scrum não é tão simples. Na verdade, é bem doloroso. Mudar papéis e cerimônias juntamente com uma inserção de nova cultura é muito doloroso.

As questões “Onde a Gerência se encaixa na Agilidade”, “Auto-organização” e etc. foram discutidas muitas vezes de modo mais raivoso, do que educativo. Parando para pensar, sabemos que Agile traz um grande benefício quanto pessoas, sentimentos e motivação, mas não foi muito pensado sobre como disseminar isto.

Muitas vezes a Agilidade (com alcunha de Scrum ou vice-versa) foi imposta tanto quanto uma nova PA e suas responsabilidades para um nível de maturidade maior de CMMI em uma empresa. Sabiamos que o remédio era necessário, mas preferiu-se aplicar através de injeção do que em gotinhas.

O Orgulho
Quantas vezes você já ouviu as frases: “Ou você é ágil, ou você não é”, “Ágil não é para todos”, “Sem Ágil, você irá falhar miseravelmente”. Estas frases não distorcem e quebram completamente a Filosofia Ágil? Mas o orgulho de ser Ágil fala mais alto em muitos casos e em muitas pessoas. A perca da humildade não colabora para a disseminação de Ágil. Uma coisa é você ajudar alguém a reconhecer que é preciso melhorar, aprender e estudar, outra coisa é fazer alguém se sentir incompentente, diferente, envergonhado.

A Certificação
O modelo/modo de certificação das maiores representantes do Ágil colabora para um defícit no aprendizado correto do Ágil. As vezes mais parecendo um negócio, as certificações são uma faca de dois gumes. Alimentando mais ainda um mercado famigerado de selos e com baixa compreensão de seu valor, as certificações não dão um conteúdo agredado forte e aumenta o ego dos certificados.

O Projeto
Colocar pessoas, valores, conhecimentos, aprendizado, relacionamentos e metas dentro de um tempo pré determinado. Um projeto é muito mais que um produto esperado e um espaço de tempo. O que é mais importante em um projeto: Difundir o conhecimento? Gerar o ROI? Integrar pessoas? O desafio é enorme e geralmente o tempo é curto e o contrato tem uma multa enorme.

A Quantidade
Com Scrum você gerencia, você pode usar XP e FDD para sua engenharia. Adicione Lean e Kanban. Some UX ao processo. Busque o MVP, com MMF, melhore com Kaizen mas não esqueça do Hansei. Cuide do Gemba, maximize o ROI e o ROE. No fim, uma Lean Startup, com Lean UX também tem muito valor. Medir o Lead Time, o Cicle Time, use User Storys, Story Points, mas o Cumulative Flow pode ser melhor que um Burndown.

Olhe para tudo isto e pense em compilar estes conhecimentos em um livro. Seria este livro do mesmo tamanho do “Engenharia de Software” do Pressman, do mesmo tamanho do “CMMI”?. Faça um site, ele teria o mesmo tamanho do antigo site do RUP?

No fim, sempre dizem para você usar o que realmente você precisa, mas não esqueça do ROI, do PDCA, do Kaizen, do Lean, do MVP e etc. etc. etc. Mas foque no que lhe acrescenta valor, mas não esqueça …

A Consultoria
Pode mesmo uma consultoria gerar a mudança da Filosofia de uma Empresa? Um consultor seria definido como Pig ou Chicken? Aparecer na empresa uma vez por semana é o bastante para plantar uma semente de mudança e ajudar em uma transição menos dolorosa? O modelo de consultoria também não foi copiado das consultorias “CMMI”? Não deveriam mudar para a Filosofia Ágil?

Tudo
O cenário composto pelas citações anteriores definem um ambiente onde é realmente complicado a Filosogia Ágil ser difundida. 10 anos após o Manifesto Ágil, sabemos seus valores, os ganhos e qualidades, mas não sabemos muito bem como fazer acontecer. Arrisco dizer que 80% das empresas que dizem “usar Ágil” não usam. E quando digo Ágil, não falo de Scrum, XP ou qualquer método ou processo. Digo a Filosofia.

É possível ter a arrogância de dizer que mudando um ou dois itens levantados a cima, e garante-se que tudo vai melhorar? Obviamente não podemos descartar todas as melhorias que aconteceram nestes 10 anos para contribuir com a difusão da Cultura Ágil. Mas usando algo da moda, o Pensamento Sistêmico, podemos nós mudar apenas alguns itens e achar que o Ágil vai mesmo se espalhar e gerar bons frutos.

Uma mudança de Cultura é algo muito profundo. Particularmente eu nunca vi uma mudança tão abrupta quanto a Cultura Ágil no Desenvolvimento de Software. Tive experiências em empresas de Autopeças, Manufatura, trabalhei como Eletricista e tanto a área de atuação (Eletricidade Industrial) quanto o ambiente (Empresas) nem de perto, nos últimos 20 anos passaram por algo igual ao que a área de TI passa nos últimos 10 anos.

Se o Ágil mira em Pessoas, a interação entre elas, busca a confiança, transparência e colaboração, não é apenas uma Framework utilizada em um projeto, com uma supervisão de consultoria, com algumas ferramentas que vai mudar um ambiente inteiro, uma empresa inteira. Não é só ficar repetindo exaustivamente os valores do Manifesto que fará as coisas acontecerem. Não é apenas palestrando sobre comos as coisas melhoraram 400% (duvido) na sua Empresa depois do Ágil que vai ajudar na disseminação da Filosofia Ágil.

Eu particularmente me lembro apenas de duas palestras onde eu vi as pessoas compartilhando fracassos e achei elas tão mais produtivas quantos as que abordam as melhorias, que muitas vezes são melhorias superficiais.

Obviamente que não se pode acreditar que ambientes Ágeis não existem problemas e dificuldades, mas no minímo que se espera é que os problemas sejam encarados de forma diferente do convecional, em ambientes verdadeiramente Ágeis. Isto é a prova da Filosofia Ágil disseminada, quando ela muda seu modo de pensar e agir.

Será que o Ágil acontece?

Anúncios

2 comentários sobre “Por que Ágil (quase) não acontece

  1. Simplesmente excelente! Vi seu post pelo RSS da Crafters, mas o post não está mais lá. Felizmente o achei aqui.

    Parabéns pela mega consolidação de tantos elementos, pontos de vista, fatos, etc. Um monte de gente fala que Ágil é difícil, que é doloroso, que é uma mudança de cultura, etc. Gostei muito da sua forma, bastante analítica e, principalmente, detalhada. Referência certa! 🙂

    Abraços!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s