Categories
Scrum

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.

74 replies on “Scrum Master técnico?”

GC, me permita descordar totalmente. 😉

quando vc faz isso, está na verdade escondendo uma deficiencia do time.
O time deve ser constituido por pessoas que possam atingir um objetivo em sua plenitude.
Quando o SM faz o papel de líder técnico, ele vira uma muleta para o time e isso começa a roer os princípios de Self Management.

Além disso acho ruim a precepção que um dia o Scrum Master não terá mais trabalho. Ele sempre terá pois sempre é possível melhorar. O que acontece é que os problemas são cada vez menos frequentes(ou difíceis de ver) e cada vez mais difíceis de resolver. Mas isso só deveria acontecer depois que um time Scrum alcançou um desempenho de 5 a 10 vezes superior, comparado ao que era antes do Scrum.

Quando eu lembro que a toyota colocou o Prius na rua em 15 meses desde a sua concepção passando por mais de 10 projetos de motores diferentes, eu vejo que a industria de software tem muito o que amadurecer ainda.

Cara, esse seu post vai fazer os bispos te mandarem pra fogueira da inquisição. E eu por comentar devo ir junto. Mas …

Eu acho que já conversei isso pelos corredores da gcom várias vezes com o GC, isso é quase que um assunto proibido lá. Mas o fato é, ao adotar scrum, a maioria dos melhores técnicos foram alçados a posição de scrummaster. De repente, os times se viram sem seus líderes, sem alguém para tomar decisões técnicas (não estou falando do que fazer, mas do como fazer). Hoje na posição de SMs estamos limitados a dizer o que não fazer, ou como não fazer, só podemos influenciar tecnicamente a direção do time através de TechTalks!

Ora, qual o maior patrimônio da gcom? São as pessoas! Estamos lutando para que tenhamos o melhor corpo técnico possível. Estamos incentivando as pessoas a fazer mestrado, queremos chegar a um nível de excelência técnica que nos coloque em outro patamar. Mas quando pegamos nossos melhores técnicos e colocamos algemas para que eles não tenham opiniões técnicas, o que estamos fazendo? Matando a galinha dos ovos de ouro?

Somos essencialmente técnicos, temos uma origem técnica, gostamos de programar. Ei! Somos bons nisso, lembram?

Mas como devemos participar?

Numa conversa com o Danilo e Antonio, certa vez o Antonio disse algo que fez muito sentido. Nós não devemos interferir ao ponto do time considerar algo como a solução do SM e não se sentir mais dono da solução, o que teria um impacto muito negativo no comprometimento do time. É muito importante que o time tenha “propriedade” sobre a solução, isso evita coisas como “a solução do fulano”, “o modulo do sicrano”. É uma linha muito tênue.

Claro que seria muito danoso para o time que os SMs tivessem tarefas. O SM é um cara que não entra em fluxo, ele é coberto de interrupções durante todo o dia. Pegando tarefas a possibilidade dele gerar um impedimento para o time por não terminá-las seria muito grande. Mas …

Existem coisas que o SM pode fazer que podem ajudar e muito o time. Entendo que uma das funções do SM é permitir que o time não saia do fluxo, é retirar impedimentos (ou atrapalhamentos como eu gosto de dizer). E vamos a lista delas:

– pequenos bugs: na minha concepção, pequenos bugs que aparecem podem ser resolvidos pelo SM, esses bugs não necessariamente são do sprint, eles podem ser resolvidos se que o time seja interrompido. Isso é saudável! Mantém o fluxo do time.

– service desks (ou nosso famigerado webdesk): por que colocar alguém do time “de castigo” atendendo ao webdesk? Ora bolas, deixa isso no colo do SM e ele só aciona o “operacional” do time se precisar. Mais uma vez isso mantém o time em fluxo, sem ser interrompido. As tarefas do webdesk são chatas por natureza. O SM em geral é um cara mais senior que tem o discernimento da importância de resolver esses pequenos problemas e não se importa de resolvê-los.

– estudos necessários a tarefas fora do sprint: diversas vezes o time levanta uma necessidade de estudar determinada tecnologia para que seja mais fácil entregar uma história, o SM pode digerir essa tecnologia antes e já entregar alguns ponteiros para o time, agilizando o estudo.

tá grande demais já …

Excelente Post GC,

Concordo com vc em praticamente tudo, e acredito fortemente que os processos devem servir para que as pessoas e a empresa atinjam seu(s) objetivo(s). Sempre digo que o Scrum não é um processo democrático, mas é um processo muito simples com poucas regras que devm ser seguidas para se obter o resultado esperado. No entanto, por sem simples o SCRUM nos dá oportunidades de improvisar e melhorar que outros processos/metodologias/frameworks não permitem.

Ou seja, se vc enxerga uma oportunidade de melhorar e tem as ferramentas necessárias ao alcance, por que não usá-las?

O ScrumMaster é um facilitador, ajuda a resolver os impedimentos, correto? Sendo assim, facilitar algo tecnicamente estaria dentro dos papéis de um ScrumMaster desde que isto não atrapalhe suas outras atividades… Como o Phillip disse, ele na verdade estaria trocando momentaneamente de papéis, atuando como um desenvolvedor. abs!

Muanis, eu acho que o buraco é mais embaixo. Como falie antes existem papéis em desenvolvimento de software e dentro do contexto existem dois relevantes: SM e tech lead.

Em projetos onde a complexidade justifique o SM deve se dedicar exclusivamente à sua tarefa. Isso é muito comum durante a introdução de uma metodologia ágil, quando o SM (ou outro nome) assume o papel de campeão da nova forma de pensar e vai perder o dia inteiro tentando fazer com que aquilo dê certo. Quando a empresa ou o departamento está azeitado o papel do Scrum Master dilui bastante.

Quando a complexidade não justifica um SM 24/7 (e dificilmente justifica) não existe qualquer problema em termos o tech lead exercendo tarefas de SM. A pior coisa que pode acontecer é quando o SM não exerce qualquer tarefa técnica mas ainda assim é ele quem vai pras reuniões, e não o time todo.

O fato de termos um time multifuncional no Scrum não invalida a necessidade de alguém que atue como coach, mentor e líder técnico. Se por algum motivo o papel de ScrumMaster não pode ser ser do tech lead então temos que fazer outra pessoa assumir este papel.

Conhcendo o cenário que voc6e fala sobre eu não me lembro de anda grande o suficiente para que um tech lead não seja Scrum Master, ainda mais quando a organização abraça a agilidade.

[]s

Guilherme, concordo…mas concordo da forma que você colocou! Nos exemplos que você citou entendo que o ScrumMaster deveria estar envolvido, e sim, realizando as tarefas/impedimentos técnicos.
O que sou contra é o ScrumMaster pegar tarefas de desenvolvimento do Sprint atual – aquelas desmembradas dos Itens selecionados para o Sprint – pois para isso ele terá que estar bastante comprometido com estas tarefas, e irá priorizá-las quando da necessidade de decidir entre isto ou aquilo, sendo que “aquilo” seriam tarefas próprias de um ScrumMaster.
Penso que quando o ScrumMaster “tem tempo” para executar estas tarefas (do sprint atual) ele – provavelmente – está falhando no seu papel! Uma frase do Ken Schwaber sinaliza isso “ScrumMaster com tempo sobrando é um ScrumMaster que ainda não entendeu o seu papel, consequentemente é um ScrumMaster fraco!”.
ScrumMaster tem que ser acima de tudo um grande facilitador, e para sê-lo precisa estar envolvido em tudo que está acontecendo no projeto e em volta dele. Se no seu projeto pegar tarefas técnicas não atrapalham isto…ótimo!

Abraços.

Alexandre Magno

Isso Phillip!

Essa é a essência, só pra você ter uma idéia, agora que estou no começo do projeto e isso coincidiu com a formação do time, eu simplesmente não tenho tempo de fazer quase nada além de manter o processo andando. Mas isso já melhorou bastante do sprint anterior pra esse. Dentro de algum tempo provavelmente eu terei “tempo ocioso como SM”, algo que poderia perfeitamente ser usado dentro de um papel diferente.

Mas é sempre importante lembrar, o limite de atuação do SM como Tech Lead deve ser delineado pela fronteira do “Command and Control”, o SM atuando num papel técnico, deve estar a serviço do time, e não no controle dele.

@Danilo

A Toyota tem dezenas de engenheiros que ganham um bocado de grana mais que todos nós juntos 🙂 Não dá pra comparar.

Eu não estou falando que o Scrum Master deva suprir deficiências do time, mas justamente ao contrário. Estou falando em deixar o time agir plenamente sobre os problemas do Sprint, enquanto o Scrum Master está totalmente focado em resolver problemas externos. Resolver impedimentos como os que eu citei no texto sempre ajudaram o time a se concentrar mais no trabalho.

Essa coisa de que os problemas ficam cada vez mais difíceis de resolver e que o Scrum Master sempre terá trabalho funciona na teoria. Na prática não é assim o tempo todo, e você tem que se adaptar a realidade e ajudar o time, não importa como. E não acho que isso tem a ver com o Scrum Master não estar fazendo seu papel. O que acontece é que o time evolui e o Scrum Master já removeu tantas barreiras que elas vão diminuindo. E não necessariamente o time será x ou n vezes mais produtivo por causa disso, porque este fator sozinho não é determinante.

O Scrum Master deve ajudar o time a atingir seu objetivo, sempre seguindo as práticas e princípios do Scrum. Em nenhum lugar foi enumerado o que ele deve ou não deve fazer. Aliás, a ênfase é sempre em inspecionar e se adaptar. Se adaptar-se significa usar seu conhecimento técnico, então, assim deverá ser feito.

@muanis, quando o SM assume o papel de resolver Bugs e Service desk acaba tirando o comprometimento do time com a qualidade do que é feito, já que tem alguém pra se preocupar com isso.

@Danilo

Tem bugs que não tem nada a ver com o software, mas sim com instabilidades do ambiente, mal uso da ferramenta, etc. O Scrum Master pode funcionar como um filtro, jogando para o time apenas o que é de fato bug, e resolvendo o que não é. É como fazemos hoje lá no meu time, e tem funcionado. Eles não perdem comprometimento com a quelidade e são eles que continuam resolvendo todos os bugs.

Reforçando o que eu disse acima, mais uma frase do Mike Cohn daquele mesmo artigo:

“While the ScrumMaster role does not always require a full-time, eight-hour-a-day commitment, it does require someone in the role who is fully committed to it. The ScrumMaster must feel the same high level of commitment to the project and the goals of the current sprint as do team members.

[…]

While the ScrumMaster may not be a full-time job, the ScrumMaster should plan on being the ScrumMaster for the full duration of the project. It is very disruptive for a team to change ScrumMasters in midstream.”

Efetivamente o Scrum Master pode não ser necessário full time. O que importa é o comprometimento, e isso ele pode ter independente da quantidade de horas que está trabalhando como SM. E eu reforço que com o passar do tempo ele é muito menos exigido que no início do projeto/adoção. Isso não é nenhuma teoria, é o que acontece na prática.

O cerne na questão não está em impedir o Scrum Master de fazer o que ele acha que é certo, mas sim em fazer com que ele não tire o comprometimento do time. São duas coisas completamente diferentes.

@Danilo

O SM nunca vai resolver grandes bugs, em geral ele vai apenas fazer um filtro, até pra decidir se algo deve ser inserido como operacional ou colocado no backlog. Ter alguem do time dedicado a isso não tem nada a ver com comprometimento e atrapalha o andamento do sprint (pelo menos na minha visão). Resolver algo trivial não vai diminuir o compromentimento do time.

@GC,

entendo que em alguns momentos se o projeto está desandando e o SM tem conhecimentos tecnicos, nada mais justo do que o SM ajudar com as tarefas tecnicas, mas ele tem que saber que está cobrindo uma deficiencia do time e que se ele não tomar uma providência isso não irá acabar nunca.

O time também tem que entender que esse não é o papel do SM e encarar o “uso” dele como faria com um outro especialista qq, que em alguns momentos, pode ser chamado pra ajudar o time a resolver um problema mais cascudo que não suporte ou justifique o aprendizado do time naquele momento. Perceba que não estou falando de pequenos bugs ou chamados de atendimento, pois esses sim, devem ser tratados pelo time, para que eles entendam a importancia de fazer treinamentos para o suporte, escrever documentação e manter a boa qualidade do código.

@Danilo

Eu seeeeei, mas não é esse o meu ponto.

Concordo com você que eu não posso cobrir deficiências do time. Mas neste caso, não estou fazendo nada nem perto disso. Nos exemplos que coloquei no meu post, apenas ajudei o time a resolver problemas. Estou ajudando o time a ser mais produtivo, a entregar mais, e a se concentrar mais nas features solicitadas pelo P.O.

Não vejo de forma alguma como isso pode ser ruim e não vejo como isso pode tirar o comprometimento do time.

Muito bem cara!!! Sempre acreditei que afastar o scrum master ao extremo das atividades técnicas não era o melhor caminho… Existe um caminho do meio em que o scrum master pode ajudar muito com suas habilidades técnicas sem deixar de cuidar de outras atividades que a ele cabem… Parabéns pela coragem de desafiar essas premissas que as vezes imobilizam as pessoas que desempenham esse papel! Abraço.

Bom GC, vc sabe o que eu penso sobre isso, mas aqui seguem mais algumas linhas.

Acho que acima de tudo estamos todos aprendendo como é esse negócio de ser ágil e estas novas iniciativas como Crystal e Scrum, entre outras.
Eu sempre acho que não devemos ser radicais, nem nas nossas vidas pessoais, nem profissionalmente.

No Scrum as regras sao poucas e muito simples, além disso o Scrum é um processo empírico, que vai se adaptando as formas de trabalho de cada empresa, time, projeto no decorrer do tempo com erros e liçoes aprendidas a cada novo ciclo, por isso temos a Retrospectiva, os impedimentos do Time e os impedimentos da empresa entre outras ferramentas que nos ajudam nessa melhoria contínua.

E não há verdades absolutas, o que não funcionou para um time em um dado projeto não quer dizer que não funcionará para um outro time em um outro projeto. As coisas devem ser testadas, medidas e depois compartilhadas para que todos possam tomar suas próprias decisões.

Acredito que é possível ter ScrumMasters como coaches técnicos desde que ele nao deixe de lado seu papel principal, seu foco em retirar os impedimentos do time e preservar o processo, e que não retire o comprometimento e responsabilidade do Time sobre os Goals dos Sprints.

That’s my 2c.

@GC concordo plenamente contigo, mas acho que resolver um impedimento técnico do time possa ser ruim quando você acaba se adiantando a solução, sem deixar que o time conheça do problema.

No caso que você citou:

“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.”

Acredito que realmente foi bom você se adiantar ao time, mas talvez com isso você acaba por levar uma solução pronta. Isso é o melhor prá o Time? É a melhor solução para o projeto? E se surgir um problema semelhante e você estiver resolvendo outro impedimento do time?

O que quero dizer com isso é: Sim, o Scrum Master pode ajudar de forma técnica, mas o Time não pode DEPENDER do SM para isso, logo faço minhas as palavras do Falcão.

@GC, concordo com todos seus argumentos, mas entendo a preocupação do Danilo.

O fato é que você (GC) sabe diferenciar claramente quando você pode ajudar tecnicamente o time sem onerar o papel de Scrum Master. O ponto é que um SM menos experiente pode se distanciar de seu foco e não estar tão atento para impediments do time se estiver preocupado demais resolvendo questões técnicas.

Acredito que no caso do Danilo, que tem uma equipe com alguns SMs que estão começando agora, não misturar o lado técnico seja uma medida de cautela, para que ganhem experiência e mais vivência como SMs.

Como porco, isso muito me interessa… 😀

Concordo com todos que defendem a atuação do SM como papel, bem como suas devidas intervenções, pitacos, alertas ou ‘chiliques’ – Se for pra ajudar, é claro!

(para os globais)
Usando o comentário do Muanis, quando fala que “a maioria dos melhores técnicos foram alçados a posição de scrummaster”, nada tenho a contestar, porém vejo – IMHO – que a partir disso a transição para o Scrum ficou um pouco dificultada pois as pessoas (como eu) habituadas ao modelo tradicional chefe-peão mantêm forte dependência e referência à hieraquia.

Acho que o SM vai botar a mão na massa se faz o que gosta e fizer com qualidade, assim não cria um impedimento. Mas isso não acontecerá a toda hora pois acredito que nem todos terão essa percepção nem voluntariedade.

As regras são poucas e simples, mas não são fáceis. Por “medida de cautela”, prefiro ver o trabalho entregue com ajudinha extra seja de quem for – ou não.

Guilherme,

Excelente post. Concordo em grande parte e fico com a seguinte dúvida: Se você ajudou programando o tal impediment dessa api de busca interna da empresa, provavelmente contribuiu com código e o time não viu nada disso por estar focado no sprint em andamento.

1. Como fica o spreading knowledge disso ?
2. Como o time vai medir a complexidade de implementar algo que usa essa api ?
3. Como você está fazendo pra passar esse conhecimento ?
4. E por fim, isso que resolveu não deveria ser categorizado como débito técnico e ser resolvido pelo time? (build, integração continua, integração com api, etc)

Abraços,
Bruno Carvalho

@Bruno

A “solução engenhosa” que fiz foi apenas mais um método de uma API que já é velha conhecida de todos os desenvolvedores. Qualquer um deles olharia o código e descobriria em 5 minutos o que foi feito, que não foi nada de mais. O que me levou a fazer isso foi saber que sempre que temos problemas desse tipo levamos no mínimo 5 dias para resolver (entre marcar reuniões, conversar, testar, etc), e definitivamente não seria bom ver todo mundo parado esperando por isso.

Acho que isso responde todas as perguntas:

1. e 3.: Foi trivial, não há nada de novo que ninguém já não conheça.
2.: Da mesma forma que mediria qualquer outra coisa que usasse qualquer funcionalidade da API. Não é o caso.
4.: Não, não é o caso. É uma nova forma de buscar conteúdo, não um fix proveniente de débito.

@Azambuja

Entendo o ponto. Mas justamente porque dois SM são diferentes e dois times são diferentes e todas as pessoas são diferentes é que não podemos criar regras generalistas. “Fulano não pode fazer isso ou aquilo”, pode servir para meia dúzia de casos mas não para todos. Como já venho enfatizando aqui, uma das práticas do processo é “inspect and adapt”, e por causa disso, não necessariamente os times terão as mesmas regras ou características ao longo do tempo.

Cada caso é um caso.

Independente se o cara é Scrum master, líder de projeto, gerente de projetos ou o que ele queira se apelidar, o “general” da equipe tem que ser alguém que é o melhor do time. Aquele que poderia criar todo o sistema sozinho, entende todas as nuances do projeto.
Isso existe? conheço vários, mas a maioria não é assim, geralmente é o cara que não “gostava” de programação na faculdade e resolveu trilhar o caminho de “gerente”, no máximo estudando UML e se certificando em PMBOK ou Scrum (A.K.A PMBOK de Jeans) 🙂

Guilherme, concordo contigo em gênero, número e grau. Vou além: na minha opinião o ScrumMaster TEM QUE TER um background técnico. Creio que ninguém mais quer gerentes de projeto que não se envolva, que não conheça. Muitos que seguem a cartilhinha do PMBOK dizem “eu não me envolvo com com projeto, estou aqui só para controlar”.

Na minha experiência, uma equipe técnica aceita melhor a liderança de um líder que é tecnicamente esperto. Isso é observação pessoal. Três anos dentro de fábrica de software me ensinaram que esses ex-programadores mainframe que não se atualizaram e seguiram o caminho de “gerentes de projeto” (e hoje são PMP) são péssimos líderes.

Não concordei com o Boris Gloger no treinamento CSM quando ele disse que o ScrumMaster é “tecnicamente idiota” (palavras dele). Na literatura (o próprio “Agile Software Development with Scrum”), o Ken Schwaber dá boas impressões que um bom ScrumMaster sabe quando a equipe não está entregando “software funcionando”, quando o processo não está sendo seguido e principalmente buscando riscos técnicos escondidos.

Agora, um ponto importante é que é necessário alguém que resolva impedimentos e seja imparcial o suficiente para compreender que ele também deve atender os desejos e prazos do PO. O ScrumMaster não pode ter apego pessoal com o Team. O ScrumMaster está lá para controlar demanda e produção. Ele não pode ser mais apegado com a equipe do que com o Product Owner.

Rodrigo Yoshima
ASPECOM / MundoJava

Saquei,

Vou contigo e com a visão do Phillip Calçado de que o que temos são papéis. Você como Scrum Master pode desempenhar outros papéis junto ao time, como de team leader, coach, whatever e fazer o que for necessário pro projeto andar em velocidade máxima 🙂

Valeu pelas respostas gc !

Abracao,
Bruno Carvalho

Por acaso li o mesmo texto do Mike Cohn no sábado (sobre as características de um bom Scrum Master). Estamos em uma fase de transição. Acho que uma das responsabilidades do Scrum Master (hoje essencialmente técnico aqui na Gcom) é fazer com que emerjam lideranças técnicas dentro dos times, pois isso os fará evoluir. Mas logicamente isso não é de uma hora para outra. Essa evolução deve ser gradual, para que seja consistente. E a ajuda do SM é fundamental para isso. Tentar sugerir as respostas de forma sutil, ou parte delas, fazendo as pessoas pensarem, pode ser uma forma interessante.

Guilherme, vou entrar no time da oposição, junto com o Danilo e o Antonio Carlos. Para mim, a figura do SM no time é de alguém para manter o processo andando, alguém que mantenha todas as engrenagens no lugar. Se ele coloca o chapéu de programador e começa a resolver bugs, ele está mascarando uma deficiência do time, o que vai contra um princípio básico do Scrum, o de fazer com que os problemas e as deficiências venham à tona.
Vestir o chapéu de especialista por algumas horas e sentar ao lado de alguém que está com dificuldade numa tarefa é algo recomendável, até porque ignorar conhecimento e experiência é um desperdício. Por outro lado, fazer da correção de bugs e das melhorias no código uma atribuição diária do SM prejudica o time, porque esconde as deficiência que levaram a estes bugs. Bugs assim podem ser sintomas da falta de conhecimento sobre um assunto novo ou da dificuldade de um programador menos experiente, mas isto pode se acumular ao ponto de comprometer o resultado do time, mascarando até mesmo as métricas de velocidade das entregas.

Para concluir, o que vou dizer vai parecer rude, mas é a extensão deste raciocínio até um ponto extremo, não uma colocação de caráter pessoal. Quanto mais o SM segue na linha de fazer pequenas tarefas, de resolver pequenos empecilhos ao andamento das entregas, pensando que isto ajuda o andamento do time, mais ele está deixando de atacar as origens deste empecilhos, gerando uma aparência de normalidade numa situação potencialmente problemática. Fazendo isso, ele está se afastando de seu papel de Scrum Master, gerando uma percepção falsa de velocidade e qualidade das entregas, o que é diametralmente oposto ao que se espera da prática do Scrum.

@Carolo

Para mim isso soa como: “se o Scrum Master resolver os impedimentos, o time terá uma falsa produtividade, gerando uma percepção falsa de velocidade e qualidade”.

Na minha opinião e no contexto do nosso projeto/equipe/etc, acho perfeitamente plausível que eu faça coisas como exemplifiquei no post, porque efetivamente elas ajudaram o time a se concentrar no que era mais importante para o P.O. e o projeto naquele momento: o Sprint.

Muito boa esta discussão!

Sempre tive dúvidas sobre como o SM preencheria seu tempo pois sempre me pareceu que lhe sobraria tempo.

Minha intervenção é mais para elogiar a discussão do que propriamente acrescentar algo de valor.

Para não ficar só no baba ovo, acho (do verbo sinônimo de chutar) que se for para fazer coisas específicas ligeiras ou para ajudar na busca de soluções para casos especiais, não vejo mal que o SM (nada a ver com a sigla sado masoquista) dedique algumas horas usando o seu chapéu de especialista super 3X. O melhor é que este papel seja exercido mais como facilitador e como orientador para que este papel de bombeiro não vire rotina dentro da equipe.

Mas a médio e longo prazo para a equipe, o melhor aproveitamento do tempo livre do SM seria estudando para se aprimorar cada vez mais como SM e nas suas relações com os stakeholders (mesmo que para isto precise fazer o sacrifício de almoçar em um restaurante chique tomando um vinho Amarone com o diretor)

Acho estamos em uma fase de transição, estamos aprendendo
oq funciona nesse novo processo. Talvez um pouco de
flexibilidade não seja problema. O SM participando
de uma discussões tecnicas, orientando e não sendo resposável pela
solução é totalmente valido. Como você mesmo disse os
melhores técnicos estão hoje no papel de SM e os integrantes
do time ainda não estão acotumados em serem “lideres”.

Mas oq eu vejo hoje é que o time espera a solução tecnica
do SM. Nesse caso o SM deve fazer
com que o time consiga total independencia e seja tão bom ou
melhor tecnicamente que os SMs de hoje.

Eu tenho uma teoria: Aqueles que acham que o SM não pode dar uma programadazinha no tempo livre, mesmo que sejam Bugs pequenos sem perder seu foco principal, na verdade não gostam muito de programar, preferem apenas ficar num “Cargo” (ai já deixa de ser papel) que cuide apenas do administrativo. Mas isso é apenas o que eu acho, afinal de contas gostar/Não gostar de programar não é certo nem errado, é apenas gosto.

Guilherme, parabéns pelo Post.

GC,

Concordo plenamente com a sua posição. Como alguns mencionaram, o que temos são pessoas exercendo papéis. Em equipes ágeis, os membros devem ser capazes de exercer os diversos papéis necessários para entregar o projeto (por exemplo, desenvolvedor e testador). Duvido que alguém seria contra que um membro do time, cujo título é de testador, exercesse o papel de desenvolvedor caso ele fosse capaz de fazer isso. Da mesma forma, acredito que um ScrumMaster capaz de exercer o papel de desenvolvedor deve fazê-lo sempre que isso ajude o time a atingir seus objetivos.

Em relação ao problema do time adotar as soluções dadas pelo SM e, dessa forma, retornamos a uma estrutura de command-control, não acredito que isso aconteça. Poderíamos ter um membro do time (não o SM) mais experiente ou com maior capacidade técnica e que, por causa disso, suas soluções sejam as mais adotadas pelo time. Nem por isso temos um gerenciamento command-control. Acho que cabe ao time ter a consciência de decidir em conjunto qual a melhor solução, independente de quem a sugeriu.

Mais um comentário. As pessoas que se posicionam contra o que o GC colocou no post usam como argumentos o fato de que quando o SM executa essas tarefas técnicas ele está, na verdade, mascarando um problema da equipe e esse problema poderá explodir em algum momento. Fica uma pergunta. Se algum membro do time, que não o SM, executar essas tarefas esse membro tb estaria mascarando os problemas? O que eu acho é que o SM pode exercer o mesmo papel de um membro qualquer do time. Nesse caso, ele nada mais é do que isso: um membro do time.

Guilherme, resolver impedimentos é diferente de escrever código. Resolver bugs e desempenhar outras atividades que deveriam ser tarefas para o time, tais como reconfigurar ambientes, etc, não são atribuições do SM. Se ele conta com seu próprio rendimento para terminar as entregas do sprint ele está saindo do papel de SM e “contaminando” as estatísticas do time.

@Guilherme Cirne,

Excelente, i++!!

@Carolo,

Resolver impedimentos é RESOLVER IMPEDIMENTOS, não há nenhuma restrição sobre codificar, matar alguém, agradar alguém, fazer um motim, etc. O cerne da questão não tem nada a ver com programar ou não.

Veja que vc está falando somente de resolver bugs. Eu concordo com você que o SM não deve resolver bugs, porque isso seria tarefa do time. Mas pode haver uma diferença sutil entre um bug e um impedimento, e sobre isso nós só chegaremos á uma conclusão definitiva se discutirmos sobre um problema específico.

Falando de forma abstrata, é um erro criar regras que limitam o funcionamento do time/SM/quem quer que seja. O SM deve fazer o que estiver ao seu alcance para resolver os problemas, sempre se preocupando em seguir as diretrizes básicas do Scrum e, como vocês mesmos já disseram, sem encobrir problemas do time/empresa/etc.

Essa idéia de quererem amarrar o SM dessa forma me fez lembrar uma coisa que li no livro Ship it! logo na introdução:

Ship it Page 2:
“… Never be afraid to remove something that doesn’t work in your circunstance, and dont keep a practice just because it’s well’known or popular. Forge out your own way, based on what works for you and what doesn’t.”

Aplicando isso ao SM, eu acho que se num ambiente for possível que o SM ajude em questões tecnicas sem deixar de desempenhar seu papel principal, tudo bem. Afinal de contas, se funciona no ambiente dele qual o problema?

Excelente discussão que se formou em torno deste tópico, na hora exata em que o vi, sabia que não seria diferente 🙂

Acredito que a melhor solução não seria nem desperdiçar o conhecimento técnico do SM, tampouco fazer com que ele se torne uma “muleta” para o time, como o Danilo falou. Ao meu ver, o SM poderia ser uma espécie de “consultor” para o time, quando ele tem o conhecimento técnico necessário para isso. Assim ele poderia ajudar o time a encontrar suas próprias soluções ao invés de já chegar com os problemas resolvidos – por ainda menores que fossem.

Excelente discussão, Gc 🙂

Legal discutir sobre isso,

Leave a Reply

Your email address will not be published. Required fields are marked *