Szuster: Bom, dia, boa tarde, boa noite. Bem-vindos a mais um episódio dos Agilistas. Antes de apresentar os convidados, nós vamos ouvir uma mensagem aqui de um ouvinte. Acho que todos devem estar sabendo, a gente, agora criou um canal no WhatsApp, o canal dos agilistas é 31 996977104. 996977104, e tem o e-mail também osagilistas@dtidigital.com.br. [00:00:30]Túlia: Olá, meu nome é Túlia. Eu vou mandando esse áudio para poder agradecer e parabenizar o trabalho de vocês aí na Podosfera. Eu sou apaixonada por podcast. Só que eu sempre seleciono podcasts de qualidade e vocês entraram na minha lista predileta. Eu estou apaixonada pelo trabalho de vocês. Parabéns pela seriedade, pelo conteúdo, pelo formato e pela forma com que vocês estão trabalhando. Eu trabalho na área de agronegócios, é um mundo à parte, diferente da parte de T I, mas todos os conceitos, tudo o que vocês abordam é extremamente aplicável ao meu negócio. Como eu viajo muito, eu sempre coloco o podcast no carro e fico ouvindo durante as minhas viagens. E a diferença agora, que, além de escutar, agora eu já arrumei um caderninho, uma caneta e, faço notas, eu paro, faço notas, do que eu escuto, dos aprendizados, para eu não esquecer algum termo, algum livro que vocês indicam, eu já anoto para poder ver depois. Então, vocês, além do conteúdo que é leve, é gostoso, vocês passam bastante informação que dá para a gente fazer um momento após o podcast, de aprendizado, de aprofundamento. Parabéns por contribuir com esses temas, com esses assuntos tão bacanas, muito bom mesmo, parabéns. [00:02:11]Szuster: Estamos aqui com o Régis, que não sai mais do podcast. [00:02:20]Régis: Apeguei. Apego muito fácil. [00:02:22]Szuster: Então, hoje nós estamos aqui com dois gerentes de projetos da DTI, que atuam como scrum master, o Pierre, tudo bom, Pierre? [00:02:27]Pierre: Tudo bem? Bom dia, boa tarde, boa noite. [00:02:30]Szuster: E com a Ângela também, que já participou de outros episódios. [00:02:33]Ângela: Oi pessoal. [00:02:34]Szuster: Então gente, o objetivo desse episódio aqui é o seguinte. A gente tenta aqui na DTI sempre ter uma posição bastante pragmática sobre como fazer as coisas. A empresa é uma empresa que, eu diria que a gente tem uma cultura muito boa de sermos estudiosos aqui, mas, acima de tudo, somos bem pragmáticos, a gente gosta de aplicar as coisas, fazer as coisas acontecerem. Então, esse episódio seria para a gente pegar e falar na prática, de forma bem pragmática, dando exemplos, contando histórias, o que o scrum master faz no dia-a-dia. Não é nem uma prescrição, mas baseado na experiência de cada um, como o papel acaba se traduzindo, de fato, além do curso teórico ou do que a certificação diz. O que alguém procura no scrum master, o que o scrum master faz, como é o perfil dele, o tipo de decisão final que ele toma, coisas desse tipo. Então vamos lançar a pergunta para o Régis. Régis, afinal, o que o scrum master faz? [00:03:31]Régis: Na verdade, eu acho que, mesmo que a gente não vai ficar preso ao conceito do framework scrum, eu acho importante começar por ela, a partir dela, talvez a maioria do pessoal conheça, e para quem não conhece, conhecer e depois a gente partir como isso vira na prática. O Scrum, não vou saber falar quantos anos para cá, mas eles, propositalmente foram ficando mais generalistas no framework deles, Cada vez menos prescritivos e um pouco mais generalistas. Isso, inclusive, para poder abarcar outras áreas de atuação, não só a parte do software. [00:04:08]Szuster: Que nasceu no software. [00:04:08]Régis: Que nasceu no software, mas tem incontáveis exemplos que não se restringem ao software. Então, eu acredito que o papel do scrum master até um pouco por isso também, acaba, isso é uma opinião minha, ele ficou generalista também. Seria mais descrito como: ele é um líder do time, ele tem um papel de liderança, até o nome master é um pouco questionado por causa disso, porque não é exatamente o tipo de liderança que está embutida no papel. Ele teria o papel dentro do time, de ser aquele líder servidor que remove os impedimentos e que fica sendo o guardião do método ali. É quem garante, entre aspas. [00:04:49]Szuster: Mas esse master é no sentido de ter (inint) [00:04:51]Régis: Isso, exatamente. Quem questiona é mais um ranço com a palavra mesmo, do que esteja tecnicamente errado. Então, ele tem esse objetivo, esse papel de tirar os impedimentos, de ser o guardião da metodologia, então quem poderia puxar os ritos, que estão previstos no framework. E não lembro se tem mais alguma coisa na (prescrição) [00:05:18]. Já tem um tempo que eu li, mas se eu não me engano era isso, basicamente dava para descrever o papel nessas linhas gerais aí. Então como isso fica muito (geral) [00:05:25], alto nível mesmo, acaba que, na prática, isso aí acaba dando espaço para adaptações, eu entendo que é de certa forma proposital, que o framework dita isso, para adaptações de realidades, no nosso caso aqui na DTI, até de cliente a cliente que isso vai ter alguma diferença. Mas acho que começar aí dessa referência, então desse papel de líder servidor, que retira os impedimentos, que é um guardião mais do método; importante dizer que o time não reporta a ele. Por exemplo: ele puxa uma reunião diária lá, o time que está na reunião não fala para ele, o pessoal reporta para o próprio time, o time tem a prioridade das decisões, enfim. Acho que, partindo disso aí dá para a gente pensar o que tem de mais particular nas situações que a gente tem aqui na DTI, que eu acho que é o grande valor dessa conversa, trazer como que isso na prática, um papel tão geral assim é instanciado em diferentes clientes. [00:06:23]Szuster: Então, e você Ângela, como você instancia esse papel? Pergunta direta essa. [00:06:30]Ângela: Assim, na verdade, acho que vai, o papel que a gente acaba assumindo na prática, ele varia muito com o momento do projeto, com a maturidade do time, então o que o Regis falou aí, o time não reporta para a gente, na verdade, ele funciona mais como um facilitador de ajudar que os ritos aconteçam, de instigar, de questionar o time ali, para tentar fazer com que o pessoal performe melhor, com que os objetivos da sprint, no caso do scrum, que sejam atingidos, não como um gerente de projetos, que às vezes, que muitas vezes a gente faz esse paralelo do gerente de projetos que se torna scrum master, então muda um pouco a forma como essa liderança enxergue dentro do scrum. [00:07:19]Szuster: Entendi, então, uma palavra-chave é essa, não é um chefe da equipe e não manda na equipe. Tem algum comentário adicional, Pierre, sobre a sua realidade? [00:07:29]Pierre: A Ângela comentou do paralelo entre o gerente de projeto e o scrum master, na minha opinião, a grande diferença entre o papel do gerente de projeto com o scrum master é o modus operandi, o que eu digo com isso: o gerente de projeto, ele tem incumbido ali em suas responsabilidades a questão muito forte de comando e controle de direcionamento para a visão dele, o scrum master está muito mais para habilitar o time para que tome as decisões corretas; e como o Régis disse, a questão de retirar impedimentos mesmo em qualquer âmbito que seja. Então, é até meio complicado, às vezes perguntam: “mas que tipo de impedimento?”. Vai depender do contexto de cada time. Isso varia de time para time, de cliente para cliente, de projeto para projeto, é bem generalista mesmo. [00:08:12]Szuster: E é engraçado, porque o nome de gerente está inevitavelmente essa carga de ser o chefe. Por mais que alguns gerentes de projeto possam se definir como não sendo isso, gerente sempre é gerente. [00:08:22]Pierre: Então (falei) [00:08:23], por isso que o pessoal está implicando com o master que eu falei. [00:08:26]Szuster: Que seria a mesma conotação. [00:08:29]Pierre: A palavra tem uma carga, pode trazer uma carga diferente. Mas o que eu estava mencionando sobre a realidade de cada cliente, é justamente isso. O cara tinha impedimentos mas, no cliente A, impedimento pode ser um monte de coisas, pode ser uma T I que não está envolvida propriamente, pode ser um patrocinador que precisa de alguém que tenha um poder de uma decisão que não está propriamente no loop, você tem que correr atrás disso. A ideia é deixar, não é ser a babá do time, que tem muito isso também: “mas eu estou protegendo o time, habilitando o time, mas o time também, como é que o time vai criar resiliência, anti fragilidade, todas aquelas coisas que a gente quer que o time crie. Então não é exatamente de ser uma redoma ali não, mas a ideia é que, dado que a gente tenha um time ágil, a gente quer que esse time gere valor o tempo todo, e eu acho que eu falei isso no naquele episódio do gerente, quando a gente discutiu um pouco o papel do gerente de projetos. Ele é (overhead) [00:09:23] por natureza, o gerente. Qualquer gestão que está ali, se ela não se traduz em valor de negócio diretamente, dificilmente ela vai se traduzir, dado que ela não está diretamente na confecção do produto, então tem que ser uma atuação extremamente focada em que o time esteja gerando valor. O que eu quiz dizer de não criar redoma, essas coisas, é que a gente quer que o time tenha um foco e que o time não seja distraído por coisas que não são necessariamente, diretamente ligadas à geração de valor. Então esses exemplos que eu dei: “eu preciso envolver uma pessoa que não está envolvida na discussão, eu preciso garantir que um rito aqui e o time está deixando um pouco de lado, por causa da pressão do momento”, então precisa ter uma pessoa ali que não tenha uma história para desenvolver, que fale assim: “gente, olha, mesmo que nós estamos apertados, precisamos fazer uma retrospectiva aqui para a gente poder se olhar”. E em cada cliente isso vai ganhar uma forma diferente. Em alguns clientes vai ser, talvez garantir uma documentação que o próprio scrum master tem condição de fazer para o time poder focar na entrega das histórias e isso não está prescrito lá no manual, isso não está dizendo: “o scrum master é quem fica responsável por fazer, por enviar os relatórios de medição para gerar os faturamentos do time”, isso não vai estar lá. Em cada cliente, essa situação vai puxar esses outros papéis, essas outras tarefas que o scrum master tem que fazer. Não necessariamente tem que ser o scrum master também esses exemplos que eu dei, são exemplos porque aqui na DTI geralmente fica isso, a gente coloca na parte da documentação, na parte do faturamento, algumas coisas que ajudam o time a focar na geração de valor. [00:10:54]Szuster: Isso que você falou é curioso, e realmente mostra que depende de cada cliente, porque tem clientes que têm uma estrutura um pouco mais tradicional. Só voltando um pouco, tem uma coisa que é muito engraçada, com meus anos de convívio com a agilidade, desde os anos 2 mil, eu acho interessante, porque eu acho que tem, apesar de eu adorar o movimento, eu acho que tem uma certa ingenuidade no manifesto, sabe? O que eu quero dizer com isso? Realmente working software, colaboration, mas parece que tudo vai acontecer, que não existe uma estrutura ali, muitas vezes, política. [00:11:25]Pierre: Puxando contra. [00:11:26]Szuster: Puxando, sabe, e que certas decisões têm que ser mais bem documentadas e que certas coisas têm que ser repetidas mil vezes e que alguém, às vezes, tem que cobrar um troço mil vezes senão não acontece, vocês concordam? Fica parecendo que se o time estiver trabalhando super bem e colaborando e etc, isso é como se você estivesse em flow o tempo todo e que se não tivesse que ter alguém que faz o flow acontecer, para mim o scrum master fica fazendo dentro e fora, a gente falou muito do time, ou seja, a coisa vai ter obstáculos, vai parando o flow. [00:11:59]Ângela: E assim, acho que um dos pilares que a gente tem é a questão da transparência, então acho que o scrum master ele também vai ajudar nesse sentido, de dar a transparência, principalmente, igual você falou, algumas organizações que às vezes são mais burocráticas, que não estão tão adaptadas ao método, existe uma resistência, às vezes, existe uma necessidade às vezes, de ter um monitoramento maior em algum momento e aí eu acho que ele também ajuda dando a transparência para ganhar a confiança do cliente na metodologia e no time e aí conseguir ganhando mais espaço para isso. [00:12:33]Pierre: E tem um ponto também que além do escopo de cliente, do squad, a atuação vai muito da maturidade também do time, o tipo de impedimento, o tipo de trabalho, o tipo de execução que você vai precisar fazer depende bastante do momento de maturidade de cada time, assim, vai ter time que está no nível de maturidade baixo, você vai ter que ter atuações ali mais, vai ter que acompanhar mais de perto, você vai ter que explicar o valor de cada coisa, para que o time entenda aquilo ali e vire (cor) [00:13:04] do time. Porque a partir daí, uma vez que isso entrou no sentimento do time e entenderam todo o valor dos ritos por exemplo, você passa a atuar num outro nível de impedimento, com outros tipos de impedimentos que aí entra, o que o Régis já falou, o que o Szuster já falou que fazer o flow acontecer muitas vezes pode ser aquele cara chato que fica cobrando uma coisa de um outro determinado setor que não está totalmente alinhado com o squad, mas sem aquilo o trabalho de squad não vai ser dado o valor necessário a ele, então não vai ser entregue o valor, então depende bastante do nível de maturidade do time também. [00:13:40]Régis: Talvez um pouco paradoxalmente só uma certificação de scrum master, na minha cabeça, ela não prepara um profissional para ser scrum master, por isso que eu acho que é meio paradoxal. Teoricamente o cara pegou as horas de curso lá, aprendeu o framework, entendeu o papel dele, mas para fazer isso na prática exige uma dose de soft skills talvez e de experiência que eu acho que curso nenhum dá. Até na DTI a gente tem uma outra abordagem inclusive para os cursos aí que a gente costuma trazer isso um pouco mais forte assim, mas experiencia de mercado para tirar esses impedimentos, para fazer negociações, para você conseguir enxergar esse tipo de situação no time, igual o Pierre falou, enxergar que existe uma imaturidade ainda, que precisa ainda de uma mão ali guiando ainda mais forte em algum momento e soltar um pouco mais depois, isso não vem com curso nenhum, é meio um paradoxo. [00:14:33]Szuster: E você sabe o que é curioso quando você fala disso, eu já passei por situações. Tem clientes que entendem perfeitamente isso aí, e ok e tem clientes que questionam o papel. Eu queria fazer um momento do desabafo aqui. É um momento do desabafo para vocês, scrum masters porque o que eu acho curioso é o seguinte. olha como sutil pode ser tua ação e, às vezes, muito invisível, tipo assim, tem alguém que está percebendo que a equipe está com o moral baixo e de alguma forma, atuando para fazer aquilo e aquilo, no final das contas é que pode estar garantindo a geração de valor. E alguém que está mais longe, ali do lado do cliente, ele pode preferir desde pensar num modelo meio mecanicista que isso nem acontece do moral ficar baixo, ou que se acontece, não interessa, o cara tem que entregar aí pronto, ou não reconhecer que o scrum master é quem faz isso, ou achar que isso de alguma mágica, que a empresa deveria não deixar isso acontecer, entendeu? Mas eu falo isso porque eu já vi várias situações, por isso que eu fico brincando que é um momento de desabafo, tem uma característica meio igual a de juiz de futebol, sabe, no scrum master que é assim: quando está tudo dando certo, aí você não aparece muito, aí alguém começa: “mas eu preciso muito daquele scrum master ali”, porque está tudo dando certo ali. [00:15:56]Régis: O juiz de futebol é bom quando ele não aparece. Passa o jogo. [00:15:59]Szuster: O juiz de futebol, quanto melhor ele atua, acabou o jogo e ninguém percebeu ele, mas ninguém fala do santo juiz. [00:16:05]Pierre: Tem uma brincadeira que tem aí usando uma palavra bonita que o Régis falou meio paradoxal, é que o papel do scrum master é que o time precise quantas vezes menos dele. Então quanto menos eu precise do meu scrum master, a maturidade do time está evoluindo, o processo está fluindo, o flow está acontecendo. Então, é mais ou menos igual ao juiz mesmo, se você não está vendo o trabalho dele ali, teoricamente ele está fazendo um bom trabalho. É meio que tem isso mesmo. [00:16:30]Szuster: É, nesse mundo dinâmico em que a gente vive, não adianta. Como que é hoje o mundo. Você tem mudança o tempo todo, você tem mudança de equipe, por mais estável que você queira deixar uma equipe, você tem mudança de equipe porque as pessoas querem mudar de desafios, então é assim, você tem muita turbulência sabe, para chegar em um ponto em que o time esteja totalmente estabilizado, tão maduro que, ainda mais em uma empresa que está prestando um serviço, porque, às vezes uma empresa de produto, ela consegue estabilizar e manter um time ali muito tempo. A gente sabe que igual na realidade nossa, as pessoas tem que ter experiencias diferentes, então eu quero dizer o seguinte: então essa estabilidade que poderia fazer com que se prescindisse do scrum master internamente, porque externamente já tem o lado de lidar com cliente, essa estabilidade não vem tanto [00:17:18]Regis: O scrum master, no fundo é engraçado, igual vocês falaram, num time maduro, teoricamente não precisaria tanto, mas eu acho que de qualquer maneira, por questão de alocação de tempo mesmo, a gente quer manter o time focado ali nas atividades de geração de valor e é meio inevitável que vai ter distrações que vai ter forças externas ali puxando o squad para outa direção, que eu acho que de qualquer maneira vai ser útil ter alguém ali para enxergar, para ler essa situação. E ele é um papel também que eu entendo que ajuda o time até a, talvez eu esteja falando de times menos maduros. Assim, um advogado do time em algumas discussões assim quando ele tem que defender o método. E quando eu falo o método, não estou defendendo necessariamente scum, estou usando a palavra. [00:18:07]Szuster: Princípios. [00:18:08]Regis: Os princípios e os valores. Cara, por que a gente precisa tanto de uma retrospectiva? Porque às vezes o cliente não vai querer fazer, ele vai querer que a gente já parta para especificar os próximos requisitos e pronto. Mas tem que entender que o modelo de trabalho. A gente está deixando de fazer uma especificação muito abrangente no início para poder fazer um negócio, já começar a fazer e tem um ciclo curto para você já ter contato com o produto. Se você não tiver esse contato com o produto e a gente não tiver esse feedback do processo, a gente não vai conseguir descobrir maneiras de ser mais produtivos. Às vezes o scrum master, eu estou tentando dar exemplos práticos aqui para instanciar na cabeça das pessoas. Uma coisa que eu precisava fazer muito, por exemplo, tem que defender que a capacidade do time, ela não é uma capacidade para desenvolvimento de software, ela é uma capacidade. Se a empresa precisa de uma documentação xyz que o time tem que gerar, cara isso é backlog também. Se a gente gerou ações de retrospectiva, ações de retrospectiva são itens de backlog também, isso não aparece em horas magicamente também. O time, às vezes não vai ter todo o traquejo para se defender. É lógico que em time mais maduro isso entra na veia e começa a se defender. [00:19:11]Szuster: Mas você está comentando um negócio que eu acho interessante também, explicitar, só que a gente já teve até experiência na própria DTI assim, nem todos têm essas habilidades de saber fazer esse tipo de negociação, isso não é assim, nem só para o bem da empresa, é para o bem dos resultados. Quando o Régis fala assim: “o cliente tem que entender que existe uma capacidade”. aquilo não é para o nosso bem, aquilo é para o cliente entender que o time tem que fazer aquilo que gera mais valor. Agora, muitas vezes o cliente não está entendendo aquilo, ou tem alguém do lado do cliente também que está pressionadíssimo, que está reagindo a alguma pressão. Quem vai ser a pessoa que vai ter a coragem de defender isso? Porque eu já vi muita gente que inveja o papel: “ah, eu queria estar ali”, achando que o cara está em uma situação melhor que a minha, mas não gosta de entrar em uma discussão mais, é porque esse tipo de discussão é menos objetiva, ela pode ser mais conflituosa dependendo do nível de pressão que tiver, então a gente entra em uma outra (inint) [00:20:13]  aqui que é das habilidades que são soft skills, com o é que traduz soft skills em habilidades macias, fofas, fofinhas, habilidades mais fofinhas. [00:20:30]Regis: Fica soft skills mesmo. [00:20:32]Szuster: Ângela, você que estuda bastante o assunto management três ponto zero, tem inclusive uma certificação. Como você identifica ali, aliás, começando, ali não define um papel, é totalmente genérico para uma organização. [00:20:51]Ângela: Sim. [00:20:51]Szuster: Falo assim, não trata de um papel, de um time igual ao scrum, não é? É uma forma de uma organização mudar em tudo, não é? [00:20:59]Ângela: Sim. É uma forma de enxergar a liderança. Então a gente sai de um contexto em um ponto zero, dois ponto zero, que era mais comando e controle, que tinha uma hierarquia, para um contexto em que você estimula, no management três ponto zero, fala que todas as pessoas são responsáveis pelo resultado, então é estimular a autonomia e a auto organização, então eu acho que tem tudo a ver, inclusive ficou muito forte com o movimento ágil também. Então dentro desse contexto, do management três ponto zero, o líder ali, ele é um líder servidor, o que a gente falou no início do scrum master como um líder servidor, como um cara que está ali para ajudar o time a performar, que está para ajudar a tirar impedimento, a ser um defensor do time. A gente falou de soft skills, então, como defensor do time, ali também, ele vai estar o tempo todo ali vendo o que pode prejudicar o que o time estes desenvolvendo, negociando, acha que negociação é uma habilidade que acaba sendo essencial para a gente também, porque muitas vezes existe uma necessidade, uma expectativa do negócio também. Então, muitas vezes, buscando essas necessidades, essas expectativas, acaba tentando uma pressão em cima do time também, de entregar mais. E aí o scrum master, ele vai estar muito focado ali em que o time entregue com qualidade, não entrar muito mais coisas, mas entregar com qualidade, alinhado sim aos objetivos do negócio que eles estão esperando, mas preservando também a capacidade de desenvolvimento do time. [00:22:41]Szuster: Ele tem que ter uma visão distanciada do time para poder provocar, ajudar o time e etc, e ele tem que ter uma certa visão distanciada da realidade do cliente para poder ver quando a pressão, por exemplo, estaria excessiva ou, porque a pressão não vem porque alguém resolveu fazer pressão, vem porque o negócio está pressionado, porque alguém está. Mas se você se sucumbe a esse tipo de pressão você acaba que não entrega nada. E isso é uma das coisas que eu acho que ficam mais invisíveis, porque esse tipo de coisa, no fundo, e muitas vezes, pode ficar parecendo no relacionamento que é só uma defesa do time ou do fornecedor e, na verdade, essa defesa do método para que o time possa gerar valor. [00:23:23]Regis: Mas é interessante, talvez o Pierre, possa até falar alguma coisa a respeito, que esse papel do scrum master, da maneira como  a gente descreveu ele aqui ele quase que até independe de ser scrum, a gente tem pessoas fazendo esse papel com o linkanban com a mistura dos dois ou com o próprio scrum no final das contas. Eu falei que você talvez pudesse comentar porque você está preparando um curso de scrum master ou talvez o viés seja esse seja na figura do líder do que propriamente na figura de um framework específico. [00:23:54]Pierre: Exato, porque assim até mesmo dentro de um mesmo time dentro de um mesmo contexto a metodologia usada, a ferramenta framework, ela pode variar. Então é no sentido de um time começou a usar o scrum e ele vai partir para usar um linkanban e eu vou ter que trocar o meu scrum master porque não é mais scrum não faz sentido. Então a questão de um papel ser muito mais voltado para a liderança para conseguir fazer esse paralelo entre a defesa do time e a defesa do lado do cliente, da pressão externa também e o que a gente está procurando abordar nesse curso que o Régis citou é muito mais nesse sentido viés prático mesmo, então a gente até, claro vai explicar o papel do scrum master na teoria que a gente já citou aqui mas o viés é muito mais prático mesmo e explicando, e eu ouso a dizer que vai até além do que o manifesto prega, do que o scrum guide prega com o papel do scrum master que toda essa parte de liderança da equipe, no guide que fica assim, fica meio subjetivo como o Régis citou aqui, é meio abrangente. Então a gente busca levar o que realmente é feito do scrum master na prática. Acho que é esse é o viés que a gente está procurando. [00:25:12]Szuster: Para a gente poder entrar dar alguns exemplos práticos.  Uma coisa que eu gosto muito de entrevista e pedir histórias práticas que mostrem. Vocês têm histórias que vocês podem contar de momentos de atuação de vocês usarem uma determinada ferramenta que exemplifique isso que estramos falando? [00:25:28]Pierre: Buscando um exemplo prático dessa necessidade de sensibilidade do papel, eu passei por uma mudança de time recente por ações externas, por forças externas, como o Szuster já falou aqui. Toda hora a gente pode sofrer uma intervenção ali e acaba tendo que executar uma mudança para poder responder àquela força externa. Então acabei trocando de time recente, o time utilizava scrum eu estava ali há um certo tempo já executando e fazendo suas entregas, mas a gente identificou que precisava ser feito algo diferente porque a gerente estava com alguns problemas muito críticos e esse algo diferente do que foi feito veio de uma sensibilidade  de uma análise talvez distanciada do time pela questão de ter entrado há pouco tempo por chegar depois. [00:26:23]Szuster: sem envolvimento emocional. [00:26:24]Pierre: Exato, sem um viés ali já direcionado para um lado ou para outro e que em um determinado período a gente deixou de usar o scrum e passamos a utilizar o linkanban para buscar uma resposta mais rápida no sentido de responder aos grandes problemas que a gente estava tendo no momento. Então, só para exemplificar a questão de, estávamos vindo em um trilho, em um caminho que a gente acreditava que o time acreditava que era o melhor, uma análise crítica feita com um viés de fora, identificou alguns problemas e uma solução, é uma hipótese que a gente não tem certeza se vai funcionar, foi a transição para o linkanban. E a gente está trabalhando com o linkanban, dando a transparência total para o cliente e tem surtido um efeito interessante, a gente tem conseguido sair desse emaranhado de programas que a gente tinha. Talvez seja um exemplo da análise um pouco distanciada, tanto do cliente quanto do time. [00:27:21]Ângela: Até um pouco semelhante assim, legal isso que você falou, que recentemente, o cliente tem a tendência de querer saber o que a gente vai entregar, quando a gente vai entregar, quase como um cronograma, um escopo definido ali, então, o tempo todo a gente fica meio que tentando lutar contra isso, até para ele também, porque dá muito mais flexibilidade para ele ajustar a necessidade dele conforme o projeto vai evoluindo. Então, durante um tempo a gente também trabalhava com o scrum, e ele tinha uma certa resistência de mudar, apesar de ter umas vantagens de a gente utilizar o kanban no cenário, ele tinha um pouco de resistência porque ele queria saber o que a gente ia entregar, e ele achava que com o framework ele ia conseguir ter mais esse controle. E aí chegou o momento, a gente fez a alteração em um dos projetos, e aí depois até ele falou: “ah, acho que a gente poderia mudar para o kanban, está funcionando bem no outro time”, então é legal quando a gente consegue ganhar essa confiança também, e mostrar para ele que ele tem essa flexibilidade, ele tem essa transparência a gente está ali trabalhando juntos, é um time só. [00:28:31]Pierre: Um exemplo da época em que eu atuava como scrum master também, que eu lembrei aqui, foi no cliente que a gente chegou e era a primeira, ou uma das primeiras experiências do cliente com ágil, estava proposto, era o scrum na época. Na primeira sprint, na hora de definir o backlog da primeira sprint, foi muito difícil, estava muito claro para mim e para o time que a gente deveria perseguir um caminho de entregar o famoso esqueleto andante, que o pessoal fala assim, o mínimo, mas que testasse o máximo do fluxo, não necessariamente o produto mais pronto. Então, na primeira sprint teve bastante negociação assim para a gente conseguir mostrar para o cliente que: “olha, a gente tem um monte de perguntas aqui que a gente não sabe responder”. Era um sistema web, só que era web que teria que criar um tipo de interação mais rica, assim, diferente, baseada em teclas de atalho. A gente vai ter uma interface com sistema X (via) [00:29:27] web, é uma coisa que vocês não têm aqui no parque de vocês. Tem uma interface com esse hardware aqui, tinha até um hardware lá no meio do caminho. E vamos fazer. A gente consegue fazer, fazendo esse conjunto de histórias aqui, a gente consegue entregar uma coisa que já testa, e não só testa e já exercita um fluxo que passa por esse hardware, por essa interface, que já valida essa aplicação, essa interface rica de interação, e de maneira que o risco do nosso projeto depois da primeira sprint vai estar muito mais baixo do que ele é hoje. E isso eu entendo que é, você pode encarar isso talvez como um impedimento que está sendo retirado ou como uma gestão de riscos quase que tradicional aplicada ao (ágil) [00:30:10] assim, que, na minha visão, cabe muito bem ao papel do scrum master, apesar de não estar prescrito em nenhum framework que a gestão de riscos fica em uma pessoa só, ou que ela se mantém e apesar de ela ser adaptável para o ágil e ser uma coisa um pouco diferente, eu acho que foi um bom exemplo da atuação de um scrum master, diminuindo o risco de um projeto e garantindo uma geração de  valor lá para frente. [00:30:33]Szuster: Você lembrou de gestão de risco, claro, isso é importantíssimo, porque é o típico exemplo em que é fácil a equipe. Porque se, em um mundo perfeito, todo mundo imagina que a equipe poderia fazer tudo. A equipe poderia ter gerido esses riscos aqui, poderia. Mas é justamente precisam entender que a equipe fica envolvida com outras coisas e que nem todo mundo tem o perfil adequado para isso. Então alguém com uma visão assim, que possa ter mais tempo preocupado com o risco, ele consegue evidenciar isso para a equipe. Uma coisa que me vem à cabeça, que eu acredito que seja uma coisa muito prática e importantíssima e que tenha esse risco da invisibilidade, na minha visão é o que? Eu acho que a análise crítica, ela tem que ser muito bem feita, sabe? A gente fala muito isso aqui na DTI. É muito fácil você cumprir o rito por cumprir e, na verdade, a análise crítica é um dos momentos mais importantes que existem, porque eu sempre brinco assim, pegando o scrum mesmo, e mesmo que não fosse o scrum, ou o linkanban, mas, de tempos em tempos você faz a análise crítica, é como se você coloca quase que uma viseira no time para ele focar em alguma coisa, mas, de vez em quando, você tem que parar para refletir e aprender. E um time que reflete bem e aprende bem, ele diminui absurdamente o impacto de problemas que ele tem, porque ele vai, no curto prazo, se corrigindo muito rapidamente. Então eu vejo um papel no scrum master importantíssimo em garantir boas análises críticas, sabe? No sentido de garantir que elas não fiquem burocráticas e fazer provocações certas e, até criar variabilidade em uma análise crítica. Quando eu falo variabilidade é mudar, às vezes, a forma como ela é feita, para não virar aquela coisa de sempre que todo mundo chega: “agora vai botar os (inint) [00:32:16] e não sei o que”. Sabe, aí todo mundo já, não é? [00:32:19]Régis: Já vai com aquilo pronto. Hoje tem retro, deixa eu pensar o que eu vou falar aqui. Já sai de casa com o (inint) [00:32:25] pronto praticamente. [00:32:26]Szuster: E qual o problema? É que no mundo real, as pessoas estão sob pressão e, às vezes está com a cabeça ali pensando: nós estamos apertados aqui e o cara está inventando retro. Eu estou com não sei o que, eu estou cansado. Mas aquilo é muito importante. E a consequência da reunião também podem, a gente tem uma cultura de gerar pelo menos uma ação, por exemplo, quem garante que aquela ação vai ser executada. Eu volto a existir no mundo imaginário, não, aqui vai ter maturidade, vai executar uma ação. No mundo real pode ser muito bonito uma ação ali, mas tem forças que vão contra. [00:33:00]Pierre: E o cliente nem sempre vai ver com bons olhos que você tem que fazer uma ação para você melhorar o seu processo. Não, mas eu não estou te pagando para você melhorar o seu processo, eu paguei o processo completo. Essa transparência, entra tudo nisso o que a gente falou, essa boa transparência, essa boa comunicação, são coisas que eu acredito que o papel do scrum master acrescenta muito, é quase que essencial assim. [00:33:22]Szuster: É curioso porque o processo, no ágil, ele define muito o que o time tem que fazer, Não quer dizer, por melhor que seja o time, que ele não esteja enfrentando problemas e não tenha que melhorar isso, porque isso faz parte da brincadeira e um time que vai evoluindo e vai ficando muito bom naquilo, [00:33:40]Régis: Eu acho que um ponto chave aí também é, para não correr esse risco de entrar no piloto automático, o scrum master tem que ter um papel meio questionador, que é instigar alguns pontos ali que pode parecer que vai gerar uma discórdia, mas é para que seja refletido sobre aquilo, Talvez uns pontos que, eu não vou falar sobre isso aqui não, porque isso vai dar muita discussão. Muita gente pode pensar assim e não vai expor isso numa retro. Acho que é papel do scrum master também, perceber isso e dar uma cutucadinha para ver se aquilo é exposto, porque o time pode começar a discutir sobre isso e pode evoluir nesse sentido. Então, eu acho que essa questão de ser questionador é um ponto chave também para o papel. [00:34:25]Szuster: Para mim, se a gente for falar um pouquinho sobre os principais skills, para mim, essa habilidade de entrar em conflito, para o bom conflito, com o objetivo construtivo, isso para mim é assim; e as pessoas não gostam de conflito, entendeu? É muito mais fácil não entrar no conflito, isso aí não tem dúvida. E vou te falar, 90% das pessoas ou mais não gostam disso, o cara paga para não. É como você falou: “a reunião está indo bem, vamos acabar aqui e pronto, não vou falar nada não”. Eu conheço um baixinho aí que adora conflitos. O que vocês, para a gente poder ir fechando, o que vocês citariam como habilidades mais importantes de um scrum master? [00:35:19]Ângela: Bom, eu falei uma aqui. Eu acho que, negociação. Eu acho que essa capacidade de ter o olhar sobre o time também, de perceber os momentos, os momentos que precisa fazer esse papel de defender, ou o momento que precisa gerar essa instabilidade, provocar essa instabilidade às vezes em um cenário que está mais ou menos estável também é positivo para gerar crescimento, para sair mesmo do piloto automático ali. [00:35:48]Szuster: Você sabe que o estresse que causa a anti fragilidade. [00:35:52]Ângela: Exatamente. [00:35:53]Szuster: Um time que só tem estabilidade vai ficando frágil. [00:35:58]Ângela: Sim, e, às vezes, à medida que o time vai se acostumando a trabalhar junto, é importante trazer essas provocações. Eu brinco lá, de vez em quando, eu falo assim: “eu vou fazer uma provocação aqui”. Então é um pouco isso, questionar, tirar um pouco daquele piloto automático mesmo. Então, eu acho que isso é bastante importante. Estar focado ali em tirar o impedimento, em remover o impedimento, então, estar ali o tempo todo. [00:36:28]Szuster: Ser dirigente mesmo, correr atrás. [00:36:29]Ângela: Isso, mas, ao mesmo tempo também, eu acho que desenvolver a capacidade de resolver os problemas, e ajudar que as pessoas, elas tenham a capacidade de resolver os problemas também, não ficar só esperando que alguém vá lá e vai resolver e, enfim. E claro, fazer esse papel de estar o tempo todo ali e, talvez vigiando, como um guardião da metodologia também, até para a gente, principalmente em cenários de crise, tem até um enzimas que fala que tende voltar às origens. Então para não deixar isso, não deixar que volte às origens. [00:37:05]Régis: Vou citar aqui a capacidade de priorização. Embora a priorização no framework lá esteja muito voltada para o product owner, mas eu, de experiência, os melhores scrum masters com quem eu trabalho, são pessoas que sabem exatamente onde gastar os esforços naquele momento. Onde é que o time precisa focar, onde que ele precisa focar, quais são as guerras que ele vai travar, escolher as guerras dele muito bem. Então, a capacidade de priorização. E uma outra soft skill que é engraçado, não sei se dá para descrever como soft skill, é a ciência de urgência. É muito importante uma pessoa que saiba se antecipar ao que vai acontecer. [00:37:43]Szuster: Tirou do Pierre ali. [00:37:44]Pierre: Roubou o que eu ia falar. Eu estava guardando na mesa aqui, eu guardei aqui no bolso aqui. [00:37:48]Régis: Então você usa o seu senso de urgência para pensar em outras aí. [00:37:55]Pierre: Não é que a pessoa precisa ser estressada por natureza. [00:38:02]Szuster: Não sei se é um soft skill, não sei o que é isso, mas o scrum master ser isso é uma desgraça, porque o troço vai acontecendo, cara. [00:38:12]Régis: É isso. Eu queria destacar essas duas, priorização e senso de urgência. [00:38:19]Pierre: Eu acho que, além disso tudo que já foi dito aí pela Ângela e pelo Régis, eu ia falar da ciência de urgência. Adaptação à mudança. Então, acredito que um ponto muito importante é ser comunicativo. Eu não consigo enxergar um scrum master que não consiga se comunicar bem, porque o papel dele, toda a atividade dele depende da comunicação. Então, para mim, se eu fosse elencar um top três, com certeza o comunicativo iria estar nesse top três, o senso de urgência, que o Régis roubou, seria um dos outros dois. Eu vou guardar isso aqui, viu Régis. [00:39:06]Régis: Isso foi uma piada, eu não roubei não. [00:39:08]Pierre: Bom, acho que é isso. [00:39:11]Szuster: Só um complemento, acho que é interessante. Quando se fala em comunicar bem, é também escutar bem, ler bem o contexto. [00:39:17]Régis: Exatamente, comunicação no todo. Não é ser um cara extrovertido necessariamente, é ser um cara que, se você junta priorização, ciência de riscos e comunicação, você pega um cara que comunica a coisa certa, na hora certa. [00:39:27]Szuster: Exatamente. [00:39:27]Régis: Na hora certa. Da forma certa. [00:39:29]Szuster: Lê o ambiente, entende o que está acontecendo, consegue sintetizar bem o que está acontecendo, porque, às vezes a coisa não anda, simplesmente porque alguém não consegue sintetizar o que está acontecendo e deixar claro para todo mundo. [00:39:39]Pierre: Talvez falte, muitas vezes a gente recebe algumas críticas, falta de visibilidade com determinado time, e às vezes não é falta de visibilidade, não é falta de entrega, é falta de comunicação, é um problema de comunicação que resolveria esse questionamento. [00:39:56]Régis: Esse ponto que o Szuster falou é impressione mesmo. às vezes é falta de síntese. É impressionante o quanto que você sintetizar uma informação e mostrar, cara é por isso que nós estamos com esses problemas aqui. E aquilo, fazer sentido para todo mundo, de repente dar aquela sensação de era isso, agora está na nossa frente aqui. Isso move acho que é muito mais do que um cara que fica lá só cobrando. [00:40:18]Szuster: Isso é engraçado, porque eu particularmente reparo muito nisso, porque, na medida em que eu fui ficando mais, durante muito tempo para a venda, por exemplo, eu comecei a perceber o tanto que era importante você ter um grupo meio que cada um falando uma coisa, às vezes está uma confusão, todo mundo está ansioso e você tentar ler ali o que aconteceu e sintetizar uma coisa e todo mundo fala: “ah, é isso mesmo”. Existe uma dificuldade de comunicação. Aí eu tive que praticar isso muito, porque nessa área ai eu acho que as equipes passam por situações muito similares, volta e meia você tem reuniões que está tudo estranhamente confuso, simplesmente por causa disso, porque alguém não consegue falar de uma forma simples o que está acontecendo para todo mundo entender. É engraçado. Ou seja, nós estamos vendo que é necessário o scrum master. [00:41:08]Régis: Szuster, faz um resumo aí para ficar no (contexto) [00:41:09]Szuster: Esse episódio não foi um episódio em defesa do scrum master, mas eu acho que a gente conseguiu ressaltar muito bem como existe um papel de líder servidor que vai muito além do que estaria prescrito como atividades rotineiras, e como que, mesmo que o time amadureça, para não precisar de certas atividades rotineiras, esse papel de líder servidor, associado a esses soft skills que o scrum master tem que ter, eles podem ser essenciais para garantir que aquela equipe continue gerando valor. Isso aí, um abraço para todos. [00:41:47]Régis: Valeu pessoal, obrigado, um abraço. [00:41:48]Ângela: Tchau, tchau, obrigada. [00:41:50]Pierre: Valeu pessoal, um abraço. [00:41:52]Ângela: Eu lembrei que eu tenho certificação sim. [00:41:55]Pierre: A certificação é tão útil que agora que ela lembrou que ela tem certificação. [00:41:58]Ângela: Eu tenho certificação do kanban, e tenho uma outra que eu não vou contar. [00:42:01]Pierre: Mas eu sei que termina com (coach) [00:42:03], eu sei que termina com (coach)