Le Scrum Master n'est pas un chef de projet

Pourquoi on voit ça

C’est la confusion la plus répandue quand une entreprise passe du cycle en V à Scrum : « on garde nos chefs de projet, on les appelle Scrum Masters ». C’est faux, et savoir expliquer pourquoi fait partie de l’essentiel sur Scrum.

Cette leçon te sert à deux choses. D’abord, à bien séparer trois personnages : le chef de projet, le Scrum Master et le Product Owner. Ensuite, à construire un discours qui tient la route face à une entreprise qui travaille en cycle en V et qui n’a pas envie de changer.

Ce que fait un chef de projet en cycle en V

En cycle en V, le chef de projet est la personne qui porte le projet. Il concentre presque toutes les décisions de pilotage :

• il planifie : découpage en phases, planning détaillé, jalons ;
• il répartit les tâches entre les membres de l’équipe ;
• il suit le budget, les délais et le périmètre ;
• il arbitre les demandes de changement ;
• il gère les risques ;
• il rend des comptes à la direction et au client.

Ce modèle s’appelle parfois « commander et contrôler » : une personne décide, l’équipe exécute, la personne vérifie. Il est cohérent avec le cycle en V, où tout est prévu au départ.

En Scrum, ces responsabilités sont réparties

Scrum ne supprime aucune de ces responsabilités. Il les répartit entre trois, parce qu’il part d’une idée différente : ceux qui sont le plus près du travail sont les mieux placés pour décider.

Ce que faisait le chef de projet	Qui le porte en Scrum	Comment
Décider du contenu et des priorités	Product Owner	Il ordonne le Product Backlog
Arbitrer les changements	Product Owner	Il réordonne le Product Backlog à tout moment
Suivre budget, délais, valeur	Product Owner, avec les parties prenantes	Sprints de durée fixe, Sprint Review
Planifier le travail en détail	Developers	Ils construisent le Sprint Backlog au Sprint Planning
Répartir les tâches	Developers	Ils s’organisent eux-mêmes
Suivre l’avancement au quotidien	Developers	Daily Scrum
Rendre des comptes	Toute l’équipe Scrum	Un Increment terminé, montré à chaque Sprint Review
Écarter ce qui bloque, veiller à la méthode	Scrum Master	Il fait lever les obstacles et garantit le cadre

En une phrase à connaître par cœur :

• le Product Owner décide du « quoi » et des priorités ;
• les Developers décident du « comment » et s’organisent eux-mêmes ;
• le Scrum Master est garant du cadre et fait lever les obstacles, sans autorité hiérarchique sur l’équipe.

Pourquoi « le chef de projet devient le Scrum Master » est faux

Quatre raisons, à dérouler dans l’ordre.

1. Le Scrum Master ne décide pas du contenu. Les priorités appartiennent au Product Owner. Un chef de projet rebaptisé Scrum Master qui continue à arbitrer prend la place du Product Owner.
2. Le Scrum Master ne distribue pas le travail. Le plan du Sprint appartient aux Developers. S’il assigne les tâches, l’équipe n’est plus autogérée.
3. Le Scrum Master n’est pas le chef de l’équipe. L’équipe Scrum n’a pas de hiérarchie interne. Le Scrum Master est un leader au service de l’équipe : il aide, il forme, il facilite, il protège le cadre.
4. Renommer ne change rien. Si la même personne garde les mêmes pouvoirs avec un nouveau titre, l’entreprise fait du cycle en V avec des mots anglais. Elle n’aura aucun des bénéfices attendus, et elle conclura que « l’agilité ne marche pas ».

D’ailleurs, le Guide Scrum ne mentionne aucun chef de projet. Le rôle disparaît ; la personne, elle, ne disparaît pas.

Alors, que devient le chef de projet ?

Cela dépend de la personne, pas du titre :

S’il aime surtout…	Il peut évoluer vers…
Le client, le métier, les arbitrages de valeur	Product Owner
Aider l’équipe à mieux travailler, faciliter, former	Scrum Master
La technique, la réalisation	Developer

Dans tous les cas, il change de posture : il passe de « je décide et je contrôle » à une responsabilité précise, partagée avec les deux autres.

Contexte, pas à apprendre. Dans les grandes organisations, on trouve encore des chefs de projet ou des responsables de programme autour des équipes Scrum, pour les contrats ou la coordination entre équipes. Ce n’est pas interdit. Ce qui compte : ils ne dirigent pas le travail à l’intérieur de l’équipe Scrum.

Argumenter une transition vers l’agilité

Tu es face à une entreprise en cycle en V. Elle a ses habitudes, et de bonnes raisons d’y tenir. Voici une trame en quatre temps.

1. Partir d’un problème mesuré

On ne vend pas une méthode, on répond à un problème. Commence par des faits chiffrés que l’entreprise reconnaît. Exemples de constats, à adapter à l’entreprise :

• une part importante des projets est livrée en retard ;
• des fonctionnalités livrées ne sont jamais utilisées ;
• les clients découvrent des écarts à la recette ;
• des démissions dans les équipes, qui se disent démotivées ou jamais consultées.

Puis relie chaque constat à une cause : effet tunnel, retour tardif du client, changement coûteux, équipe qui exécute sans décider.

2. Montrer ce que l’agilité change, concrètement

À chaque problème, une réponse précise :

Problème constaté	Ce que Scrum apporte
Retards découverts à la fin	Un Increment vérifiable à chaque Sprint : on voit l’écart au bout de quelques semaines
Produit qui ne correspond pas au besoin	Retour des parties prenantes à chaque Sprint Review
Changements ruineux	Product Backlog réordonné à tout moment
Équipes démotivées	Autogestion : l’équipe décide de son organisation et s’améliore à chaque Retrospective

3. Proposer un projet pilote

Ne demande pas à l’entreprise de tout changer. Propose une équipe, un produit, quelques Sprints, avec des indicateurs choisis ensemble avant de commencer (délai de livraison, satisfaction du client, nombre de défauts). À la fin, on compare et l’entreprise décide. Le risque est limité, et la démarche est elle-même agile : essayer, inspecter, adapter.

4. Répondre aux objections

Objection	Réponse
« Sans planning détaillé, on perd le contrôle. »	On contrôle plus souvent : un résultat réel à chaque Sprint, au lieu d’un pourcentage dans un rapport.
« Sans chef, personne n’est responsable. »	Les responsabilités sont explicites : valeur (Product Owner), réalisation et qualité (Developers), cadre (Scrum Master).
« Nos clients veulent un prix et une date. »	Date et budget peuvent rester fixes. C’est le périmètre qui s’ajuste, en livrant d’abord ce qui compte le plus.
« Agile, ça veut dire pas de documentation. »	Non : on documente ce qui est utile. Le Manifeste dit « plus que », pas « à la place de ».
« Ça marche chez les autres, pas chez nous. »	C’est justement ce que le projet pilote permet de vérifier, avec vos chiffres.
« Nos chefs de projet seront Scrum Masters. »	Non : le Scrum Master ne décide ni du contenu ni de la répartition du travail. On regarde avec chacun quelle responsabilité lui convient.

Deux points rendent l’argumentaire plus solide. Dire ce que le cycle en V fait bien : un discours qui compare est plus crédible qu’un discours qui attaque. Et ne pas promettre de miracle : l’agilité ne supprime pas les problèmes, elle les rend visibles plus tôt.

À retenir

• En cycle en V, le chef de projet planifie, répartit les tâches, suit budget et délais, et rend des comptes : tout passe par lui.
• En Scrum, ces responsabilités sont réparties : le Product Owner décide du « quoi » et des priorités, les Developers du « comment », le Scrum Master garantit le cadre et fait lever les obstacles.
• Le Scrum Master n’a pas d’autorité hiérarchique : il ne distribue pas les tâches et ne fixe pas les priorités.
• « Le chef de projet devient le Scrum Master » est faux : renommer sans redistribuer les responsabilités ne change rien.
• Pour convaincre : un problème mesuré, des réponses concrètes, un projet pilote avec des indicateurs, et une réponse prête pour chaque objection.