Hoje em dia não considerar o pensamento ágil parece uma afronta ao bom senso, mas você sabia que seus próprios criadores, criticam abertamente a forma na qual os valores indicados no Agile Manifesto vem sendo deturpados?

 

Dave Thomas, um dos autores, é categórico quanto a isso. Basta ler seu artigo “Agile is Dead” para entender sua decepção, ou assistir sua palestra aqui.

 

Algumas das considerações são tão óbvias que parecem desnecessárias, mas quando se observa a crescente procura por métodos infalíveis que ululam por aí, principalmente na esteira dos mais preguiçosos que adoram receita pronta ou alguma modinha para surfar no hype, a coisa começa a fazer sentido.

 

Uma dessas críticas se refere ao óbvio fato de que ‘’ágil’’ é um adjetivo, portanto não pode ser vendido como método. Também não existe essa de metodologia “ágil”. Para entender isso é preciso diferenciar método e metodologia, que são coisas diferentes. O que por si só já confunde muita gente.

 

O que existe é um conjunto de valores e princípios que permitem a adoção do adjetivo ao método utilizado, que pode ser qualquer um. Portanto, o foco não é o método, mas em como praticá-lo, em como se praticam os valores e os princípios que permitam que a agilidade seja perceptível.

 

Isso nos leva a outro fator relevante a considerar. Nem só de SCRUM vive o homem. O Agile Manifesto é resultado da reflexão sobre diversas e diferentes metodologias, dentre elas a SCRUM, a Crystal Clear, a XP e a DSDM, portanto, não se pode reduzir a um conceito único. Portanto, você pode ser um expert em SCRUM e não imprimir agilidade alguma em sua aplicação por não ter internalizado os valores do Agile Manifesto. Dedução lógica então, conhecer sobre SCRUM não te torna um agilista.

 

Na outra ponta temos o paradoxo de Teseu que não me deixa surtar sozinho. Para quem não conhece, este paradoxo revela uma questão que dá nó na cabeça de muitos filósofos pois trata de uma questão relativamente simples.

 

Se o barco de Teseu tiver suas peças trocadas ao longo do tempo de forma a nenhuma original restar, continuaria sendo o mesmo barco? E se alguém pegou todas as peças jogadas fora e remontou o velho barco? A apropriação das peças tornam a remontagem o mesmo barco de Teseu? E o barco que sofreu atualização contínua de peças não pode ser considerado o de Teseu? É possível a existência de dois barcos, quando só um de fato foi utilizado? Esses questionamentos dão nó na cuca de filósofos há séculos.

 

E o que Teseu tem a ver com agilidade? A resposta vem à remo lá do Japão e se chama Kanban. As tais “metodologias ágeis” (me pergunto se alguma metodologia sai correndo por aí dando perdido em alguém ou se faz algo às pressas, como trocar um pneu, sempre que leio esse termo) incorporaram uma ferramenta que não foi desenvolvida, não foi pensada, nem articulada para a área de TI, foi como o barco remontado de Teseu, tomado em apropriação. Então, o nome e os benefícios de seu uso de sua origem ainda lhe cabem?

 

Esqueça essa de que Kanban ou Lean é relativo aos tais métodos ágeis. Este dueto surgiu para a indústria automotiva. Enquanto seus valores mais subjetivos até podem ser utilizados como alcance da agilidade, suas técnicas tem sido grosseiramente deturpadas ao ponto da descaracterização quase completa. Você pode até argumentar que isso não invalida o uso, e estará de certa forma com razão. Contudo, a associação de uma ferramenta desenvolvida para a indústria automobilística que deturpa tanto a essência de sua prática nos deixa diante do mesmo dilema do pobre herói Teseu.

 

O que surgiu para gerenciar o controle de estoque entre atividades de um sistema produtivo puxado – aquele em que a produção só acontece sob demanda confirmada – virou um cardboard muito mais parecido com listas de tarefas do tipo “Para Fazer” bombada. E afirmo isso depois de anos aplicando essa ferramenta na indústria, e anos dando treinamento sobre seu uso. A  desconfiguração chega a ser grotesca, então por que não dar logo outro nome? Surfar na onda? Se aproveitar da fama do barco de Teseu? Vai saber!

 

Se você leu The Lean Startup de Eric Ries ou Running Lean de Ash Maurya, e se conhece os princípios do modelo Toyota maestralmente detalhados nas diversas obras de Taiichi Ohno e Eiji Toyoda vai entender que são apenas os princípios, os valores norteadores, que existem em comum. Suas técnicas e ferramentas não são copiadas ipsis litteris. O motivo é simples, o contexto automobilístico não é o mesmo da TI. A dinâmica, os processos, as variáveis, o contexto são completamente diferentes. Portanto muito cuidado ao buscar pela agilidade ou pela adoção de qualquer método que tenha sido transportado de um contexto a outro, principalmente quando você não conhece a origem.

 

Com isso em mente fica mais fácil entender que ao falar sobre agilidade estamos fazendo uma referência direta a seus valores:

 

1- Indivíduos e interações acima de processos e ferramentas;

2- Produto funcional acima de documentação abrangente;

3- Colaboração com cliente acima de negociação de contrato;

4- Resposta à mudança acima de seguir planos formais.

 

Estes valores reforçam duas variáveis que a gana por métodos enlatados desconsidera: a subjetividade e o fator humano. Considera que o trabalho de programação é de alto valor subjetivo, relativo à qualificação e a habilidade do programador de descrever ideias em códigos para uma determinada demanda, entendendo que esse exercício é puramente imagético e subjetivo nas entranhas e que será tão diferente quanto a exertise de cada programador. Assim sendo, quanto menos método enlatado que restrinja a criatividade, melhor.

 

Não importa qual o método escolhido, o que define a agilidade não é a receita, mas como os envolvidos no time internalizam e praticam seus valores e princípios. É a adoção destes valores que garante a agilidade, não o contrário.

 

Contudo o estrago da gourmetização já está feito e a deturpação dos valores envenena diversas áreas, passando longe de sua origem.

 

Portanto, cuidado! Ao adotar conhecimentos alheios a sua área, conheça seus princípios e adapte seus benefícios, mas não se aproprie do conceito julgando que o contexto seja replicável, porque não será.

Compartilhe este artigo:

o autor
Sobre

O Autor

conteúdo relevante
Conheça

Nossos conteúdos relacionados

Preencha os dados abaixo e receba seu e-book

Preencha os dados abaixo e receba seu e-book

Preencha os dados abaixo e receba seu e-book

Preencha o Formulário para Solicitar Cotação

Preencha os dados abaixo e receba seu e-book