Através deste estou iniciando uma série de artigos que irá avaliar detalhadamente cada um dos três principais papéis do Scrum. O que motivou esta série foi a grande quantidade de questionamentos que recebo em meus treinamentos e consultarias em volta deste assunto: quem deve ser o Product Owner? ScrumMaster é o gerente de projeto? Ele deve ser técnico? Um membro do time pode exercer mais de um papel? Por quem são gerenciados os problemas burocráticos do projeto (custo, penalidades, etc.)? Estas são apenas algumas das mais freqüentes perguntas que tenho recebido e que acredito que habite a cabeça de muitos que estão iniciando (ou não) o trabalho com Scrum. Na série de artigos “...por ele mesmo” não vou citar perguntas e respostas, mas sim situações reais que aconteceram em variados projetos em meus clientes. Por exemplo, no artigo “ScrumMaster por ele mesmo” estarei narrando um conjunto de histórias vivenciadas junto a ScrumMasters de alguns clientes. Obviamente não conseguirei abordar em detalhes tudo que envolve o dia-a-dia de um ScrumMaster, nem mesmo é este o objetivo do artigo, mas pretendo citar situações reais de lições aprendidas por clientes em relação a este importante papel em projetos Scrum.Por motivos óbvios estarei utilizando nomes fictícios tanto para as empresas e verticais quanto para os ScrumMasters. Espero que o conjunto de artigos agrade a comunidade, e esclareça, dentro do alcance de um artigo, as principais dúvidas em volta dos papéis no Scrum.
- Quem é o ScrumMaster?
O papel do ScrumMaster, diferentemente dos gerentes de projeto na maioria das práticas e metodologias, está distante do tradicional “comando e controle”. Em Scrum, um ScrumMaster trabalha com e, principalmente, para o time. É esperado que um ScrumMaster possua as seguintes responsabilidades:
• Permitir que o time seja auto-gerenciável: esta talvez seja uma das mais desafiadoras responsabilidades de um ScrumMaster, pois no mundo de projetos que temos hoje a própria equipe espera que haja dentro do time alguém com o perfil comando-controle para dizer o que cada um tem que fazer e, na seqüência, controlar o desenvolvimento do que foi atribuído a cada membro do time. Em Scrum espera-se que os times sejam auto-gerenciáveis, o que significa que cada membro do time será responsável por decidir o que vai fazer, como e em quanto tempo. Sendo assim a necessidade de termos nos times alguém cobrando status de atividades passa a ser nula, visto que cada membro estará comprometido com aquilo que planeja entregar. O grande problema aqui é que, devido a anos e mais anos de comando-controle, os próprios membros do time – que reclamam tanto deste modelo – se sentem inseguros ao se verem com uma carga de comprometimento que não estão acostumados. Ao sentir esta insegurança o mais comum é que estes membros tentem “empurrar” de volta o comando-controle para o líder do projeto (em nosso caso, o ScrumMaster) e é aqui que está a grande dificuldade pois, neste momento, o ScrumMaster não deve aceitar o comando-controle que o esta sendo oferecido, mas sim orientar cada membro do time a manter-se de forma auto-gerenciada. Um bom ScrumMaster não aceita o controle, por mais tentador que isto possa parecer – principalmente para gerentes acostumados com a forma tradicional de gerenciamento de projetos.
• Garantir que os caminhos para a comunicação do time estejam abertos permanentemente: sem uma comunicação eficiente um time Scrum certamente irá falhar pois ela é uma peça chave em todo o processo de gerenciamento de projetos com Scrum. Por este motivo temos que ter em um time alguém que seja responsável por garantir que a comunicação do time esteja funcionando de forma satisfatória, esse alguém é novamente o ScrumMaster. Neste cenário o ScrumMaster deve garantir que não haja nenhuma barreira de comunicação (seja física, política, hierárquica, etc.) entre os membros do time, entre time e Product Owner (ou especialistas de domínio) e entre Pigs e Chickens.
• Garantir e auxiliar o time a seguir corretamente as práticas do Scrum: o ScrumMaster é o responsável pela boa aplicabilidade das práticas do Scrum no projeto. O time deve enxergá-lo como alguém que conhece bastante de Scrum e que está pronto para corrigir qualquer deslize na utilização de suas práticas e para tirar as dúvidas relativas a Scrum de qualquer pessoa envolvida no projeto.
• Remover qualquer impedimento que o time encontre: durante a execução das Sprints os membros do time estarão envolvidos em mecanismos que farão com que seus problemas apareçam quase que de imediato. Por exemplo, em um reunião diária membros do time serão encorajados a informar se tiveram algum impedimento no dia anterior e, caso positivo, o ScrumMaster é quem deverá se empenhar para remover aquele impedimento, de forma que mantenha o membro do time focado em seu trabalho. O dia-a-dia do ScrumMaster está diretamente ligado à remoção de impedimentos e, por este motivo, ele deve conhecer habilidades que o façam enxergar os impedimentos o quanto antes e removê-los com rapidez.
• Proteger o time de interferências externas para garantir que sua produtividade não seja afetada: o ScrumMaster é um típico líder-servidor e, como tal, uma de suas principais atribuições é manter o time focado na meta da Sprint e na visão do produto. Para isso ele deve garantir que fatores externos não estejam interferindo na produtividade do time, isso inclui o surgimento de impedimentos, que por ele deverão ser removidos, a interferência no trabalho de algum membro do time através de decisões hierárquicas da empresa, que por ele deverão ser negociadas, e o surgimento da multi-tarefa dentro do time devido à solicitações externas ao projeto.
• Facilitar as reuniões do projeto (Planning Meeting, Daily Meeting, Review e Retrospectives): Entenda por facilitação a habilidade de transformar divergência em convergência, a habilidade de fazer com que um tema seja explorado de diversas formas diferentes com o propósito de fazer com que todos os envolvidos na discussão consigam entender o que está sendo explorado da melhor forma possível. As reuniões em Scrum, por serem freqüentes, precisam ser rápidas e eficientes, e é nestas reuniões que o papel de facilitador do ScrumMaster deve ser elevado, pois é neste ponto que ele precisará utilizar todas as suas técnicas e conhecimentos de Scrum e de facilitação para fazer com as reuniões sejam bem sucedidas.
Histórias de ScrumMaster
1. O ScrumMaster conhecedor
A Cosmos Brothers é uma empresa com mais de 15 anos no mercado brasileiro, eles possuem uma rede de postos de gasolina com unidades instaladas na regiões Sul e Sudeste do Brasil.
Paulo Cosmos é sócio e diretor de tecnologia da empresa e, quando assumiu este papel, determinou que a empresa iria trabalhar com softwares caseiros para a gestão do negócio, ou seja, softwares desenvolvidos por sua própria equipe.
Gabrielle Moraes é a atual gerente de projetos da Cosmos, ela gerencia os principais projetos da empresa, que são desenvolvidos por uma equipe composta de 8 (oito) membros, dentre eles: programadores, analistas de requisitos, testers e arquitetos. Gabrielle participou de um treinamento de Scrum há alguns meses e, recentemente, começou a utilizá-lo no gerenciamento de projetos. Durante a reunião de planejamento do último Sprint, Gabrielle se sentiu insegura para exercer este papel, pois ao ser questionada por Frank sobre qual seria a framework Java ideal para a integração do produto deles com o de terceiros, ela não soube responder. Entrave similar ocorreu durante a Sprint, veja abaixo um trecho de uma reunião diária:
“Bom, ontem eu efetivei a criação dos métodos buscarClientesPorUF e buscarClientesPorRegiao. Iniciei a publicação destes métodos em nosso WebService principal, mas passei a ter problemas porque a versão da JRE instalada no servidor não contempla o recurso de parsing que precisei utilizar nos métodos...” - disse Cristiano, desenvolvedor.“...eu já havia mencionado isto na Sprint passada...” - disse Frank, também desenvolvedor do time, “tive um problema similar, conforme mencionei em nossa última Retrospectiva.”“Então, eu até pensei em fazer um upgrade da JRE, mas tive receio desta ação afetar o trabalho dos outros. O que você acha Gabrielle?” - complementou Cristiano.
“Bom gente...é...como vocês sabem eu não sou especialista em Java, mas andei dando uma pesquisada sobre este assunto desde a nossa última Retrospectiva. Me desculpem, mas eu estou fazendo o melhor que posso para tentar encontrar a melhor solução para o caso.” - disse Gabrielle, a ScrumMaster do time.
Frank expôs seu ponto de vista - “...ok, mas acho que o quanto antes tivermos isto melhor pois este é um impedimento que realmente nos está atrapalhando. Gabrielle, outra pergunta, devemos discutir estes assuntos técnicos aqui na reunião diária ou deixamos para citar estes problemas na retrospectiva?”
“Bom, acho que não tem problema em falar aqui não...inclusive se alguém tiver alguma sugestão para me dar quanto à resolução do impedimento da JRE, eu ficaria grata. “ -disse Gabrielle.
Paulo Cosmos, Sócio-Diretor da empresa, estava participando da reunião e deu sua contribuição, “Gabrielle” - disse ele, “eu acho que você deveria se reunir com alguns desenvolvedores mais experientes para que lhe ajudem neste caso. Se necessário contratar algum serviço de suporte técnico ou consultoria.”
“Ótimo, é uma excelente idéia!...bom, Cecília, agora é sua vez de responder às 3 perguntas...mas pessoal, nossos 15 minutos já passaram, então solicito a todos que respondam às perguntas o mais rápido possível” disse Gabrielle.
Ao ser procurado por Gabrielle, ela me narrou o fato ocorrido naquela reunião diária e falou sobre sua apreensão por não conhecer Java. Falou também que como o papel do ScrumMaster ficava bem mais próximo do time do que um tradicional Gerente de Projetos, ela via agora claramente que só conseguiria exercer bem este papel se conhecesse profundamente assuntos técnicos.“Muito bom Gabrielle” eu disse, “conhecimento nunca é demais, e conhecer mais sobre a plataforma de desenvolvimento que seu time está utilizando será muito bom para você e para eles.”.“Pois é Alexandre, quando ocorreu este fato eu lembrei de certa vez quando você me disse que um ScrumMaster deve ser um conhecedor!” - complementou Gabrielle.“É verdade Gabrielle, eu disse isso. Mas veja, quando eu digo que um ScrumMaster deve ser conhecedor isto não significa necessariamente ser um grande conhecedor da plataforma ou linguagem de desenvolvimento que seu time utiliza.” eu disse.Gabrielle espantou-se com minha colocação e perguntou “Não?? Então conhecedor em que?”Eu respondi com outra pergunta “Gabrielle, me responda: quais são as principais atribuições de um ScrumMaster?”. “Remover impedimentos, facilitar as reuniões, garantir o uso de Scrum...dentre outras, certo?” disse ela.“Correto...então vamos lá, como você pode ser uma grande conhecedora na remoção de impedimentos?” enviei mais uma pergunta como resposta. “Bom, depende...mas no caso que estamos falando, conhecer Java me ajudaria a remover o impedimento mais rapidamente” rebateu Gabrielle.“Hmmm...vamos a uma metáfora Gabrielle, imagine que você está viajando de carro com sua família, seu marido está ao volante, é noite e chove bastante... no caminho vocês encontram uma árvore caída no meio da estrada que impede a passagem de vocês. O que seria melhor neste momento: o seu marido ter lido um livro for Dummies de como remover árvores de uma estrada com as próprias mãos ou você ter garantido levar consigo todos os números de emergência, tal como o da empresa responsável pelo socorro na estrada? Qual seria o mecanismo mais seguro para fazer com que sua família seguisse em frente?” - disse eu.Gabrielle respondeu pensativa “É...neste caso não necessariamente saber remover uma árvore do caminho com as próprias mãos seria a melhor solução para remover o impedimento".“Exatamente Gabrielle...” - eu disse, “ser conhecedor na remoção de impedimentos não significa saber fazer tudo, mas sim saber direcionar o melhor caminho para a resolução do problema. Seus filhos estavam no carro, com frio e fome, enquanto isto seu marido lutava com a árvore teimando em tirá-la do caminho com as próprias mãos, você pegou o celular e ligou para o socorro que em 20 minutos estava lá resolvendo o problema. Em quem você acha que seus filhos mais confiarão na próxima vez que estiverem em apuros? Em você ou no seu marido?”.Gabrielle entendeu a mensagem, e percebeu que ao tentar resolver o problema da JRE do servidor com as próprias mãos ela não só estava atrasando a resolução de um impedimento – e conseqüentemente atrapalhando o time – como também se mostrando como uma péssima removedora de impedimentos, o que, talvez, num futuro faria com que algum membro do time omitisse a existência de algum impedimento só para não ter que vê-la novamente “lutando com a árvore”.Eu disse “Gabrielle, você deve ter o conhecimento para escolher o melhor caminho na hora de remover um impedimento, isto sim é ser um ScrumMaster conhecedor! No entanto não é só isso. Voltemos ao assunto da reunião diária que você citou, nela você não se mostrou muito boa na facilitação da reunião”. “Como assim?”, espantou-se Gabrielle.“Ficou claro para mim que você não se colocou na postura de um bom facilitador” - eu disse “Por exemplo, um assunto técnico citado pelo Cristiano tomou conta da reunião, além disso, ao se ver apressada você sugeriu que todos respondessem suas perguntas o mais rápido possível – o que diminui a qualidade nas resposta – e nem sequer permitiu que o Cristiano finalizasse seu raciocínio!”.“É, agora percebo que o meu desespero em providenciar uma solução técnica para algo que já atrapalhava o time desde a Sprint anterior me fez perder o rumo da reunião” disse Gabrielle.“Não só isso Gabrielle. Por não ter facilitado bem a reunião você acabou comprometendo o bom uso do Scrum e, como você mesmo citou, garantir o uso do Scrum é uma das principais atribuições do ScrumMaster. Além de permitir que um assunto técnico invadisse a reunião, você permitiu que um chicken interferisse no andamento da mesma” - eu disse.“Puxa, estou me sentido péssima...acho que realmente não sou uma boa ScrumMaster” - lamentou Gabrielle.“Não é isso, você apenas estava investindo sua atenção para o conhecimento errado (pelo menos para o momento). Para ser uma boa ScrumMaster você deve primeiramente ser conhecedora da arte de remover impedimentos, ser conhecedora em técnicas de facilitação e comunicação, ser conhecedora da cultura da empresa e, tão importante quanto, ser conhecedora de Scrum para saber exatamente o que fazer em cada prática e para enxergar as armadilhas o quanto antes. Ser conhecedora na plataforma de desenvolvimento de seu time será um ótimo plus, mas sem dúvida nenhuma os pontos citados inicialmente são os mais importantes para um ScrumMaster” - conclui.
2. O ScrumMaster facilitador
Élder era ScrumMaster da Essential Systems, uma empresa que fabricava um ERP voltado para a vertical de móveis modulados. Ele havia sido meu aluno em uma turma de Scrum e depois havia me chamado para realizar um coaching de 60 dias na Essential, e agora, 12 meses depois, entrou em contato para me convidar a participar de uma reunião de planejamento do mais importante projeto que ele estava envolvido atualmente. Aceitei o convite de pronto e, como um chicken, fiquei quieto em um canto apenas acompanhando o desenrolar da reunião.Élder tinha sido um excelente aluno e agora estava claro para mim que ele realmente havia se tornado um grande ScrumMaster. Minha primeira surpresa foi ao constatar que a equipe era muito focada durante as reuniões, a tal “bolinha” para pedir a vez de falar já havia sido apresentada por Élder pelo jeito há muito tempo, pois todos respeitavam a vez de cada um falar e faziam isso de uma forma extremamente natural.Num momento seguinte, ainda na reunião, Élder interrompeu a apresentação do Product Owner, que estava sendo feita em volta de uma das Features mais complexas do Product Backlog. Ele informou ao time que aquela interrupção estava sendo feita porque ele acreditava que o foco da conversa estava tendo desvios e que o assunto “Impressão de Boleto”, mesmo sendo deveras importante, não estava diretamente ligado àquela Feature. Élder então sugeriu que este tópico fosse colocado em uma área denominada Rat Hole que ele havia criado no quadro-branco, esta área iria conter assuntos importantes a serem discutidos, mas que não estavam diretamente ligados àquela reunião de planejamento. Ao fazer isto ele trouxe a conversa novamente para o foco, mas sem causar o mal que seria gerado caso ele sugerisse abandonar aquele assunto por ser “menos importante”. Uma boa técnica de facilitação.Na segunda parte da reunião de planejamento o time solicitou a presença de algum especialista de domínio que pudesse explicar-lhes em mais detalhes como deveria ser a página na qual os usuários conseguiriam visualizar toda a movimentação financeira de um ano para um cliente especificado, pois muito já havia sido discutido com muitas “idas-e-vindas” na conversa. Carla, a especialista de negócio, falou durante 20 minutos sobre aquela funcionalidade e pareceu colocar mais interrogações na cabeça do time, que descordou em grande parte do que Carla havia explanado. Élder pediu a palavra e solicitou que Carla e um ou dois membros do time se aproximassem de um grande quadro branco que ficava ao fundo da sala. Reunindo todos lá ele pediu para que tentassem em conjunto desenhar a tal página no quadro branco, de forma com que todos os outros envolvidos na reunião pudessem participar. Cada um desenhava um pouco, apagava um pouco e em poucos minutos conseguiram chegar a um consenso, tendo agora em mãos (ou melhor no quadro) uma tela que havia sido desenhada por todos. Um conjunto de fotos, tiradas através de uma máquina digital, documentou o trabalho. Transformar divergência em convergência, esse é o objetivo da facilitação.No fim da reunião Élder me chamou para tomarmos um capuccino na área de convivência da empresa e lá chegando ele foi direto ao ponto “Alexandre, que tal, o que achou?”.“Élder, foi muito bom!” - eu disse, “Você utilizou simples – mas poderosas - técnicas de facilitação e, o mais importante, demonstrou entender perfeitamente qual é o papel do ScrumMaster dentro desta reunião. Além disso o time se mostrou educado e focado, o que com certeza deve ser mérito de sua postura nas reuniões ao longo desses últimos meses. Eles lhe enxergam como um facilitador, como alguém que vai ajudá-los e, por isso, permitem e enxergam sempre com bons olhos a sua entrada no meio de alguma discussão.”“É verdade Alexandre” - disse ele, “eu percebi que com o tempo e com os resultados que eu ajudava a gerar durante as reuniões, eles passaram a enxergar minha entrada nas conversas como uma saída para a discussão. Certas vezes percebo inclusive que eles param e ficam olhando para mim, como dizendo: por favor, nos salve desse debate.” Élder continuou, “Mas e agora, como aprender mais sobre facilitação? Já li todos os livros sobre este tema e, mesmo sabendo que a boa facilitação parte de ações simples, percebo que preciso aprender mais.”.“Veja, facilitação, na minha opinião, é uma expansão da habilidade de comunicar. Você só consegue ser um bom facilitador se for um bom comunicador. A facilitação é a arte de tornar mais eficiente a comunicação entre grupos maiores, e quem foi um dos maiores comunicadores de toda a nossa história se não Sócrates? Grande parte das técnicas de facilitação que utilizo hoje em reuniões e retrospectivas foram aprendidas através das lições por ele nos ensinada. Facilitação é uma daquelas habilidades do ScrumMaster que mais está ligada ao lado humano do que ao lado técnico da pessoa .”, conclui.
3. O ScrumMaster líder
João Pedro era Gerente de Projetos de uma das principais empresas de aviação do país quando nos conhecemos a 2 anos atrás. Naquela época eu havia sido contratado como consultor para ajudar a agilizar os processos da empresa, e um dos passos a serem dados envolvia a adoção de Scrum no gerenciamento de projetos. Durante o treinamento que ministrei para todos os gerentes de projetos de lá, João havia se mostrado bastante resistente à idéia do ScrumMaster não possuir poder sobre o time. Lembro dele ter me questionado bastante sobre como ser responsável por algo que não se pode comandar e controlar. Foi bom encontrá-lo novamente em uma conferência sobre gestão de projetos e poder convidá-lo para um almoço.“Então João, pelo que conversei com o Borges (diretor da empresa) recentemente, parece que Scrum realmente se institucionalizou na empresa. O que você pode me falar sobre isso?” - eu disse.“Como você sabe muito bem tivemos um trabalho muito duro no início. Mas a boa execução daquele desafiador projeto piloto que você esteve envolvido conseguiu motivar o restante da empresa, tivemos quer criar um Backlog de Projetos – uma espécie de portfólio – para conseguir definir a prioridade de cada e conseguir atender a todos.”, - disse João.Resolvi expandir a conversa, “Muito bom, me fale um pouco sobre as lições aprendidas, sobre o que aprendeu com o projeto piloto e que conseguiu melhorar nos projeto seguintes?”“Alexandre, o ponto principal que posso citar foi a questão da postura, percebi a grande diferença entre ser líder e ser gerente. Antigamente, como um gerente de projetos, eu me portava de uma forma que fazia com que os membros do time me enxergassem do lado de fora do círculo. Percebi que eles só passaram a me enxergar como alguém que estava junto com eles dentro do círculo a partir do momento em que mudei minha postura nas pequenas coisas do dia-a-dia.” - disse João.“Você pode me citar um exemplo de algum fato que tenha deixado isso claro pra você?” - eu disse.“Olha, certa vez quando estávamos realizando uma reunião de planejamento, eu estava bastante preocupado para que a reunião fosse executada de forma otimizada, então a conduzi de forma a fazer com que o time estimasse e planejasse tudo o mais rápido possível. A conseqüência disso foi que durante a Sprint o planejamento se mostrou desastroso, e eu tive que sugerir o cancelamento da Sprint. Marquei uma reunião com todos – incluindo Product Owner – e expus a situação, falei que o planejamento havia sido fraco e que eu me sentia responsável por isso, por justamente ter forçado o time a acelerar o processo. Eu mesmo me surpreendi com essa minha atitude, pois em outros tempo eu, sinceramente, buscaria um culpado. Para o Product Owner eu diria que o time era inexperiente e se precipitou, para o time diria que o Product Owner não entendia bem do negócio. Faria isso principalmente para que o time não enxergasse minha falha, afinal nada pode ser pior do que ver um gerente seu falhando, certo? Engano meu! Veja que impressionante. Com essa atitude o efeito foi inverso ao que eu imaginava. O time se colocou ao meu lado, dividiu a responsabilidade do erro, e a partir daí poucas foram as vezes em que vimos alguém no time criando desculpas para algum problema ou tentando colocar a culpa em alguém. Vi que aquela minha atitude serviu de exemplo para eles, e a partir daquele momento passei a me sentir um líder de verdade.”, - finalizou João.“Muito interessante esta experiência João. É esse exatamente o papel do líder, deixar visível que você é igual a todos, tem fraquezas, comete falhas, e por aí vai, mas que está ali para ajudá-los a fazer um trabalho melhor. Não adianta falar de time, tem que sempre apresentar a prova. Se fala que não há indivíduos e sim um time, tem que mostrar como é que se faz isso, porque todos já estão cansados de discursos. Um bom líder tem que produzir energia diariamente, tem que fazer com que todos se sintam realizando o trabalho mais importante do mundo, tem que inspirar a audácia.” - conclui.
4. O ScrumMaster influente
Mário Wernner é gerente de sistemas do Duff Bank. Ele me procurou a alguns meses para atuar como consultor em um projeto de alto-risco que estava a ser iniciado utilizando Scrum. ScrumMaster deste time. Eu o informei que não achava que esta formação fosse a ideal, citei o fato de eu não conhecer a cultura do banco e de não possuir influência em volta de todos os ambientes que iriam estar envolvidos com o projeto. Sugeri a minha participação como coach.“Mas Alexandre,” disse Mário, “Scrum é algo completamente novo para nós, não vejo ninguém do nosso time que possa exercer este papel. Sem contar que acho completamente arriscado colocar um projeto nas mãos de alguém que ainda não liderou nenhum projeto com Scrum.”“Mário, justamente por este motivo que estou sugerindo que eu atue como coach, para ajudar o ScrumMaster a seguir pelo caminho correto, ajudá-lo a fazer os desvios necessários e a não cair em nenhuma das armadilhas que surgirão. No entanto, pense no ScrumMaster como alguém que terá que remover os impedimentos do time, esses impedimentos estão espalhados por toda a empresa e seus departamentos, e muitas vezes até fora dela. Agora imagine que um desenvolvedor do time que estarei fazendo parte me fale sobre um impedimento que precisa ser resolvido, é um impedimento burocrático que envolve pessoas de outros departamentos. Quem devo procurar? Como devo fazer a solicitação? Mas tudo bem, com algum pouco de comunicação eu consigo pular estas questões e fazer a solicitação à pessoa certa. Esta pessoa não me conhece, o Duff é enorme eu sou novo aqui...será que eu terei a influência necessária para remover este impedimento da melhor forma possível?”, eu disse.“Entendo sua colocação, mas ninguém nasce sabendo não é verdade? Acho que você conseguiria aprender como as coisas funcionam aqui num espaço de tempo razoável. Eu poderia colocar ao seu lado algumas pessoas influentes que poderiam lhe auxiliar...” - disse Mário.“Certo, realmente poderia funcionar.” eu disse, “Mas veja, o que você está me propondo é exatamente o mesmo que eu. A diferença é que eu estou lhe propondo guiar um ScrumMaster seu, e você está propondo colocar algumas pessoas que conhecem a cultura da empresa e tenham influência aqui para me guiar. O que será que é mais complexo: Scrum ou a cultura da sua empresa?” perguntei.“Hmmm...olhando por essa ótica vejo que você tem razão, é mais fácil eu colocar alguém para ajudar um ScrumMaster do meu time com Scrum do que tentar tornar alguém influente aqui dentro.”“Exato, além do que eu como consultor sairei da sua empresa ao final do projeto, e você voltará a ter o mesmo problema de antes. E lembre-se, para ser influente não basta ter um alto cargo impresso em seu cartão de visitas, mas sim ter um conhecimento verdadeiro da cultura da empresa e ser bem visto dentro dela”, conclui.
Palavras finais
Mike Cohn, autor de importantes livros sobre abordagens e práticas ágeis, citou em seu artigo “Leader of the band: Six Attributes of a Good ScrumMaster” que as principais qualidades esperadas em um ScrumMaster são: responsabilidade, colaboração, humildade, comprometimento, influência e conhecimento. Note que grande parte destas qualidades está ligada diretamente ao lado humano, e não técnico, de um profissional. Isto vai de encontro com o que foi bastante discutido quando da reunião que originou o manifesto ágil, ou seja, precisamos mais de uma mudança de atitude e comportamento em nossos projetos do que de novos processos e ferramentas, e para esta mudança comportamental – a qual está diretamente ligada com as responsabilidades do ScrumMaster – precisamos mais de alguém com habilidades humanas do que técnicas. É óbvio que é muito interessante quando o ScrumMaster possui um conhecimento técnico suficiente para conversar na mesma linguagem com o time, isto é ótimo pois facilita a comunicação e faz com que o ScrumMaster consiga mais rapidamente ajudar o time, mas de longe suas habilidades humanas, necessárias para conduzir o time à mudança comportamental desejada, são mais importantes.
