Le ScrumMaster n'est pas un chef de projet

Je viens de lire Project Management and Scrum – A Side by Side Comparison(pdf), une comparaison entre le rôle traditionnel de chef de projet (selon le PMBOK) et le rôle de ScrumMaster. Cette comparaison factuelle montre un grand nombre de différences ce qui est normal puisque les principes de management du PMBOK et de Scrum sont radicalement opposés. Des billets récents de l'Agilitateur donnent sur le sujet un point de vue complémentaire.

L'existence simultanée des 2 rôles dans une organisation est d'ailleurs possible provisoirement, c'est le cas chez mon client Total. De nombreuses activités de gestion de projet comme le reporting -traditionnel-, la participation au comité de pilotage, le budget, la gestion des ressources humaines ne sont pas faites par le ScrumMaster qui se consacre uniquement à l'animation de l'équipe.

Commentaires

1. Le lundi 22 janvier 2007, 22:45 par JC

Sans surprise deux mondes trés différents ... le chef de projet "classique" version PMBOK est déjà trés différent des chefs de projet évoluant en mode iteratif et incrémental comme UP par exemple. Alors sa distance vis à vis du ScrumMaster !!
Qu'un rôle ne se consacre qu'à l'animation de l'équipe (même s'il y a beaucoup à faire) est dans mon contexte plutôt difficile : en revanche qu'un chef de projet (type UP) y consacre une grosse partie de son activité avec des variations selon les iteartions et les moments de l'iteration, est un peu plus réaliste pour moi. En cela UP est selon moi un bon compromis pour le chef de projet.

2. Le mardi 23 janvier 2007, 23:05 par claude aubry

Bienvenue JC. Quel est votre contexte à vous ? Quand vous dites UP, vous voulez dire Unified Process, certes, mais quel processus précisément ? RUP, EssUP, OpenUP, AUP, EUP ?

3. Le mercredi 24 janvier 2007, 13:59 par JC

bonjour, disons qu'on a avant tout cherché à adopter Up (dans sa forme générique) à notre contexte en s'attaquant aux processus et mettant en avant les principes et bonnes pratiques: cycle iteratif et incrémental, pilotage par les risques, validation continue, time boxing, développement d'un proto. trés vite... le but était de faire un truc simple répondant à nos besoins. Appliquer ces bons principes faire de vraies estimations, un mode de planifiaction spécifique (grosse maille sur estimation et détaillé seulement pour une itération), c'était une vraie révolution!!.
Ensuite, de manière pragmatique on a identifié comment ça se passait sur nos projets en termes de rôles / activités et disciplines. Ce fut pour nous l'occasion de formaliser voire officialiser certains rôles, au niveau test par ex et même le mien, celui d'ergonome (on n'est jamais mieux servi ....): en cela SCRUM n'aurait pas été suffisant.
Le RUP a ses lourdeurs mais il est bien documenté par les gens d'IBM notamment pour son adoption et son fonctionnment: ce fut une bonne référence. Ensuite c'est un peu d'experience et un vrai travail d'analyse ;il faut savoir prendre du recul pour retenir les choses pertinentes par rapport à son propre contexte dans les différentes instantiations d'UP. Scott Ambler amène des choses intéressantes, tout comme EssUP ou Entreprise. Open UP en était à ses prémisses quand on a commencé notre accompagnement du changement.
Il faut rester ouvert, c'est beaucoup une question d'état d'esprit (j'en parle dans un billet UP= agile ?, je viens tout juste de créer mon blog). En plus tout n'est pas toujours rose. C'est pour cela que je m'interesse à Scrum (et au passage merci pour la pertinence et la précision de vos billets), outre les similitudes, j'essaie de voir surtout ce que ça pourrait nous apporter au quotiden. Peut être plus de dynamisme et d'engagement, plus de réactivité, plus d'interactions ... des bénéfices pour le chef de projet et l'équipe.

4. Le mercredi 24 janvier 2007, 22:46 par JC

Disons que nous avons adapté UP (dans sa forme générique) à notre contexte en cherchant à mettre en avant principes agiles et bonnes pratiques: cycle itératif, incrémental, validation continue, pilotage par les risques... Ajouté à cela des nouveaux modes d'estimation et de planification (détaillé seulement pour une itération...), et c'était déjà une révolution. Dans le même temps, et dans une approche pragmatique nous avons analysé nos projets, nos besoins, et identifié rôles/ activités et disciplines nécessaires à la mise en place de nos méthodes. Cela nous a permis par exemple de mettre le focus sur le test ou d'officialiser certains rôles : ergonome (on est jamais mieux servi ...), rédact. tech. En cela Scrum ne pouvait guère nous aider.
Je connaissais déjà pas mal le RUP ; les gens d'IBM ont pas mal documenté son adoption, son adaptation et son fonctionnement (et pas seulement les livrables !). Ce fut une bonne référence.
Ensuite, il faut savoir être ouvert et trouver les bonnes pratiques là où elles se trouvent : chez Scott Ambler par ex. ou dans ESSUP.
OpenUp n'en était quà ses premisses.
Le tout est de faire quelque chose de léger et de garder un état d'esprit "agile" (j'ai moi même écrit un billet la dessus dernièrement).

Et c'est là que je vois l'interêt de Scrum (et à ce propos, bravo pour la précision de vos écrits) : pour son côté dynamique et réactif, pour ses benéfices potentiels en termes de communication, interactions et engagement pour l'équipe et le chef de projet.

5. Le jeudi 25 janvier 2007, 11:54 par claude aubry

Hello JC. Je viens de retrouver vos commentaires. Ils avaient été mis dans les spams... Dans les mots à surveiller, il y a cialis et vous avez utilisé officialiser.

En tout cas merci pour vos commentaires et bienvenue dans la blogosphère. Je serai particulièrement intéressé par l'intégration de l'ergonomie avec les méthodes Agiles.

6. Le lundi 05 février 2007, 12:19 par Matthieu

Bonjour,
A votre avis, si dans un projet de taille modeste le rôle de ScrumMaster n'occupe pas quelqu'un à plein temps, quel autre rôle le ScrumMaster peut-il tenir en parallèle ?

Par exemple, est-ce que le ScrumMaster peut aussi assumer les tâches "traditionnelles" de gestion de projet (le reporting, la participation au comité de pilotage, le budget, la gestion des ressources humaines) ou bien faut-il éviter ce cumul pour ne pas "polluer" son rôle de ScrumMaster ?

7. Le lundi 05 février 2007, 15:27 par claude aubry

Un ScrumMaster qui n'est pas occupé à plein temps peut contribuer aux activités de développement. Cela arrive fréquemment sur mes projets. Faire du reporting, gérer (au sens animer) les ressources humaines de son projet ça fait partie du boulot normal d'un ScrumMaster. Il n'y a pas besoin de quelqu'un d'autre pour ça sauf dans le cas où l'organisation n'est pas encore habituée à Scrum et qu'il faut traduire le reporting Scrum (burndonwn chart) en reporting traditionnel. C'était le cas pour le projet que j'évoquais. Cela devrait être temporaire en attendant d'agilifier toute l'organisation.

8. Le lundi 05 février 2007, 17:11 par Matthieu

Donc lorsqu'on passe d'une organisation traditionnelle à une organisation scrum, le chef de projet est un bon candidat au rôle de ScrumMaster, à condition qu'il adhère au concept et sache se montrer beaucoup moins directif dans ses rapports avec l'équipe...

Ceci dit je pense que même dans les organisations traditionnelles la tendance est déjà à se montrer moins directif et à laisser plus de liberté à l'équipe pour s'auto-organiser, afin d'obtenir une meilleure adhésion et une meilleure implication.

9. Le lundi 05 février 2007, 17:34 par Camille Bloch

Je pense que de toute façon, lorsqu'un chef de projet s'oriente vers Scrum, il est déjà dans cette approche là.
Un chef de projet qui passe à Scrum cherche souvent juste à "formaliser" une façon de travailler qui est déjà en place.
Ou alors la décision est prise à un autre niveau hiéréchique, et dans ce cas, il faut que le chef de projet adhère ou change.

10. Le lundi 05 février 2007, 21:58 par Oaz

Au risque de mettre les pieds dans le plat, je suis très étonné par les propos de ce billet et de la discussion que je lis dans les commentaires.

J'ai du mal à comprendre la séparation évoquée entre le scrummaster et un chef de projet qu'il soit "classique" ou qu'il le soit moins. L'existence d'un autre niveau de gestion de projet dans lequel le scrummaster ne serait pas partie prenante ne signifie rien d'autre, à mon avis, qu'une organisation de projet qui n'est PAS agile. Un des principes de base de l'agilité est quand même de favoriser les interactions en mettant tout le monde au contact de tout le monde.
La notion même de "comité de pilotage" me parait tout simplement antinomyque avec la notion d'agilité.

Dans la même lignée, comparer la propension "à laisser plus de liberté à l'équipe pour s'auto-organiser" avec la notion de scrummaster me semble être un raccourci dangereux.

Quiconque n'y prendrait pas garde pourrait croire qu'il lui suffit de mettre en place une équipe auto-gérée accompagnée par un Gentil Animateur et le tout organisé à plus haut niveau par un comité restreint pour croire qu'il vient de mettre en place une organisation "agile"...

11. Le lundi 05 février 2007, 22:54 par claude aubry

Hello Oaz. J'évoquais dans le billet initial une histoire vécue où des travaux de gestion de projet n'étaient pas faits par le ScrumMaster. Ces travaux visaient à produire des rapports pour une organisation pas agile -nous sommes d'accord-, qui, en gros, voulait voir des Pert et des Gantt comme d'habitude et pas des Burndown Charts. Comme je le précise dans mon commentaire de 15h27, cela devrait être temporaire. Mais comme on ne peut pas changer tout d'un coup, cela arrive.