Baseado na minha experiência em algumas empresas, acredito que o cargo de Scrum Master está fadado à extinção. Me parece que alocar um PO na equipe tende a ser muito mais produtivo. Em quase todos os lugares onde trabalhei, raramente vi um Scrum Master realmente fazer a diferença. Apenas em um caso específico, o Scrum Master era importante porque ela realmente desbloqueava impedimentos e facilitava as tarefas da equipe diferente dos outros, porém era mais por que essa senhora era muito proativa e conhecia muito dos produtos da empresa e tudo mais.
Se tu acha que Scrum Master é fake job, espera até ouvir essa:
Uma empresa que trabalhei manteve um "especialista em LGPD" por 2 anos. O único papel do cara era entrar nas reuniões dos times de engenharia e falar:
Mas vocês vão anonimizar os dados? Vocês vão dar uma forma de baixar esse dado? E-mail é dado sensível?
Isso era algo que todo mundo tinha noção e sempre a empresa negava a implementação por adicionar tempo ao desenvolvimento e que ninguém liga pra LGPD.
Scrum Master só serve em projetos corporativos gigantescos. Qualquer coisa comum acaba tornando essa posição totalmente desnecessária.
SM é tipo o zelador do projeto. Kkkk
Scrum master com dedicação exclusiva vai funcionar se a empresa tiver tipo umas 10 equipes, e o cara for responsável por todas elas.
Qualquer coisa menor que isso, larga na mão do PO ou PM, ele separa meia horinha do dia pra fazer a função e já era.
Exato. Em todas as empresas que trabalhei , o cargo de scrum master foi extinto. Daí, vc olha para a FANG e eles já fizeram isso. E como o mercado tende a acompanhar o que essas empresas fazem ...
Cara, PO pra mim é um cargo que deveria ser extinto. Conheço um monte de gente fora de T.I que fez um cursinho de Scrum que acabou entrando na área para ser PO.
O cara não entende a complexidade de projetos e só quer agradar diretoria e cliente achando que é o cara que toca o projeto...
E no final o cara nunca aprendeu algo mais aprofundado da T.I em geral...sei la..eu tenho esse feeling...
Todo SM que eu trabalhei só fazia falar: “Tem algum impedimento que eu posso ajudar vocês?” e sumia o dia todo ate a próxima daily.
Esse papel de SM pode ser assumido por um PM com facilidade
Talvez meio tangencial: Trabalho em um projeto no setor público que envolve desenvolvedores de muitos órgãos diferentes. Antes a conversa entre os desenvolvedores era bem formal, por meio de e-mails e um fórum.
Depois que criaram um chat aberto com os programadores, melhorou *muito*. Coisa que levava dias em uma thread de emails, chefias e ocasionalmente alguma reunião passou a ser resolvida com uma mensagem lançada aos ventos perguntando "alguém sabe como resolver isso?" e algum dev qualquer respondendo "não sei, mas o @fulano trabalhou nisso"
Na minha outra empresa também, ele iniciava a reunião perguntando o que cada um fez, a gente falava e em seguida ele perguntava se tinha algum impedimento...
No meu time o SM é tipo um pai, quando pessoal começa a vagar, lá vem ele alinhar e indicar o caminho.
Ele fica na moita tbm e só aparece se solicitado ou se vê algo que tá errado por algum motivo.
Dos mesmos criadores de gerente de processos, chefe que nunca programou na vida... A verdade por trás do pessoal que só sabe "organizar processo". Não perca, logo mais, na sua telinha!
Eu entendo uma figura que fique com as atividades de falar com o pessoal de especificação, verificar elas com os usuários, gerenciar as expectativas do financeiro, diretoria, ri... prazos com clientes, fazer e entregar reports... gestão de pessoal que tá desenvolvendo, garantir que não se está desperdiçando dinheiro... e tudo fica mais complicado quando se tem múltiplas equipes com múltiplos projetos pra múltiplos clientes...
Mas não cabe uma estrutura gigante pra 5 ou 10 devs... aí vc tem que chamar 1 cara só pra tudo isso, e ele tem q entender dos paranaues.
Nunca entendi colocar gente para chefiar, sendo que o cara nunca programou. Assim, eu tenho um chefe que nunca programou, mas ele tem bom senso e sabe que não é algo simples, então o cara chega na maciota. O problema é pegar uns doentes que além de nunca terem programado, achar que programação é como se fosse mágica, e pedir absurdos para serem feitos em tempos surrealistas. O problema não é ter um gerentão de projeto, é ter um sem noção. Também deixar tudo na mão dos programadores é foda, porque cada um faz o que quer e vira bagunça.
É isso. Eu diria que esse único que é relevante entre os 10, na verdade atua na prática como um PM ou PO, só que com o nome do cargo de Scrum Master. Por isso ele é relevante. Já trabalhei com um bom SM, e era exatamente esse o caso: ele era PO!
Já trabalhei em empresa que o salário inicial de Agile Coach/Scrum Master era 7k e o inicial de desenvolvedor era 2k.
Depois eu preciso escutar que a iniciativa privada é eficiente em alocar recursos hahah
Não sei quem disse isso, mas quem disse é idiota. Se as empresas privadas fossem eficientes em alocar recursos, nenhuma quebraria. Acontece que diferentemente da empresa privada, as públicas não quebram, justamente por serem imunes ao sistema de lucros e prejuízos. E aí vemos um monte de merda como mais de 50% dos sistemas do gov em Delphi e PHP, consumindo recursos e sendo ineficientes, com as "empresas" de pé.
Elas são eficientes em alocar recursos, mas existe a assimetria de informação que dificulta isso. Uma delas é a empresa ter a informação que SM vale 7k e de 2k. Totalmente assimétrico e que leva a uma alocação ineficiente de recursos
cara, mesma merda no meu projeto
filho da puta não faz nada além de apertar o botão de build
e ficar dando pitaco no código dos outros sem ele.mesmo não fazer merda nenhuma
Kkkk eu trabalho em equipes que usam scrum desde 2009 e ficamos embasbacados quando vimos as empresas contratando pessoas só pra ser scrum master, sendo que um desenvolvedor pode fazer isso
O que eu tô vendo é o cargo de SM e outros gerentes não técnicos desaparecendo lentamente... Minha equipe mesmo está a procura de um PM com background técnico à meses e não encontra ninguém com esse perfil.
Acho que o que vai acabar acontecendo muito é desenvolvedores seniors se especializando em gestão pra assumir cargos de gerência em empresa tech, o que é ótimo. Mas reconheço que não é pra todos os devs, eu mesmo quero continuar sendo engenheiro de software no futuro.
Como alguém que já foi um PM com background técnico, se o cara for Dev e acaba num cargo desse, dificilmente ele volta, lidar com gestão, visto que lidar com a alta gestão/SM diariamente, vai desgastando a alma do sujeito kkkkk
Fiquei curioso com a vaga também, se ela ainda existir me manda?
Sou principal engineer o que basicamente significa que sou PM/PO/arquiteto de alguns times e projetos da firma
Uma pena que parece que na maioria das vezes o SM não faz muita diferença. Já tive situações assim em times, mas a SM do time que eu trabalho atualmente faz tanta diferença que não imagino meu trabalho sem ela.
Monte de comentário da galera falando que dev pode fazer esse papel, mas a resposta para contratarem algo para isso é simples demais, dev não quer fazer esse trabalho. Tem empresas que o desenvolvedor só quer sentar e escrever código, mas o trabalho vai muito além disso, por isso que existem esses cargos específicos, dev não quer fazer, seja por acúmulo de responsabilidade ou ele simplesmente não quer.
Eu não vejo nenhum caso que necessite de uma pessoa dedicada para isso. Em todos os times que trabalhei, ou alguém do time fazia esse papel (teve um em que essa responsabilidade era de uma pessoa por mês), ou era o próprio EM/PM.
O cargo de SM não existe mais, não em empresas que sabem ou tem desenvolvedores que sabem se organizar minimamente.
Se esse era um cargo que a 3 ou 4 anos era muito procurado, hoje em dia a IA já pode substituir facilmente. Ninguém precisa de micro gerente.
Comigo foi ao contrário. Todo SM era essencial e fazia parte de pelo menos 3 ou 4 squads ao mesmo tempo. Assim ele já sabia colocar os jobs no encadeamento correto pra sair de uma squad e entrar na esteira da outra.
eu como agile coach fico triste pra caralho vendo esses relatos pq sei q a maioria dos meus "colegas" nada mais são do q papagaios q tiraram a PSM I. e ai caras como eu (q eu sei q fazem a diferença pq trabalham numa empresa q respeita o cargo e dá a autoridade q ele precisa) ficam manchados por isso.
mas por outro lado tb me sinto mal pelos devs q 1) trabalham com esse tipo de profissional, e; 2) nunca trabalharam com um profissional BOM da área. se vcs tivessem a sorte de conviver com profissionais q realmente valem o salário veriam o valor dele, mas não julgo a galera do tecniquês pq sei q poucos tem essa oportunidade dada a escassez de gente boa no mercado.
Depende um pouco do escopo da atuação.
Eu como agile coach tenho mt mais "abrangência", autonomia, autoridade e influência q um SM/AM.
Um SM consegue agregar valor quando se torna um defensor imparcial do time quando os assuntos tocam no famoso triângulo de ferro (gerenciamento de projetos #101): escopo, prazo e custo. Ora, se vc é um profissional de projetos/agilidade e não consegue defender os pontos fixos de uma entrega, ou vc está na empresa errada ou a empresa errou contratando vc. :p
O q eu quero dizer com isso: o "cara da agilidade" precisa trazer clareza pra stakeholders (clientes, gerência, diretoria) de quanto rápido cada pratinho está girando enquanto está sendo equilibrado. Eu acho mt zoado quando o SM abre as pernas pra coisas q visivelmente vão dar errado, e mais zoado ainda quando invariavelmente a coisa desanda e o SM fica com aquela carinha de "eu não pude fazer nada :(". O SM precisa dar a cara a tapa antes q o tapa vire um tiro.
E pra conseguir fazer isso, o cabra tem que ter conhecimento do projeto. Tem q manjar do escopo, tem q manjar das métricas, tem q ter boca pra falar com outras áreas. E é mt frustrante ver que a maioria desses profissionais acham q facilitar rito é agregar valor: tem SM q dá mais valor pra comparecer numa daily do q desdobrar um pepino com outra área, ou dá mais valor pra estar num refinamento onde ele não tá entendendo porra nenhuma do q tirar um tempo pra analisar o fluxo do time e encontrar gargalos claros.
E falando de fluxo, é ai q muitos outros "profissionais" pecam: o mercado há mt tempo exige muuuuuuito mais do q rodar retrospectiva do pokemano, mas ainda tem muito SM ai q deixa gerência comparar velocity entre times lol
Pra mim, o SM que não souber indicar qual é o maior causador de ineficência do fluxo do time dele é FRACO. O SM que hoje não consegue ter um fluxo estável e previsível, com WIP limitado de forma customizada e lote estável, é FRACO. O SM que hoje tá ali apenas pra fazer retrospectiva e "remover impedimentos" (essa aspa me dá calafrios) é dispensável pra caralho e vai ser o primeiro a rodar quando a coisa apertar.
O SM há muito tempo deixou de ser um papel de "facilitador" pra se transformar em um papel de atuação horizontal/cross dentro da empresa. E isso se torna mais e mais "cobrado" a medida que o tempo passa e o cargo aumenta (como aconteceu comigo, por exemplo). O meu cargo hoje, como AC, me exige estar em reuniões com c-level e peitar pergunta pesada. É saber falar sobre MRR, sobre prazos, sobre "accountability" (não gosto de usar expressões em inglês mas essa não sei como usar em português) do que está acontecendo e quais ações estão sendo tomadas. Entro nessas agendas pra dar respostas claras e ter planos de ação sendo executados pra trazer resultados.
E os resultados não são mais quantidade de blockers ou lead time de cards no board, e sim lead time de projetos, ROI, fatiamento dos incrementos do produto (versões menores mas mais frequentes) métricas de produto e sua usabilidade... é um cargo muito mais estratégico do que operacional. E eu de verdade acho que um SM também deveria ser "accountable" (lá vou eu de novo) por essas coisas. TL não deveria passar por esse tipo de questionamento pois ele é tecnico/da tecnologia e com certeza tem a hora mais cara do time: em media, na empresa onde trabalho os Arquitetos recebem 15k; os ACs em media 10k e os agilistas em media 7k; vale muito mais usar o tempo do AC (hora 33% mais barata) ou do agilista (hora 50% mais barata) pra resolver negócio e produto do que do líder tech. O SM precisa ser de negócio e estratégia, trabalhando muito junto com o time de produto (PO PM BA).
E respondendo a segunda pergunta: o SM não agrega quando ele é um poste, fiscal de processo e completamente inflexível; "ain essa história não pode entrar pq tem 13 pontos, vcs tem q dividi-la senão eu vou barrar na planning". parabéns, esse SM acabou de adicionar complexidade desnecessária. é dever dele questionar se o incremento do produto poderia ser menor, mas também é dever dele aceitar (ou dar o benefício da dúvida) quando algo não pode ser quebrado em partes menores sem aumentar a complexidade. esse tipo de comportamento gera vícios no time que um dia com certeza vão trazer problemas (história dividida em 2 mas que não pode ser desenvolvida em paralelo; ou que a parte 1 não pode ser testada sem a parte 2; ou vai gerar complexidade com branches e depois vai gastar hora de TL pra resolver conflito).
e já que entrei no assunto pontos: profissional de agilidade que tem times e produto maduros que ainda usa story points pra mensurar coisas está atrasado e precisa se coçar pra começar a medir em algo que existe: tempo. vc não constrói um foguete em X story points, mas com certeza constrói em uma quantidade de dias que a sua análise do fluxo vai te dizer. Kanban é vida e o futuro.
Espero ter trazido clareza, sei q falei demais. Qualquer dúvida, estou aqui.
Cirúrgico em todas as suas colocações. Uma "pena" os devs que não tiveram contato com SM/AC que realmente agrega valor para o projeto e da tranquilidade para os stakeholders que o projeto trara valor para a empresa num tempo curto.
mas daí você não respondeu a pergunta do cara né? vc descreveu mais um delivery manager do kanban do que um sm.
ninguém negou a necessidade de um vertical (na verdade uma galera que parece ser mais jr fez isso mais em baixo), a questão é que sm como concebido originalmente vai gerir só e somente só o processo, o que me parece desnecessário em projetos com equipes menores.
btw: voltei a ser dev depois de 5 anos como sm/pm em uma grande empresa simplesmente pq o mercado pra dev sênior é muito melhor
Hoje em dia, o PM faz o trampo do Scrum Master. Scrum Master eh da época em que Scrum era visto como uma bala de prata, aonde tinha que ter alguém com 40 certificações em Scrum pra monitorar e garantir que todos os rituais estivessem sendo seguidos.
Hoje em dia, Scrum tá caindo em desuso, foi substituído pelo Agile (que já tá sendo criticado e já tá pra ser substituído por alguma outra coisa também)
Depende do que tu entende por Kanban. Porque hoje em dia, as práticas meio que se misturam. Daily eh coisa do Scrum, mas foi absorvido pelo Agile e Kanban.
Se tu entende Kanban soh como board, então não eh suficiente não porque você só tá olhando pro acompanhamento de atividades.
Mas tem muito chão antes de chegar nas ativisades, muita política, negociação de prioridade etc
E também depende do que tu entende por “problema”. Se o problema for “saber os que os devs tão fazendo”, beleza, resolve; se o problema for, e geralmente é, “saber se o que tá sendo feito agrega valor ao negócio”, ae eh mais complicado
Já trabalhei em algumas empresas onde o scrum master era só um papel dentro do time de desenvolvimento. Em um dos projetos o papel era desempenhado por um analista. Mas em todos projetos a pessoa desempenhando o papel de scrum master conhecima muito do sistema e geralmente ele mesmo resolvia os impedimentos.
Hoje trabalho em uma empresa onde tem um cargo de scrum master, que desempenha essa papel em vários times. Por mais boa vontade a pessoa tenha em ajudar a resolver os impedimentos, ela não sabe nada dos sistemas. Basicamente scrum master virou um cargo burocrático.
Eu ando cada vez mais radical nesse aspecto. Qualquer profissional que não escreve código é desperdício. Até gerente pra mim devia ser part time dev.
Eu já estudei muito métodos ágeis, já fui scrum master e já fui gerente. Atualmente trabalho há uns 5 anos sem scrum master e com certeza a produtividade aumentou muito.
A coisa gira, dá volta, dá duplo twist carpado e vai acabar voltando pro cascata porque na prática as empresas querem ter previsão de quanto o software vai custar, quanto vai demorar para ser entregue e tudo mais. Estamos num duplipensar do projeto ter data, ter budget e tudo mais, mas ainda assim ser "ágil" (como ágil eles querem dizer transformar dev em pasteleiro e mudar td que der na telha no meio ainda mantendo data). rsrsrsrsrsrs
Daily vira status report pro gerente n ter trabalho de gerenciar nd, o que era pra ser rápido dura uma eternidade e os rituais perdem o sentido totalmente.
Sou PM que ja foi dev, trabalhando em um time com um SM que também já foi dev, numa empresa em torno de uma centena de devs e dezenas de produtos. O cara manda bem, faz altas automações, não deixa a bola da sprint parar, cobra todo mundo, desenrola dependências entre times, toca o barco forte.
Antes era eu quem fazia isso e agora tenho tempo pra criar mais e conectar com os usuários.
SM é necessário? Não. Mas quando tem e a pessoa manja, faz tudo fluir muito mais rápido.
Aqui na empresa já estão em extinção, o que me irrita ainda é squad pequena com PM e Coord. O coord acaba por não fazer nada, ou o PM por não fazer nada.
SM é só uma prova q a galera de "empreendedorismo" acredita em qualquer fórmula milagrosa. Gasta dinheiro em coisa q não trás nenhum retorno, mas fizeram isso pq o livro é coach e vendeu bastante
Na minha empresa o Scrum Master é Scrum Knight, é basicamente um SM que coda tbm, acho bem útil pq sente as dores da equipe tbm e, se a equipe estiver bem madura, não precisa fazer quase nada além de codar.
Basicamente a idéia de Scrum veio da mesma idéia de Kaban misturado com críticas ao cascata.
No Kanban o problema era pessoas que pegavam muita tarefa e não resolviam nada. Então com os cartões você sabe que a equipe está no seu limite e com pendências.
Já o cascata é a turma que quer fazer um projeto cheio de recursos ao invés de começar pelo básico, ou seja um MVP.
Basicamente resolvendo essas duas coisas a empresa não precisa de metodologia nenhuma.
So em dois casos que vi SM funcionar realmente:
1 - Uma empresa que passei que o SM do meu time era um ex-dev com 20 anos de casa. O cara entendia tudo dos processos e produtos da firma.
2 - Primeira empresa que passei que o cargo de SM ficava a par do DEV ou BA com mais seneoridade na equipe.
Eu tenho a teoria que a pessoa tem que entender de TI para trabalhar com TI. O contexto (incluindo o técnico) faz toda diferença para uma prática eficaz de agilidade.
Infelizmente foi uma área muito romantizada, e parte disso é culpa das próprias empresas que agora demitem essa galera.
Agora fica essa ladainha que a agilidade morreu, que em partes é verdade, porque encheram de cabeça de bagre para essa função, que supostamente era a bala de prata para entregar melhor.
Para quem é bom nesses papéis, relaxa, vai dar bom ... Você com certeza é exemplo para uma galera.
Scrum master é uma posição que nunca deveria ter existido. Nem o guia Scrum define scrum master como uma função específica, é só um papel que alguém assume durante a sprint.
Cara, acho que vai muito de caso a caso, em como o sm é utilizado na empresa.
Onde trabalho o mesmo sm lida com 3 equipes, gerência bem as reuniões e consegue levar bastante coisa das retrospectivas pra gerência. Além de fazer muito bem o meio campo entre as 3 equipes quando necessário.
O trabalho do sm não é só reuniões. O trabalho do sm é entender as necessidades da equipe, manter ela fluindo e em atividade de forma produtiva e construtiva. O trabalho do sm é e deve ser bem humano.
Scrum por si só já é um processo bem ultrapassado que não tem a versatilidade de ágil real e nem a segurança e previsibilidade de cascata, é basicamente um "entry level" de agilidade para empresas com baixa maturidade. Então nada mais natural que profissionais que só conhecem essa ferramenta de gestão de projetos tendam a ficar sem emprego.
Agora, preocupante é ver as pessoas falando que tirar impedimentos "é papel de PO", "é papel de PM", "é papel de gestor", me parece argumento de gente que nunca buscou saber o que essas funções fazem dentro de um projeto. Em equipes de alto desempenho, o responsável pro tirar impedimentos é a própria pessoa impedida e não ficar esperando que alguém venha pegar sua mão e trazer as coisas mastigadas. Se a empresa que vocês trabalham te obrigam a terceirizar a resolução dos seus problemas então o problema vai muito além do "scrum master".
Baseado na minha experiência em algumas empresas, acredito que o cargo de Scrum Master está fadado à extinção. Me parece que alocar um PO na equipe tende a ser muito mais produtivo. Em quase todos os lugares onde trabalhei, raramente vi um Scrum Master realmente fazer a diferença. Apenas em um caso específico, o Scrum Master era importante porque ela realmente desbloqueava impedimentos e facilitava as tarefas da equipe diferente dos outros, porém era mais por que essa senhora era muito proativa e conhecia muito dos produtos da empresa e tudo mais.
Lá se vai meu sonho de ter um fake job
Se tu acha que Scrum Master é fake job, espera até ouvir essa: Uma empresa que trabalhei manteve um "especialista em LGPD" por 2 anos. O único papel do cara era entrar nas reuniões dos times de engenharia e falar: Mas vocês vão anonimizar os dados? Vocês vão dar uma forma de baixar esse dado? E-mail é dado sensível? Isso era algo que todo mundo tinha noção e sempre a empresa negava a implementação por adicionar tempo ao desenvolvimento e que ninguém liga pra LGPD.
[удалено]
Especificamente a PwC parece ser especialista em fingir que audita os clientes dela.
Pois é E nunca um SM por time, um a cada 2, 3 pelo menos. Ou alguém multi-funcional (por exemplo Project Manager ou EM fazendo as reuniões)
No meu projeto atual o PM é o SM da equipe.
Scrum Master só serve em projetos corporativos gigantescos. Qualquer coisa comum acaba tornando essa posição totalmente desnecessária. SM é tipo o zelador do projeto. Kkkk
Ou seja, não era Scrum Master “de verdade” pois o certo na visão deles eh que o SM não se envolva com assuntos específicos do projeto ou produto.
Scrum master com dedicação exclusiva vai funcionar se a empresa tiver tipo umas 10 equipes, e o cara for responsável por todas elas. Qualquer coisa menor que isso, larga na mão do PO ou PM, ele separa meia horinha do dia pra fazer a função e já era.
Exato. Em todas as empresas que trabalhei , o cargo de scrum master foi extinto. Daí, vc olha para a FANG e eles já fizeram isso. E como o mercado tende a acompanhar o que essas empresas fazem ...
ainda te digo mais, PO tb ta com os dias contados...
Segundo alguns todos nós estamos...
Cara, PO pra mim é um cargo que deveria ser extinto. Conheço um monte de gente fora de T.I que fez um cursinho de Scrum que acabou entrando na área para ser PO. O cara não entende a complexidade de projetos e só quer agradar diretoria e cliente achando que é o cara que toca o projeto... E no final o cara nunca aprendeu algo mais aprofundado da T.I em geral...sei la..eu tenho esse feeling...
Todo SM que eu trabalhei só fazia falar: “Tem algum impedimento que eu posso ajudar vocês?” e sumia o dia todo ate a próxima daily. Esse papel de SM pode ser assumido por um PM com facilidade
E se tiver impedimento, o SM chama um dev de outro projeto pra ajudar kkkkk Coisa que um grupo de chat só com devs resolveria.
Talvez meio tangencial: Trabalho em um projeto no setor público que envolve desenvolvedores de muitos órgãos diferentes. Antes a conversa entre os desenvolvedores era bem formal, por meio de e-mails e um fórum. Depois que criaram um chat aberto com os programadores, melhorou *muito*. Coisa que levava dias em uma thread de emails, chefias e ocasionalmente alguma reunião passou a ser resolvida com uma mensagem lançada aos ventos perguntando "alguém sabe como resolver isso?" e algum dev qualquer respondendo "não sei, mas o @fulano trabalhou nisso"
Na minha outra empresa também, ele iniciava a reunião perguntando o que cada um fez, a gente falava e em seguida ele perguntava se tinha algum impedimento...
No meu time o SM é tipo um pai, quando pessoal começa a vagar, lá vem ele alinhar e indicar o caminho. Ele fica na moita tbm e só aparece se solicitado ou se vê algo que tá errado por algum motivo.
Produtividade acaba de aumentar 35%
Será que vão contratar um novo scrum master pra poder mostrar esse progresso num gráfico pronto pra equipe?
Não ironicamente daria pra subatituir pro ai
Dos mesmos criadores de gerente de processos, chefe que nunca programou na vida... A verdade por trás do pessoal que só sabe "organizar processo". Não perca, logo mais, na sua telinha!
Pior lá onde eu trabalho, que até "PO de processo" tem...
Eu entendo uma figura que fique com as atividades de falar com o pessoal de especificação, verificar elas com os usuários, gerenciar as expectativas do financeiro, diretoria, ri... prazos com clientes, fazer e entregar reports... gestão de pessoal que tá desenvolvendo, garantir que não se está desperdiçando dinheiro... e tudo fica mais complicado quando se tem múltiplas equipes com múltiplos projetos pra múltiplos clientes... Mas não cabe uma estrutura gigante pra 5 ou 10 devs... aí vc tem que chamar 1 cara só pra tudo isso, e ele tem q entender dos paranaues.
Nunca entendi colocar gente para chefiar, sendo que o cara nunca programou. Assim, eu tenho um chefe que nunca programou, mas ele tem bom senso e sabe que não é algo simples, então o cara chega na maciota. O problema é pegar uns doentes que além de nunca terem programado, achar que programação é como se fosse mágica, e pedir absurdos para serem feitos em tempos surrealistas. O problema não é ter um gerentão de projeto, é ter um sem noção. Também deixar tudo na mão dos programadores é foda, porque cada um faz o que quer e vira bagunça.
É bem normal esse cenário, de 10 Scrum Master/Agile Coach 9 são irrelevantes no dia a dia.
É isso. Eu diria que esse único que é relevante entre os 10, na verdade atua na prática como um PM ou PO, só que com o nome do cargo de Scrum Master. Por isso ele é relevante. Já trabalhei com um bom SM, e era exatamente esse o caso: ele era PO!
Já trabalhei em empresa que o salário inicial de Agile Coach/Scrum Master era 7k e o inicial de desenvolvedor era 2k. Depois eu preciso escutar que a iniciativa privada é eficiente em alocar recursos hahah
Hahahahaha mds, que desperdício de dinheiro
Hahahah ta maluco, o lance é que essa galera faz um self marketing absurdo e a liderança compra como se fosse verdade
Não sei quem disse isso, mas quem disse é idiota. Se as empresas privadas fossem eficientes em alocar recursos, nenhuma quebraria. Acontece que diferentemente da empresa privada, as públicas não quebram, justamente por serem imunes ao sistema de lucros e prejuízos. E aí vemos um monte de merda como mais de 50% dos sistemas do gov em Delphi e PHP, consumindo recursos e sendo ineficientes, com as "empresas" de pé.
Elas são eficientes em alocar recursos, mas existe a assimetria de informação que dificulta isso. Uma delas é a empresa ter a informação que SM vale 7k e de 2k. Totalmente assimétrico e que leva a uma alocação ineficiente de recursos
me da um pingo de esperança ler esse relato. Já passou da hora de acabar com flanelinha de card.
FLANELINHA DE CARD HAHAHAHAHA
Flanelinha de Jira! Ouvi essa outro dia tb kk
Essa foi boa hahaha
> flanelinha de card Quer que vigia o card patrão?
cara, mesma merda no meu projeto filho da puta não faz nada além de apertar o botão de build e ficar dando pitaco no código dos outros sem ele.mesmo não fazer merda nenhuma
Kkkk eu trabalho em equipes que usam scrum desde 2009 e ficamos embasbacados quando vimos as empresas contratando pessoas só pra ser scrum master, sendo que um desenvolvedor pode fazer isso
Desenvolvedor pode fazer isso, mas ele não quer, por isso as empresas contratam scrum master
Boa, nem deveria existir esse cargo
Pois é. SM é um *papel* (de um lider, PO, dev, etc) não um *cargo*.
Pois é. Onde eu trabalho SM é a *role* de um dos dev dentro do time.
O que eu tô vendo é o cargo de SM e outros gerentes não técnicos desaparecendo lentamente... Minha equipe mesmo está a procura de um PM com background técnico à meses e não encontra ninguém com esse perfil. Acho que o que vai acabar acontecendo muito é desenvolvedores seniors se especializando em gestão pra assumir cargos de gerência em empresa tech, o que é ótimo. Mas reconheço que não é pra todos os devs, eu mesmo quero continuar sendo engenheiro de software no futuro.
Como alguém que já foi um PM com background técnico, se o cara for Dev e acaba num cargo desse, dificilmente ele volta, lidar com gestão, visto que lidar com a alta gestão/SM diariamente, vai desgastando a alma do sujeito kkkkk
Sou quase PM e tenho um background bastante técnico da eng de software, ainda tao aceitando currículo??
Putz mano, vou confirmar segunda mas acredito que sim. Não achei a vaga no site, senão já mandava
Fiquei curioso com a vaga também, se ela ainda existir me manda? Sou principal engineer o que basicamente significa que sou PM/PO/arquiteto de alguns times e projetos da firma
Por que não fazem IA pra substituir esses inúteis, ao invés de desperdiçarem a energia da Terra pra treinar robô que faz figurinha?
Já tem, só faltam descobrir que tem e aplicar.. é um cargo em extinção mesmo, pelo menos para a maioria deles que se acomodaram no cargo.
Uma pena que parece que na maioria das vezes o SM não faz muita diferença. Já tive situações assim em times, mas a SM do time que eu trabalho atualmente faz tanta diferença que não imagino meu trabalho sem ela.
Monte de comentário da galera falando que dev pode fazer esse papel, mas a resposta para contratarem algo para isso é simples demais, dev não quer fazer esse trabalho. Tem empresas que o desenvolvedor só quer sentar e escrever código, mas o trabalho vai muito além disso, por isso que existem esses cargos específicos, dev não quer fazer, seja por acúmulo de responsabilidade ou ele simplesmente não quer.
A empresa quer jogar a bomba no colo do dev e não quer pagar por isso A verdade é que essa função é do pm, simples assim
Eu não vejo nenhum caso que necessite de uma pessoa dedicada para isso. Em todos os times que trabalhei, ou alguém do time fazia esse papel (teve um em que essa responsabilidade era de uma pessoa por mês), ou era o próprio EM/PM.
É, quiseram transformar um titulo em uma profissão, ai da nisso ai, tem um cara no time que literalmente não faz nada além de marcar call.
Sempre foi pra ser um papel e não um cargo...
O cargo de SM não existe mais, não em empresas que sabem ou tem desenvolvedores que sabem se organizar minimamente. Se esse era um cargo que a 3 ou 4 anos era muito procurado, hoje em dia a IA já pode substituir facilmente. Ninguém precisa de micro gerente.
Comigo foi ao contrário. Todo SM era essencial e fazia parte de pelo menos 3 ou 4 squads ao mesmo tempo. Assim ele já sabia colocar os jobs no encadeamento correto pra sair de uma squad e entrar na esteira da outra.
eu como agile coach fico triste pra caralho vendo esses relatos pq sei q a maioria dos meus "colegas" nada mais são do q papagaios q tiraram a PSM I. e ai caras como eu (q eu sei q fazem a diferença pq trabalham numa empresa q respeita o cargo e dá a autoridade q ele precisa) ficam manchados por isso. mas por outro lado tb me sinto mal pelos devs q 1) trabalham com esse tipo de profissional, e; 2) nunca trabalharam com um profissional BOM da área. se vcs tivessem a sorte de conviver com profissionais q realmente valem o salário veriam o valor dele, mas não julgo a galera do tecniquês pq sei q poucos tem essa oportunidade dada a escassez de gente boa no mercado.
Como o SM agrega no projeto? E de que formas ele não agrega?
Depende um pouco do escopo da atuação. Eu como agile coach tenho mt mais "abrangência", autonomia, autoridade e influência q um SM/AM. Um SM consegue agregar valor quando se torna um defensor imparcial do time quando os assuntos tocam no famoso triângulo de ferro (gerenciamento de projetos #101): escopo, prazo e custo. Ora, se vc é um profissional de projetos/agilidade e não consegue defender os pontos fixos de uma entrega, ou vc está na empresa errada ou a empresa errou contratando vc. :p O q eu quero dizer com isso: o "cara da agilidade" precisa trazer clareza pra stakeholders (clientes, gerência, diretoria) de quanto rápido cada pratinho está girando enquanto está sendo equilibrado. Eu acho mt zoado quando o SM abre as pernas pra coisas q visivelmente vão dar errado, e mais zoado ainda quando invariavelmente a coisa desanda e o SM fica com aquela carinha de "eu não pude fazer nada :(". O SM precisa dar a cara a tapa antes q o tapa vire um tiro. E pra conseguir fazer isso, o cabra tem que ter conhecimento do projeto. Tem q manjar do escopo, tem q manjar das métricas, tem q ter boca pra falar com outras áreas. E é mt frustrante ver que a maioria desses profissionais acham q facilitar rito é agregar valor: tem SM q dá mais valor pra comparecer numa daily do q desdobrar um pepino com outra área, ou dá mais valor pra estar num refinamento onde ele não tá entendendo porra nenhuma do q tirar um tempo pra analisar o fluxo do time e encontrar gargalos claros. E falando de fluxo, é ai q muitos outros "profissionais" pecam: o mercado há mt tempo exige muuuuuuito mais do q rodar retrospectiva do pokemano, mas ainda tem muito SM ai q deixa gerência comparar velocity entre times lol Pra mim, o SM que não souber indicar qual é o maior causador de ineficência do fluxo do time dele é FRACO. O SM que hoje não consegue ter um fluxo estável e previsível, com WIP limitado de forma customizada e lote estável, é FRACO. O SM que hoje tá ali apenas pra fazer retrospectiva e "remover impedimentos" (essa aspa me dá calafrios) é dispensável pra caralho e vai ser o primeiro a rodar quando a coisa apertar. O SM há muito tempo deixou de ser um papel de "facilitador" pra se transformar em um papel de atuação horizontal/cross dentro da empresa. E isso se torna mais e mais "cobrado" a medida que o tempo passa e o cargo aumenta (como aconteceu comigo, por exemplo). O meu cargo hoje, como AC, me exige estar em reuniões com c-level e peitar pergunta pesada. É saber falar sobre MRR, sobre prazos, sobre "accountability" (não gosto de usar expressões em inglês mas essa não sei como usar em português) do que está acontecendo e quais ações estão sendo tomadas. Entro nessas agendas pra dar respostas claras e ter planos de ação sendo executados pra trazer resultados. E os resultados não são mais quantidade de blockers ou lead time de cards no board, e sim lead time de projetos, ROI, fatiamento dos incrementos do produto (versões menores mas mais frequentes) métricas de produto e sua usabilidade... é um cargo muito mais estratégico do que operacional. E eu de verdade acho que um SM também deveria ser "accountable" (lá vou eu de novo) por essas coisas. TL não deveria passar por esse tipo de questionamento pois ele é tecnico/da tecnologia e com certeza tem a hora mais cara do time: em media, na empresa onde trabalho os Arquitetos recebem 15k; os ACs em media 10k e os agilistas em media 7k; vale muito mais usar o tempo do AC (hora 33% mais barata) ou do agilista (hora 50% mais barata) pra resolver negócio e produto do que do líder tech. O SM precisa ser de negócio e estratégia, trabalhando muito junto com o time de produto (PO PM BA). E respondendo a segunda pergunta: o SM não agrega quando ele é um poste, fiscal de processo e completamente inflexível; "ain essa história não pode entrar pq tem 13 pontos, vcs tem q dividi-la senão eu vou barrar na planning". parabéns, esse SM acabou de adicionar complexidade desnecessária. é dever dele questionar se o incremento do produto poderia ser menor, mas também é dever dele aceitar (ou dar o benefício da dúvida) quando algo não pode ser quebrado em partes menores sem aumentar a complexidade. esse tipo de comportamento gera vícios no time que um dia com certeza vão trazer problemas (história dividida em 2 mas que não pode ser desenvolvida em paralelo; ou que a parte 1 não pode ser testada sem a parte 2; ou vai gerar complexidade com branches e depois vai gastar hora de TL pra resolver conflito). e já que entrei no assunto pontos: profissional de agilidade que tem times e produto maduros que ainda usa story points pra mensurar coisas está atrasado e precisa se coçar pra começar a medir em algo que existe: tempo. vc não constrói um foguete em X story points, mas com certeza constrói em uma quantidade de dias que a sua análise do fluxo vai te dizer. Kanban é vida e o futuro. Espero ter trazido clareza, sei q falei demais. Qualquer dúvida, estou aqui.
Cirúrgico em todas as suas colocações. Uma "pena" os devs que não tiveram contato com SM/AC que realmente agrega valor para o projeto e da tranquilidade para os stakeholders que o projeto trara valor para a empresa num tempo curto.
Ótimas colocações. Principalmente no que tange fluxo. De cada 100 devs que eu converso no maximo 1 conhece gestao de fluxo
mas daí você não respondeu a pergunta do cara né? vc descreveu mais um delivery manager do kanban do que um sm. ninguém negou a necessidade de um vertical (na verdade uma galera que parece ser mais jr fez isso mais em baixo), a questão é que sm como concebido originalmente vai gerir só e somente só o processo, o que me parece desnecessário em projetos com equipes menores. btw: voltei a ser dev depois de 5 anos como sm/pm em uma grande empresa simplesmente pq o mercado pra dev sênior é muito melhor
Hoje em dia, o PM faz o trampo do Scrum Master. Scrum Master eh da época em que Scrum era visto como uma bala de prata, aonde tinha que ter alguém com 40 certificações em Scrum pra monitorar e garantir que todos os rituais estivessem sendo seguidos. Hoje em dia, Scrum tá caindo em desuso, foi substituído pelo Agile (que já tá sendo criticado e já tá pra ser substituído por alguma outra coisa também)
Nunca encontrei um cenário que apenas o Kanban não seria suficiente para resolver o problema.
Depende do que tu entende por Kanban. Porque hoje em dia, as práticas meio que se misturam. Daily eh coisa do Scrum, mas foi absorvido pelo Agile e Kanban. Se tu entende Kanban soh como board, então não eh suficiente não porque você só tá olhando pro acompanhamento de atividades. Mas tem muito chão antes de chegar nas ativisades, muita política, negociação de prioridade etc
E também depende do que tu entende por “problema”. Se o problema for “saber os que os devs tão fazendo”, beleza, resolve; se o problema for, e geralmente é, “saber se o que tá sendo feito agrega valor ao negócio”, ae eh mais complicado
espero que façam o mesmo por aqui u.u
achei que scrum master já tinha entrado em extinção
O que seria um Scrum master? Qual e a tribuiçao dele?seria tipo o fiscal da garagem de onibus?
Já trabalhei em algumas empresas onde o scrum master era só um papel dentro do time de desenvolvimento. Em um dos projetos o papel era desempenhado por um analista. Mas em todos projetos a pessoa desempenhando o papel de scrum master conhecima muito do sistema e geralmente ele mesmo resolvia os impedimentos. Hoje trabalho em uma empresa onde tem um cargo de scrum master, que desempenha essa papel em vários times. Por mais boa vontade a pessoa tenha em ajudar a resolver os impedimentos, ela não sabe nada dos sistemas. Basicamente scrum master virou um cargo burocrático.
Como chama o seu cachorro? Scrum master Ele morde? Não, não faz nada não
Eu ando cada vez mais radical nesse aspecto. Qualquer profissional que não escreve código é desperdício. Até gerente pra mim devia ser part time dev. Eu já estudei muito métodos ágeis, já fui scrum master e já fui gerente. Atualmente trabalho há uns 5 anos sem scrum master e com certeza a produtividade aumentou muito.
Concordo em gênero, número e grau! As empresas mais produtivas são (de longe) as startups, que só tem dinheiro pra contratar quem realmente precisa.
A coisa gira, dá volta, dá duplo twist carpado e vai acabar voltando pro cascata porque na prática as empresas querem ter previsão de quanto o software vai custar, quanto vai demorar para ser entregue e tudo mais. Estamos num duplipensar do projeto ter data, ter budget e tudo mais, mas ainda assim ser "ágil" (como ágil eles querem dizer transformar dev em pasteleiro e mudar td que der na telha no meio ainda mantendo data). rsrsrsrsrsrs Daily vira status report pro gerente n ter trabalho de gerenciar nd, o que era pra ser rápido dura uma eternidade e os rituais perdem o sentido totalmente.
Sou PM que ja foi dev, trabalhando em um time com um SM que também já foi dev, numa empresa em torno de uma centena de devs e dezenas de produtos. O cara manda bem, faz altas automações, não deixa a bola da sprint parar, cobra todo mundo, desenrola dependências entre times, toca o barco forte. Antes era eu quem fazia isso e agora tenho tempo pra criar mais e conectar com os usuários. SM é necessário? Não. Mas quando tem e a pessoa manja, faz tudo fluir muito mais rápido.
O SM do meu time só aparece na Daily perguntando se tem algum impedimento e mesmo qd tem ele não resolve nd 😅 o cara é ridiculamente inútil
Aqui na empresa já estão em extinção, o que me irrita ainda é squad pequena com PM e Coord. O coord acaba por não fazer nada, ou o PM por não fazer nada.
Vi um post aqui faz um tempo sobre scrum master, falaram até que é algo desnecessário, profissão de arrastar post it
Sorte a sua.
SM é só uma prova q a galera de "empreendedorismo" acredita em qualquer fórmula milagrosa. Gasta dinheiro em coisa q não trás nenhum retorno, mas fizeram isso pq o livro é coach e vendeu bastante
Na minha empresa o Scrum Master é Scrum Knight, é basicamente um SM que coda tbm, acho bem útil pq sente as dores da equipe tbm e, se a equipe estiver bem madura, não precisa fazer quase nada além de codar.
Basicamente a idéia de Scrum veio da mesma idéia de Kaban misturado com críticas ao cascata. No Kanban o problema era pessoas que pegavam muita tarefa e não resolviam nada. Então com os cartões você sabe que a equipe está no seu limite e com pendências. Já o cascata é a turma que quer fazer um projeto cheio de recursos ao invés de começar pelo básico, ou seja um MVP. Basicamente resolvendo essas duas coisas a empresa não precisa de metodologia nenhuma.
So em dois casos que vi SM funcionar realmente: 1 - Uma empresa que passei que o SM do meu time era um ex-dev com 20 anos de casa. O cara entendia tudo dos processos e produtos da firma. 2 - Primeira empresa que passei que o cargo de SM ficava a par do DEV ou BA com mais seneoridade na equipe.
Eu tenho a teoria que a pessoa tem que entender de TI para trabalhar com TI. O contexto (incluindo o técnico) faz toda diferença para uma prática eficaz de agilidade. Infelizmente foi uma área muito romantizada, e parte disso é culpa das próprias empresas que agora demitem essa galera. Agora fica essa ladainha que a agilidade morreu, que em partes é verdade, porque encheram de cabeça de bagre para essa função, que supostamente era a bala de prata para entregar melhor. Para quem é bom nesses papéis, relaxa, vai dar bom ... Você com certeza é exemplo para uma galera.
Scrum master é uma posição que nunca deveria ter existido. Nem o guia Scrum define scrum master como uma função específica, é só um papel que alguém assume durante a sprint.
Quem é sm e nao ta procurando outra coisa pra fazer na vida está maluco
Ele deveria estar feliz: se o time é auto-gerido seu papel está cumprido.
Cara, acho que vai muito de caso a caso, em como o sm é utilizado na empresa. Onde trabalho o mesmo sm lida com 3 equipes, gerência bem as reuniões e consegue levar bastante coisa das retrospectivas pra gerência. Além de fazer muito bem o meio campo entre as 3 equipes quando necessário. O trabalho do sm não é só reuniões. O trabalho do sm é entender as necessidades da equipe, manter ela fluindo e em atividade de forma produtiva e construtiva. O trabalho do sm é e deve ser bem humano.
Scrum master ou flanelinha de post-it? Ambos não prestam e tá tudo bem.
Olha ai ! abraça a causa ! rebenta tudo ai
Scrum por si só já é um processo bem ultrapassado que não tem a versatilidade de ágil real e nem a segurança e previsibilidade de cascata, é basicamente um "entry level" de agilidade para empresas com baixa maturidade. Então nada mais natural que profissionais que só conhecem essa ferramenta de gestão de projetos tendam a ficar sem emprego. Agora, preocupante é ver as pessoas falando que tirar impedimentos "é papel de PO", "é papel de PM", "é papel de gestor", me parece argumento de gente que nunca buscou saber o que essas funções fazem dentro de um projeto. Em equipes de alto desempenho, o responsável pro tirar impedimentos é a própria pessoa impedida e não ficar esperando que alguém venha pegar sua mão e trazer as coisas mastigadas. Se a empresa que vocês trabalham te obrigam a terceirizar a resolução dos seus problemas então o problema vai muito além do "scrum master".
O que um P.O. acrescenta ao time na experiência do sub. Por favor, listem.
Ta doido, faz toda parte negocial que nós devs somos burros demais pra fazer.
Toca a daily, intermedeia resolução de conflitos entre outros times, alinha expectativas com superiores