Os gerentes de projeto são úteis no Scrum?

Existem três funções definidas no Scrum: Equipe, Dono do produto e Scrum Master. Não há gerente de projeto; em vez disso, o trabalho de gerente de projeto está distribuído pelas três funções .

Por exemplo:

• O Scrum Master: Responsável pelo processo. Remove impedimentos.
• O proprietário do produto: gerencia e prioriza a lista de trabalhos a serem realizados para maximizar o ROI. Representa todas as partes interessadas (clientes, partes interessadas).
• A Equipe: Autogerencie seu trabalho estimando e distribuindo entre si. Responsável por cumprir seus próprios compromissos.

Portanto, no Scrum, não há mais uma única pessoa responsável pelo sucesso do projeto. Não existe uma estrutura de comando e controle em vigor. Isso parece confundir muitas pessoas, especificamente aquelas que não estão acostumadas a métodos ágeis e, é claro, PMs.

Estou realmente interessado nisso e em quais são suas experiências, pois acho que essa é uma das coisas que pode fazer ou interromper uma implementação do Scrum.

Você concorda com o Scrum que um gerente de projeto não é necessário? Você acha que esse papel ainda é necessário? Por quê?

Talvez você deva apresentar coisas como esta:

O gerente de projeto não desapareceu no Scrum . Ele ainda está lá. Há três deles agora!

• O Scrum Master : ele gerencia o processo e resolve impedimentos. Essa era a responsabilidade do gerente de projetos antes.

• O Dono do Produto : ele gerencia a lista de pendências. Essa era a responsabilidade do gerente de projetos antes, quando ele previu tudo no Microsoft Project.

• A Equipe : autogerencia sua produção. Quem e como uma determinada história de usuário é convertida em um incremento de produto potencialmente liberável. Essa era a responsabilidade do gerente de projeto quando ele atribuiu tarefas.

Para mim, isso vem da falta de compreensão do que o gerente de projetos faz e da natureza bastante genérica do título do PM. Não sou especialista em SCRUM, mas sempre vi o SCRUM Master substituindo o gerente de desenvolvimento / líder da equipe, e não o gerente de projetos.

Os gerentes de projeto (conforme definidos por metodologias como o PRINCE2 - que é praticamente compatível com as metodologias ágeis) realmente não têm nada a ver com o processo de desenvolvimento, eles estão cuidando do projeto de uma perspectiva de entrega mais ampla, cobrindo mais do que apenas a TI Construir. Há muitas coisas na função de gerente de projetos que não são abordadas em nenhum outro local do Scrum (gerenciamento e monitoramento do caso de negócios, gerenciamento de partes interessadas nos negócios, elementos do projeto fora da construção de TI, como reformulação de processos de negócios, suporte, treinamento e assim por diante).

Se o seu gerente geral é o cara que cuida dos desenvolvedores e não faz muito mais do que isso (por exemplo, em projetos que são amplamente de TI apenas onde o escopo é muito bem definido), pode ser que ele não seja necessário em um projeto SCRUM.

Mas antes que alguém diga que você não precisa de um PM para o SCRUM, eu quero uma explicação bastante clara de como os elementos que não são de TI do projeto estão sendo cobertos e, em particular, quem está gerenciando o caso de negócios (porque os usuários querem isso e sendo algo que deve ser feito são coisas diferentes).

Pode ser que o PM acabe ocupando mais o lado comercial do projeto - o Dono do Produto pode muito bem assumir mais o papel do PM do que o Scrum Master, mas acho improvável que ele se perca completamente.

Existem algumas coisas que um gerente de projeto pode fazer que um Scrum Master ou Product Owner talvez não consiga.

• Os gerentes de projeto geralmente têm uma vasta experiência na execução de projetos (surpresa!).
• Eles estão cientes das armadilhas comuns e podem identificá-las e ajudá-las a evitá-las antes que elas aconteçam.
• Eles geralmente são negociadores experientes e podem apoiar outros membros da equipe em discussões sobre prazos, escopo e requisitos conflitantes (muito importante se a OP for relativamente nova na função).
• Eles podem gerenciar o dinheiro. Eles têm o poder de contratar e demitir e podem ajudar se alguém da equipe for incapaz de desempenhar seu papel (organizando treinamentos, aconselhando etc.).
• Eles podem ajudar a garantir que o projeto se encaixe efetivamente em um programa de trabalho maior.
• Eles podem tirar as coisas do caminho da equipe.
• Eles podem ajudar a orientar as políticas da empresa para serem eficazes ao lado do Scrum (por exemplo, se os testadores ainda estiverem sendo medidos pelo número de bugs encontrados).
• Eles podem gerenciar a governança.
• Eles podem mover os móveis.
• Seu vocabulário é o da empresa maior, e eles podem discutir o projeto - e a abordagem Scrum - em termos de risco, impacto, ROI, opções e diferenciação.
• Eles podem explicar à diretoria por que a transparência repentina e as notícias ocasionais de falhas, vindas de um mar de relatórios verdes, são boas e úteis de se saber.
• Uma boa PM pode ajudá-lo a se sentir seguro, parecer legal e ter uma ótima aparência.

O Scrum não exige um PM. Mas você pode querer ter um de qualquer maneira.

Em um dos projetos em que trabalhei, quando ele se transformou no Scrum, nosso gerente de projetos anterior assumiu alternativamente as funções de Product Owner e Scrum Master. Funcionou nos 6 meses que passei com essa equipe, embora não fosse o ideal (para mim). Ele era o tipo de cara que queria manter as coisas sob controle rígido, mas o fazia razoavelmente bem (ou seja, deixar a equipe fazer seu trabalho e tomar suas decisões quando apropriado).

O pano de fundo disso foi que a empresa estava em uma situação financeira terrível, embora nós (a equipe) soubéssemos disso apenas algum tempo depois. Portanto, havia um motivo para manter tudo sob controle rígido, para garantir que apenas o material absolutamente necessário estivesse sendo construído e a primeira versão do produto fosse entregue no prazo.

Eu seria justo e diria que, na minha opinião, o que funciona para mim é o mestre Scrum atuando também como gerente de projetos. Ser um Scrum Master não é um trabalho de período integral - uma vez que a equipe está madura, o Scrum Master não precisa nem comparecer aos levantamentos diários.
Há cada vez mais vagas que eu vejo para um gerente de projetos / Scrum Master em que as empresas não desejam diferenciar essas funções - e sim a mesma pessoa que lida com as duas funções - ou seja: um gerente de projeto ágil.

Gerente de projeto: uma função dentro de uma organização ou empresa tradicional.

Scrum master: um papel dentro de uma equipe de desenvolvimento de software usando a metodologia Scrum.

Falar sobre gerente de projeto e scrum master é realmente falar de maçãs e laranjas porque as funções têm contextos diferentes. Eu nunca ouvi falar de uma organização que tenha "Scrum master" como título oficial ou nota de pagamento. E os gerentes de projeto de qualquer projeto, Scrum ou não, geralmente são um pouco removidos das atividades diárias de desenvolvimento de software.

Exatamente o que um gerente de projeto faz e o quanto sua função se sobrepõe à de um mestre do Scrum ou proprietário do projeto depende muito do tamanho e da natureza do projeto, mas certamente há tarefas normalmente atribuídas a um gerente de projeto que não são especificamente parte das funções de mestre do Scrum ou proprietário do projeto. Em um projeto pequeno, pode ser possível expandir as funções das funções de mestre do Scrum ou proprietário do projeto para incluir essas tarefas (contratação, demissão, compra, gerenciamento de contratos, interface com executivos de nível superior, etc.). Em um projeto maior, o desenvolvimento de software é apenas uma parte do gerenciamento de projetos, e é improvável que os deveres do gerente de projeto e do Scrum master se sobreponham.

Um gerente de projeto deve ser a interface do Scrum master para a organização. O Scrum master deve ser a interface do gerente de projeto para a equipe.

Então, os gerentes de projeto são úteis no Scrum? Não, os gerentes de projeto são úteis fora do Scrum. Eles não fazem parte da metodologia de desenvolvimento de software Scrum, mas fornecem os recursos que permitem ao Scrum funcionar.

Esta questão cheira a Scrumbut .

Scrum é um subconjunto do que está contido em um método de gerenciamento de projetos (Prince2 / PMP etc). De fato, se você observar o processo MP do Prince2 (gerenciamento da entrega do produto), todos os elementos do Scrum podem estar contidos nele.

O Scrum Master não deseja ficar atolado em reuniões com fornecedores, pessoal, jurídico, finanças, fornecedores, executivos ou atividade da BAU . Eles precisam se concentrar em remover os impedimentos da equipe no sprint atual, sem negociar quanto uma agência de emprego pode reduzir as taxas de contratados no EF2011 / 12 ou validar o contrato de garantia com o fornecedor x.

Se o seu Scrum Master estiver fazendo o procedimento acima, você não está executando o Scrum, está executando o Scrumbut.

Por experiência, a melhor combinação é ter um Scrum Master para cada líder de equipe e um gerente de projeto para coordenar os mestres do scrum da maneira Scrum. Ter um gerente de projeto nessa função mais eficaz devido aos motivos mencionados acima e à profundidade de sua experiência. Por sua vez, esses gerentes de projeto se reportam a um Gerente de Portfólio / Programa etc. e todos na cadeia de comando são pelo menos Scrum Masters certificados.

Lembre-se de que o Scrum é uma ferramenta para gerenciar a entrega de produtos, em uma camada de abstração pode ser usada para executar projetos, mas já existem processos muito melhores para isso.

Um dos principais problemas da função tradicional de gerente de projetos é que ela separa autoridade e responsabilidade. O PM tem total autoridade sobre a organização do projeto - ele decide quais tarefas precisam ser executadas, por quem, em que ordem, etc. Mas ele não é responsabilizado pela conclusão dessas tarefas ou pela qualidade do software isso é produzido. Os membros da equipe são os únicos responsáveis. Isso cria uma enorme sobrecarga de comunicação; para colocar de volta autoridade e decisão em sincronia com o trabalho operacional, os membros da equipe precisam constantemente relatar tudo o que é feito ao PM, além do restante da equipe. Também cria um sentimento de desapropriação, impotência e perda de propósito com os membros da equipe, o que é uma grande fonte de frustração e desânimo.

O Agile, de alguma forma, junta essas noções - a autoridade sobre a organização do trabalho é mantida pela equipe como um todo (por meio de liberação, iteração e reuniões diárias), para que todos sintam que podem ter uma opinião sobre o assunto, em troca da qual cada um deles os membros da equipe devem assumir a responsabilidade pela produção de software de qualidade que funcione e se comprometer fortemente com esse objetivo. Assim, teoricamente, você poderia se livrar do gerente de projetos.

Uma vez que você disse isso, ainda existem tarefas tradicionalmente designadas para o PM que ainda precisam ser cuidadas - o lunívoro as descreveu com bastante precisão.

Como este artigo sugere, em equipes verdadeiramente qualificadas, uma coisa que você pode fazer é descartar a função de gerente de projeto, redistribuir suas funções entre os membros da equipe e fazer com que ex-PMs se tornem membros regulares da equipe.

As funções do Scrum são bastante bem definidas (se parecem vagas, é porque devem ser aplicáveis ​​em diferentes tipos de organizações) e, como as equipes do Scrum são sempre (bem, comumente) do mesmo tamanho - ou seja, não são muito grandes - é relativamente fácil concordar com o que eles abrangem, mesmo que isso varie dependendo da organização subjacente.

Lendo a pergunta, respostas e comentários acima, parece óbvio que a definição da função de gerente de projeto é muito mais difícil de definir. Tenho certeza de que você pode encontrar uma definição geral agradável e compendita do papel de um gerente de projetos, mas o que isso realmente significa na vida real é uma história totalmente diferente.

De qualquer forma, como funciona no meu trabalho, os gerentes de projeto raramente se envolvem com o "Scrumming" real. Eles não podem ser mestres do Scrum (uma regra local de conflito de interesses com a qual todos estamos muito felizes), e eles são apenas proprietários de produtos em casos excepcionais.

Então, onde eu trabalho, os gerentes de projeto ainda estão lá, fazendo praticamente o que sempre fizeram. Isso significa que eles mantêm o projeto nos trilhos, atuam como um filtro contra demasiadas tendências de paranóia e microgerenciamento "acima", resolvendo problemas que precisam de mais influência do que possuímos para resolver, e assim por diante.

Tenho certeza de que isso é bem diferente em outros lugares, mas para nós funciona muito bem.

Edit : Talvez eu deva esclarecer que, para nós, uma equipe Scrum não substitui uma equipe de projeto. Uma ou mais equipes Scrum são iniciadas para executar o trabalho de desenvolvimento real para (e geralmente em) um projeto. A (s) equipe (s) Scrum (s) podem (e provavelmente sempre o fazem) consistir nos antigos membros da equipe, exceto pelo líder do projeto :-)