Méthode Scrum pour une gestion de projet agile

Les méthodes de gestion de projet agile permettent à une équipe de mettre en œuvre des projets plus conséquents de manière souple et autogérée. Alors que la gestion de projet classique place le résultat au cœur de la planification, ce sont le temps et l’effort qui constituent la base de la planification dans la gestion de projet agile. L’équipe doit d’abord déterminer un cadre temporel et financier fixe, et ce n’est qu’ensuite que seront définis les résultats réalistes qui pourront être atteints dans ce cadre. Grâce à cette approche, l’équipe se demande « Que pouvons-nous réaliser ? » au lieu de « Que devons-nous réaliser ? » La gestion de projet agile aide donc à planifier de manière réaliste et à respecter les délais.

Avec la méthode agile, le temps et la force de travail de chaque membre de l’équipe doivent être utilisés au mieux. Lors d’un projet organisé selon les critères de la gestion agile, chaque participant doit rester concentré en permanence sur la réalisation d’une tâche jusqu’à ce que celle-ci soit terminée.

Scrum est sans doute la méthode la plus utilisée pour la gestion de projet agile et devrait être connu dans ses grandes lignes par la plupart des équipes. Scrum structure le travail sur le projet sous forme de « sprints ». Il s’agit de phases de développement ponctuelles lors desquelles les participants travaillent sur un aspect du projet jusqu’à ce qu’il soit finalisé. En général, les sprints ne durent pas plus de 30 jours et ne doivent pas être prolongés. Le sprint est suivi d’une rétrospective qui permet à l’équipe d’évaluer le travail fourni et les méthodes utilisées. Qu’est-ce qui a fonctionné ou non ? Qu'est-ce qu'il est possible d'optimiser ? La répartition et l’avancée des tâches est consignée sur un « scrum board » dédié. Des solutions numériques existent naturellement aussi.

Le prérequis pour une collaboration fluide au sein d’une équipe Scrum est une structure bien organisée. Deux rôles définitifs sont à pourvoir au sein de l’équipe : Scrum Master et Product Owner. Le Scrum Master régule la communication interne, répartit les tâches et veille au bon respect des échéances des sprints. Le Product Owner veille au respect des exigences des clients et des supérieurs hiérarchiques et redresse éventuellement le cap lorsque l’équipe perd ces dernières de vue. Lors des projets plus importants, il peut arriver que le client fournisse lui-même un Product Owner qui doit alors être intégré à l’équipe. Pour que Scrum fonctionne bien, les membres de l’équipe doivent travailler de manière flexible et interdisciplinaire. Si les spécialistes se concentrent au maximum sur leur domaine d’expertise, ils doivent néanmoins pouvoir aider dans un autre domaine en cas de problèmes.

Une équipe Scrum se rencontre une fois par jour pour le « Daily Scrum », une réunion quotidienne aussi brève que possible au cours de laquelle les membres de l’équipe évoquent ce sur quoi ils travaillent actuellement, comment le travail avance et quand la tâche sera potentiellement achevée. Les « Dailys » ne doivent pas dépasser 15 minutes et sont de simples réunions d’information. Les discussions doivent être évitées. Elles interviennent uniquement dans le cadre des réunions de planification et dans les rétrospectives. La méthode Scrum garantit une répartition claire du travail. Grâce au Scrum Master, il y a toujours quelqu’un qui veille à ce que chaque membre de l’équipe fasse un usage optimal de sa capacité de travail. Cela permet d’éviter les temps morts et d’améliorer le rendement de l’équipe. Les intervalles de temps prédéterminés pour les sprints évitent de bloquer sur certaines parties du projet et propulsent le développement continuellement d’étape en étape.

Mais le fait que la durée des sprints soit prédéfinie peut vite se transformer en piège. Dans le pire des cas, si les objectifs intermédiaires ne sont pas atteints dans les délais prévus, les sprints doivent être prolongés. Les équipes novices, notamment, sont rapidement en échec face à une planification de projet insuffisante et doivent par la suite consacrer du temps et de l’énergie à la mise en place de nouveaux plans. De plus, le modèle des sprints laisse peu de place à la souplesse de décisions. Si des tâches inattendues apparaissent, elles ne pourront être engagées que lors de la prochaine phase de sprint.

De nombreuses équipes souhaitent profiter des avantages de Scrum, sans néanmoins considérer tous les aspects du système comme pertinents pour leur situation. Les intégrations partielles de Scrum sont appelées « ScrumButs », car elles sont « Scrum, mais... ». Ces aspects de Scrum qui sont éliminés dépendent des besoins et de la taille de l’équipe. Les petites équipes, par exemple, préfèrent souvent ne pas nommer de Scrum Master. Leurs membres sont ainsi contraints de choisir eux-mêmes leurs tâches en concertation avec le reste de l’équipe et doivent veiller eux-mêmes à respecter les délais des sprints. D’autres changements ScrumBut très appréciés sont la longueur flexible des sprints ou la suppression des « dailys » au profit de réunions hebdomadaires.

ScrumBut divise la communauté Scrum. Certains considèrent Scrum comme un système ouvert, modulable par chaque équipe en fonction de ses besoins individuels. D’autres traduisent cette nécessité d’adapter Scrum par l’expression de problèmes plus profonds au sein de l’équipe. Selon eux, une équipe qui fonctionne bien devrait pouvoir travailler facilement et efficacement sans devoir modifier la méthode. Quoi qu’il en soit, les modifications apportées aux principes de Scrum doivent être fondées sur des valeurs empiriques. Seul un animateur rompu à l’utilisation de Scrum avec son équipe peut être à même de juger de la légitimité d’une solution ScrumBut. Il est donc intéressant d’essayer de faire un Scrum complet sur quelques petits projets avant de vouloir faire des entailles dans le système.