GP digivolve para ScrumMaster!

Apenas para alinharmos: o meu pensamento pessoal sobre o ScrumMaster, é muito simples:

1. Ele é quem mais manja de Scrum, garante que o Scrum será aplicado e ensina e ajuda a todos a aplica-lo; (inclusive ajudar o PO a montar o Product Backlog)
   
   
2. Ele é o paizão do time de desenvolvimento. Ele cobre todo mundo e deixa que o time faça o seu trabalho; Ele é um facilitador. Ou servidor.
   
   
3. Ele remove todos os obstáculos que aparecerem durante o desenvolvimento;
   
   
4. Ele é parte do time;
   
   
5. Ele é PIG; e
   
   
6. É ele quem cultiva o espírito de time da equipe (essa é por minha conta! rs..)
   

Como disse, isso é o que eu entendo como sendo as atribuições do ScrumMaster.

Note que em nenhum momento há nada parecido como: "gerencia", "coordena", "organiza", "comanda", "controla" ou "cobra".

Como o Time Scrum é auto-gerenciado, é do time responsabilidades como: definir o que irá compor o Sprint Backlog; garantir a qualidade do produto; e etc.

Ok, parece bem simples, né? Pois é.

Quando GP digivolve para ScrumMaster!


Sabemos que não é fácil quebrar paradigmas (ou "paradinha", como diz Luli Radfahrer, rs..).

Eu sei. Estudo POO há um bom tempo, e ainda não peguei o jeito, de verdade! Os vícios que adquirimos com o tempo, dificultam essa mudança do pensamento.

Agora imagine mudar uma "paradinha" muito maior, como o fato de vc estar acostumado a ter o controle, ser o centralizador de tudo, organizar cronogramas, mandar e desmandar.

Poxa, vc vai perder o seu poder que demorou tanto para vc conquistar!

É a barra que passa quem era GP e passa a ter a função de ScrumMaster.

Veja bem, eu não estou criticando GP's. Conheço alguns ótimos, onde sem eles alguns projetos simplesmente não rolariam. O que estou comentando é sobre o abismo que há entre as atribuições do GP e as do ScrumMaster.

Isso virou um post motivado por uma ocasião específica.

Estava conversando com um certificado ScrumMaster (ex GP), apresentando o esquema de Integração Continua (IC) que estamos adotando na equipe (aliás, ótimo assunto para outro post! rs..).

Quando comentei sobre a auditoria automática de código, ouvi o seguinte comentário (não exatamente nessas palavras):

"(..) Ótimo! No final do dia, quando o desenvolvedor estiver indo embora, se o ScrumMaster notar algum problema nos relatórios de auditoria de código ele vai barrar o desenvolvedor no momento e falar: 'você não vai embora enquanto não resolver isso aqui!'.(..)"

(no way!!!)

..pois é.

Veja bem: eu estava apresentando uma técnica que foi estudada pelo time, que estava sendo defendida e implementada pelo time e, principalmente, para benefício do time!

Realmente, talvez o desenvolvedor ir embora deixando algo a ser feito talvez não fosse a postura mais legal do mundo, porém não é esse o ponto que estou comentando aqui, mas sim sobre o controle do ScrumMaster sobre o time (que como comentei no inicio do post, na minha visão, é nenhum! rs..)

Entendo que a preocupação com a qualidade do produto é do time. Nosso time quer implementar IC, para melhorar a qualidade do nosso produto!

Ok, o ScrumMaster também faz parte do time, mas essa não é uma de suas atribuições. ScrumMaster não gerencia: ele facilita e ajuda!

Agora, se o seu time não está comprometido com a qualidade do produto, com a meta, com o conceito de pronto e tudo mais, bom, daí a ferramenta de auditoria é o menor dos seus problemas.

Como faz parte das atribuições do ScrumMaster garantir que o Scrum seja aplicado (e isso não tem nada haver com a Engenharia do Software!), se o Scrum Master se depara com um time que não PIG, que não é auto-gerenciável ou desmotivado, aí sim ele deve interferir!

Mas interferir no sentido de motivar o time. De enciná-lo a ser auto-gerênciável. De fazer o time ser PIG! Essa é uma das atribuições do ScrumMater, pois tem tudo haver com "garantir que o Scrum seja aplicado corretamente". E não se preocupar em fiscalizar o time!

Esse tipo de fiscalização é totalmente prejudicial para a saúde do Scrum, e é uma potêncial causa de fracasso!

Ao contrário do que possa parecer, isso não é anarquia!! Apenas com um time PIG é que os métodos ágeis podem funcionar. E com um time PIG, o ScrumMaster não precisa se preocupar em ficar fiscalizando relatórios: o próprio time faz isso! É interesse deles, mais do que qualquer um!

Acho que um dos problemas, é o esquema atual de certificação ScrumMaster. Eu acho tão furada, mas tão furada que apesar de ter feito o (excelente) curso da Caelum, não me considero ScrumMaster e nem divulgo que eu tenho o tal certificado.

Essa certificação como é, pode dar uma falsa impressão a quem a tira, para quem a vende (o comercial das consultorias) e para quem as compra (o cliente).

A transição não é fácil! A filosofia ágil traz uma série de mudanças desde pensamento até comportamento. É todo um conjunto de inteligências que devem ser estimuladas.

É como reaprender a andar. Mas dessa vez, com agilidade!

É isso!

;)