Agile Coaching: de 180 para 18 pessoas
Talvez seja um caminho natural ser primeiro um Scrum Master, depois um Agile Coach e, para quem gosta da nomeclatura, por último virar um Agile Coach Enterprise. Lembro me bem de algumas palestras da Annelise Gripp sobre definição de Agile Coach e da discussão que para você virar um Agile Coach é necessário ter tido experiência como Scrum Master (ou algo parecido). Se for observar pela ótica de que um Scrum Master (pode substituir por qualquer outra nomenclatura ao seu gosto) supostamente cuida de somente um time e um Agile Coach pode cuidar de mais times, faz total sentindo o raciocínio dela.
No entanto, comecei a escutar mais o termo Agile Coach depois do video no qual o Spotify explica sobre a cultura de trabalho que eles tinham, o “Spotify Engineering Culture”. Como eles não se prendiam em utilizar só Kanban ou só Scrum ou qualquer outro framework ou método, então eles renomearam o Scrum Master para Agile Coach. Afinal, eles queriam mais “líderes servidores do que mestres em processos”. Em algumas outras empresas, ainda existe um terceiro termo: Agile Master, ou seja, um mestre em ágil e, dessa maneira, conseguem juntar o conceito defendido pela Annelise Gripp ( e também pela Lyssa Adkins) e a idéia do Spotify.
Particularmente também prefiro o conceito da Annelise Gripp e da Lyssa Adkins…
E como é ser um agile coach? Quantas pessoas você precisa atender? Como é o dia-a-dia? Primeiramente, não tem regra, fórmula ou receita de bolo. Cada experiência é única, cada desafio é único. Em 2017, eu virei agile coach de uma consultoria e passei por duas grandes empresas como consultora. Quantidade de pessoas? Entre 150 a 180 pessoas, divididas em times e cada time tinha seu “Scrum Master” e o seu Product Owner. Na primeira grande empresa, éramos uma equipe de 3 agile coaches e, na segunda, eu estava praticamente sozinha com as 180 pessoas.
Em ambas, eu mal tinha contato com as pessoas, pois é humanamente impossível você atender 180 pessoas todos os dias, fazendo sessões de coaching e/ou mentoring com cada uma delas, entendo sua situação, seus valores, suas crenças, seus problemas, suas angústias e seus anseios. A solução encontrada para este caso foi de realizar coaching e mentoring com os Scrum Masters e orientá-los a realizar com seus respectivos times. Afinal de contas, no próprio Guia do Scrum, fala das habilidades de coach do SM. Ponto de atenção: em nenhum momento afirmei que é a solução correta, mas foi a melhor alternativa que encontramos.
Outro ponto importante, é que inconscientemente esquecíamos que estávamos trabalhando com pessoas e essas possuem curvas de aprendizado e níveis de maturidade diferentes uma das outras. Era comum, apesar de não normal, tratar em massa os times e, salientando novamente que era inconsciente, acabávamos valorizando mais a padronização do processo do que a interação entre as pessoas. E isso acontecia não porque os agile coaches eram ruins ou que não conheciam de ágil, mas simplesmente porque era necessário facilitar a vida dos agile coaches.
Você leitor pode sugerir a contratação de mais agile coaches, mas infelizmente não era a solução para esses casos.
Voltando para o meu caso… no finalzinho do ano de 2017, chamaram me para bater um papo aqui na Bionexo e ofereceram me uma oportunidade de ser Agile Coach, mas tinha uma grande diferença: eu atenderia 10x menos pessoas do que eu estava acostumada. Depois de muito pensar, aceitei o desafio.. e que desafio! Apesar de muitos acharem que o desafio é maior quando se tem mais pessoas, eu afirmo que, na verdade, o desafio é apenas diferente, mas continua tão grande quanto.
Com poucas equipes, finalmente teria tempo para fazer o que realmente um Agile Coach precisa fazer: coaching e mentoring com os membros do time para que se tornem juntos um time de alta performance. Não que “times de alta performance” não fosse o objetivo das empresas anteriores, mas, como descrevi, dar coaching e mentoring para cada membro era humanamente impossível.
E o desafio era tão grande quanto, pois, para tratar com cada membro, é necessário entender os valores que regem cada um deles e seus objetivos, que muitas vezes não são explicitos para os próprios membros. Entendendo seus valores, conseguimos entender o porquê das suas ações e também o porquê de alguns conflitos entre eles.
Outro ponto que difere os dois desafios (ser agile coach para muitas pessoas e ser agile coach para poucas pessoas) é apossibilidade de colocar em prática o estilo de ser do agile coach de acordo com o Shu Ha Ri e transitar entre dar coaching para ora para o time ora para os membros de forma individual
De acordo com a Lyssa Adkins, o Agile Coach deve mudar seu estilo de acordo com o momento que o time vive. Basicamente, Shu: siga a regra. Ha: quebre a regra. Ri: seja a regra. Quando o time não tem domínio ou é algo novo para ele, o time simplesmente segue a regra, mesmo não a compreendendo. Depois do Shu, vem o Ha, ou seja, o time passa a entender a verdade da regra e porque ela existe, chegando até a ensinar os outros como seguir a regra. Finalmente, vem o Ri. O time tem total domínio que consegue mudar a regra, adaptando da melhor maneira possível.
E o Agile Coach deverá acompanhar o time nesses momento e desempenhar estilos diferentes. No Shu, o Agile Coach deverá ensinar mais, no Ha, ele deverá dar mais coach e no Ri deverá dar avisos e conselhos.
Tudo isso combinado com o momento do time no desenvolvimento. Caso utilize sprints, a sugestão da Lyssa Adkins é que ele dê coach para o time no começo e no fim da sprint e dê coach para os membros do time durante a sprint. No seu livro, ela explica bem esses dois pontos.
Aqui na Bionexo, finalmente consegui colocar isso em prática e ver como é gratificante acompanhar os times de perto em cada momento e em cada etapa. Apesar de eu ter invertido os desafios, aconselho primeiro ser Agile Coach de multiplos times para depois chegar ao nível enterprise.
