Est-ce une bonne idée de nommer un membre de l'équipe Scrum ou un Scrum Master en tant que Product Owner?

Dernièrement, nous avons eu un projet, dans lequel le client était en tournée. Comme l'équipe Scrum habituelle a été formée, la direction a décidé de nommer notre analyste en tant que Product Owner car le Client ne pourra pas participer activement. L'analyste était celui qui travaillait en étroite collaboration avec le client pour l'analyse des exigences et la rédaction des spécifications.

Le client n'a pas le temps d'examiner les deux premières versions. Tout s'est bien passé jusqu'à ce que le client ait vu la troisième version; il n'était pas satisfait de certaines fonctionnalités, et celles-ci ont été introduites par Make shift Product Owner (notre analyste).

On nous a dit d'attendre que l'équipe de conception ait terminé la maquette de toutes les pages et que le client ait vérifié chacune d'elles et approuvé de continuer à travailler. L'équipe Scrum est là, mais pas de sprints - nous avons fini de travailler presque comme la méthode classique en cascade.

Est-ce une bonne idée de nommer un membre ou un maître de l'équipe Scrum en tant que propriétaire du produit? Faut-il suivre scrum en l'absence de participation du client / propriétaire du produit?

Il y a seulement quelques semaines, Mike Cohn a écrit sur la combinaison des rôles Scrum Master et Product Owner sur son blog. Je ne pense pas pouvoir le dire mieux que lui, mais mon bref résumé de son message est le suivant:

• C'est une mauvaise idée
• SM et PO exécutent des types de tâches très différents («tâches étoiles» et «tâches de gardien», selon les mots de Cohn)
• il est peu probable que la personne combinant les deux rôles convienne à toutes les tâches impliquées dans les deux rôles
• l'équipe peut être blessée si le SM / PO combiné néglige les tâches pour lesquelles elle n'est pas la meilleure.

Je pense qu'il n'y a rien de mal en soi à emmener un membre d'une équipe Scrum et à le déplacer vers le Product Owner. Mais vous devez réaliser que c'est comme une promotion ou un transfert interne; cela crée un trou dans l'équipe et le trou doit être rempli. Peut-être que l'équipe peut "se réorganiser" pour combler le trou; il doit peut-être embaucher un nouvel employé pour combler le poste vacant.

Votre processus me semble bien. Vous ne l'avez pas décrit en détail, mais au moins, les rôles sont respectés (c'est important).

Cependant, avec les quelques détails dont je dispose, je peux voir un problème au niveau du propriétaire du produit.

Il / elle doit s'assurer que le client est correctement informé de l'avancement. On dirait qu'il fait de la «cascade» en externe avec le client et de la «mêlée» en interne avec vous.

Résultat : la cascade gagne puisque le client est roi. Même si dans ce cas, le client a sa responsabilité ...

Votre équipe actuelle (y compris Scrum Master), devrait se concentrer sur la livraison du backlog de sprint. Cependant, le propriétaire du produit (analyste) doit s'assurer que ce qui se trouve dans son carnet de commandes reflète ce que le client veut. Elle doit également s'assurer que la communication est bonne et que le client participe.

Solution possible : envoyez votre propriétaire de produit (analyste) à un cours Scrum Product Owner ou faites-lui lire (et comprendre) ce livre: Agile Product Management with Scrum .

Scrum fonctionne mieux avec un vrai client en place. Il y a quelques vrais défis dans le traitement des clients qui ne sont pas habitués à la conception itérative de produits.

• Le syndrome du drap blanc
• Syndrome du client effrayé

Les étapes de conception avec une feuille vierge ont tendance à aller très vite dans le ciel, et vont généralement en profondeur sur quelques problèmes latéraux et pas assez en profondeur sur les fonctionnalités de base nécessaires. Vous avez vraiment besoin d'un homme de paille pour que le client se sépare pour que les réunions de conception se déroulent avec succès. En vous concentrant sur un seul aspect à la fois, vous aidez votre client à apprendre la conception itérative.

Les clients effrayés (comme vous l'avez fait avec votre expérience) ne réalisent pas que les projets agiles anticipent une certaine quantité (contrôlée) de retouches dans le cadre du processus. Ce qu'ils ont du mal à comprendre, c'est qu'à mesure que le développement du produit avance, il y aura moins de moments "Oh mon dieu". Plus important encore, la partie avec laquelle la plupart des clients ont du mal, c'est que les moments "Oh mon dieu" ne nécessitent pas de grosses sommes d'argent à réparer en raison du peu de temps entre les cycles d'examen / de planification.

La gestion des attentes des clients est très difficile. C'est un bon équilibre entre l'éducation des clients, l'apaisement et même l'apprentissage du «non». Le client ne peut pas toujours venir toutes les semaines ou toutes les deux semaines. Parfois, ils ne peuvent venir qu'une fois par mois. C'est bon. Tant que vous leur montrez ce que vous avez fait pour répondre à leurs préoccupations le mois précédent, puis que vous vous concentrez sur le travail de ce mois-ci, cela contribuera grandement à rendre le projet plus fluide. En bout de ligne, en l'absence du client, vous avez quelqu'un qui peut faire des recommandations raisonnables pour certaines questions. Il doit s'agir d'une personne familière avec les objectifs que le client essaie d'atteindre.

Idéalement, le propriétaire du produit a un certain niveau d'autorité et de connaissances sur le projet. Cette même chose aurait pu se produire si le client avait affecté un employé de niveau inférieur qui avait ensuite été renversé à une phase ultérieure, vous obligeant à presque recommencer.

Merci pour votre message. Je me rends compte que c'est vieux, mais je pense que vous avez soulevé un grand cas et voici mes 0,02 $:

Problème 1: nommer l'analyste comme PO dans votre cas court-circuite sérieusement le cadre Scrum. Pourquoi? Parce que seul le PO peut faire des jugements de valeur, des évaluations de retour sur investissement, des priorités et des choix décisifs qui découlent de l'entreprise, pas de la technologie, ni même de la familiarité avec le produit. Je suis sûr que votre sr. L'analyste a fait un travail fantastique en imitant le bon de commande, mais a finalement dû deviner les désirs, les valeurs et les choix qui proviendraient de votre bon de commande. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . À moins que votre analyste n'ait obtenu un POA du client (peu probable), il ne serait pas en mesure d'accepter ou de rejeter quoi que ce soit lors de la revue de sprint.

Cette approche pourrait-elle fonctionner? Oui, mais il faudrait un transfert total des responsabilités pendant que votre client était absent. Le patron de votre client devrait accepter le substitut et qu'aucune décision raisonnable ne serait annulée. Cela semble probable? Il est plus probable que vous obteniez un bon de commande temporaire de l'organisation de votre client (ce qui n'est certainement pas sans inconvénient!) Mais si votre sr. l'analyste a travaillé avec le bon de commande temporaire, toute décision incorrecte proviendrait de l'entreprise, ce qui maintiendrait les rôles de votre équipe propres.

Problème 2: "le client n'a pas le temps de réviser". Gros problème (et que j'ai rencontré récemment aussi). Le bon de commande doit être présent pour accepter le produit. Personne d'autre ne peut «signer le chèque». L'absence d'OP signifie que l'insatisfaction se produit plus tard, potentiellement plus de retouches et une perte de confiance. Plus fondamentalement, je sens que le client n'est pas activement engagé dans votre projet: pas de temps pour le standup quotidien, pas de temps pour répondre aux questions, etc.

Problème 3: "on nous a dit d'attendre que l'équipe de conception ait terminé la maquette". Et maintenant, vous êtes complètement hors mêlée. Les gens qui font la maquette devraient faire partie de votre équipe interfonctionnelle. Je ne peux pas dire si cela est dû à un manque de compréhension de la direction de Scrum ou à une réaction de choc à votre troisième version.

Question: Où était votre scrum master dans tout ça? Le SM reconnaît généralement le danger du conflit de rôle et le manque de participation des OP, les deux obstacles / dangers devant être traités.