Introduction
Pour l'organisation agile d’un projet de développement logiciel, Scrum propose un cadre simple et précis, avec notamment 3 rôles, ni plus ni moins :
- Scrum Master
- Product Owner
- Equipier
Ces derniers mois, à plusieurs reprises, je me suis posé la question de savoir lequel de ces rôles était le plus important, voici mes éléments de reflexion.
Le « ScrumMaster » est le rôle le plus important
Je pratique l’agilité depuis des années, et quasiment depuis le début, j’ai estimé que le rôle du ScrumMaster était le plus important. En effet, c’est grâce à ce « facilitateur », ni fonctionnel, ni technique, que l’approche agile peut être bien mise en place et garantir le succès de l’agilité.
Le ScrumMaster a un rôle primordial en s’assurant que chacun des acteurs respecte bien le sien, en protégeant l’équipe des interférences extérieures, en la guidant dans ces choix de priorités, d’optimisation de la valeur produite, de solutions techniques et d’architecture, etc …
Mais le ScrumMaster a également un rôle très important, et souvent difficile, sur les aspects humains, pour fédérer l’équipe, en l’aidant à exprimer ses difficultés et trouver les meilleures solutions, pour atteindre l’efficacité maximum.
Le rôle de ScrumMaster est donc très important pour garantir la bonne mise en oeuvre de l’agilité et sa réussite.
« ProductOwner », un rôle encore plus important ?
Dans mon cheminement de découverte de l’agilité, par la suite, j’ai mieux compris le rôle du Product Owner, le « responsable du produit ». Cet acteur maitrise le métier, les besoins des utilisateurs, leurs attentes, et comment y répondre au mieux. Il a une vision d’ensemble sur le projet, le planning, les étapes clés, les contraintes, et les contextes (vision d’entreprise, budget, autres projets, …).
Il n’a pas de compétences techniques, idéalement, il a des notions pour comprendre certains choix ou contexte, en oubliant le reste. Il se polarise donc entièrement sur le fonctionnel, pour optimiser la valeur produite par l’équipe, en priorisant les histoires du backlog, et en les rédigeant au mieux (précisions, exemples, critères d’acceptation).
Il est en contact avec l’extérieur de l’équipe (clients, utilisateurs, managers, autres équipes, …). Il s’assure de bien capturer les besoins des utilisateurs, de présenter au mieux le contexte à l’équipe, et il est en charge de transmettre les informations relatives au projet : avancement, difficultés éventuels, planning prévisionnel remis à jour régulièrement, etc …
Le rôle du Product Owner est donc très important pour garantir de faire le bon produit, avec le meilleur budget, et dans les meilleurs délais possibles.
Mais finalement, le rôle d’ « Equipier » est primordial !?
Je trouve que les équipiers sont souvent négligés, ou sous-estimés, voire dénigrés. Et pourtant, ce sont eux les « faiseurs ». Sans cette force vive de réalisation, le produit n’existerait pas. Ils sont donc au coeur du projet, au service du produit, mais à la servitude de personne.
Pour un projet de développement logiciel, les équipiers sont le plus souvent des développeurs qui doivent avoir toute latitude dans leur organisation et leurs choix technique, l’équipe est auto-organisée.
Pour une itération, l’équipe prend un engagement sur un ensemble de fonctionnalités qu’elle va implémenter au cours de cette itération. Elle est donc engagée sur le « quoi », et fait les choix qui lui semble bons sur le « comment », du moment qu’elle atteint son objectif.
Personne en dehors de l’équipe ne peut juger ou commenter les choix suivants dont seuls les équipiers ont la responsabilité :
- traiter les histoires dans l’ordre du backlog ou pas,
- faire du pair-programming ou du dojo à plusieurs,
- investir du temps pour refactorer des parties du logiciel ou innover (tant que c’est au service du produit),
- etc …
En contre-partie, les développeurs ont la charge et la responsabilité de la qualité, sous tous ses aspects : logiciel sans défaut et maintenable, architecture évolutive, code propre et lisible, outillage performant, etc …
Le rôle d’Equipier est donc très important pour que le logiciel soit produit, et qu’il soit bien réalisé, en toute qualité.
Conclusion
Vous l’avez compris, finalement, chacun des rôles proposé par Scrum a son importance, et il est primordial que chaque rôle soit bien compris et bien respecté.
En résumé, le Product Owner est en charge de tous les aspects fonctionnels (le « quoi »), les équipiers sont en charge de tous les aspects techniques (le « comment »), et le Scrum Master est là pour que « tout roule », pour que l’équipe soit efficace, productive, créative et en permanente amélioration continue.
Personnellement, dans une époque du « no-ceci », « no-cela », je me rapproche de plus en plus des fondamentaux de l’agilité, et dans la mise en oeuvre précise de Scrum.
Et vous ? Quel est votre vision sur les rôles de Scrum ?
C'est très juste. En fait, il s'agit d'une équipe et dans une équipe tous les rôles sont importants.
RépondreSupprimerBien sûr, ça semble évident, et pourtant, dans la réalité, sur le terrain, les mauvaises mises en oeuvre ou dérives sont courantes. Personnellement, j'en reviens de plus en plus aux fondamentaux : les valeurs et principes du manifest agile, les concepts de base de Scrum !
SupprimerMerci Xavier Nopre pour ce billet.
RépondreSupprimerMettre au même niveau Scrum Master, Product Owner et équipier fait sens. Scrum met naturellement en avant l’importance des équipiers mais cela peut s’effacer dans bon nombre d’implémentations du framework.
Ce billet est un bon rappel des fondamentaux pour chaque rôle. Et il est toujours bon de revenir de temps en temps à la base !