Scrum Master, tão simples quanto possível

Olá pessoal. No post de hoje vou falar um pouco do papel do Scrum Master, e vou usar como pano de fundo, o caminho que trilhei.

O Post também vem para cumprir uma Meta, e desde já agradeço ao Mestre Manoel Pimentel.

Hoje é muito debatido qual o verdadeiro papel do Scrum Master, se é necessário, se é desnecessário, se ajuda a promover a auto-organização…

Bem, como sempre, vamos por parte.

Scrum Master é um facilitador que remove impedimentos do Time, e que isso não necessariamente quer dizer que ele seja o único a fazer isto. Eu como Scrum Master sempre busquei auxiliar ao Time como descobrir seus reais problemas, e como combate-los como Time.

Em alguns impedimentos, minha atuação direta como Scrum Master ajudava, pois não precisaria dispender alguém do Time, logo não atrapalha o pessoal. Contudo, toda atuação minha para tirar impedimentos era clara. Eu fazia questão de informar ao Time o que eu fiz, como fiz, com o intuito de transmitir conhecimento.

Porém, alguns impedimentos realmente tinham que ser tirados pelo time. Geralmente conhecimentos técnicos, necessidades de infra que exigiam o conhecimento apurado de alguém para explicar. Nestes casos, eu atuava realmente como facilitador, buscando ajudar ao máximo.

Um Scrum Master tem uma meta básica que é zelar pelos Valores do Scrum, logo os Valores do Manifesto Ágil. Isto é realmente muito difícil e requer experiência.

Quando me foi sugerido ser Scrum Master, que no caso fui indicado pelo pessoal do Time, eu já tinha um bom conhecimento de Métodos Ágeis, porém, não poupei esforços para conhecer mais.

E qual foi a primeira coisa que fiz? Não. Não foi buscar a certificação.

Foi buscar um arsenal de Literatura e Mentoring. Na época a empresa era assistida por um Mentoring, o Felipe Rodrigues. Dezenas de livros amontoaram minha mesa e meu computador, dentre eles:

  • Agile Software Development with Scrum – Ken Schwaber
  • Agile Restrospecitves – Diana Larsen
  • Agile Estimating and Planing – Mike Cohn

Porém, fui mais além disto e quis conhecer as raízes então fui ler:

  • Scrum Papers – Jeff Sutherland
  • The New New Product. Development Game – Hirotaka Takeuchi and Ikujiro Nonaka

Me inundei numa leitura de Posts, tanto dos Gurus externos quanto internos e deixo aqui dois grandes posts do Fabio Akita:

http://akitaonrails.com/2009/12/10/off-topic-voce-nao-entende-nada-de-scrum

http://akitaonrails.com/2010/01/30/off-topic-lendo-os-principios-ageis

Sem falar nos Mentorings e troca de experiência com vários grandes profissionais da nossa área. Mergulhei mais ainda também em participação em eventos, reuniões, grupos de usuários e etc.

Em seguida veio a certificação CSM com o grande Alexande Magno. O processo certificatório pode ser falho, mas a oportunidade de troca de experiência com o Magno foi sensacional.

A atuação de um Scrum Master, zelando pelos Valores do Scrum é simples ou complicado mediante a sua verdade. Não se cria um sentimento de união, um senso de comprometimento e auto gerenciamento num Time de uma hora pra outra.

Cada Time tem sua dinâmica, e isto deve ser somado a realidade de cada Empresa. Como Scrum Master aprendi que melhorias no Time são ótimas mas podem não gerar bons frutos se forem feitas isoladas. Melhorias que buscam impulsionar os Valores Ágeis devem ser feitas em escala Empresarial. Eu tive muita dificuldade nesta parte.

O que acontece com algumas pessoas que atuam como Scrum Master, é que elas passam a achar que estão sempre certas e são Juízes, julgadores do bem e do mal. Eu sempre mantive claro para mim, que eu não era assim. Que como todo profissional eu estava passível de erros e acertos. Logo, eu aprendi com meus próprios erros vendo que quando estava pensando em lutar pelos Valores Ágeis, na verdade eu estava criando um cabo de guerra.

Se todo Scrum Master deve prezar pelos Valores Ágeis então ele deve ser o primeiro a realmente se fazer deles. Eu fazia retrospectivas e buscava melhorias. Quando percebi que minha atuação criava cabo guerra, sentei com todos os envolvidos e busquei dissolver isto.

Hoje, percebo que a atuação de um Scrum Master é tão simples quanto possível, utilizando como sua principal arma o Bom Senso.

Porém, o bom senso é algo relativo e deve levar em conta vários aspectos. Neste ponto, uma literatura me auxiliou muito:

Buscando melhorias, não podia me contentar com melhorias locais e passei a buscar melhorias sistêmicas. Minhas Retrospectivas tomaram outro caminho, onde junto do Time, analisavamos nossos problemas, o que os causavam, os pontos de alavancagem para as melhorias e o que isto impactaria a estrutura como um todo.

Mais uma vez, isto foi algo que eu errei e aprendi como Scrum Master. A grande dica que eu dou a quem exerce este papel é:

Jamais se ache MASTER

A simplicidade me guiou nesta caminhada. Como todo desenvolvedor que busca aprender, como todo analista que deseja conhecimento, eu também como Scrum Master segui o caminho de buscar aprendizado, de fazer, de errar, de aprender.

Eu causei muita polêmica como Scrum Master, gerei muitos embates e hoje vejo que não foi um dos melhores caminho que segui. Porém também vejo o quão o pessoal dos Times que atuei se desenvolveram, o quanto eles entregaram, o quanto estavam felizes. Tudo como um processo simples e natural da vida.

Ser Scum Master é tão simples quanto qualquer outro papel. Você deve buscar sempre conhecer tudo que é tido como fundamental e bom para exercer seu papel, você deve atuar, errar e aprender.

Grandes questões como “Scrum Master pode ajudar na auto gestão”, a respostas não está no papel do Scrum Master, e sim na pessoa que atua nele.

Ter Empatia por todos os envolvidos na dinâmica de desenvolvimento da Empresa, buscar melhorias consistentes e sustentáveis, ser verdadeiro, ter conhecimento podem fazer com que boas coisas aconteçam, independente do papel que a pessoa exerça.

Hoje, posso dizer que por espaços de tempo, eu vi times realmentes auto gerenciados, pude ver Retrospectivas com toda a Estrutura da Empresa envolvida no Produto, pude ver o crescimento de várias pessoas.

Não posso jamais dizer que eu criei Times Auto Gerenciaveis, que tinham total noção do ROI e blá blá blá. Mas posso dizer com certeza que por bons momentos, pude ver coisas feitas da forma certa. Pude ver P.Os discutindo com o Time o real alor das coisas, pude ver Times conseguirem atingir Metas incríveis, pude ver produtos Entregues, pude ver elogios da Gerencia e outras coisas boas.

Para mim, as coisas hoje são tão simples quanto possível. Eu vejo desejos de várias partes, vejo necessidades e oportunidades e busco fazer parte de toda esta dinâmica.

Ambientes que buscam melhorias e se valem dos Valores Ágeis, proporcionam a um Scrum Master ou um Agile Coach auxiliar o pessoal a chegar a grandes feitos. É isso que faço hoje.

Já conheci Scrum Masters que colocavam o nome do papel na assinatura de e-mail, já conheci outros que estimavam pelo Time, conheci outros que não sabiam o que era uma Iteração e outros ainda que não sabiam quem era Ken Schwaber. Por isso que digo que o X da questão não está no papel, está na pessoa.

E você caro amigo, como foram suas experiências como Scrum Master? Ou como o Scrum Master com que você atua é?

[]s.

Anúncios

Aprendendo a andar de bicicleta

Versão resumida do post: Scrum Master’s, deixem as equipes se ralarem um pouco, só cuide para que eles não se matem.

Se você leu e não entendeu, leia o resto do post 😛

Image

Quando somos crianças, ou já adultos, quando vamos aprender a andar de bicicleta, sempre caímos.

Nunca, ninguém aprendeu a andar de bicicleta sem ter ralado um joelho antes, mas mesmo depois que se aprende, continuamos a ralar os joelhos e cotovelos e esse processo é essencial para o nosso aprendizado. Fazemos isso porque estamos testando nossos limites, quando nunca andamos antes, nosso limite é conseguir andar e fazer algumas curvas.

Após esse passo básico, nossos limites vão aumentando, mas continuamos a testá-los e a cada teste continuamos ralando os joelhos e cotovelos, as vezes algo mais. Quando estamos aprendendo a andar, temos sempre alguém nos ajudando a descobrir os limites à serem testados, e ajudando a evitar que a gente se mate nos primeiros 5 minutos em cima da bicicleta.

Em outros momentos da nossa vida passamos pelo mesmo tipo de situação, aprendendo a fazer alguma coisa, testando os nossos limites e com alguém nos ajudando a não nos matarmos. No Scrum eu vejo uma situação dessas principalmente na hora da Sprint Planning.

Na Sprint Planning a equipe deve estimar as estórias e definir com o que eles vão se comprometer na sprint. O SM (Scrum Master) está lá para ajudar a equipe a manter o foco, ver se a equipe está seguindo os “rituais” necessários e, entre outras coisas, a ajudar a equipe não se “matar” com a quantidade de estórias que eles vão colocar na sprint.

Nesse ponto o SM tem que tomar muito cuidado para que ele não “trave”, impedindo que eles testem seus limites e aprendam, uma das maneiras de “travar” a equipe é exigindo que eles sempre entreguem tudo com o que eles se comprometerem, sem dar uma margem para que a equipe erre. Ele tem que saber deixar a equipe testar os seus limites, isso, com certeza, vai gerar alguns ralados, mas assim como quando aprendemos a andar de bicicleta, esses ralados fazem parte do aprendizado, eles nos dizem que naquele momento ultrapassamos nossos limites e que precisamos melhorar em algo antes de descobrirmos novos limites. Mas mesmo assim o SM também tem que tomar cuidado com o outro lado, evitar que a equipe se comprometa com uma quantidade irreal de estórias e se “mate” na sprint.

O conceito essencial para que as coisas funcionem na Sprint Planning é o mesmo conceito fundamental para se andar de bicicleta, equilíbrio. Não é algo fácil, não existe fórmula mágica para calcular isso, esse equilibrio vem da convivência e da conversa entre a equipe e o SM, lembrem-se, assim como quando aprendemos a andar de bicicleta existe alguém nos ajudando a não nos matarmos, essa mesma pessoa nos ajuda a levantar quando caímos, ajuda a curar os nossos ralados, evitando infecções e outras coisas.

Assim tem que ser o SM na Sprint Planning, ajudando a equipe a testar seus limites, ajudando ela a se levantar após um tombo, ajudando a tratar os ralados, mas sem proibir a equipe de andar de bicicleta alegando que é muito perigoso.

Portanto: Scrum Master’s, deixem as equipes se ralarem um pouco, só cuide para que eles não se matem.