Gestion de Projet Agile Sprint

Les sprints sont une fonctionnalité des approches agiles les plus populaires pour la gestion de projet et la livraison de produits. Ils sont principalement utilisés pour segmenter de gros volumes de travail en portions plus petites et plus gérables à livrer par les équipes agiles.

Les sprints ont été décrits pour la première fois dans le cadre de Scrum – l'une des premières et certainement la plus populaire des approches agiles utilisées aujourd'hui. Ils sont également utilisés par Nexus et LeSS (approches utilisées pour faire évoluer Scrum à plus grande échelle) et la dernière version d'AgilePM. D'autres approches agiles telles que SAFe, DAD et XP utilisent un concept presque identique mais emploient le terme Itération plutôt que Sprint.

Dans les paragraphes suivants, je commencerai par décrire ce que sont les sprints et comment ils sont structurés avant d'aborder des conseils et orientations pragmatiques pour s'assurer qu'ils livrent comme ils le devraient.

Un Sprint est une période de travail courte et de durée fixe pendant laquelle une équipe s'efforce de terminer un ensemble de tâches priorisées. Les Sprints sont destinés à permettre aux équipes de livraison de réaliser des progrès significatifs et progressifs vers des objectifs à plus long terme de manière prévisible et par étapes.

Limiter les Sprints à une période de 2 à 4 semaines, et s'assurer que chaque Sprint a un objectif clair, favorise la livraison fréquente de résultats précieux et stratégiquement alignés.

Le rythme et la discipline des Sprints aident les équipes à créer une dynamique, à gérer la complexité de manière progressive et à s'adapter rapidement au changement. Surtout, cela permet une amélioration continue en offrant des opportunités fréquentes de retour d'information, d'apprentissage et d'ajustement.

Le Sprint, tel que défini par Scrum, a une structure spécifique. Sous cette forme, il est mieux adapté à une utilisation dans un contexte non-projet étant donné que Scrum ne reconnaît pas le rôle d'un Chef de Projet. AgilePM suggère quelques améliorations pratiques et pragmatiques à cette structure par défaut offrant de la valeur dans le contexte d'un projet sans contredire ou nuire à l'intention originale de Scrum.

Le diagramme ci-dessous montre la structure d'un Sprint tel que décrit dans le Scrum Guide 2020 – le guide définitif de Scrum rédigé par les co-créateurs de Scrum Jeff Sutherland et Ken Schwaber.

Il décrit quatre Événements clés que la plupart des gens reconnaîtraient comme des réunions d'équipe qui ont lieu pendant un Sprint. Le diagramme illustre un sprint de 2 semaines, mais pour les Sprints de durée différente, la plupart des Événements devraient être adaptés en conséquence.

1. Chaque Sprint commence par un événement de Planification de Sprint lors duquel :

• Un Objectif de Sprint est convenu
  • Il s'agit d'un processus collaboratif impliquant le Product Owner et les Développeurs de l'Équipe Scrum.
  • Le Product Owner est responsable de s'assurer que le travail planifié apporte une valeur optimale aux parties prenantes.
  • L'Équipe Scrum doit négocier un objectif auquel elle peut s'engager.
• Ce qui doit être fait dans le Sprint est négocié
  • Il s'agit également d'un processus collaboratif impliquant le Product Owner et les Développeurs.
  • Les éléments nécessaires pour atteindre l'Objectif de Sprint et réaliser un Objectif Produit sont tirés du Backlog Produit. Notez qu'un Objectif Produit peut nécessiter plusieurs Sprints pour être atteint.
  • Il peut y avoir un certain degré d'itération entre la définition d'un Objectif de Sprint précis et le travail nécessaire pour l'atteindre.
• Comment le travail convenu sera accompli
  • Il s'agit d'un processus collaboratif dans lequel les Développeurs décomposent les éléments sélectionnés du Backlog Produit en éléments de travail réalisables et conviennent de la façon dont ils seront ordonnés dans le Backlog de Sprint.

Le Backlog de Sprint inclut les trois éléments ci-dessus du travail à effectuer. À la fin de la Planification de Sprint, le Backlog de Sprint, qui est « le plan » pour le Sprint détenu par les Développeurs, est convenu.

2. Le Scrum Quotidien

• Il s'agit d'une réunion quotidienne de 15 minutes (maximum) des développeurs
  • Elle se tient généralement à la même heure chaque jour ouvrable.
  • Elle ne s'adapte pas à la durée du Sprint.
  • Son objectif est de permettre aux développeurs d'ajuster leurs plans pour maintenir une concentration sur, et leur engagement envers, l'Objectif de Sprint.

Au fur et à mesure que le Sprint progresse, des Incréments Produit peuvent être livrés, chaque Incrément englobant ceux qui le précèdent. La livraison d'Incréments Produit est la mesure du progrès incrémental significatif mentionné précédemment.

3. Revue de Sprint

• Il s'agit du forum utilisé par l'Équipe Scrum pour démontrer aux parties prenantes la valeur qu'elle a livrée à la fin du Sprint.
• L'Incrément Produit final est formellement examiné dans le contexte de sa contribution à l'Objectif Produit et toute amélioration potentielle est discutée
• Ces améliorations sont ajoutées au Backlog Produit, en supposant qu'elles ne soient pas déjà notées.

4. Rétrospective de Sprint

• L'objectif de cet événement est que l'Équipe Scrum réfléchisse sur l'efficacité de sa façon de travailler
• Toutes les idées d'amélioration sont discutées et priorisées. Une ou deux de ces idées sont adoptées comme expériences pour le Sprint suivant, l'impact étant évalué lors de la Rétrospective ultérieure

Les améliorations suivantes au Sprint Scrum sont proposées par AgilePM lorsqu'elles apportent de la valeur dans le contexte de la gestion de projet. Elles sont plus susceptibles d'apporter de la valeur dans les projets multi-équipes où les plans entre équipes doivent se synchroniser dans un plan de projet global cohérent.

5. La première des améliorations consiste à remplacer le Daily Scrum qui a lieu 2 jours avant la fin du Sprint par un Consolidation Scrum spécial.

• D'une durée de 30 minutes, cet événement est légèrement plus long que le Daily Scrum.
• En plus de l'objectif de l'événement qu'il remplace, il est demandé à l'équipe Scrum de prédire quelle partie du travail restant du Sprint sera terminée et quelle partie restera très probablement incomplète.

6. La deuxième amélioration est l'introduction de l'événement Planification de Projet.

• Cet événement réunit les rôles de direction du projet : Business Visionary, Solution Architect et Project Manager, chacun ayant des responsabilités spécifiques dans la direction du projet dans AgilePM.

Note : D'un point de vue général de gestion de projet, les intitulés des rôles sont sans importance. L'événement devrait réunir le chef de projet et toute autre personne responsable de définir l'orientation du projet Sprint par Sprint.

• Les prédictions à très court terme du Consolidation Scrum servent d'entrée à l'événement et permettent une planification sensée pour toutes les équipes pour le Sprint suivant
• L'événement offre également l'opportunité de planifier au-delà de l'horizon du Sprint imminent et pour toute activité de projet devant être menée par des membres de l'équipe projet qui ne sont peut-être pas membres d'une équipe Scrum.

Je travaille avec des approches agiles de gestion et de livraison de projet depuis 1997. Je sais à quel point elles peuvent bien fonctionner et, tout aussi bien, à quel point les performances peuvent être médiocres si les choses ne fonctionnent pas comme elles le devraient.

Si vous voulez adopter l'agilité dans la gestion de projet, le meilleur conseil que je puisse offrir est d'exécuter vos Sprints conformément aux directives Scrum. Cela signifie que si vous êtes chef de projet, vous devez garder un peu de distance par rapport à la planification et à l'exécution des Sprints. Vous devez être suffisamment proche pour vous assurer qu'ils fonctionnent comme ils le devraient tout en permettant aux aspects les plus puissants de l'agilité de booster leur livraison.

Voici 6 « conseils essentiels » pour l'utilisation réussie des Sprints

1. Essayez de laisser Scrum tranquille.

• Il est éprouvé, testé et efficace s'il est opéré correctement conformément aux directives du Guide Scrum. Cela dit, comprendre ce qui le fait fonctionner, plutôt que de simplement le suivre de manière procédurale, est essentiel pour en tirer le maximum.

2. Utilisez des Sprints de longueur fixe selon une cadence régulière

• En théorie, vous pouvez faire varier la longueur de chaque Sprint dans une séquence et il est parfois logique d'avoir un Sprint de longueur irrégulière de temps à autre. Par exemple, un Sprint occasionnel peut être plus long ou plus court que d'habitude pour s'adapter aux vacances saisonnières ou pour respecter une date de livraison qui tomberait autrement au milieu d'un Sprint.
• Opter par défaut pour un Sprint de longueur fixe facilite cependant la planification de l'engagement des parties prenantes et le suivi des progrès.

3. NE JAMAIS reporter une date de fin de Sprint

• L'un des principaux avantages de l'utilisation des Sprints est la prévisibilité de livraison qu'elle offre. La livraison à temps d'un produit de valeur peut être pratiquement garantie en :
  • Respectant la date de fin du Sprint, et
  • Priorisant le travail pour traiter les aspects de plus haute valeur et/ou les plus risqués avant les aspects de plus faible valeur et/ou plus simples.

4. Ne sautez pas d'événements.

• Chaque événement d'un Sprint a un objectif lié aux fondements empiriques de l'agilité. Spécifiquement :
  • Transparence de ce qui est fait et comment
  • Inspection du produit en évolution et des façons de travailler
  • Adaptation de ceux-ci pour rendre le produit de plus en plus précieux et pour améliorer l'efficience et l'efficacité des pratiques de travail

5. Essayez de « vivre » le concept d'autonomisation d'équipe.

• Comprenez et adoptez les valeurs qui sous-tendent la façon agile de travailler et encouragez toutes les personnes associées au projet à le faire. Scrum définit ces valeurs comme l'Engagement, la Concentration, l'Ouverture, le Respect et le Courage. Citation du Guide Scrum 2020 :

« Quand ces valeurs sont incarnées par l'équipe Scrum et les personnes avec lesquelles elle travaille, les piliers empiriques de Scrum que sont la transparence, l'inspection et l'adaptation prennent vie en construisant la confiance. »

Gardez à l'esprit que vous n'avez pas besoin de suivre une approche Scrum pour adopter ses valeurs. Les adopter ajoutera de la valeur dans toute entreprise basée sur le travail d'équipe.

• Ne dictez pas, dirigez de manière collaborative.
  • La propriété et l'engagement de l'équipe sont considérablement diminués dans un environnement où un seul individu, comme un chef de projet, dicte ce qui doit être fait et quand
  • Une approche collaborative du leadership qui adopte les valeurs Scrum décrites ci-dessus conduira à une qualité et une productivité améliorées.
• Influencez les plans (tant pour la solution que pour le planning de livraison) via les Product Owners. Cela nécessite une reconnaissance par le Product Owner que les rôles de direction de projet sont des parties prenantes clés.

Et si vos équipes ne sont pas les mieux placées pour performer de manière agile…

6. Accompagnez-les vers cela

• La façon agile de travailler s'appuie fortement sur l'idée que les personnes qui font le travail sont les mieux à même de prendre des décisions détaillées sur ce qui doit être fait et comment. Combinée à une définition claire et détaillée de ce qui est nécessaire et pourquoi de la part d'un Product Owner travaillant de manière collaborative au sein de l'équipe, cela fonctionne très bien. J'ai personnellement été témoin d'augmentations significatives de productivité qui ne peuvent être attribuées qu'à un passage vers des équipes autonomisées depuis une approche centralisée de « commandement et contrôle ».
• L'autonomisation doit cependant être reconnue comme une voie à double sens, avec des dirigeants prêts à autonomiser leurs équipes et des équipes capables d'adopter cette autonomisation. Dans des situations sans compétence et engagement de la part des membres d'équipe, j'ai vu la productivité chuter.
• La théorie du leadership situationnel développée par Paul Hersey et Ken Blanchard dans les années 1970 décrit comment un dirigeant, peut-être dans notre contexte un chef de projet, peut évoluer vers une dynamique dirigeant/équipe optimale pour l'agilité.

Les Sprints sont un pilier de nombreuses approches agiles, apportant structure, concentration et rythme à la livraison de valeur. Bien que leurs racines se trouvent dans Scrum, le concept a été adapté avec succès par une gamme de frameworks et de modèles à grande échelle, souvent sous le terme plus large d'« itération ». Indépendamment de la terminologie, les principes restent cohérents : limiter le travail dans le temps, permettre une inspection et une adaptation fréquentes, et donner aux équipes les moyens de s'auto-organiser autour d'objectifs clairs.

Lorsqu'ils sont utilisés de manière réfléchie, les Sprints peuvent améliorer considérablement la livraison de projet — mais seulement s'ils sont respectés. Traiter les Sprints comme plus qu'un simple planning, et adopter la discipline, les valeurs et l'esprit collaboratif qui les sous-tendent, c'est ce qui libère leur potentiel.

Pour les chefs de projet travaillant dans des environnements agiles, le défi consiste à soutenir sans contrôler — à créer un espace pour des équipes autonomes tout en garantissant l'alignement et la concentration. Bien fait, cet équilibre mène non seulement à des Sprints réussis, mais à des équipes constamment performantes et à un succès de projet durable.