Qu'est-ce qu'une méthodologie Agile ?

En répondant à la question « qu'est-ce qu'une méthodologie agile ? », je vais essayer de clarifier certains défis linguistiques qui ont tendance à compliquer les choses. Par exemple, y a-t-il une différence entre Agile (avec un A majuscule) et agile (avec un a minuscule) ?  Et que voulons-nous dire par méthode, framework ou méthodologie et est-ce que cela importe ?

Les opinions sur ce qui précède diffèrent, donc j'utiliserai le concept d'agilité pour aider à répondre car c'est un mot qui surplombe tout cela sans être controversé.

L'agilité est définie comme la capacité à penser et à agir rapidement et facilement. Dans le contexte de la planification et de l'exécution du travail, l'agilité englobe le concept de changement continuel. Elle est particulièrement précieuse dans un environnement où un certain degré de volatilité, d'incertitude, de complexité ou d'ambiguïté rend difficile la formulation et l'exécution de plans détaillés rigides.

Certaines personnes voient « Agile » comme définissant une façon de travailler, tandis que d'autres y voient une description d'une façon de penser ou de se comporter. Certaines tentent même d'utiliser la majuscule d'Agile par rapport à agile pour différencier ces approches. Cela seul peut alimenter des heures de débat parfois divertissant, mais plus souvent frustrant, sur ce qui est le plus important ou le plus précieux – faire de l'Agile ou être agile ?

Personnellement, je préférerais me concentrer sur le terrain d'entente – en reconnaissant que la pensée et l'action sont étroitement liées. En fait, étant donné la définition précédente de l'agilité, en particulier l'aspect lié à la réactivité, il ne devrait même pas être possible de « faire de l'Agile » en l'absence de réflexion. De plus, sans action subséquente, l'agilité de pensée n'a aucune valeur tangible, si ce n'est peut-être l'apprentissage par observation. Ainsi, toute façon de travailler véritablement agile doit combiner les perspectives humaines et processuelles pour être efficace.

Avant de partager mon point de vue à ce sujet, il convient de préciser que les mots méthode, framework et approche sont souvent utilisés de manière interchangeable avec méthodologie.

Framework est le plus souvent utilisé dans un contexte de marque avec, par exemple, Scrum, AgilePM et SAFe qui se décrivent tous comme des frameworks. Les autres termes sont plus souvent utilisés lorsqu'on parle de l'agilité en termes plus généralisés.

Les meilleurs frameworks agiles décrivent des combinaisons spécifiques de valeurs, principes, processus, pratiques, rôles, responsabilités et produits de travail ou artefacts de soutien. Les valeurs, principes, rôles et responsabilités traitent des aspects humains de l'agilité, tandis que les processus, pratiques et produits de travail fournissent la structure et les mécanismes de livraison.

Parmi les frameworks agiles les plus populaires, on trouve :

Scrum est un cadre de travail agile utilisé principalement dans la création de produits. Il trouve ses origines dans le domaine du développement logiciel et c'est là qu'il est encore le plus utilisé. Contrairement au langage courant, ce n'est PAS une méthodologie de gestion de projet car elle n'aborde aucun aspect de la gestion de projet. Il se concentre exclusivement sur la livraison de produits où il excelle véritablement.

Scrum comprend un ensemble de 5 valeurs (Engagement, Concentration, Ouverture, Respect et Courage) fortement axées sur les aspects humains de l'agilité. Elles décrivent un ensemble de comportements idéaux que chaque membre d'une équipe Scrum devrait essayer d'adopter et de soutenir chez les autres. Scrum définit également trois rôles au sein du cadre de travail :

• Un Product Owner responsable d'identifier et de prioriser le travail pour livrer une valeur optimale de manière précoce et fréquente ;
• Plusieurs Développeurs qui s'auto-organisent pour livrer des Incréments de valeur du produit ; et
• Un Scrum Master qui aide toute l'équipe à tirer le meilleur parti de la méthode de travail agile que Scrum décrit.

La livraison de produit est orchestrée dans un cycle de développement simple et répétitif appelé Sprint. Les Sprints sont généralement courts – d'une durée d'un mois ou moins. Chaque cycle commence par des événements (réunions courtes et ciblées) pour convenir et planifier le travail. Il se termine par des événements pour examiner ce qui a été livré et explorer comment le produit et la façon de travailler peuvent être améliorés. Chaque jour, il y a une réunion Daily Scrum de 15 minutes utilisée par les Développeurs pour maintenir un focus sur la livraison de leur Objectif de Sprint convenu et ajuster les détails fins de leurs plans en conséquence.

Scrum met l'accent sur l'empirisme dans le contrôle de ses processus - un autre fondement humain clé de la véritable méthodologie agile. Au fur et à mesure que le développement progresse, l'équipe est censée exploiter la transparence offerte par les événements et artefacts Scrum. Basée sur l'inspection de ceux-ci, elle devrait continuellement adapter ce qu'elle fait pour optimiser la livraison de valeur. La transparence, l'inspection et l'adaptation sont les trois piliers du contrôle de processus empirique.

Certaines personnes considèrent Kanban comme une approche lean du développement plutôt qu'agile. Bien qu'il puisse y avoir un mérite technique à cet argument, pour la plupart des objectifs, c'est sans importance. Comme Scrum, Kanban décrit une façon de travailler qui se concentre sur la livraison de valeur tôt et souvent, encourage la collaboration entre les membres de l'équipe et les habilite à gérer les détails de leur travail.

Une différence clé entre Scrum et Kanban est que le processus Kanban est un flux continu de travail plutôt que des cycles répétés. Les membres de l'équipe tirent un élément de travail d'un backlog dès qu'ils ont terminé l'élément précédent. Contrairement à Scrum, qui préfère que les membres de l'équipe soient polyvalents (multi-compétents), les transferts d'une personne à une autre en Kanban sont plus courants. Le nombre d'éléments de Travail en Cours (TEC) est délibérément restreint, encourageant les membres de l'équipe à collaborer pour résoudre les problèmes lorsque la limite TEC est atteinte.

Les aspects comportementaux humains de Kanban sont guidés par six pratiques fondamentales : Visualiser le travail ; Limiter le Travail en Cours ; Gérer le flux ; Rendre les politiques explicites ; Implémenter des boucles de rétroaction ; S'améliorer collaborativement ; et Évoluer expérimentalement.

Comme en Scrum, un backlog ordonné est maintenu pour guider et façonner le travail des développeurs. Contrairement à Scrum, la planification, les revues et les rétrospectives ne sont pas liées aux cycles de développement. Des analogues de ceux-ci existent cependant en Kanban et sont généralement organisés selon une cadence pré-convenue et incluent un Daily Stand-up. Le tableau ci-dessous décrit les événements Scrum et leurs analogues Kanban.

SAFe – le Scaled Agile Framework – est un peu différent car, comme son nom l'indique, il aborde une vision beaucoup plus large. Il est spécifiquement conçu pour étendre les pratiques agiles à travers de grandes entreprises.

Tandis que Scrum et Kanban conviennent bien aux équipes individuelles, SAFe fournit une structure pour coordonner plusieurs équipes agiles, souvent à travers les départements et les chaînes de valeur, dans la livraison de produits et solutions complexes.

SAFe s'appuie sur les principes fondamentaux agiles et lean – puisant dans des frameworks comme Scrum, Kanban et le Lean Product Development – et les intègre dans une hiérarchie structurée. Il aborde non seulement la livraison au niveau de l'équipe mais aussi l'alignement stratégique, la gouvernance, la budgétisation et la collaboration inter-équipes.

Les rôles clés dans SAFe incluent :

• Équipes Agiles (suivant Scrum ou Kanban),
• Product Owner et Scrum Master (au niveau de l'équipe),
• Release Train Engineer (RTE) – un leader de style agile pour un Agile Release Train (ART),
• Product Management et System Architect/Engineer – coordonnant les priorités et l'architecture à travers les équipes,
• Lean Portfolio Management – alignant les investissements sur la stratégie.

Le travail est planifié et livré en Program Increments (PI) – typiquement de 8 à 12 semaines – et structuré autour d'événements réguliers basés sur la cadence :

• PI Planning – une session de planification à grande échelle, en face-à-face, qui aligne toutes les équipes sur les objectifs et les dépendances,
• System Demos – qui montrent les progrès intégrés à travers les équipes,
• Inspect & Adapt – une rétrospective structurée pour l'amélioration continue.

SAFe encourage le leadership Lean-Agile, une culture d'apprentissage continu et une pensée centrée sur le client. Bien que plus prescriptif que Scrum ou Kanban, SAFe fournit un échafaudage pour l'échelle, permettant aux organisations de maintenir l'agilité tout en gérant la complexité et l'alignement au niveau de l'entreprise.

AgilePM se distingue également par le fait qu'il se concentre sur un contexte de projet plutôt que de produit, traitant tous les aspects classiques de la gestion de projet mais d'une manière fondamentalement agile. Il équilibre tous les avantages de l'agilité avec la rigueur des disciplines de gestion de projet plus traditionnelles.

Il convient particulièrement bien aux organisations telles que celles du secteur public, des services financiers ou d'autres industries réglementées qui exigent une assurance des parties prenantes, des rôles et responsabilités définis, et un environnement de livraison contrôlé.

AgilePM inclut des éléments de mise à l'échelle pour plusieurs équipes auto-organisées et se concentre sur la livraison de valeur. Contrairement à la plupart des approches agiles, cependant, il se concentre sur les résultats plutôt que sur les livrables, englobant tout le travail nécessaire pour réaliser la valeur plutôt que de simplement livrer quelque chose qui devrait être précieux.

Comme tout bon cadre agile, il inclut à la fois des éléments humains et processus, tous identifiés dans le diagramme ci-dessous.

Ayant résumé certains des frameworks agiles les plus importants, il est maintenant temps de revenir sur le terme méthodologie.

Pour beaucoup, méthodologie est simplement un autre mot pour framework, mais je préfère creuser un peu plus profondément la valeur supplémentaire que ce mot pourrait transmettre. De nombreuses sources définissent la méthodologie comme « l'étude, l'analyse ou l'application de méthodes ». Ainsi, une méthodologie agile pourrait être interprétée un peu différemment d'un framework dans ce contexte pour inclure une véritable compréhension de ce qui fait qu'un framework particulier fonctionne, et pourquoi.

Ces derniers temps, certaines organisations semblent être devenues désenchantées par l'« agile », se détournant souvent d'investissements importants qui ont échoué à tenir les promesses faites. Pourquoi cela ? Est-ce parce que les frameworks agiles ne fonctionnent pas ? Est-ce parce que trop de choses ont été promises ? Ou est-ce par manque d'attention à la méthodologie ?

Je suis impliqué dans l'agilité depuis son émergence au milieu des années 1990, implémentant, adaptant et même créant des frameworks agiles. Ayant vécu, et parfois dirigé, le bon, le mauvais et le pire des initiatives visant à améliorer les performances grâce à l'agilité, je pense que cette dernière option pourrait être la plus proche de la vérité.

Comme je l'ai mentionné précédemment, l'attention aux dimensions humaines et processus de tout framework agile doit être prise en compte.  La partie processus est facile… Travailler par courtes périodes à partir d'un backlog de travail priorisé, tenir des revues de produit fréquentes pendant le développement, tenir des réunions d'équipe « debout » de 15 minutes chaque jour, etc.

La partie humaine est beaucoup plus délicate. Une véritable compréhension des aspects personnels et interpersonnels de la façon de travailler agile est nécessaire si le potentiel de tout framework doit être réalisé. Ceux-ci incluent :

Toutes les approches agiles mettent l'accent sur l'auto-organisation (ou l'autogestion) au niveau de l'équipe. Le principe sous-jacent est que ceux qui sont les plus proches du travail sont les mieux qualifiés pour décider de la meilleure façon de l'accomplir. Ajoutez à cela le besoin de réagir rapidement à des changements relativement mineurs dans l'environnement de travail et l'auto-organisation devient essentielle à la méthode de travail agile.  Les deux dimensions de ceci sont l'autonomisation et l'appropriation.

L'autonomisation concerne le degré d'autonomie et d'autodétermination dont disposent les équipes et les individus au sein des équipes. Elle doit équilibrer l'autorité sur quoi faire, quand et comment, pour atteindre un objectif convenu, avec la compétence pour le faire efficacement. 

Ceci est contrebalancé par l'appropriation. Les individus et les équipes qui sont autonomisés pour s'approprier leur travail de cette manière montrent de meilleures performances et productivité, et une satisfaction professionnelle accrue comparés à ceux dont le travail est contrôlé par d'autres.

Un bon leader agile (traditionnellement, un manager) travaillera donc à assurer une autonomisation optimale de ses équipes.

Parmi les caractéristiques des êtres humains qui nous distinguent de la plupart des autres espèces animales figure notre capacité à collaborer pour résoudre des problèmes. La collaboration est alimentée par nos compétences avancées en communication – principalement notre capacité à partager des pensées et des idées par le langage. Toutes les approches agiles ont le travail collaboratif au cœur de leur démarche et s'appuient sur la transparence soutenue par une communication claire, ouverte et honnête sur tous les aspects du travail entrepris. Il s'agit d'une exigence essentielle au sein d'une équipe agile et cela devrait également être la norme pour la communication externe.

C'est là que la méthodologie entre vraiment en jeu… L'une des principales causes d'échec des initiatives de transformation agile découle d'un manque d'application intelligente et pragmatique. Cela renvoie au fondement humain essentiel de l'agilité. Si vous traitez Scrum, AgilePM ou tout autre framework agile purement comme un ensemble de processus à suivre, vous risquez de ne pas en tirer beaucoup de valeur.

Le succès complet avec tout framework agile nécessite l'empirisme. C'est-à-dire qu'il nécessite une transparence continue et une inspection et adaptation perpétuelles :

• La transparence à la fois de l'approche suivie et des progrès réalisés vers les objectifs souhaités est essentielle. Elle est nécessaire pour permettre…
• L'inspection de ces deux éléments. Plus spécifiquement, analyser si toutes les personnes impliquées comprennent la façon de travailler et appliquent correctement le framework choisi et si les résultats et les issues sont conformes aux attentes. Ceci est nécessaire pour permettre une… efficace
• Adaptation. Qui peut aussi concerner l'adaptation des personnes ou du processus.
  • Les personnes nouvelles à une façon de travailler agile la trouveront probablement assez différente de leur façon de travailler précédente. Les membres de l'équipe ET les parties prenantes externes à l'équipe devront probablement ajuster leur façon de travailler.
  • Les processus et pratiques par défaut du framework pourraient nécessiter d'être adaptés pour des résultats optimaux. Toute adaptation qui permet à l'équipe d'être plus efficiente et efficace dans l'atteinte des objectifs finaux business devrait être considérée. Avec l'agilité, il ne devrait y avoir aucune crainte d'expérimentation à cet égard.

AgilePM est le premier, et sans doute le meilleur framework de Gestion de Projet Agile. Il décrit la gestion de projet agile comme une approche flexible et itérative pour gérer les projets. Il est conçu pour relever les défis d'environnements modernes et dynamiques. AgilePM se concentre sur la livraison de valeur métier précoce et continue tout en embrassant le changement et l'incertitude tout au long du cycle de vie du projet. Contrairement aux méthodes traditionnelles qui s'appuient fortement sur une planification détaillée en amont et supposent un environnement stable, AgilePM est conçu pour prospérer dans des conditions de volatilité, d'incertitude, de complexité et d'ambiguïté (VUCA).

Dans les projets agiles, les personnes, la collaboration et les solutions opérationnelles sont privilégiées par rapport aux processus rigides et à la documentation. AgilePM intègre les valeurs du Manifeste Agile – auxquelles toutes les approches véritablement agiles se conforment – dans un contexte de projet plus large, s'étendant au-delà du développement logiciel pour s'appliquer à divers projets métier.

AgilePM met l'accent sur le développement itératif de la solution métier, la délimitation temporelle du travail et l'engagement fréquent des parties prenantes pour s'assurer que les solutions évoluent en réponse aux retours du monde réel plutôt qu'aux exigences fixes définies dès le départ. Mais AgilePM va au-delà. Il ne se limite pas à superviser le développement de produits mais inclut la garantie de réalisation de valeur en alignant les ressources, en gérant les risques et en maintenant la gouvernance. Le framework soutient la planification et la prise de décision juste-à-temps, encourageant la flexibilité et l'adaptabilité tout en fournissant des contrôles robustes et une responsabilité.

Dans l'ensemble, la Gestion de Projet Agile, illustrée par AgilePM, est une approche disciplinée mais adaptable aux projets qui équilibre agilité et gouvernance. Elle est particulièrement efficace pour les projets où le changement est attendu et où la valeur client est un objectif central. Elle aide à permettre l'agilité métier en permettant aux organisations de répondre rapidement et de manière responsable aux besoins changeants sans compromettre la qualité ou l'orientation stratégique.

L'agilité d'entreprise est la capacité d'une organisation à s'adapter rapidement aux changements du marché et de l'environnement de manière productive et rentable. Elle met l'accent sur la réactivité, l'innovation et la centralité client, permettant aux organisations de prospérer dans l'incertitude et le changement.

Historiquement, ce concept s'inspire de penseurs comme Alvin Toffler et Peter Drucker, qui ont souligné la nécessité de l'adaptabilité et de l'innovation face aux changements rapides. Le terme « agilité d'entreprise » a gagné en notoriété au début des années 2000, influencé par le mouvement du développement logiciel agile, et a depuis évolué pour englober des pratiques organisationnelles plus larges.

Les aspects clés de l'agilité d'entreprise incluent :

• Orientation client : Les organisations agiles privilégient la création de valeur pour les clients de manière efficace, utilisant des retours continus pour améliorer l'expérience client.
• Flexibilité et adaptabilité : Ces organisations peuvent ajuster rapidement les processus et structures en réponse aux variations mineures comme aux changements majeurs, s'appuyant sur des employés responsabilisés pour prendre des décisions éclairées.
• Efficacité opérationnelle : En rationalisant les processus et en réduisant le gaspillage, les entreprises agiles atteignent l'efficacité, souvent en responsabilisant les équipes pour qu'elles s'approprient leurs flux de travail.

L'agilité d'entreprise n'est pas une approche universelle ; elle varie d'une organisation à l'autre et même au sein de différents domaines de la même organisation. C'est un parcours continu, nécessitant une culture qui soutient l'apprentissage et l'adaptation permanents. La mise en œuvre de cadres agiles comme Scrum peut être un point de départ, mais la véritable agilité implique un changement de mentalité dans toute l'organisation.

En définitive, l'agilité d'entreprise procure un avantage concurrentiel en permettant aux organisations de répondre rapidement aux demandes du marché, d'innover en continu et de fournir une valeur durable aux clients.

Beaucoup de personnes utilisent les termes méthodologie agile, méthode agile et framework agile de manière interchangeable. C'est très bien – c'est ainsi que va le monde. Cela dit, je pense que méthodologie suggère un approfondissement du pourquoi et du comment les méthodes et frameworks fonctionnent.

Beaucoup obtiendront des améliorations modestes de performance grâce à une implémentation relativement « irréfléchie » d'un framework agile tel que Scrum ou AgilePM « prêt à l'emploi ». Pour beaucoup d'entre eux, cela constituera une récompense suffisante, mais pour ceux qui rêvent d'une amélioration radicale, « vivre l'agilité » plutôt que « faire de l'agilité » est une étape suivante essentielle.  

Ceci peut être réalisé en exploitant les fondements empiriques de tous les meilleurs frameworks – en tirant parti de la transparence et de l'apprentissage par l'inspection et l'adaptation expérimentale qui sous-tendent la façon agile de travailler.

Bien que des améliorations significatives puissent être réalisées relativement rapidement, adopter l'agilité n'est pas toujours facile car cela nécessite généralement un changement de comportement au sein et autour des équipes de livraison. Optimiser l'agilité est un voyage sans fin, et il convient de noter que l'adaptation dans les aspects humains de la façon de travailler plutôt que dans les aspects processuels est susceptible de débloquer les récompenses les plus riches.