Transição - Não existem métodos porta de entrada

Tenho visto uma onda de pensamentos modernos sobre como iniciar uma transição ágil. Modernos se estivéssemos na década passada. Parece que voltou a "moda" de que o Scrum seria uma boa porta de entrada dos métodos ágeis nas empresas. Apesar de respeitar quem pense dessa forma, eu tenho as minhas dúvidas. Para esse post, chega de rapidinhas.


Tenho meia década trabalhando com transição e o que tenho visto, principalmente em grandes corporações, é justamente o contrário. OK, o Scrum é disciplinador e "força" que a empresa trabalhe segundo a sua cartilha. Só que, infelizmente (ou felizmente), as grandes corporações (pelo menos onde eu tive o prazer de estar inserido), não estão nem aí para o fator disciplinador do Scrum. OK, elas podem ter dores, mas não querem que algum método/framework/sistema/whatever lhes cause mais dores.

Mas por que o Scrum causaria mais dores?

1. Para o Scrum "funcionar" você precisa ter o cliente presente.
2. Para o Scrum "funcionar" você precisa ter equipes multidisciplinares.
3. Para o Scrum "funcionar" você precisa ter uma área de QA ou absorvida pela área de desenvolvimento ou muito próxima da área de desenvolvimento.
4. Para o Scrum "funcionar" você precisa ter variação de escopo.
5. Para o Scrum "funcionar" você precisa ter desenvolvedores "pigs" preocupados com a qualidade.
6. Para o Scrum "funcionar" você precisa ou não ter fornecedores (terceirização/body shop/outsourcing) ou que eles estejam alinhados com a filosofia do Scrum.
7. Para o Scrum "funcionar" você precisa ter gerentes/diretores facilitando a auto-organização.

São apenas 7 pontos. Eu poderia passar a tarde inteira escrevendo sobre os problemas para entrar com Scrum em diversos contextos.

Algum especialista em Scrum pode até dizer: para o Scrum entrar ele não precisa ter tudo isso. OK, mas para funcionar precisa. Quantas sprints a iniciativa suporta falhar? Quantos indicadores vermelhos antes de pedir a cabeça de um gerente? De um diretor?

Nesta quase meia década atuando com transições, trabalhei com quase uma dezena de empresas, onde apenas uma era pequena. As outras eram médias e outras gigantes, principalmente no setor de telecom. Até na empresa pequena, uma micro empresa ligada ao setor de rastreamento de veículos de carga, onde eu também atuo como desenvolvedor, eu usei uma técnica que, ao longo desta minha experiência, se mostrou mais eficaz: AgileMMA.

Em todas estas empresas onde eu tive a felicidade de atuar, nenhum dos 7 pontos estava presente e ninguém tinha a menor preocupação com eles. Sim, eles queriam uma forma nova e mais eficiente de desenvolver software acontece que, se eles se adequassem ao Scrum, o choque de gestão faria com que a empresa provavelmente quebrasse.

Vamos pegar um exemplo: equipes multidisciplinares. Se você não tem, você forma. Se alguns não querem ser formados, são substituidos. Sim, ao longo destes anos eu percebi que alguns desenvolvedores simplesmente "não queriam"/"estavam preparados para" lidar com o desenvolvimento ágil. E eu pergunto: como manter a empresa substituindo tanto da sua capacidade intelectual? Tanto para ensinar novamente? Tanto para mitigar da Lei de Brooks.

Vamos pegar outro exemplo: cliente presente. Em todas as ocasiões que eu testemunhei, a iniciativa ágil nasceu na área de TI. E não é que a diretoria ou a vice presidencia de TI não quisesse envolver a área cliente. A área cliente simplesmente resiste a adoção do ágil. Por que? Porque com o cascata, o cliente entrega uma lista de requerimentos e cobra a área de TI 8 meses depois. Dá uma nota para a área de TI 8 meses depois. Com o desenvolvimento ágil, a área cliente precisa sujar a mão de sangue. Precisa também se comprometer com o resultado. Precisa também colocar o bônus dela em jogo se comprometendo com o resultado.

***

Algumas empresas para forçar a entrada do Scrum, usam projetos pilotos, pessoas "eleitas" que trabalharão em uma forma mais humana para desenvolver software. Essa abordagem é falha por diversos motivos, mas vou destacar dois: 1) Gera ciumes nos não eleitos, pois além de não estarem trabalhando com processos na "crista da onda", a agilidade prega que as pessoas precisam ter respeito às pessoas. O que fazer com os outros projetos que não estão recebendo esse respeito? Algumas pessoas dizem que o "piloto" precisa estar escondido. Mas você acha que isso é de fato respeito às pessoas? A todas as pessoas? Você acha que em uma empresa grande uma iniciativa como essa consegue ficar escondida por muito tempo? Você acha que as pessoas não se falam? 2) O que fazer quando o piloto der certo? Forçar a entrada do Scrum no resto da empresa? Será que a empresa terá fôlego para mudar tanta coisa ao mesmo tempo?

***

Você pode estar pensando: Poxa Celso, isso quer dizer que os métodos ágeis não são para empresas médias e grandes?

Mas claro que são. Mas em médias e grandes empresas acontece a metáfora que tenho usado muito na atual transição em que estou ajudando: Você está trocando a turbina do avião em pleno vôo. Simplesmente existem parafusos que você não pode mexer, se mexer o avião cai. Gerentes, diretores e VPs, em sua grande maioria, são grandes estrategistas. O que você acha que acontecerá com a iniciativa ágil caso eles percebam que o "avião pode cair"? Pois é.

Então como fazer?

Existem abordagens mais leves, como o Kanban, que visam mapear o fluxo de valor, o método de trabalho atual, com o objetivo de mostrar onde estão os problemas e sugerir soluções pontuais, evolutivas. Entretanto, eu estou convencido de que a melhor abordagem para transições seja de fato o AgileMMA, inclusive para pequenas empresas.

O Scrum foi considerado porta de entrada no início da década passada, principalmente para empresas pequenas e por ter criado o mercado de certificação ágil, tão importante para as empresas 1.0. Antes de transicionar para a gestão moderna, as empresas possuem a cultura 1.0.

Hoje em dia, ainda vemos esse pensamento dogmático por aí. Pessoas tentando convencer que o Scrum é a melhor porta de entrada para a agilidade nas empresas que desejam realizar uma transição. Mas será que essas empresas estão preocupadas com o vale da morte do kaikaku? Será que essas empresas estão preocupadas em realmente tornar a empresa cliente mais ágil? Ou está mais preocupada com a venda de certificações e consultoria?

Uma dica: quando uma empresa, através de uma pessoa, disser para você que o método A ou a abordagem X ou o framework Y é o mais aconselhável para o seu contexto, mesmo sem conhecer esse seu contexto, pesquise sobre as certificações que essa pessoa (ou as pessoas dessa empresa) têm. Procure saber se vende certificações. É provável que a resposta seja sim. Eu tenho uma abordagem que reconheço ser bem radical, mas bem defensiva também: desconfie de uma pessoa que te vende um método X se essa pessoa é certificada nesse método X. Vejo um grande e perigoso conflito de interesses nesses casos.

Agora se uma empresa diz que vai usar os princípios do Lean, dos Sistemas Complexos (Pensamento Complexo) e da Teoria das Restrições para analisar o seu contexto e chegar a uma solução, um set de práticas, que vão se encaixar na sua transição, com baixo risco e com uma abordagem pragmática, eu colocaria todas as minhas fichas nessa empresa.

Diagnosticar, aprender, adaptar, diagnosticar, aprender, adaptar.... infinitamente.

Não acredite em empresas que chegam com formulas mágicas e milagrosas. Isso não existe.