Scrum Master técnico?

Há algum tempo que tenho pensado muito sobre o que um Scrum Master pode/deve ou não fazer dentro de uma equipe Scrum.

Lendo vários livros e artigos sobre o assunto, percebi que todos eles enfatizam várias características do Scrum Master. Ele deve ser influente dentro da empresa, corajoso, comprometido com o projeto, deve ajudar o time a entender as práticas do Scrum e assegurar que elas não sejam violadas, dentre outras coisas.

O Scrum Master não precisa ser técnico. Todas as tarefas principais exigidas pela função podem perfeitamente ser realizadas por uma pessoa sem nenhum conhecimento técnico. Porém isso não significa que é ruim quando ele tem conhecimento técnico e usa-o em favor do time ou do projeto. Mais do que isso, acredito fortemente que os melhores Scrum Masters necessariamente devem ter conhecimento técnico e do negócio, pois isso os ajuda a entender melhor os problemas do projeto e ajudar melhor o time.

Essa não é uma opinião só minha. Mike Cohn, um dos grandes nomes do mundo ágil, escreveu no ano passado um artigo sobre o que ele considera que sejam as seis principais características dos melhores Scrum Masters. Uma dessas características é:

Knowledgeable

The best Scrum Masters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.” Lockhart, K. 2006. Responsibility Junkie. Harvard Business Review (October): 30.

A princípio o Scrum Master não deve estar comprometido com tarefas dentro do projeto e deve evitar se intrometer tecnicamente. Primeiro, porque impedirá que ele se concentre em resolver os impedimentos e problemas que estão no caminho do time, que no início da adoção são muitos e muito graves. Segundo, porque ele pode acabar tirando o compromisso do time. Ele pode acabar tomando decisões que nem todos concordam exatamente, mas farão porque alguém acima na hierarquia determinou e aí voltamos ao gerenciamento command-control onde as pessoas só fazem o que são mandadas. Para evitar esses problemas, no início da adoção é recomendável que o Scrum Master siga as recomendações e as práticas à risca e que se concentre em cuidar só disso.

Porém, vejo que depois de um certo tempo o time e o Scrum Master se adaptam tanto à empresa e a forma como ela trabalha (assim como a empresa se adapta às necessidades do time) que o time precisa cada vez menos do Scrum Master. Ele continuará sendo necessário na hora em que aparecerem problemas fora do alcance do time, mas penso que isso aconteça na menor parte do tempo e cada vez menos. O time e a empresa amadurecem sua relação e evoluem tanto que o time entra num ritmo de alta produtividade e sofre cada vez menos interferências.

E quando isso acontecer o Scrum Master deverá ficar sentado esperando o próximo problema/impedimento a ser resolvido? Certamente isso não seria bom para a empresa.

Todos os Scrum Masters ou líderes de projeto que conheço são pessoas excelentes tecnicamente. Muito modestamente e humildemente falando, eu me incluo neste grupo. Eu e todos esses líderes/Scrum Masters que conheço chegaram nesta posição por terem sido ótimos técnicos e se destacarem entre os demais. Como é que se pode ignorar este fato e pedir que eles simplesmente deixem de fazer o que mais sabem? Porque o Scrum Master não pode trabalhar com impedimentos técnicos? Ou programar? Desde que se concentre primariamente em exercer seu papel de Scrum Master, que não atrapalhe o time e que não atrapalhe o projeto, é totalmente aceitável que ele faça isso. Aliás, nenhum livro sobre Scrum fala o contrário.

Hoje, por exemplo, eu diria que uso metade do meu tempo exercendo ativamente o papel de Scrum Master. Na outra metade, eu não fico parado esperando o próximo problema acontecer.

No último Sprint do meu time, por exemplo, trabalhei para resolver um impedimento técnico gigantesco do próximo Sprint. Estamos no meio de um projeto importante para a empresa e a história que talvez seja a mais importante de todas acabou ficando de fora do Sprint. Já é certo que ela será a primeira história do próximo Sprint, porém, existe um grande impedimento técnico relacionado à forma como funciona uma API de busca interna da empresa, e eu trabalhei para contornar este problema e o time possa trabalhar tranquilamente na próxima semana. Outro exemplo, foi quando parei uns três dias para reconfigurar todo nosso ambiente de integração contínua e fazer um refactor agressivo no build. Ou então, para não desfocar o time do seu trabalho, eu resolvo silenciosamente vários bugzinhos chatos.

Muitas pessoas discordam dessa atitude simplesmente porque eu tive que codificar alguma coisa. Mas eu não estou facilitando o trabalho do time? Não estou resolvendo problemas e fazendo com que o time só precise se concentrar em entregar seu trabalho? O Scrum é um framework onde a cada período de desenvolvimento temos oportunidade de avaliar o que fizemos e nos adaptarmos às circuntâncias do projeto/time/empresa. Refletindo sobre o meu trabalho, percebi que se eu me adaptasse para trabalhar desta forma poderia contribuir muito mais com o time e a empresa do que simplesmente fazendo o feijão-com-arroz do Scrum.

Coincidentemente (ou não), o Phillip Calçado escreveu um post que vou usar como argumento para outro ponto importante. O manifesto ágil, base para todas as metodologias ágeis que conhecemos, coloca pessoas acima do processo. Ou seja, o processo importa menos do que as pessoas que participam dele. Parafraseando o Phillip, você não pode fazer que o processo –ágil ou não- vença à razão e você tenha um desenvolvedor (ou Scrum Master) completamente desestimulado e frustrado na equipe. Mais ainda, você não pode fazer com que o processo deixe de lado pessoas técnicas altamente capazes.

A verdade é que não existe uma regra. Você faz a regra, mas faça com consciência e sabedoria.

Tags: , , ,

74 Responses to “Scrum Master técnico?”

  1. Muanis says:

    Tudo tem pelo menos 2 facetas …

    O SM corrigir um bug.
    1 – Pode esconder a deficiencia do time em produzir codigo de qualidade
    2 – Pode aumentar a velocidade do time, mantendo o mesmo em fluxo.

    É dificil decidir o que é mais danoso ou lucrativo no curto/medio prazo.

    Por isso é muito complicado intervir.

  2. octavio magalhaes says:

    Guilherme,

    Ótimo post !! Parabéns !!

    Na minha opinião, existem algumas formas de o SM ajudar o time tecnicamente sem que ele venha a lidar diretamente com código.

    Se o time não está conseguindo resolver um problema é por que existe uma deficiencia que precisa ser tratada. Nesse caso o SM poderia até estudar sobre o assunto e passar o conhecimento para o time, de forma que ELES consigam resolver a pendencia. É importante que ELES resolvam senão perdem o know-how daquela sitação e, na minha opiniao, perdem a confianca no SM.

    Sim … na minha opinião, o fato de o SM colocar a mao no codigo pode passar a impressão de que ele não confia no time.

    Por outro lado, se ele passa o conhecimento técnico que tem, de forma que o TIME resolva o problema, cria um laço de confiança que, a medio prazo, vai aumentar a produtividade do time.

    Nada impede que o SM estude um determinado assunto e faça uma apresentação para o time, de forma que todos aprendam. Ele não precisa se envolver com código para isso.

    Quanto as pequenas atividades do dia a dia (webdesk por exemplo), uma boa solução seria escolher 1 responsável por sprint. Essa pessoa vai analisar toda a demanda, ver o que realmente é importante e, dependendo do tamanho da tarefa, cria uma atividade operacional ou uma história para o backlog. É legal que o time tenha essa responsabilidade, para que todos tenham um comprometimento maior com o produto.

    No mais, acho que o SM nunca vai ficar muito tempo de bobeira. Grande parte do seu trabalho é o de lidar com as pessoas de forma que o ambiente de trabalho seja harmonioso, que todos trabalhem de forma unida e feliz. Motivar o time é nunca é demais !!!! :)

    Grande abraço

  3. Salve, gALLera, globo.com!
    Saudades de vocês!
    O nível das discussões continua excelente, como sempre!
    Parabéns, Guilherme!
    Vou filosofar, futebolisticamente: Rogério Ceni é o Scrum Master do São Paulo. É goleiro, mas faz gol de falta quando o time precisa!

    Abração a todos!

  4. Elton Okada says:

    Ótimo post Guilherme.
    Uma questão: um profissional com altíssimo nível técnico não teria mais a agregar fazendo parte do time do que exercendo a função de SM ?

    IMHO, em um projeto de desenvolvimento de software, creio que seja interessante termos um SM com conhecimento técnico, mas se o cara for ao mesmo tempo SM e tech lead, as coisas podem acabar indo para o modelo “command and control”.

    Abraços

  5. octavio magalhaes says:

    perfeito fabiano !!

    Na verdade ele esta cobrindo uma falha do time ( que eh nao ter outro otimo cobrador de faltas ).

    Se o adriano treinar muito e virar um otimo cobrador, fatalmente o Rogerio ceni deixara de cobrar( a nao ser pelo ego dele ) ;)

    Grande abraco

    Octavio

  6. Alexandre Bairos says:

    Filosofando um pouco, baseando-me no que o PhilC falou, parece claro que as tarefas que competem ao papel ScrumMaster(http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1121) podem ser desempenhadas pelo líder técnico do time, até uma certa escala. Se o volume de tarefas começa a prejudicar o trabalho essencial do tech lead, esse papel pode ser prenchido por uma outra pessoa. Na essência, o ScrumMaster serve para atender à necessidade de produtividade de um time que cresce até um certo tamanho para gerar mais valor, diferentemente dos papéis Team(com tech lead) e Product Owner, que são fundamentais para a entrega de produto.

  7. javalijr says:

    1- o scrum master deve ser tecnico ou com um vies tecnico muito forte.

    2- tambem acho que as pessoas nao devem ser escravas de processos (que estao em continua evolucao pq as pessoas mudam)

    3- nao vejo nenhum problema que com o tempo os scrum masters possam se dedicar a outras atividades, temos, no entanto que garantir que na fase atual todo o tempo dele esteja dedicado a nossa mudanca cultural.

  8. Demetrius says:

    Excelente tema Guilherme.

    Gostaria apenas de contribuir da seguinte forma:

    Como bem disse o Phillip, também acredito que Scrum Master e Líder Técnico são papéis que podem ser representados por qualquer pessoa dentro da Organização. Entretanto, acredito que para desempenhá-los bem é necessário um aprendizado constante e uma dedicação integral o que pra mim inviabiliza a troca de papéis a toque de caixa. Acho que a função do SM vai muito além dos impedimentos de software ou infraestrutura. Acredito no SM como um facilitador de projetos dentro de uma organização sejam eles tecnicos ou não. De outro lado, como técnico não descarto a necessidade do líder técnico nos projetos de software e isto leva a crer que na verdade o que ainda está em cheque e se temos equipes onde o papel do líder técnico está sendo desempenhado por alguém. Acredito que como fomos técnicos antes de SM, sempre que enxergamos esta brecha (E ela existe na maioria das equipes) acabamos mudando nosso papel para líder técnico. O problema desta questão pra mim é a síndrome do “Sofá Cama” (Bechara essa é tua) que sentimos e isso é realmente frustrante.

    Explicando a síndrome: O sofá cama se dispõem a ser um sofá ou uma cama quando requisitado porém não é tão bom como cama nem tampouco como sofá.

    []’s

  9. Ana Porto says:

    Concordo com o Elton. Acho que o scrum master não precisa ter um alto conhecimento técnico, mas sim um bom relacionamento dentro da empresa. Pelo menos na minha área, os maiores impedimentos são gerados por questões internas. Muito raramente (acredito e espero que isso mude um dia :) ))surgem impedimentos de cunho técnico. Uma pessoa com esse perfil seria mais útil no time.
    Mas acho também que as coisas não podem ser rigorosas, se o scrum master está disponível e pode ajudar, por que não?
    abraços

  10. Rubens says:

    Creio que quanto mais orgânico for o processo melhor, não podemos por conta da adoção do Scrum abandonar nossos skills, porque nesse caso a empresa como um todo perde valor.

    Lembro que entre os princípios dos processos ágeis estão colaboração e humildade para reconhecer que não sabemos tudo (duas cabeças pensam melhor do que uma)

    Sinceramente não vejo problema algum do SM ajudar a equipe num dado momento, desde que esteja sinalizando para a organização as deficiências e correndo atrás para resolve-las.

    O mais importante nisso tudo, no meu ponto de vista é a divisão de responsabilidades, portanto se o time aceitar uma diretriz técnica seja lá de quem for, deve assumir a responsabilidade por isso.

    abs

  11. fagner moura says:

    Penso também por aí Demetrius, como conversamos.

    Sendo prático, acredito que precisamos que as pessoas além de, obviamente, conhecerem, que elas acreditem no Scrum e, ainda, que exista um líder técnico dentro das equipes (há esta visível necessidade), tendo em vista o déficit de conhecimento técnico na maioria. Este que seria um catalisador para que o time evolua como um todo e deixaria os Scrum Masters folgados em sua posição, já que naturalmente estes tendem a querer, mesmo que intuitivamente, resolver impedimentos técnicos devido à carreira destes.

  12. Muanis says:

    Eu li em algum lugar, e eu não me lembro aonde, que o scrum deve ser moldado as necessidades da empresa, porém que ele não deve ser moldado cedo demais, pois você pode estar achando que o problema é o processo, quando na verdade o problema é que as pessoas não entenderam o processo.

    Do meu lado, eu tenho tentado não me meter, é difícil pra kct. Meu time reclama disso em toda retrospectiva, pra nao dizer todo dia. E caramba, eu desenvolvo a mais de 10 anos, me pedir pra esquecer isso em uma semana é complicado. Principalmente quando você sente um “bad smell”.

    Duro é saber se voce está certo ou errado … o tempo dirá :-)

  13. @Muanis
    Eu penso igual a você nesse aspecto. Eu tento fazer assim: Se vejo que uma coisa não está dando certo, primeiro eu verifico se estou fazendo da forma que deveria estar. Em caso positivo, me sinto a vontade para mudar. Em caso negativo, verifico a maneira correta e tento novamente.

  14. [...] discussão que meu amigo Guilherme Chapiewski gerou em seu blog ao fazer um post sobre o papel do Scrum Master atuando como líder técnico do time. Como o assunto é polêmico, e vou adicionar um pouco mais de pimenta, preferi fazer esse [...]

  15. Patricia says:

    discutimos um pouco essa questão nas últimas semanas na equipe de webmedia. Acho que existe um limite bastante sutil para que um SM atue também como líder técnico da equipe. O líder técnico é responsável por apontar o caminho das soluções, representando certa autoridade. O SM deve ser um facilitador, como já mencionado, mas não deve ter autoridade (ou se colocar como autoridade), pois isso necessariamente mina o ownnership do time. Então, é preciso muita sensibilidade para ser um influenciador e ainda assim resguardar o livre arbítrio do time. Metaforicamente, ser deus e deixar o mundo ser mundo. Eis o drama. Em jogo está a maturidade das equipes e o sucesso da metodologia.

  16. [...] Guilherme Chapiewski escreveu um post esta semana bem polêmico e a discussão esta correndo solta no Blog. O ponto é, até onde vai o [...]

  17. [...] discussão que meu amigo Guilherme Chapiewski gerou em seu blog ao fazer um post sobre o papel do Scrum Master atuando como líder técnico do time. Como o assunto é polêmico, e vou adicionar um pouco mais de pimenta, preferi fazer esse [...]

  18. [...] Comentário no blog do Guilherme Chapiewski Enviar por e-mail  | Hits para esta publicação: [...]

  19. [...] discussão que meu amigo Guilherme Chapiewski gerou em seu blog ao fazer um post sobre o papel do Scrum Master atuando como líder técnico do time. Como o assunto é polêmico, e vou adicionar um pouco mais de pimenta, preferi fazer esse [...]

  20. [...] técnico, mete a mão na massa, faz café e chuleia, ou seja, começa a sofrer da sindrome do sofá-cama e não consegue fazer mais nada [...]

  21. hilmo says:

    creio que misturar papéis é a pior falha dos que se dizem profissionais. O scrum master está muito além de preencher documentos.
    Geralmente o scrum master participa em mais de um projeto. Uma das suas funções é verificar gargalos, é mostrar solucoes. botando a mao na massa so mostra que está mascarando necessidades do projeto e ao invés de estar programando deveria se mexer para mostrar aos gesteres onde se está falhando…
    é lamentável ler o que li, na verdade o artigo ta parecendo mais complexo de narciso …
    concordo com que Demetrius fala sobre a sindrome do sofá cama.
    Na empresa onde trabalho TODOS os melhores scrum masther, isso é fato pois houve uma avaliacao para tanto, foram aqueles que se manteram fora dos projetos e que tinham conhecimento técnico básico, pois quando os outros scrum masther com bastante conhecimento se metiam em decisoes e complicava o bom relacionamento das equipes, pois esses acabavam misturando os papéis.

    é aquela coisa, fazer… misturar… é perfeitamente possivel, nao precisa nem ser o poderoso da historia… basta decidir fazer… mas ai entra os conceitos de eficiencia e eficácia… conceitos bem distintos.

    Se gosta tanto de programar porque perde tempo fazendo papel de scrum master?

    • Com o tempo aprendi várias coisas novas e com minhas experiências atuais não necessariamente eu concordo com todas as coisas que escrevi nessa época (há quase 2 anos). O tempo passa e as opiniões evoluem :) Não sei você mas estou em constante aprendizado.

      Enfim, saindo um pouco do assunto do post, sua experiência deve ser bem mais relevante que a minha e provavelmente você sabe bem mais desse assunto que eu. Provavelmente por isso não quis nem se identificar, para evitar de me deixar constrangido ou algo assim, já que provavelmente você também é uma/um profissional reconhecido no mercado e com feitos bem relevantes.

      Ao invés de perder seu tempo escrevendo um comentário enorme e pouco construtivo aqui no meu blog, crie um blog pra você, compartilhe suas excelentes experiências com os outros e aprenda um pouco mais a cada dia – assim como eu.

      [ ]s, gc

  22. Ueide Santos says:

    Ótimo post Guilherme. Concordo plenamente.

    Como “Jorge Luis Risco Becerra” diz: Bom senso vale dinheiro!

  23. [...] colabore com a equipe. Como é argumentado nos posts de Phillip Calçado e Guilherme Chapiewski, resume-se que, já que o manifesto ágil coloca as pessoas acima do processo, [...]

Leave a Reply