Agile comme approche métier

Agile est une approche permettant de gérer un travail incertain au moyen de cycles d’apprentissage courts, d’une collaboration étroite et d’une livraison fréquente de valeur. Cette approche est apparue comme une alternative aux modèles de projet qui tentent de définir la solution complète dès le départ et considèrent tout changement ultérieur comme un échec. Agile ne signifie pas travailler sans plan. Il s’agit de planifier à plusieurs niveaux, de tester les hypothèses rapidement et de réviser les décisions lorsque les données observées évoluent.

Le Manifeste Agile exprime quatre préférences en matière de valeurs : les individus et leurs interactions plutôt que les processus et les outils, des solutions opérationnelles plutôt qu’une documentation exhaustive, la collaboration avec les clients plutôt que la négociation contractuelle, et l’adaptation au changement plutôt que le suivi d’un plan. Les éléments situés à droite restent importants, mais ils doivent contribuer aux résultats plutôt que devenir eux-mêmes des finalités. Par exemple, un plan de projet est utile lorsqu’il aide les parties prenantes à se coordonner. Il devient préjudiciable lorsqu’une équipe continue de livrer un périmètre à faible valeur uniquement parce que celui-ci figurait dans le plan initial.

Les douze principes Agile traduisent ces valeurs en lignes directrices opérationnelles. Parmi les thèmes importants figurent la livraison précoce et continue de valeur, l’acceptation de l’évolution des exigences, les livraisons fréquentes, la collaboration quotidienne entre les équipes métier et techniques, un rythme soutenable, l’excellence technique, la simplicité, les équipes auto-organisées et la réflexion régulière. Du point de vue de l’entreprise, ces principes réduisent le délai entre une décision d’investissement et l’obtention de données fiables indiquant si cette décision crée de la valeur.

Framework Scrum et empirisme

Scrum est un framework léger permettant d’appliquer les idées d’Agile à la livraison de produits complexes. Il repose sur l’empirisme, ce qui signifie que les décisions sont fondées sur l’observation et l’expérience plutôt que sur des prévisions non étayées. Ses trois piliers sont la transparence, l’inspection et l’adaptation. Le travail, les objectifs, les attentes en matière de qualité et les problèmes doivent être suffisamment visibles pour pouvoir être inspectés. L’inspection doit ensuite conduire à des ajustements rapides lorsque les résultats diffèrent des attentes.

Scrum organise le travail en Sprints, des périodes de durée fixe d’un mois ou moins. Chaque Sprint constitue un cycle d’apprentissage complet au cours duquel la Scrum Team poursuit un Sprint Goal et crée au moins un Increment utilisable. Les cycles courts limitent les risques, car les parties prenantes n’ont pas à attendre plusieurs mois pour découvrir qu’une fonctionnalité ne résout pas le bon problème. Un Sprint de deux semaines, par exemple, peut permettre de vérifier si un parcours d’intégration client simplifié réduit le taux d’abandon avant que l’entreprise ne finance une automatisation plus avancée.

Scrum est intentionnellement incomplet. Il définit un ensemble minimal de responsabilités, d’événements et d’artefacts, mais ne prescrit ni procédures de projet détaillées, ni intitulés de poste, ni configurations Jira. Une organisation peut utiliser des prévisions, des études, des indicateurs de niveau de service et des contrôles de gouvernance parallèlement à Scrum, à condition que ces pratiques ne compromettent pas la transparence, la responsabilisation de l’équipe ou sa capacité d’adaptation.

Responsabilités de l’équipe Scrum

Une équipe Scrum se compose d’un Product Owner, d’un Scrum Master et de Developers. L’équipe est pluridisciplinaire, ce qui signifie qu’elle possède collectivement les compétences nécessaires pour créer de la valeur, et autogérée, ce qui signifie que ses membres décident qui fait quoi, quand et comment. Les parties prenantes peuvent définir des contraintes et les résultats attendus, mais elles ne doivent pas répartir les tâches quotidiennes entre les membres de l’équipe.

Le Product Owner est responsable de maximiser la valeur du produit et de gérer efficacement le Product Backlog. Cela comprend la communication du Product Goal, la création ou la clarification des éléments du Product Backlog, leur ordonnancement et la garantie de la transparence du backlog. Le Product Owner peut déléguer certaines activités, mais il conserve la responsabilité qui lui incombe. Dans le cadre d’un projet de portail client, cette personne pourrait donner la priorité à la récupération de mot de passe plutôt qu’à la personnalisation du profil, car les données du support montrent que les problèmes d’accès engendrent des coûts et une frustration plus importants pour les clients.

Les Developers sont responsables de créer un Increment utilisable à chaque Sprint, de planifier le travail du Sprint, de maintenir la qualité au moyen de la Definition of Done et d’adapter leur plan quotidiennement. Le Scrum Master est responsable d’établir Scrum conformément à sa définition et d’améliorer l’efficacité de l’équipe Scrum. Le Scrum Master accompagne l’équipe, facilite les échanges lorsque cela est utile et contribue à supprimer les obstacles systémiques. Il ne s’agit pas d’un rôle de chef de projet fondé sur le commandement et le contrôle, et le Scrum Master n’attribue pas les tâches ni n’approuve le travail terminé.

Événements Scrum et décisions associées

Le Sprint Planning lance le Sprint en répondant aux questions suivantes : pourquoi le Sprint est-il utile, que peut-on réaliser et comment le travail sélectionné sera-t-il effectué ? Le Sprint Goal qui en résulte fournit à l’équipe un objectif cohérent, plutôt qu’une liste disparate de tickets. Les Developers prévoient le travail qu’ils peuvent réaliser en tenant compte de la capacité disponible, des performances passées, des dépendances et de la Definition of Done. Le Product Owner apporte le contexte lié à la valeur et aux priorités, mais n’impose pas d’engagement sur le périmètre.

Le Daily Scrum est un événement de quinze minutes au cours duquel les Developers inspectent leur progression vers le Sprint Goal et adaptent leur plan. Il ne s’agit pas d’un rapport d’avancement destiné au Scrum Master ni d’un tour de table obligatoire fondé sur trois questions prédéfinies. Un Daily Scrum utile permet de déterminer si le travail en cours contribue toujours à l’objectif, de faire émerger les besoins de coordination et de déclencher des échanges de suivi, sans transformer l’événement en une longue réunion de résolution de problèmes.

La Sprint Review examine le résultat du Sprint avec les parties prenantes et détermine les adaptations à venir. Elle doit être une séance de travail consacrée aux éléments probants, aux évolutions du marché et aux prochaines priorités, et non une simple démonstration ou une étape d’approbation. La Sprint Retrospective se concentre sur l’efficacité de l’équipe, notamment les interactions, les processus, les outils et la qualité. L’équipe sélectionne des améliorations concrètes pour le Sprint suivant. Le Sprint contient tous les autres événements et instaure le rythme régulier qui rend l’inspection prévisible.

Artefacts Scrum et engagements

Le Product Backlog est une liste ordonnée et évolutive de ce qui est nécessaire pour améliorer le produit. Son engagement est le Product Goal, une cible à plus long terme qui guide les décisions relatives au backlog. Les éléments proches de la mise en œuvre contiennent généralement davantage de détails que les possibilités plus lointaines. Le backlog refinement est une activité continue visant à décomposer et à clarifier les éléments, mais il ne s’agit pas d’un événement Scrum officiel ni d’une promesse que toute incertitude disparaîtra.

Le Sprint Backlog contient le Sprint Goal, les éléments du Product Backlog sélectionnés pour le Sprint et le plan d’exécution concret des Developers. Son engagement est le Sprint Goal. Les Developers mettent à jour le Sprint Backlog au fil de leurs apprentissages, et le périmètre peut être renégocié avec le Product Owner sans mettre l’objectif en danger. Cette flexibilité distingue une prévision d’un contrat fixe. Seul le Product Owner peut annuler un Sprint, généralement lorsque le Sprint Goal devient obsolète.

L’Increment est le résultat intégré et utilisable du travail terminé. Son engagement est la Definition of Done, une description partagée des mesures de qualité requises pour qu’un travail soit considéré comme terminé. Le travail qui ne satisfait pas à la Definition of Done ne peut pas être présenté comme faisant partie de l’Increment ni être considéré comme terminé. Plusieurs Increments peuvent être créés ou mis en production au cours d’un Sprint ; le calendrier de mise en production relève d’une décision métier et ne doit pas nécessairement attendre la Sprint Review.

Appliquer les fondamentaux avec Jira

Jira peut rendre le fonctionnement de Scrum visible, mais la configuration d’un outil ne peut pas créer l’agilité. Une configuration pratique relie les éléments du Product Backlog aux résultats métier, utilise un tableau pour afficher le workflow actuel et offre à l’équipe une vue partagée de l’avancement du Sprint. L’objectif de Sprint doit rester visible aux côtés des issues sélectionnées afin que les parties prenantes ne confondent pas l’achèvement des tickets avec la finalité du Sprint. Les statuts du workflow doivent représenter des états significatifs, et non chaque transfert mineur.

Prenons l’exemple d’une équipe de services financiers qui cherche à réduire le nombre de demandes d’ouverture de compte incomplètes. Le Product Owner ordonne les éléments du backlog en s’appuyant sur les retours des clients et l’impact attendu. Pendant le Sprint Planning, l’équipe sélectionne le travail contribuant à un objectif tel que la réduction de l’abandon lors de la vérification d’identité. Jira enregistre les éléments sélectionnés et le workflow, tandis que le Daily Scrum utilise ces informations pour identifier les travaux bloqués. Lors de la Sprint Review, l’équipe examine l’Increment utilisable et les premières données relatives aux achèvements. Lors de la Retrospective, elle peut décider d’impliquer plus tôt les spécialistes de la conformité après avoir constaté des retards d’approbation répétés.

La réussite ne doit pas être évaluée uniquement à partir de la vélocité, des story points, du taux d’utilisation ou du nombre d’issues clôturées. Ces mesures peuvent contribuer aux prévisions, mais elles ne prouvent pas la valeur créée. Les équipes doivent combiner des indicateurs de livraison, tels que le cycle time et la prévisibilité, avec des mesures de qualité, le comportement des clients et les résultats métier. Le critère de décision central consiste à déterminer si chaque Sprint produit un résultat utilisable, améliore les connaissances et éclaire la prochaine décision d’investissement.