Uma idéia comum e compartilhada por muitos é a de que equipes Scrum precisam de um Scrum Master(SM) dedicado. Para equipes novas, isso até faz algum sentido. Mas à medida que as equipes amadurecem, elas ainda precisam de um SM dedicado? Pode um SM ter várias equipes? Pode a equipe assumir este papel por meio de um de seus integrantes? Este artigo propõe que, para equipes maduras, um SM dedicado não é mais necessário.
Alguns meses atrás eu participei de uma reunião de um grupo local de usuários Agile e criei um pouco de agitação quando fiz minha primeira pergunta: "Quantos de vocês são Scrum Master em tempo integral?" Todas as empresas representadas revelaram ter Scrum Masters em tempo integral. Então, eu fiz minha segunda pergunta: "O que eles fazem?" Eu achei que tinha feito a pergunta de forma que deu a entender que um Scrum Master em tempo integral era estranho pois fui saudado por diversos momentos de um silêncio completo. A maioria das pessoas, com exceção das pessoas que trabalham comigo, me olharam como se eu tivesse três cabeças. Para finalizar o espetáculo, obviamente mau educado de um membro do grupo, ou seja, eu, citei explicações diretamente do Guia do Scrum, a respeito do que um Scrum Master deve fazer. Eu os deixei ainda mais chocados quando lhes disse que tínhamos ido além da necessidade de ter um Scrum Master em tempo integral. E não me incomodei dizendo-lhes que, na verdade, nunca tivemos Scrum Masters em tempo integral.
O Guia Scrum geralmente descreve o papel de um Scrum Master como a de um professor, treinador, facilitador ou uma pessoa que remove impedimentos. E quando uma equipe Scrum é nova, essas coisas levam tempo. Uma equipe Scrum nova tenta seguir o Scrum como está nos livros e precisa de alguém que possa lhes ensinar, treinar, facilitar e remover impedimentos. Mas o que acontece quando as entregas da equipe tornam-se estáveis e maduras? O aprendizado diminui. O ensinamento diminui, embora seja necessário continuar treinando para uma melhora contínua. Facilitar ainda é necessário, mas isso ocupa muito pouco tempo. E os impedimentos diminuem à medida que a equipe aprende a lidar com eles por conta própria. Se o trabalho em tempo integral de um dos membros da equipe é ensinar, treinar, facilitar e remover impedimentos e todas estas coisas diminuem com o passar do tempo, porque então é necessário uma pessoa que executará seu trabalho em apenas 10/25 por cento de seu tempo total? o que esta pessoa faz com o resto do seu tempo?
Em nossa experiência, tomamos o seguinte caminho . Começamos com Scrum, embora eu não diria seguindo rigidamente o livro. Nós viemos de um mundo onde tínhamos gerentes de projetos executando vários projetos, trabalhando desta forma com várias equipes de projeto. Nosso primeiro passo foi treinar nossos gerentes de projeto em Agile. Vários deles fizeram cursos avançados. Alguns transformaram-se mesmo em Scrum Masters certificados e Gerentes de Projetos Ágeis pelo Project Management Institute(PMI-ACP). Assim, nossos gerentes de projetos (PM) tornaram-se nossos primeiros Scrum Masters. Devido as restrições para obtenção de recursos (tínhamos mais equipes do que PM 's) e, possivelmente, devido a um pouco de precaução, não dedicamos imediatamente um Scrum Master para uma única equipe. Sim, isso mesmo, nós violamos uma das regras do Scrum desde o início. De um modo geral, cada PM nosso tinha duas equipes onde ele atuava como Scrum Master. Isso os manteve ocupados, mas não os deixava oprimidos. Seu papel, como é possível imaginar, era ensinar e treinar as equipes em Scrum, facilitar as cerimônias do Scrum, e remover os impedimentos que a equipe identificava. E isso funcionou nos primeiros nove meses durante um ano.
Felizmente, nossas equipes Scrum amadureceram. Com o tempo, tornou-se evidente para nós que nossa configuração inicial de usar os PM como Scrum Master estava começando a se tornar um problema quando, durante conversas com nossos colaboradores, para continuar a receber feedback sobre o processo, perguntei o que melhorou quando os PMs (note que não nos referimos a eles como Scrum Masters da equipe) foram acrescentados ao time. Os integrantes dessas equipes sentiram que estavam sendo sobre gerenciados por várias pessoas. Eles tinham seus próprios gerentes funcionais e tinham também Scrum Masters que não eram realmente parte da equipe.
Com isso, fizemos a primeira mudança na estrutura. A cada equipe, foi permitido que escolhessem seu Scrum Master a partir dos participantes da equipe. Como Scrum Master, eles ainda teriam suas responsabilidades como um membro da equipe em tempo integral, mas também facilitariam as cerimônias do Scrum e seriam o primeiro ponto de contato para os impedimentos da equipe. O que fizemos com os gerentes de projeto? No início, nós os deixamos como gerentes de projetos - fazendo algumas tarefas de gerenciamento de projetos, tais como a coordenação entre as equipes. Mas também os deixamos como capacitadores em Agile. E ter capacitadores em Agile tornou-se algo o qual uma equipe solicitava, não algo que nós impúnhamos a eles. Isso funcionou bem. As equipes que eram mais maduras em sua abordagem Agile e compreensão do processo não se sentiam sobre gerenciadas. Essas equipes além de apresentarem uma boa velocidade em seu processo, ainda podiam contar com alguém que poderia lhes acompanhar e ensinar.
Uma transformação menor ocorreu à medida que continuamos a amadurecer. Nós promovemos os gerentes de projeto para gestores de programas. Com isso, eles tornaram-se responsáveis por iniciativas entre equipes. Ou seja, em projetos que transcendem produtos e possuem tarefas/histórias o qual várias equipes estão envolvidas. Também reorganizamos nossa visão de gerenciamento, onde passamos de gerentes funcionais/supervisores para gerentes de entrega/supervisores, um papel que chamamos de gerente de entrega. E é o gerente de entrega que agora é o responsável pelo treinamento e a mentoria em Agile. Nós ainda estamos trabalhando nos desdobramentos deste modelo, mas as equipes estão entregando bem, por isso parece estar funcionando bem.
Nossa opinião é a de que Scrum Masters iniciam como posições na empresa e evoluem para papéis à medida que nos tornamos mais experientes ao usarmos técnicas Ágeis. Pegamos as responsabilidades de um Scrum Master e separamos a parte de ensinamento/treinamento da parte de facilitação/remoção de impedimentos. Este cenário funcionou bem para nós, permitindo que as equipes se sentissem auto gerenciadas e permitindo-lhes amadurecer em um ritmo sustentável, pois o acompanhamento/ensino tornou-se algo que eles solicitavam ao invés de uma imposição sobre eles. Este cenário também permite que mais integrantes da equipe experimentem o papel, uma vez que muitas equipes mudam seu Scrum Master em períodos de tempo determinados. E assim, descobrimos que qualquer integrante da equipe pode ser um Scrum Master. Temos analistas de negócios, desenvolvedores e testadores experimentando ser um Scrum Master. Também descobrimos que até mesmo o treinamento/ensino ficam dentro das equipes com os Scrum Masters, uma vez que os integrantes das equipes que assumem esse papel são os únicos interessados em aprender os princípios ágeis e transmitir esse aprendizado para suas equipes.
Finalmente, o pano de fundo que torna o nosso gerenciamento feliz é que temos menos pessoas fazendo a mesma quantidade de trabalho. Temos dezesseis equipes de entrega sem a necessidade de Scrum Masters dedicados, que nos salvou da necessidade de ter mais de dezesseis pessoas frente a um orçamento fixo, que realmente nos quebraria pois nos daria a capacidade de ter dezesseis equipes de entrega, em vez de apenas treze equipes porque precisaríamos daquelas pessoas extras para preencher uma posição que no nosso entendimento é apenas um papel.
Minha preocupação e a razão para este artigo, é realmente um aviso para todos que estão iniciando sua jornada Ágil. Se você contratar uma enorme quantidade de Scrum Masters em tempo integral, fato que tem acontecido, pelo menos aqui em St. Louis, você precisa ter um plano de contingência, com o que você vai fazer com eles quando suas equipes amadurecerem. E, pelo menos aqui, a maioria dos Scrum Masters contratados saíram de experiências como gestores de projetos. Nada de errado com isso, mas, novamente, esteja preparado para responder a pergunta: "Ok, agora o que vamos fazer com todos esses gerentes de projetos que usamos para serem Scrum Masters?"
Sobre o Autor
Brian Lawrence atualmente é Diretor de TI da TriZetto Solutions Provider em St. Louis, onde é responsável por várias equipes de desenvolvimento de produtos usando Agile e Kanban, assim como também aplicação de arquiteturas. Ele é um viciado em processos desde os tempos de Edward Yourdan. Durante sua carreira, tem conduzido empresas por várias transformações de metodologia, incluindo o Processo Unificado da Rational, Processo Unificado Essencial e Agile. Ele ama melhoria de processos e busca continuamente formas de desenvolver software melhor, mais rápido e mais barato. Sua paixão atual é buscar formas de gerenciar melhor dentro de um ambiente ágil.