Os primeiros 90 dias do Scrum Master

Olá, tudo bem? Espero que sim! Estou escrevendo este para compartilhar os meus primeiros 90 dias como Scrum Master, minhas experiências e estratégias quando começo uma nova etapa profissional.

Caso você esteja iniciando na área ou prestes a entrar nesse papel no Scrum, meus textos podem te ajudar, mas atente-se a isto: não se trata de um guia para o Agilista iniciante, mas como eu crio minhas estratégias e planejo ações em uma nova empresa ou projeto, algo totalmente empírico. Funciona pra mim, talvez ajudará você. Com os três meses superados e utilizando minhas anotações das estratégias, compartilho aqui os resultados.

Ah, um adendo sobre o meu perfil: sou observador, gosto de sentir o clima das reuniões, ouvir diálogos e ver como o dia a dia acontece. Essa minha ambientação é necessária, pois preciso entender os porquês . Evito julgamentos ou expor opiniões prematuramente e sem contexto. Me mantive com esse comportamento até me sentir confortável com o time e projeto, o que aconteceu após uns 45 dias. Detalhes sobre o meu perfil profissional aqui.

Fui contratado como Agilista Sênior para substituir o profissional anterior, que foi promovido para Squad Leader. Com isso, procurei entender como a Agilidade estava estruturada no contexto empresa, equipe e produto, como as interações e alinhamentos aconteciam, a transparência das decisões e comunicações, métricas, a segurança para exposição de opinião contraditória e demais princípios do querido nosso manifesto ágil e dos pilares Scrum.

Para entender e me ambientar ao time participei de reuniões mesmo sem ter históricos, entender dos contextos, estar por alinhado das fases e criticidade do produto/projeto e, evidentemente, não as liderei inicialmente. Meu foco era conhecer o time (conversei individualmente com eles) e me ambientar àquele cenário vivenciando, na prática, o dia-a-dia: a imersão mostra muito mais do que documentações ou explicações de processo.

Havia uma estrutura interna dividindo profissionais entre times e projetos, chamada de POD. Foram idealizados seis PODs no total, com 5 pessoas em média em cada um deles: sendo um líder técnico (POD Leader), QA e DEVs, totalizando umas 30 pessoas. Essa mudança foi comunicada no meu terceiro dia de empresa durante uma sprint retrospectiva pelo cliente(?!¹). Ver isso foi importante para entender a estrutura do time que eu acabara de entrar.

Entendido a organização interna, dediquei em conhecer as pessoas. Tentei me enturmar durante as reuniões e em conversas informais. Além disso, falei individualmente com os POD Leaders para me apresentar, passar meu histórico profissional e vida pessoal. Nesses papos, eu quis saber sobre carreiras e afins. Além de conhecê-los e tentar criar conexões, perguntei o que precisava ser melhorado e COMO e EM QUE eu poderia ajudar.

Em nenhum momento dessas conversas comentei que estaria lá para fazer mudanças. Normalmente, a palavra mudança causa bloqueios e pode ser intimidadora quando ainda não temos uma relação de confiança. Meu interesse era saber do ambiente, das histórias e como as coisas aconteciam. Não somos obrigados a fazer alterações nos ambientes que acabamos de chegar, por isso, contextualização antes de qualquer mobilização .

Finalizado minha estratégia para conhecer as pessoas do time, compartilho, abaixo, as minhas conclusões. Todos esses itens foram aprofundados com os colegas para que eu pudesse obter mais detalhes e, basicamente, me ligaram sinais de alerta sobre como aquela Squad estava estruturada. Aqui, foi uma ótima fonte do que eu, como Agilista, poderia trabalhar com o time, em conjunto, para trabalharmos em melhorias:

• Pelo menos 40% dos integrantes do time era novato, com menos de três meses de time e/ou de empresa
• Havia um processo de integração com os novatos que estava incompleto, pois não considerava o interesse genuíno em conhecer as pessoas que estavam fazendo parte do time.
• O processo de ambientação dos novatos ao time/projeto era assíncrono e solitário, repleto de vídeos e documentações (na maioria defasada)
• O Confluence estava abarrotado de informações desatualizadas ou não praticadas pelo time (O DOR e DOD estavam escritos, mas não eram seguidos)
• O Product Owner não era próximo da equipe
• A equipe pouco se conhecia (com exceção dos mais antigos que já trabalhavam no escritório e criaram vínculos)

Passando para o próximo tópico, voltado para a minha necessidade de ter entendimento e contextualização dos projetos que o time desenvolvia: cada POD era responsável por uma gama de projetos que eram alocados de acordo com uma pré-definição do CTO, além de um roadmap de produtos que somente o time de negócio tinha acesso. Ele conhecia muito bem os POD Líderes, suas expertises e históricos e dividia esses projetos nos times.

A mentalidade ágil, tanto pelo lado do cliente quanto no time técnico, estava bem inicial. O escopo dos projetos era fechado, com data fixa. O arquiteto era responsável por trazer as histórias de usuário(?!²) e os requisitos. Os objetivos de negócio passavam longe do conhecimento do time. A interação com o PO não agregava e o time de negócio era 100% cliente. Literalmente, eu estava em um time aonde eficiência era mais importante do que a da eficácia.

As métricas de performance do time, com relação aos projetos anteriores, inexistiam. Eu havia acabado de entrar em um time que, teoricamente, trabalhava com agilidade, um pseudo Scrum, que não possuía uma única métrica disponível. Sem métricas, como saber se de fato a performance faz diferença, se entregávamos e atingíamos os objetivos de negócio e como media a satisfação do time?

Com todas essas constatações, tive uma conversa com o CTO e Squad Leader para alinhar expectativas com relação ao time. Pude, de fato, utilizar da ambientação da cultura daquela equipe para, a partir disso, propor ações condizentes com o que era esperado pela alta gestão. Descobri que sim, tinha-se um interesse de aprimorar a mentalidade ágil da empresa como um todo, não só do time. Era de conhecimento muito dos problemas que existiam ali.

Então, alinhado a expectativa, iniciei algumas ações para a equipe ser cada vez mais integrada e ágil. Essas ações, foram voltadas para os pilares de pessoas e processos. Abaixo, detalho um pouco mais sobre elas e os resultados:

• Retrospectivas — Fizemos dinâmicas de helth check, checkin e atividades para ganho de confiança da equipe para exposição do contraditório. Uma boa fonte de consulta é o Fun Retrospectives. Usando muito dos fatores “5 disfunções das equipes” para team building. Aos poucos, o time foi entendendo que era responsável por esse momento e passaram a realizar a condução.
• Dailys — Também tiramos a dependência do Scrum Master puxar a daily. Trata-se de um evento pro time e para o time. Entenderam que tinham essa autonomia.
• Plannings — Apesar de ainda ter muita resistência, em alguns dos PODs já foi possível que o time fizesse a condução da planning em conjunto com o PO. Com o SM interagindo cada vez menos.
• Moving Motivators — Utilizando da técnica, fizemos em todos os PODs e foi possível identificar o perfil de motivadores para cada um dos profissionais. Além disso, criou-se conexões entre eles devido ao conhecimento de similaridades.
• Personal Map — Para os novatos foi colocado como obrigatório fazer um personal map e apresentá-los para o time. Era um momento bacana para troca de informação pessoal e profissional, possibilitando criação de conexões e empatia em muito dos casos.
• Métricas — Iniciamos a adequação do fluxo de trabalho para refletir exatamente o que estava acontecendo nas etapas. Além disso, iniciamos o uso do gráfico “Burn-up” para evidenciar as variações de escopo que aconteciam, refletindo em um planejamento incompleto e excesso de trabalho para o time.

Esses foram os principais pontos, aprendizados e ações desses 90 dias. Espero que esse texto tenha sido útil para sua nova jornada profissional.

(?!¹) — Normalmente, a retrospectiva é uma reunião para inspeção e adaptação do time, para verificarmos como foi a última sprint e discutir melhorias. Também podemos falar de planos futuro (futurospectiva), mas ser usada para passar recados “corporativos” me pareceu estranho. Isso se repetiu duas vezes no total (depois, eu passei a puxar as retros e, com ajuda do time, passamos a fazer helth-check e variar as atividades).

(?!²) — Normalmente, o PO escreve as histórias de usuário. Quando um arquiteto o faz, como acontecia nesse contexto, mostra que era esperado ao time apenas “fazer” o que foi determinado. Sem chances para inovação e/ou formas diferentes de chegar numa resolução.