Dans Scrum, les membres de l’équipe travaillent ensemble pour atteindre des objectifs communs, dans un environnement de responsabilité collective et de progrès continu.
Nous avons reçu beaucoup de questions sur le rôle du Scrum Master lors de notre dernier webinaire et nous avons décidé de créer un post avec les réponses, afin que le rôle du Scrum Master et de tous les membres de l’équipe Scrum soit plus clair !
1) Quelle est l’importance des compétences technologiques du Scrum Master ? Le Scrum Master est-il plutôt un leader, qui motive les équipes et a des compétences en management plutôt qu’en informatique, ou est-il le lien entre le Product Owner et l’équipe de développement ?
En lisant attentivement le guide de Scrum de Ken Schwaber et Jeff Sutherland, on ne trouve aucune référence aux compétences « technologiques » du Scrum Master. Il n’est cependant pas exclu que le Scrum Master fasse partie de l’équipe de développement et ait des compétences en informatique.
Pour en savoir plus sur les compétences d’un Scrum Master, consultez notre article !
2) Les clients acceptent-ils sans problème de financer le développement de produit pour une durée déterminée sans toutefois avoir la certitude du résultat final ?
Si vous avez l’habitude des achats via des contrats à « périmètre fixe », il peut être difficile de changer même si l’objectif est de saisir une opportunité. N’oubliez pas qu’Agile est un état d’esprit. Il est donc nécessaire que chacun (client/fournisseur) évolue ; d’une approche « fermée », avec un faible partage externe, il est nécessaire de passer progressivement à une approche « ouverte », basée sur un cycle apprendre-partager-collaborer-améliorer, pour favoriser l’échange et le transfert des connaissances de manière non conventionnelle.
3) Quelle responsabilité le Scrum Master a-t-il généralement en termes de contrôle des coûts et des délais d’un projet ?
Le Scrum Master a de nombreuses responsabilités, mais parmi celles-ci il n’y a pas d’items qui concernent spécifiquement la gestion des contraintes de coûts et de durée du projet. C’est une responsabilité partagée de toute l’équipe Scrum. N’oubliez pas que la durée et les coûts sont fixes et que c’est à l’équipe Scrum de bien définir l’objectif du sprint.
4) Si l’objectif du sprint n’est pas atteint, est-ce un échec pour le Scrum Master ? Quelle approche le Scrum Master doit-il adopter dans une telle circonstance ?
La situation décrite n’est pas un échec pour le Scrum Master mais est très certainement un motif de réflexion pour toute l’équipe Scrum ; les questions sur lesquelles réfléchir pourraient être :
- Qu’est-ce que nous n’avons pas compris dans le projet/produit ?
- Y a-t-il un manque de connaissances techniques à combler ?
- Les changements internes/externes liés au client rendent-ils l’objectif du sprint systématiquement obsolète ?
5) Si les objectifs ne sont pas atteints lors des sprints, les temps s’allongent, non ? Par conséquent les coûts augmentent également ?
Lorsque l’approche est prédictive dans les premières phases du projet, l’accent est mis sur le détail de la planification, en basant les estimations sur le périmètre défini dans les documents formels (approche axée sur la planification). Au cours du cycle de vie du projet, le plan de projet sera le guide de gestion des travaux et la référence pour le calcul de l’avancement. Les modifications sont gérées via un système formel et la valeur est générée à la fin du projet, lors de la livraison du produit final.
Lorsque, au contraire, les besoins et exigences ne sont pas arrêtés, il est préférable de prendre des décisions qui privilégient les activités de plus grande valeur et les actions à faibles risques (approche axée sur la valeur), en fixant à l’avance les budgets et les délais et en rendant le périmètre du projet négociable, plutôt que d’essayer de fixer à l’avance les caractéristiques du produit, déterminant ainsi les délais et les coûts de mise en œuvre ajoutés (approche axée sur la planification).
Lorsque l’approche est adaptative, la planification est effectuée de manière itérative avant chaque sprint/itération. Cette approche permet de réagir rapidement et efficacement au changement, ce qui se traduit par une réduction des coûts et, au final, une augmentation de la rentabilité et du retour sur investissement (ROI). De manière plus générale, nous passons d’un modèle «inside out», où vous fabriquez et vendez votre produit sur le marché, à un modèle «outside in», où vous construisez itérativement le produit/service avec votre client. On parle alors de Produit Minimum Viable (MVP).
6) Le Product Owner participe-t-il également à la sprint retrospective ? Si oui, quel rôle joue-t-il dans l’équipe de développement ?
L’Agile Business Consortium « recommande fortement » la présence du PO lors de la réunion sprint retrospective ; comme tous les membres de l’équipe Scrum, il s’introspecte et participe activement dans un objectif d’amélioration continue.
7) Quel est le rôle du PO pendant le stand-up meeting? Sa présence n’est-elle pas un obstacle pour le Scrum Master ?
Le Product Owner peut être un des membres de l’équipe de développement. C’est une situation parfaitement possible et dans de telles circonstances, le PO peut évidemment assister et participer pleinement aux Daily.
Si, en revanche, le Product Owner ne fait pas partie de l’équipe de développement, sa présence fait débat. Il existe différentes écoles de pensée à ce sujet. Par exemple, Agile Alliance suggère de garder le PO hors de la réunion quotidienne alors que l’Agile Business Consortium recommande plutôt la participation du PO et suggère à l’équipe de développement d’inviter le PO (c’est une bonne idée de partager les choix et l’engagement).
Vous aviez d’autres questions en tête ? Vous trouverez peut-être la réponse dans notre FAQ SCRUM : Les 10 réponses à vos questions les plus fréquentes sinon contactez-nous à l’adresse france@qrpinternational.com
