É uma boa idéia nomear um membro da equipe de scrum ou scrum master como Dono do produto?

Ultimamente tivemos um projeto, no qual o cliente estava ocupado em turnê. Como a equipe de scrum habitual foi formada, a gerência decidiu nomear nosso analista como proprietário do produto, uma vez que o cliente não poderá participar ativamente. Foi o analista que trabalhou em estreita colaboração com o cliente na análise de requisitos e elaboração de especificações.

O cliente não tem tempo para revisar os dois primeiros lançamentos. Tudo correu bem até que o cliente viu o terceiro lançamento; ele não estava satisfeito com algumas funcionalidades, e essas foram introduzidas pelo proprietário do produto turn shift (nosso analista).

Disseram-nos que esperássemos até que a equipe de design terminasse o mock-up de todas as páginas e o cliente verificasse cada uma delas e aprovasse continuar trabalhando. A equipe Scrum está lá, mas não há sprints - terminamos o trabalho quase como o método clássico de cascata.

É uma boa idéia nomear um membro da equipe do scrum ou mestre como proprietário do produto? Precisamos seguir o scrum na ausência de participação do cliente / proprietário do produto?

Apenas algumas semanas atrás, Mike Cohn escreveu sobre a combinação de papéis de mestre de scrum e proprietário de produto em seu blog. Eu não acho que posso colocá-lo melhor do que ele, mas meu breve resumo de seu post é o seguinte:

• É uma má idéia
• SM e PO executam tipos muito diferentes de tarefas ("tarefas em estrela" e "tarefas de guardião" nas palavras de Cohn)
• é improvável que a pessoa que combina os dois papéis seja adequada para todas as tarefas envolvidas nos dois papéis
• a equipe pode ser prejudicada pelo SM / PO combinado, negligenciando as tarefas em que não são as melhores.

Acho que não há nada errado em levar qualquer membro de uma equipe de scrum e transferi-lo para o Product Owner. Mas você precisa perceber que é como uma promoção ou uma transferência interna; ele cria um buraco na equipe e o buraco precisa ser preenchido. Talvez a equipe possa se auto-reorganizar para preencher o buraco; talvez seja necessário contratar um novo funcionário para preencher a vaga.

Seu processo parece bom para mim. Você não o descreveu em detalhes, mas pelo menos os papéis são respeitados (isso é importante).

No entanto, com os poucos detalhes que tenho, vejo algum problema no nível do proprietário do produto.

Ele / ela deve garantir que o cliente seja devidamente notificado do progresso. Parece que ele está fazendo "cascata" externamente com o cliente e "scrum" internamente com você.

Resultado : a cachoeira vence porque o cliente é rei. Mesmo que neste caso, o cliente seja responsável ...

Sua equipe atual (incluindo Scrum Master) deve se concentrar em fornecer o backlog do sprint. No entanto, o proprietário do produto (analista) deve garantir que o que está em seu backlog reflita o que o cliente deseja. Ela / ele também deve garantir que a comunicação seja boa e que o cliente participe.

Solução possível : envie o proprietário do produto (analista) para um curso Scrum Product Owner , ou faça-o ler (e entender) este livro: Gerenciamento Ágil de Produtos com Scrum .

O Scrum funciona melhor com um cliente real. Existem alguns desafios reais ao lidar com clientes que não estão acostumados ao design de produto iterativo.

• A síndrome da folha em branco
• Síndrome do cliente assustado

Os estágios de design com uma folha em branco tendem a aparecer rapidamente no céu, e costumam ter grande profundidade em algumas questões secundárias e pouca profundidade na funcionalidade básica necessária. Você realmente precisa de um homem de palha para o cliente separar para que as reuniões de design sejam bem-sucedidas. Ao se concentrar em apenas um aspecto de cada vez, você está ajudando seu cliente a aprender o design iterativo.

Clientes assustados (como você teve com sua experiência) não percebem que projetos ágeis antecipam uma certa quantidade (controlada) de retrabalho como parte do processo. O que eles têm dificuldade em entender é que, à medida que o desenvolvimento do produto avança, haverá menos momentos "Oh meu Deus". Mais importante, a parte com a qual a maioria dos clientes tem dificuldade é que os momentos do tipo "Oh meu Deus" não exigem muito dinheiro para consertar devido ao pouco tempo entre os ciclos de revisão / planejamento.

Gerenciar as expectativas do cliente é muito difícil. É um bom equilíbrio entre educação do cliente, apaziguamento e até mesmo aprendendo a dizer "não". O cliente nem sempre pode vir semanalmente ou quinzenalmente. Às vezes, eles só podem vir uma vez por mês. Isso está ok. Desde que você mostre a eles o que você fez para lidar com as preocupações deles no mês anterior, depois se concentre no trabalho deste mês, será um longo caminho para tornar o projeto mais tranquilo. Resumindo, na ausência do cliente, você tem alguém que pode fazer recomendações razoáveis ​​para algumas perguntas. Precisa ser alguém familiarizado com os objetivos que o cliente está tentando alcançar.

Idealmente, o proprietário do produto tem algum nível de autoridade e conhecimento sobre o projeto. O mesmo poderia ter acontecido se o cliente designasse um funcionário de nível inferior que seria então substituído em uma fase posterior, exigindo que você quase começasse de novo.

Obrigado pela sua postagem. Sei que é velho, mas acho que você levantou um ótimo caso e aqui estão meus $ .02:

Problema 1: nomear o analista como OP no seu caso causa um curto-circuito sério na estrutura do scrum. Por quê? Porque apenas o OP pode fazer julgamentos de valor, avaliações de ROI, priorização e escolhas decisivas que fluem dos negócios, não da tecnologia, nem mesmo da familiaridade com o produto. Tenho certeza que seu sr. O analista fez um trabalho fantástico imitando o pedido, mas finalmente teve que adivinhar os desejos, valores e escolhas que viriam do pedido. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . A menos que seu analista tenha recebido POA do cliente (improvável), ele não estaria em posição de aceitar ou rejeitar nada na revisão do sprint.

Essa abordagem poderia funcionar? Sim, mas seria necessário haver uma transferência total de responsabilidades enquanto seu cliente estava fora. O chefe do seu cliente precisaria concordar com o substituto e que nenhuma decisão razoável tomada seria revertida. Parece provável? É mais provável que você receba um pedido temporário da organização do seu cliente (o que certamente não está isento de desvantagens!) Mas se o seu sr. analista trabalhou com o pedido temporário, qualquer decisão incorreta viria do negócio, mantendo assim as funções de sua equipe.

Problema 2: "o cliente não tem tempo para revisar". Grande problema (e um que eu encontrei recentemente também). O pedido deve estar presente para aceitar o produto. Ninguém mais pode 'assinar o cheque'. A ausência de OP significa insatisfação depois, potencialmente mais retrabalho e perda de confiança. Mais fundamentalmente, sinto que o cliente não está envolvido ativamente no seu projeto: não há tempo para o stand up diário, não há tempo para responder perguntas etc.

Problema 3: "nos disseram para esperar até a equipe de design terminar o mock-up". E agora estão completamente fora de controle. As pessoas que fazem o mock-up devem fazer parte de sua equipe multifuncional. Não sei dizer se isso é causado pela falta de entendimento da gerência sobre o scrum ou uma reação de choque ao seu terceiro lançamento.

Pergunta: Onde estava o seu scrum master em tudo isso? O SM normalmente reconheceria o perigo do conflito de papéis e a falta de participação da OP, ambos obstáculos / perigos a serem enfrentados.