Dois meses atrás a InfoQ informou sobre o popular artigo do Jim Shore O Declínio e a Queda do Agile, que destacou a tendência das organizações adotarem "Agile" (no nome) mas falharem em adotar o que realmente significa Agile (na prática). Este artigo, tanto da InfoQ como do blog do Jim, acumularam enormes respostas que vale a pena conferir.
Mas, infelizmente, a saga continua. Os líderes da comunidade tal como Martin Fowler, Joshua Kerievsky, Ron Jeffries e outros, levaram a declaração inicial de Shore a alguns passos além, postando seus próprios pensamentos sobre o que está acontecendo.
Em seu artigo Flaccid Scrum (Scrum Flácido), Martin Fowler em grande parte re-itera o sentimento de Shore e sugere que, o que está faltando em muitas adoções ágeis é a aplicação das práticas técnicas destacadas pelo Extreme Programming, tais como pair programming, integração contínua, e test-driven development. Como Shore, Fowler reconhece o que isto é mais comum em organizações que estão escolhendo Scrum como sua metodologia preferida, mas que mesmo assim, isso não é culpa do Scrum em si. Como um remédio e lembrete, ele enfatiza que (entre outras coisas) as pessoas que lideram estas adoções do Scrum sejam mais abertos para estimular as práticas técnicas apropriadas:
A comunidade precisa redobrar seus esforços para assegurar que as pessoas compreendam a importância de uma prática técnica forte. Certamente, qualquer tipo de revisão de projeto, deve incluir uma análise de quais os tipos de práticas técnicas estão presente. Se você está envolvido ou ligado a um projeto como este, avise (faça barulho) se o lado técnico for negligenciado.
Fowler também acrescenta um bom lembrete de que no centro de qualquer sucesso ou falha, na adoção de agile, são as pessoas por trás dela; é o time que traz o sucesso ou a falha.
Logo após Fowler publicar este artigo, o fundador daIndustrial Logic e IXP Joshua Kerievsky trouxe o tópico para o Grupo XP do Yahoo. Em seu primeira post, The Whole Enchilada, Kerievsky reprisou uma mensagem que ele mandou à comunidade Ágil em 2006 em uma palestra muito popular de mesmo nome, a mensagem em grande parte foi "faça tudo, e faça tudo desde o início":
Scrum Flácido? O Declínio e a Queda do Agile?
Mais evidências que organizações e a comunidade de desenvolvimento precisam do Bolo inteiro -- agilidade técnica e gerencial, não apenas só uma ou outra.
A idéia de que "só iriam evoluir adotando coisas técnicas" é, na minha humilde opinião e experiência, uma suposição ingênua. A maior parte do tempo, essa adoção não acontece ou acontece tão casualmente que é como se nunca tivesse acontecido absolutamente nada.
O Scrum seguido à risca, não diz nada sobre técnicas de agilidade. É como vender um carro sem cintos de segurança e outras funções críticas de segurança. Você precisa ter sorte o suficiente para conhecer as pessoas corretas que irão lhe dizer o que você precisa em termos de práticas técnicas também (embora ainda façam acreditar nesta idéia de "fase posterior de adoção").
O XP (que, como nós nesta lista sabemos, é muito mais do que apenas práticas técnicas), Scrum+XP, IndustrialXP, etc., são exemplos de Bolos inteiros.
Nós continuamente descobrimos que as organizações e a comunidade de desenvolvimento são bem melhores quando começam com o Bolo Inteiro enquanto esperam para eles descobrirem quão insuficiente seu processo ágil é.
Então precisamos reconhecer que bons processos endereçam coisas críticas e agilidade técnica é definitivamente uma coisa crítica no desenvolvimento de software. É um péssimo conselho adiá-lo para uma fase de adoção posterior.
O post do Kerievsky começou com um furacão de discussões, aproximadamente 90 entradas debatendo o mérito e a aplicabilidade da sugestão de Joshua, bem como várias possíveis razões sobre o porquê adotar o Bolo Inteiro acontece ou não em muitas organizações, e mais. A thread é leitura obrigatória.
Em seu artigo Context, My Foot!, Ron Jeffries concorda com Shore, Fowler e Kerievsky que no centro da maioria das adoções de agile que falharam, há uma falah na adoção de tudo que é necessário para verdadeiramente ser ágil:
Você tem que fazer as coisas certas e você tem que fazer direito as coisas, para alcançar o sucesso.
...
Para aplicar Scrum ou XP ou qualquer outra forma Agile com sucesso, você deve refatorar. Desculpe, não é opcional. É necessário.
...
Há muito mais práticas, geralmente descritas no XP e em outros lugares, que são tão essenciais como esta. Esta realmente não é uma escolha. Se você quiser ter sucesso, você tem que fazê-lo.
Mas a verdadeira jóia do post do Jeffries vem depois que ele interpreta a mensagem "sim, temos que fazer o bolo inteiro", quando ele explica o que realmente pode estar no centro das falhas das organizações é adotar tudo que o agile é: a própria organização. Apontando para o elefante pink na sala, Jeffries afirma:
Como XP / Agile / Scrum tem se tornado mais popular, muitos times e indivíduos estão querendo adotá-los, ou estar na moda. Isto levou a uma escola de métodos Ágeis chamada de “dependentes de contexto”. A idea é que não importa a "marca" de Agile esteja em discussão ela é “muito rígida” e “não se enquadra em nosso contexto”. Então nós temos que modificar o Agile porque Deus sabe que não podemos modificar nosso contexto.
Bem, minhas queridas pequenas crianças, eu tenho más notícias para vocês. É seu precioso contexto que está te prendendo. São seus executivos nível-C e gerentes de alto escalão que não podem delegar sua responsabilidade real e autoridade para as pessoas. São as pessoas de produto que estão ocupadas demais para explicar o que realmente precisa ser feito. Trata-se das pessoas de layout que não podem criar um espaço de trabalho para trabalhar nele. São seus programadores que não aprendem as técnicas necessárias para prosperar. São seus gerentes e product owners que continuam aumentando a pressão até que qualquer foco na qualidade seja expulsa do projeto.
Então, esta é uma discussão que merece muita atenção - Agile está em um ponto crítico. Os experts que olhamos continuam a falar sobre isso e você também deve. Todos nós devemos. Então continue aqui.