Quais são os erros comuns em 'abordagens Scrum adaptadas'? [fechadas]

Movido dos comentários ...

Já pensou em tentar e ver como funciona antes de fazer lobby contra isso? Enquanto eles estiverem abertos para adaptar a estrutura ao longo do tempo, eu não vejo nenhuma falha fatal nesse plano, a não ser que ela não siga o dogma Ágil ao pé da letra.

Outra coisa a considerar é que você deseja incorporar o suficiente das idéias do líder de negócios na abordagem para que elas se sintam responsáveis pela adoção do Agile. Se o fizerem, eles serão investidos em garantir que seja bem sucedido em vez de menosprezá-lo (porque sua abordagem teria sido melhor) se as coisas ficarem de lado. E inevitavelmente vai para os lados, especialmente no começo. As pessoas geralmente são resistentes a mudanças e muitas vezes são desajeitadas por um tempo quando são forçadas a adotar uma nova maneira de fazer as coisas.

Tornar a gestão um parceiro no processo e não um adversário.

O Gerente de Desenvolvimento e, até certo ponto, o ScrumMaster são variações do papel tradicional do líder em tecnologia. Eu não vejo o Gerente de Desenvolvimento necessariamente tendo mais ou menos comando e controle como você diz, do que um típico líder de tecnologia.

O Scrum Master é um pouco mais especial do que isso. O Gerente de Desenvolvimento também não deve ser o Scrum Master, mas não há razão para que o Scrum Master não seja apenas o PM, já que eles têm mais interesse em timesheets. O tempo de rastreamento em um cronograma do projeto não é disjuntivo com o conceito de Histórias do Usuário, Pontos e Gráficos Burndown.

Você meio que tem um ponto sobre a função de agente do proprietário do produto. Eu não vejo uma pessoa nesse papel tendo qualquer responsabilidade única e clara além de ser um elo adicional na cadeia de comando.

O Product Owner é ridiculamente importante. Ele é dono do produto. Não vou explicar a importância disso, mas se você já trabalhou em um projeto onde não havia um dono de produto claro, porque os gerentes intermediários eram muito fritos - $$$$ para assumir qualquer propriedade da direção do PRODUTO e decisões sobre o PRODUTO, então você verá como ele sabota completamente todos os projetos antes mesmo de começar.

Você precisa deles para diferenciar como a empresa é estruturada e como as pessoas em um processo de desenvolvimento de scrum são estruturadas. Isso é bom para um organograma.

Para um projeto de ERP muito grande, você pode ter uma seção quase separada com seus próprios proprietários de produtos. Eles podem se reportar a alguém, mas do ponto de vista do Scrum, é preciso que haja um proprietário de produto trabalhando com o grupo designado para essa parte do projeto.

O gerente de desenvolvimento é mais a pessoa que pode fazer as avaliações, organizando dias de folga e outros deveres de gerente que não têm nada a ver com desenvolvimento.

Apenas mostre como você separa os dois. Não há motivos para que pequenos grupos scrum não possam existir em uma grande corporação. Você precisa saber onde as pessoas se encaixam nos dois mundos.

Na verdade não é tão longe assim. Depende dos papéis de certas pessoas.

• Pode haver mais de uma pessoa em uma equipe que preencha o papel de Dono do Produto (como na entidade de tomada de decisão responsável pela geração, priorização e aceitação de requisitos). Em grandes projetos, uma pessoa simplesmente não pode fazer tudo. O importante é que haja um único caminho de comunicação de e para o Dono do Produto, para o qual as perguntas são direcionadas e de onde vêm as diretrizes de requisitos, embora muitas pessoas estejam por trás delas (ou mesmo na frente delas) ajudando no processo. Em resumo, sempre deve haver um cara com quem você possa fazer uma pergunta, não importa com quem ele fala para obter a resposta ou com quem ele comunica a resposta. Então, se o agente é simplesmente alguém da "equipe" de propriedade do produto que participa como um frango nos IPMs e em levantamentos diários, e reporta de volta ao PO, tudo bem; o PO não pode estar em todo lugar. Se for uma pessoa capaz de tomar decisões independentemente de outros agentes ou do Product Owner, ou quem é designado para restringir o acesso ao PO, isso pode ser um problema.

• O gerente de desenvolvimento parece ser "gerente de projetos" ou "líder de equipe" para mim. Também poderia ser "Arquiteto", que é o responsável por manter uma boa estrutura de design e decidir os padrões de nível corporativo a serem seguidos no desenvolvimento de certas áreas. Normalmente, há apenas um Arquiteto, como se houvesse apenas um Dono do Produto, portanto, se esse cara é um "Gerente de Projeto" ou "Arquiteto", ele deve ser um trabalho de equipe cruzada, não um por.

• Não vejo BAs neste gráfico. No meu último trabalho Ágil, os BAs receberam e revisaram as matérias-primas, determinadas dependências que criariam conflitos de cronograma e um "caminho crítico", e geralmente também faziam algum controle de qualidade. Eles também eram os que mais telefonavam ao PO. Isso liberou as equipes de codificação para fazer o que eles fazem melhor - codificação heads-down.

A ideia de quadros de horários em oposição a uma burndown para acompanhar o progresso parece estranha. Parece que o contrato foi negociado por tempo e materiais, e eles querem tempo, não uma estimativa de tempo com base na complexidade dos pontos. Tudo bem, até certo ponto, mas o ponto do Agile é que seus clientes preferem pagar por ponto em vez de por hora; um ponto é uma unidade de trabalho que pode ser calibrada e, quando estiver pronto, você tem um produto real que deve valer esse valor como uma fração de todo o projeto.

Eu não acho que isso é óbvio que as coisas vão falhar.

There are product owner agents (an obvious WTF), who report to the product owner: causing dilution of decision making capability

Assumindo que alguém precisa representar o cliente (no caso em que o cliente real está ausente) isso não é um erro. No entanto, o critério de sucesso é a visualização das necessidades reais do cliente.

There is a role that looks similar to a manager in the traditional approach - development manager: an obvious attempt at command-and-control model

Isso geralmente acontece quando um tech guy tradicional não é sênior o suficiente (ou sabe ser bom o suficiente para fazer gerente de projetos, mas conhece a maioria das coisas tecnológicas melhor do que a maioria. A diferença real vem com base no que eles realmente fazem.

The ScrumMaster's role includes collecting timesheets, which are used to track progress instead of burndown charts: detrimental to agile's efforts to build teams with motivated individuals

Isso soa surpreendente embora. No entanto, acredito que as empresas de software mais tradicionais não podem se livrar de quadro de horários . Donno porque. Mas não há alternativa para rastrear o projeto do ponto de vista de

Existem alguns critérios que farão ou quebrarão as coisas.

1. Os desafios reais do Agile não são o processo e a precisão com os quais se aderem. O verdadeiro desafio é quando você começa o ritual puro em vez de ajudar a simplificar processos para os desenvolvedores, para que eles possam se concentrar no que fazem de bom - programação!

2. Conhecendo a necessidade real e iterativamente indo melhor nisso. O que você precisa é obter clareza (e transparência) em todas as pessoas e compromisso pessoal de todos para alcançar os objetivos certos.

É claro que existem 12 princípios básicos que você deve conhecer. Meu ponto é seguir esse conceito central - você pode fazer um trabalho ágil sob qualquer estrutura organizacional.

Se estas coisas básicas falharem, tudo irá falhar - senão tudo o resto é bom.