Alguns aprendizados de uma Scrum Master

Frequentemente, eu percebo no contexto de agilidade, muitos cursos e textos, com um monte de teoria, o que é muito importante. Porém, há pouco material sobre prática e aprendizados no âmbito de agilidade.

Então, eu resolvi compartilhar aqui, os meus aprendizados com dicas resultantes de dores vividas na prática nessa minha caminhada como Scrum Master, na área de aplicativo e site.

Assim, dividi em duas sessões, aprendizados de questões técnicas e comportamentais.

Nesse momento alguém pensa:” Mas um Scrum Master não precisa ser técnico” Eu respondo:”é verdade”. Porém, quanto mais eu aprendizados sobre, mais eu consigo ser proativa, e isso faz com que surjam menos bloqueios e impedimentos para o time e para o projeto.

Aprendizados sobre questões Técnicas:

API

Se a API tiver dependência de outro time, tente evitar bloqueios e impedimento. Planeje uma ou duas Sprint para estudo da documentação de cada parte da API que for sendo entregue e só na próxima Sprint coloque a integração com a API. Igualmente, se ela for entregue de uma vez só.

Quando surgirem problemas em alguma funcionalidade, é preciso uma investigação, por que pode não ser problema na API, pode ser no Front, ou no LEGADO!

Designer

Tente evitar bloqueios e impedimento com Designer. Em suma, esteja com Designer pelo menos uma Sprint a frente.

Tem que refinar as APIs, antes do fluxo ser desenhado, senão pode ser desenhado algo que não faz sentido, gerando retrabalho. Logo, é preciso averiguar se a API retorna o que a Design está projetando. Afinal, podem haver limitações técnicas para desenhar as melhores soluções.

Tente evitar problemas de conteúdo, tenha bem definido logo no início do projeto, quem e como serão tratadas as questões de conteúdo.

Massa de teste

Tenta evitar problemas com Massa de teste, Imediatamente, já no inicio do projeto, combine com quem e como serão tratadas as questões de massa.

MVP

Seu cliente está pressionando o time? Finaliza um MVP em tempo hábil, período de poucos meses, tipo 3 ou 4 no máximo. e disponibiliza para colocar em produção. Dessa forma, muito provavelmente a cobrança inverte, de time para cliente. Isso da credibilidade, confiança do cliente e do time, além de aliviar a pressão.

Sobre o MVP, conscientize o time para fazer o mais simples e limpo possível, ainda é um momento de teste de hipóteses. Se tiver muita qualidade, caso seja necessário muitas mudanças, ou até mesmo pivotar, o projeto perderá tempo e dinheiro,

Esclareça o entendimento de DONE. para o time. Done não é Mokado. Done é estar pronto para ir para produção, se for necessário. Por que, somente dessa forma, o time estará entregando valor. Então faça com que todo o time tenha obsessão para colocar em produção. Afinal, código na máquina do desenvolvedor não traz valor para o cliente.

Após colocar o MVP no ar, é mais fácil mensurar valor gerado. Pois, é possível acompanhar com métricas, por que nesse momento já se tem acessos reais.

Refatoração

Em projeto de Refatoração, já no incio, pense em indicadores, para mostrar o resultado final, e poder mensurar o progresso (ex: número de linhas de código que estão diminuindo, aumento de velocidade de alguma funcionalidade etc).

Definitivamente, faça o projeto por tempo, não por escopo. Assim, faça o que der para fazer de melhor nesse período. O resultado esperado é a diminuição do código replicado, ter um código mais fácil de entender e a cobertura de teste aumentar.

Dica: Plugar um analisador de código na análise estática do 1 código antes do projeto e depois vai fazendo ao longo para ir comparando.

Silos

Incentive um membro Devops dentro do time, assim como um membro de qualidade, e se puder, que a API esteja sendo produzida dentro do time, isso é muito benéfico. Minimiza os bloqueios e impedimentos, por que são menos dependências externas, com outros silos da empresa.

Aprendizados sobre questões comportamentais:

Faça um on-board forte no time:

Fale muito dos valores, principalmente do respeito. Definitivamente, mostre que você não esta disposto a tolerar certos comportamentos. Desencoraje logo, caso alguém tenha tendencia de ir na contramão de algum dos valores, seja do Manifesto ágil, do Scrum ou da sua empresa.

Pergunte ao time, o que sabem e esperam de cada papel, você vai perceber muito gap de conhecimento, só depois mostre o que de fato, faz cada papel no Scrum.

Deixe claro, que o papel de um SM, é ser o guardião do framework. E que faz parte do trabalho, fazer com que as coisas aconteçam, na periodicidade e tempo necessário. Peça ajuda e colaboração de todos. Enfim, tente fazer com que tenham empatia por você, para que você consiga rodar o Scrum sem grandes resistências.

Use dados e fatos a seu favor, seja uma experiência na ultima empresa, ou algum estudo. Fiz isso com a Daily. Levei um estudo publicado, que mostra que a maioria dos projetos falham, por problemas de comunicação. Passei o gráfico de mão em mão e pendurei na parede. Expliquei que a Daily é um dos gatilhos do framework, para diminuir a probabilidade de problemas de comunicação, no âmbito do time, além de promover outros benefícios. O time aceitou bem essa abordagem.

Feedback:

Quando você SM estiver recebendo feedback, o melhor que você pode fazer é ficar quieto e anotar. Vai por mim: “Qualquer coisa que você dizer, será usado contra você.” Não faça defesa no feedback.

Em falar em feedback, ensine ao time que feedback independente de ser para outro membro do time ou para você, deve ser construtivo, e não destrutivo, além disso deve vir com dados e fatos.

Faça one one toda semana, se não tiver feedback, o que eu acho difícil, aproveite para tirar dúvidas de agilidade, mantendo dessa forma os profissionais do time se atualizando e/ou consolidando os conceitos.

Faça Feedback Canvas com o time de tempos em tempos. Vai por mim, após a dinâmica, o time sem perceber, acaba te empoderando. Pensa comigo, você pode tirar eles da zona de conforto, e ninguém pode reclamar, você está fazendo as melhorias do resultado dos feedback deles.

Liderar

Essa dica eu não sei se rio ou se choro!!! Se você estiver com um time de millennials, e provavelmente estará, por ser um ramo de tecnologia, cuidado com a forma de se expressar. Em suma, podem falar que você é incisivo, que é top-down ou que faz microgestão.

Faça sempre perguntas ao time, mesmo se eles te perguntarem, pergunte de volta. Se souber direcione para solução, mas não de respostas prontas. Faça os profissionais evoluírem, pensando por si só. Use a técnica dos 5 por que, por exemplo.

SM, impedimento não é preguiça em?!!! Se liga!!! Você deve desenvolver o time a se auto organizar e se auto gerenciar.

Eu aconselho, ao SM e PO, estarem presentes na Daily, e com escuta ativa, para poder identificar possíveis problemas (bloqueios e impedimentos). SM só direcione a palavra para facilitação, caso o assunto tenha ficado com muito detalhe ou técnico de mais.

Interromper o time no meio do desenvolvimento, pode ser ruim, pode prejudicar o raciocínio, e render boas reclamações. O que eu fiz, foi combinar com o time que o pós daily a SM e o PO darão os recados. Em suma, esse é um momento, que todos já estão em pé, e pré dispostos a ouvir.

Eu fiz, e recomendo, coloque todo o seu trabalho diário de forma visual para o time. Isso traz liga, traz pertencimento, traz união, traz consideração.

Faça com que todos os SM da empresa sejam uma rede de apoio, uns para os outros. Se unam, compartilhem, aprendam uns com os outros. Eu tive essa experiência e foi maravilhosa.

Então é isso, essas foram algumas aprendizados nessa minha caminhada como SM.

Informações sobre a autora: Jacqueline Viana é Scrum Master na Concrete Solutions, e é apaixonada por agilidade.

https://www.linkedin.com/in/jacqueline-mba-e-pmp/