Ep. 16 - O que forma um bom Agile Coach?

Vamos falar sobre o que forma um bom Agile Coach. Dentro da nossa empresa, a gente não tá nem mais usando o termo Agile Coach formalmente, a gente trocou para Agile Expert, e isso já tem a ver com a primeira pergunta: que problema estamos resolvendo aqui ao falar sobre o que forma um bom Agile Coach?

Só acrescentar uma visão sobre que problema a formação, ou o próprio processo de evolução de um Agile Coach, ajuda a resolver. Pensando a empresa como uma persona: métodos ágeis já existem no nosso ecossistema há algum tempo, mas para a grande maioria das empresas, agile sempre foi um bicho de sete cabeças, um negócio meio mítico. Essas empresas precisam de alguém que chegue e diga, você tem essas opções, esses riscos, pode minimizar assim. Na maioria das vezes, as empresas começaram a chamar isso de Agile Coach, por isso esse papel se tornou tão massificado, assumindo um protagonismo em ajudar as organizações a fazer essa transição.

Sobre por que trocamos Agile Coach por Agile Expert: isso tem muito a ver com como a palavra 'coach' se popularizou no mercado de forma geral, coach espiritual, life coach, coach quântico. Uma infinidade de tipos de coaching, e alguns não exerciam um bom papel, com formação inadequada, e isso gerou uma depreciação desse tipo de trabalho. A gente, como empresa de consultoria, também queria se posicionar de uma maneira diferente: a gente não está fazendo só o coach, está fazendo outras coisas que ajudam a estratégia da empresa como um todo, falando de business agility, de agilidade organizacional.

A empresa é vista como vários pedacinhos: financeiro, marketing, jurídico. No modelo industrial, a gente sempre pensou que, se cada componente performa na sua excelência independentemente, a coisa vai sair. A interação entre esses componentes não era vista como relevante. Isso é exatamente pensamento sistêmico: parar de ver componentes isolados e voltar a atenção para como eles se relacionam, como aquela atividade do jurídico ajuda ou atrapalha aquela do financeiro. A grande mensagem é que a importância está em olhar a empresa como um todo, como um ser vivente que consegue entregar coisas diferentes.

Se você olhar a evolução da nossa comunidade ágil e a história do papel do Agile Coach, vai observar que ele é um fenômeno emergido do mercado, diferente do Scrum Master ou do Product Owner, que têm instituições e autores associados (Jeff Sutherland, Ken Schwaber): não existe um elemento central que determine o que é Agile Coach. Isso é bom e ruim: bom porque permite evolução e adaptação; ruim porque, por ter diferentes formatos, você cai na armadilha de criar variações que não geram o resultado necessário, não criam o impacto de transformação, o senso de participação e ownership.

Esse episódio foi sugerido por alguém que queria dar direções para quem está perdido nessa imensidão de funções e disfunções: tem gente prometendo formar um Agile Coach em um final de semana. Numa roda de conversa no Agile Coach Camp de 2019, sobre essas disfunções que o mercado gera em cima do papel, um colega me disse que não queria ter um papel moralizador de dizer o que é certo ou errado. Isso bateu forte em mim: eu também não quero ser moralizador. Então quero fazer um call to action para quem se vê como agente de mudanças, mesmo sem o label Agile Coach: se enxergue dentro de um de dois arquétipos.

Um é a síndrome do impostor. Quando comecei a trabalhar como Agile Coach, caí muito nisso, direto pensando 'não está dando resultado, será que eu presto pra isso?'. Se você está nesse arquétipo, tenta encontrar caminhos para ter mais autoconfiança. O outro arquétipo é o 'macaco doido', excessivamente confiante, que sai apertando todos os botões porque já viveu isso e aquilo. Se você se vê mais nesse arquétipo, tenta entender as provocações que a gente traz aqui para achar um caminho benéfico.

Onde o Agile Coach se encaixa dentro das organizações? De maneira geral, ele tem um papel fundamental na transformação. A partir do momento que a empresa decide que quer abraçar a agilidade e contrata alguém para ajudar, geralmente a primeira missão é como estruturar essa transformação, desdobrando em formação das pessoas (que muitas vezes nem sabem que não sabem sobre agilidade) e em gerar uma coerência da estrutura e da estratégia, para que a empresa obtenha os resultados que espera.

Dá para ser um bom Agile Coach sem falar do negócio da empresa? Uma frase que ouvi: se você não consegue conversar sobre o business da sua empresa, você só vai conseguir fazer otimização local. Na minha opinião, o Agile Coach precisa ter essa visão: se a empresa tem capital aberto, leia o relatório para investidores; se não tem, você vai precisar conversar com a diretoria, para entender como ajudar as pessoas a priorizarem o backlog delas. Se a gente fica focado só nas métricas organizacionais, na eficiência pela eficiência, isso vai gerar resultados de otimização local, sem olhar para o todo. Se você não sabe como a sua empresa ganha dinheiro, você não sabe como desenvolvê-la.

Isso traz uma responsabilidade de aprendizagem constante: o Agile Coach precisa ter uma capacidade de compreensão sistêmica mais aguçada. Ele não precisa ser um expert naquele campo: trabalhar para um banco não significa que você domina todo o processo bancário ou vira banqueiro. Mas você vai tentar compreender ao máximo como essas engrenagens funcionam, entender a relação de sistemas, subsistemas e ecossistemas, no caso de um banco, o que o Banco Central determina, a legislação que regulamenta. Essa compreensão sistêmica não é para você centralizar a informação, mas para usá-la e ajudar os outros a entender as consequências, os influenciadores, as dependências.

Como o Agile Coach tem múltiplos formatos de atuação, ele também tem múltiplas origens: agile já saiu da esfera só de TI. Numa transformação num grande banco na Austrália, num grupo de cerca de 45 coaches, eu era um dos poucos que vinha da área de desenvolvimento de software; a maioria vinha de gestão, ou até de psicologia, de serviço social. Uma colega vinda de serviço social era uma excelente coach, mesmo sem conseguir falar de TDD ou integração contínua, porque o ambiente de aplicação já não era mais esse, era um time de marketing, ou um time definindo políticas de aprovação de empréstimo, que não toca nenhuma linha de código, usando práticas ágeis para colaborar melhor.

Na minha visão, eu não acredito que você forma um Agile Coach com treinamento, nem com certificação. Eu tenho um livro de Agile Coach, tenho treinamentos, mas você não precisa deles para se tornar um. Eu gosto de trazer o elemento cicatriz, experiência. Comecei com Agile em 2002, com XP, e só em 2008 comecei a trabalhar oficialmente como Agile Coach: foram seis anos construindo experiência antes disso. Essa questão de acumular rodagem antes de iniciar as aventuras como Agile Coach é uma coisa que sinto falta hoje. Como contratante, encontra-se muita gente que trabalha com agile há dois anos, fez um monte de certificação, passou seis meses como Scrum Master e virou Agile Coach, ainda muito focado num sabor só de agile.

Eu trabalhava no mundo de ERP, muito regido por PMBOK e RUP: a mesma ferramenta usada para controlar obra de engenharia era usada para controlar projeto de desenvolvimento de software. Aquilo nunca casou bem com o que eu acreditava. Comecei a pesquisar, achei o livro do Kent Beck, o site original da Chrysler, e comecei a experimentar, levei feedbacks muito loucos, 'isso não é profissional', 'você é anarquista'. Um momento transformador foi numa concorrência para uma fábrica que precisava de um sistema de PCP: o outro fornecedor fez uma abordagem tradicional, um monte de documentos e requisitos; eu simplesmente criei o software. Foi muito mais fácil, e o cliente escolheu quem já tinha entregado algo funcionando. Foi meu grande estalo do benefício do agile: entregar valor antecipado, ganhar vantagem competitiva. Enquanto o agile não está te ajudando a ter algum benefício real, talvez você ainda não tenha pego a essência do que ele é.

A gente não pergunta para quem está entrando na empresa se leu ou não Peter Senge; é mais sobre essas cicatrizes, sobre se a pessoa já entende, por padrão, que o todo importa mais que as partes. Uma das formas que usamos para sentir isso é o que chamamos de Coaching the Agile Coach, uma autoavaliação com os quatro domínios explícitos: negócios, cultural, organizacional e técnico, numa visão de indivíduo, de time e da organização como um todo. No começo da minha carreira, meus processos eram fluidos tecnicamente, culturalmente todo mundo estava feliz, mas descobri depois que o que eu fazia não gerava valor real para o negócio, só gerava dinheiro para mim como desenvolvedor. Essa ferramenta ajudou a perceber meus gaps.

Tudo estava funcionando bem, todo mundo feliz, mas eu percebia que tinha algo errado e não conseguia identificar onde. Descobri que o problema estava em negócios: eu não entendia nada do meu business, só transformava o que alguém queria em código. Comecei a tentar entrar nesse mundo de negócios, e a mensagem que recebia era que precisava conhecer tudo sobre derivativos, swaps, debêntures, e eu não queria aprender isso a fundo. Depois de tomar alguns socos da vida, percebi que não precisava conhecer toda a bíblia do mercado financeiro, só precisava entender como resolver o problema de alguém. Hoje eu digo amplamente: não entrego nenhum serviço que não esteja resolvendo o problema de alguém. Então as cicatrizes que formam um bom Agile Coach estão relacionadas ao como, ao que, mas muito mais ao porquê: você entende o porquê de estar fazendo o que está fazendo, o propósito do sistema.

Minha história nasce em tecnologia, com um autodidatismo muito forte, desde a faculdade, já lendo sobre Scrum e XP e querendo conversar sobre isso. Trabalhava sozinho como freelancer, e fui entendendo minha capacidade produtiva como autônomo, fatiando histórias e tarefas, praticando o método sem entender ainda muito bem o porquê. Talvez eu tenha sido esse macaco louco apertando botão em algum momento, se achando. Mas depois a gente cai na real, e o Coaching the Agile Coach ajuda bastante nessa reflexão. O autoconhecimento, para quem está se achando demais, é muito importante.

Há duas coisas fundamentais para um Agile Coach: a humildade de conseguir ouvir, perceber e reconhecer o que você faz de fato, e a observação, que ajuda a entender relações e pensamento sistêmico. Mas para quem sofre da síndrome do impostor, não adianta só se observar: isso pode afundar ainda mais na síndrome. Nesse caso, trate as pessoas com quem você lida como clientes: peça feedback, entenda o impacto do seu trabalho. Recebendo feedback sincero, você vai descobrir que provavelmente não é esse impostor, mas um profissional competente. Isso vale para qualquer profissional que se ache um impostor, e vale também para o macaco doido pedir feedback. Isso está bem explicado no efeito Dunning-Kruger: a percepção de que, não importa o quanto você estuda, acha que a qualquer momento vai ser desmascarado.

Comecei em tecnologia, com banco de dados, e fui trabalhar numa empresa de tecnologia para contabilidade que já respirava agilidade, lá por volta de 2008. Eu era prepotente, achava que aquilo era bagunça, que não podia funcionar numa empresa de contabilidade, mas isso me mostrou que muito do que chamamos de organização é só burocracia: você enche de coisas que não podem ser controladas, e não adianta quanto papel colocar em cima, não vai estar sob controle. Você tem que entender que aquilo vai mudar e conviver com isso. Levei tempo para perceber quanto tinha aprendido lá, depois via gente batendo cabeça tentando desenhar o produto perfeito para o próximo ano, um desperdício enorme.

Toda verdade passa por três estágios: primeiro é ridicularizada, depois rejeitada com violência, e no terceiro é aceita como evidente por si própria. Acho que todos nós passamos por isso: hoje é fácil convencer as pessoas de agilidade; há alguns anos, dizer 'banco nunca vai ter essa bagunça que vocês chamam de ágil' era comum.

A quantidade de coisas que você não sabe vai ser sempre infinitamente maior do que a quantidade de coisas que você sabe; isso retrata bem a humildade necessária. Uma dica: procure referências que te inspirem, pegue feedback sobre essas referências, entenda o que outras pessoas na caminhada acham delas, e vá construindo sua própria história com suas próprias cicatrizes.

Fuja do seu local comum: a gente quer levar as empresas a pensar o todo, então é fundamental se aprofundar no que cada empresa faz. Hoje um cliente é finanças, amanhã é combustível, depois é uma plataforma de petróleo; entender como cada um desses mercados funciona é muito enriquecedor. Para quem está numa única empresa: não se prenda ao job description, vá além, transborde, isso amplia a visão para tomar melhores decisões. E experimente: só criamos cicatrizes se experimentarmos coisas novas, situações diferentes, inclusive com um pensamento mais científico, como: o que eu quero construir, onde quero chegar, cheguei ali ou não.

No livro que escrevi, o elemento central é catalisar melhorias, usando diferentes técnicas, atuando de diferentes maneiras, mas sempre entendendo o porquê de estar fazendo as coisas. Escrevi de forma muito iterativa, permitindo o direito de usufruir da imperfeição, lancei, peguei feedback, fui evoluindo ao longo de mais de dois anos. Sempre evitei trazer uma visão ditatorial: convidei o máximo de pessoas possível não só para revisar, mas para trazer diferentes pontos de vista e relatos de experiências reais em cada capítulo. Essa diversidade foi fundamental para construir o que o livro é hoje, uma construção coletiva, não uma coisa só minha. A dica final: foque em identificar quais melhorias, quais problemas primários você quer resolver de fato, enquanto transformação, enquanto adoção de agile.