Les chefs de projet sont-ils utiles dans Scrum?

Il y a trois rôles définis dans Scrum: Team, Product Owner et Scrum Master. Il n'y a pas de chef de projet, mais le travail de chef de projet est réparti entre les trois rôles .

Par exemple:

• Le Scrum Master: Responsable du processus. Supprime les obstacles.
• Le Product Owner: Gère et priorise la liste des travaux à effectuer pour maximiser le retour sur investissement. Représente toutes les parties intéressées (clients, parties prenantes).
• L'équipe: Gère son travail en estimant et en le répartissant entre eux. Responsable de respecter ses propres engagements.

Donc, dans Scrum, il n'y a plus une seule personne responsable de la réussite du projet. Il n'y a pas de structure de commandement et de contrôle en place. Cela semble dérouter beaucoup de gens, en particulier ceux qui ne sont pas habitués aux méthodes agiles, et bien sûr, les PM.

Je suis vraiment intéressé par cela et quelles sont vos expériences, car je pense que c'est l'une des choses qui peuvent faire ou défaire une implémentation Scrum.

Êtes-vous d'accord avec Scrum qu'un gestionnaire de projet n'est pas nécessaire? Pensez-vous qu'un tel rôle soit toujours requis? Pourquoi?

Vous devriez peut-être présenter des choses comme ceci:

Le chef de projet n'a pas disparu dans Scrum . Il est toujours là. Il y en a trois maintenant!

• Le Scrum Master : il gère le processus et résout les obstacles. C'était la responsabilité du chef de projet auparavant.

• Le Product Owner : il gère le backlog. C'était la responsabilité du chef de projet avant de prédire tout dans Microsoft Project.

• L'équipe : autogérer sa production. Qui et comment une user story donnée est convertie en un incrément de produit potentiellement libérable. C'était la responsabilité du chef de projet lors de l'attribution des tâches.

Pour moi, cela vient d'un manque de compréhension de ce que fait un chef de projet et de la nature plutôt générique du titre PM. Je ne suis pas un expert en SCRUM mais j'ai toujours considéré le SCRUM Master comme remplaçant le responsable du développement / chef d'équipe plutôt que le chef de projet.

Les chefs de projet (tels que définis par des méthodologies telles que PRINCE2 - qui est à peu près compatible avec les méthodologies Agile) n'ont vraiment rien à voir avec le processus de développement, ils s'occupent du projet dans une perspective de livraison plus large couvrant plus que le seul IT construire. Il y a beaucoup de choses qui relèvent du rôle de chef de projet qui ne sont pas couvertes ailleurs dans Scrum (gestion et suivi de l'analyse de rentabilisation, gestion des parties prenantes de l'entreprise, éléments du projet en dehors de la construction informatique tels que la refonte des processus métier, le support, formation, etc.).

Si votre PM est le gars qui s'occupe des développeurs et ne fait pas beaucoup plus que cela (par exemple sur des projets qui sont en grande partie informatiques uniquement où la portée est assez bien définie), alors il se pourrait bien qu'il ne soit pas nécessaire sur un projet SCRUM.

Mais avant que quelqu'un dise que vous n'avez pas besoin d'un MP pour SCRUM, je voudrais une explication assez claire de la façon dont les éléments non informatiques du projet sont couverts et en particulier qui gère l'analyse de rentabilisation (parce que les utilisateurs le souhaitent et c'est quelque chose qui devrait être fait sont des choses différentes).

Il se peut que le PM finisse par s'asseoir davantage du côté commercial du projet - le Product Owner pourrait bien assumer davantage le rôle du PM que le Scrum Master, mais je pense qu'il est peu probable qu'il disparaisse complètement.

Un chef de projet peut faire un certain nombre de choses qu'un Scrum Master ou un Product Owner pourrait ne pas être en mesure de faire.

• Les chefs de projet ont généralement une vaste expérience dans la gestion de projets (surprise!).
• Ils sont conscients des pièges courants, et peuvent les repérer et les aider à éviter avant qu'ils ne se produisent.
• Ils sont généralement des négociateurs expérimentés et peuvent soutenir les autres membres de l'équipe dans les discussions sur les délais, la portée et les exigences contradictoires (très important si l'OP est relativement nouveau dans son rôle).
• Ils peuvent gérer l'argent. Ils ont le pouvoir d'embaucher et de licencier et peuvent aider si un membre de l'équipe est incapable de jouer son rôle (en organisant une formation, des conseils, etc.).
• Ils peuvent aider à garantir que le projet s'intègre efficacement dans un programme de travail plus vaste.
• Ils peuvent retirer des trucs de l'équipe.
• Ils peuvent aider à guider les politiques de l'entreprise pour être efficaces aux côtés de Scrum (par exemple, si les testeurs sont toujours mesurés par le nombre de bogues trouvés).
• Ils peuvent gérer la gouvernance.
• Ils peuvent déplacer les meubles.
• Leur vocabulaire est celui de la grande entreprise, et ils peuvent discuter du projet - et de l'approche Scrum - en termes de risque, d'impact, de retour sur investissement, d'options et de différenciation.
• Ils peuvent expliquer au conseil d'administration pourquoi la transparence soudaine et les nouvelles occasionnelles d'échecs, venant d'une mer de rapports verts, sont bonnes et utiles à savoir.
• Un bon PM peut vous aider à vous sentir en sécurité, à avoir l'air cool et à avoir fière allure.

Scrum n'impose pas d'avoir un PM. Mais vous voudrez peut-être en avoir un de toute façon.

Dans l'un des projets sur lesquels j'ai travaillé, quand il est devenu Scrum, notre ancien chef de projet a pris alternativement les rôles de Product Owner et Scrum Master. Cela a fonctionné pendant les 6 mois que j'ai passés avec cette équipe, même si ce n'était pas idéal (pour moi). C'était le genre de gars qui voulait garder les choses sous contrôle serré, mais qui le faisait assez bien (c'est-à-dire laisser l'équipe faire son travail et prendre ses décisions quand c'était approprié).

Le contexte était que la société était dans une situation financière désastreuse, bien que nous (l'équipe) ayons eu connaissance de cela seulement un peu plus tard. Il y avait donc une raison de tout garder sous contrôle strict, afin de garantir que seules les choses absolument nécessaires soient construites et que la première version du produit soit livrée à temps.

Je serais juste et je dirais qu'à mon avis, ce qui fonctionne pour moi, c'est le Scrum master agissant également en tant que chef de projet. Être un Scrum master n'est pas un travail à plein temps - une fois que l'équipe est mature, le scrum master n'a même pas besoin d'assister aux stand up quotidiens.
Il y a de plus en plus de postes vacants que je vois pour un chef de projet / Scrum Master où les entreprises ne veulent pas différencier ces rôles - plutôt que la même personne gère les deux rôles - à savoir: un chef de projet Agile.

Chef de projet: un rôle au sein d'une organisation ou entreprise traditionnelle.

Scrum master: un rôle au sein d'une équipe de développement logiciel utilisant la méthodologie Scrum.

Parler de chef de projet par rapport à Scrum Master, c'est vraiment parler de pommes et d'oranges car les rôles ont des contextes différents. Je n'ai jamais entendu parler d'une organisation qui a "Scrum master" comme titre officiel ou grade de rémunération. Et les chefs de projet sur n'importe quel projet, Scrum ou autre, sont souvent quelque peu éloignés des activités quotidiennes de développement de logiciels.

Exactement ce que fait un chef de projet et combien son rôle chevauche celui d'un maître Scrum ou d'un propriétaire de projet dépend fortement de la taille et de la nature du projet, mais il y a certainement des tâches normalement attribuées à un chef de projet qui ne sont pas spécifiquement partie des rôles Scrum maître ou propriétaire de projet. Sur un petit projet, il peut être possible d'élargir les fonctions des rôles de maître Scrum ou de propriétaire de projet pour inclure ces tâches (embauche, licenciement, achat, gestion des contrats, interface avec des cadres supérieurs, etc.). Sur un projet plus important, le développement de logiciels n'est qu'une partie de la gestion de projet, et les tâches du chef de projet et celles du Scrum master ne se chevaucheront probablement pas du tout.

Un chef de projet doit être l'interface du Scrum master avec l'organisation. Le Scrum master doit être l'interface du chef de projet avec l'équipe.

Les chefs de projet sont-ils donc utiles dans Scrum? Non, les chefs de projet sont utiles en dehors de Scrum. Ils ne font pas partie de la méthodologie de développement logiciel Scrum, mais ils fournissent les ressources qui permettent à Scrum de fonctionner.

Cette question sent Scrumbut .

Scrum est un sous-ensemble de ce qui est contenu dans une méthode de gestion de projet (Prince2 / PMP, etc.). En fait, si vous regardez le processus Prince2 MP (gestion de la livraison des produits), tous les éléments de Scrum peuvent y être contenus.

Le Scrum Master ne veut pas s'enliser dans les réunions avec les vendeurs, le personnel, le juridique, les finances, les fournisseurs, les cadres ou l' activité BAU . Ils doivent se concentrer sur la suppression des obstacles de l'équipe sur le sprint actuel, ne pas négocier combien une agence pour l'emploi peut réduire les tarifs des entrepreneurs au cours de l'exercice 2011/12 ou valider l'accord d'entiercement avec le fournisseur x.

Si votre Scrum Master fait ce qui précède, vous n'exécutez pas Scrum, vous exécutez Scrumbut.

Par expérience, la meilleure combinaison est d'avoir un Scrum Master pour chaque chef d'équipe et un chef de projet pour coordonner les Scrum Masters à la manière de Scrum of Scrums. Avoir un chef de projet dans ce rôle plus efficace pour les raisons évoquées ci-dessus et leur grande expérience. À leur tour, ces chefs de projet relèvent d'un gestionnaire de portefeuille / programme, etc. et tous dans la chaîne de commandement sont au moins des Scrum Masters certifiés.

N'oubliez pas que Scrum est un outil de gestion de la livraison des produits, à une couche d'abstraction, il peut être utilisé pour exécuter des projets, mais il existe déjà de bien meilleurs processus pour cela.

L'un des principaux problèmes du rôle traditionnel de chef de projet est qu'il sépare l'autorité de la responsabilité. Le PM a une autorité complète sur l'organisation du projet - il décide quelles tâches doivent être effectuées, par qui, dans quel ordre, etc. Mais il n'est pas tenu responsable de l'achèvement de ces tâches ou de la qualité du logiciel qui est produit. Les membres de l'équipe sont les seuls responsables. Cela crée un énorme coût de communication, car pour remettre l'autorité et la décision en synchronisation avec le travail opérationnel, les membres de l'équipe doivent constamment signaler tout ce qui est fait au PM en plus du reste de l'équipe. Cela crée également un sentiment de dépossession, d'impuissance et de perte de but avec les membres de l'équipe, ce qui est une grande source de frustration et de découragement.

Agile rassemble en quelque sorte ces notions - l'autorité sur l'organisation du travail est détenue par l'équipe dans son ensemble (par le biais de la libération, de l'itération et des réunions quotidiennes) afin que chacun se sente capable d'avoir son mot à dire en la matière, en retour duquel chacun des les membres de l'équipe doivent prendre la responsabilité de produire des logiciels de qualité qui fonctionnent et s'engager fortement à cet égard. Vous pourriez ainsi théoriquement vous débarrasser du chef de projet.

Une fois que vous avez dit cela, il y a encore des tâches traditionnellement assignées au PM qui doivent encore être prises en charge - lunivore les a décrites assez précisément.

Comme le suggère cet article , dans les équipes véritablement polyvalentes, une chose que vous pourriez faire est de supprimer le rôle de chef de projet, de redistribuer ses fonctions parmi les membres de l'équipe et de faire en sorte que les anciens PM deviennent membres réguliers de l'équipe.

Les rôles Scrum sont assez bien définis (s'ils semblent vagues, c'est parce qu'ils sont censés s'appliquer à différents types d'organisations), et puisque les équipes Scrum sont toujours (enfin, généralement) de la même taille - c'est-à-dire pas très grandes - il est relativement facile de s'entendre sur ce qu'ils englobent, même si cela varie en fonction de l'organisation sous-jacente.

À la lecture de la question, des réponses et des commentaires ci-dessus, il semble évident que la définition du rôle de chef de projet est beaucoup plus difficile à cerner. Je suis sûr que vous pouvez trouver une définition générale agréable et complète du rôle d'un PM, mais ce que cela signifie réellement dans la vie réelle est une histoire totalement différente.

Quoi qu'il en soit, comme cela fonctionne dans mon travail, les chefs de projet sont très rarement impliqués dans le "Scrumming". Ils ne sont pas autorisés à être des maîtres Scrum (une règle locale de conflit d'intérêts dont nous sommes tous très satisfaits), et ils ne sont propriétaires de produits que dans des cas exceptionnels.

Alors là où je travaille, les chefs de projet sont toujours là, faisant à peu près ce qu'ils ont toujours fait. Cela signifie qu'ils gardent le projet sur la bonne voie, agissent comme un filtre contre trop de paranoïa et les tendances de micro-gestion "d'en haut", résolvant des problèmes qui ont besoin de plus d'influence que nous n'en avons pour résoudre, et ainsi de suite.

Je suis sûr que c'est assez différent à d'autres endroits, mais pour nous, cela fonctionne très bien.

Edit : Je devrais peut-être préciser que pour nous, une équipe Scrum ne remplace pas une équipe de projet. Une ou plusieurs équipes Scrum sont commencé à effectuer le travail de développement réel pour (et généralement) un projet. La ou les équipes Scrum peuvent (et probablement toujours) se composer des anciens membres de l'équipe, à l'exception du chef de projet :-)