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 à faire obstacle. 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, alors j'utiliserai le concept d'agilité pour aider à répondre car c'est un mot qui surplombe tout cela sans être polémique.

L'agilité se définit comme la capacité de penser et de se mouvoir rapidement et facilement. Dans le contexte de la planification et de l'exécution du travail, l'agilité embrasse le concept de changement continu. 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 le voient comme décrivant une façon de penser ou de se comporter. Certains tentent même d'utiliser la capitalisation d'Agile versus agile pour différencier entre ces concepts. Cela seul peut alimenter des heures de débats parfois divertissants, mais plus souvent frustrants, 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 – reconnaissant que penser et faire sont étroitement liés. En fait, étant donné la définition antérieure 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é dans la pensée n'a aucune valeur tangible, sauf peut-être l'apprentissage par observation. Ainsi, toute façon de travailler véritablement agile doit combiner à la fois les perspectives humaines et processus si elle veut être efficace.

Avant de partager mon point de vue à ce sujet, il est préférable 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 en termes plus généralisés d'agilité.

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 support. 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 pour la 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. Elle se concentre exclusivement sur la livraison de produits, domaine où elle 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 chacun dans une équipe Scrum devrait essayer d'adopter lui-même et 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 façon 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 décrit Scrum.

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 pour 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 l'attention 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, cela n'a pas d'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 à l'autre dans Kanban sont plus courants. Le nombre d'éléments de Travail en Cours (WiP) est délibérément restreint, encourageant les membres de l'équipe à collaborer pour résoudre les problèmes lorsque la limite WiP 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 ; Améliorer de manière collaborative ; et Évoluer de manière expérimentale.

Comme dans 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 celles-ci existent cependant dans Kanban et sont généralement organisés selon une cadence pré-convenue et incluent un Stand-up quotidien. 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 perspective beaucoup plus large. Il est spécifiquement conçu pour faire évoluer les pratiques agiles à l'échelle des grandes entreprises.

Alors 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 Lean Product Development – et les intègre dans une hiérarchie structurée. Il aborde non seulement la livraison au niveau des équipes, mais aussi l'alignement stratégique, la gouvernance, la budgétisation et la collaboration inter-équipes.

Les rôles clés dans SAFe incluent :

• Les É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é par Program Increments (PI) – généralement 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 présentiel, 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 réflexion centrée sur le client. Bien que plus prescriptif que Scrum ou Kanban, SAFe fournit un échafaudage pour la mise à l'échelle, permettant aux organisations de maintenir leur 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 les gouvernements, les services financiers ou d'autres secteurs réglementés 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 vers 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 processuels, tous identifiés dans le diagramme ci-dessous.

Après avoir résumé quelques-uns des frameworks agiles les plus significatifs, c'est le bon moment pour revenir au terme méthodologie.

Pour beaucoup, méthodologie n'est qu'un autre mot pour framework, mais je préfère approfondir la valeur supplémentaire que ce mot pourrait véhiculer. 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 fonctionner un framework particulier, et pourquoi.

Récemment, certaines organisations semblent être devenues désenchantées par l'« agile », se détournant souvent d'investissements importants qui n'ont pas réussi à tenir les promesses faites. Pourquoi cela ? Est-ce parce que les frameworks agiles ne fonctionnent pas ? Est-ce parce que trop de promesses ont été faites ? 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 laid d'initiatives visant à améliorer les performances grâce à l'agilité, je pense que la dernière de ces raisons pourrait être la plus proche de la vérité.

Comme je l'ai mentionné auparavant, l'attention portée aux dimensions humaines et processuelles de tout framework agile doit être prise en compte.  La partie processus est facile… Travailler par courtes périodes à partir d'un carnet de travail priorisé, organiser des revues de produit fréquentes pendant le développement, tenir des réunions d'équipe « stand-up » 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. L'hypothèse sous-jacente est que ceux qui sont les plus proches du travail devraient être les mieux qualifiés pour décider de la meilleure façon de le faire. Ajoutez à cela le besoin de répondre 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 que possèdent 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 prendre possession de 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 pour 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 fonctionnement 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 par défaut 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 si important de l'agilité. Si vous traitez Scrum, AgilePM ou tout autre framework agile purement comme un ensemble de processus à suivre, vous n'en tirerez probablement pas beaucoup de valeur.

Le succès complet avec n'importe quel 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 précisément, 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 outcomes sont conformes aux attentes. Ceci est nécessaire pour permettre une... efficace
• Adaptation. Qui peut également concerner l'adaptation des personnes ou des 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. À la fois 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 permettant à l'équipe d'être plus efficiente et efficace dans l'atteinte des objectifs métier finaux 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 cadre de référence pour la Gestion de Projet Agile. Il décrit la gestion de projet agile comme une approche flexible et itérative de la gestion de projets. Il est conçu pour répondre aux défis des environnements modernes et dynamiques. AgilePM se concentre sur la livraison de valeur métier de manière 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 fonctionnelles sont privilégiées par rapport aux processus rigides et à la documentation. AgilePM intègre les valeurs du Manifeste Agile – auxquelles se conforment toutes les approches véritablement agiles – 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éfinition de créneaux temporels pour le 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'à des exigences fixes définies dès le départ. Mais AgilePM va au-delà de cela. Il ne se limite pas à superviser le développement de produits mais inclut la garantie de la réalisation de valeur en alignant les ressources, en gérant les risques et en maintenant la gouvernance. Le cadre de référence 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 responsabilisation.

Dans l'ensemble, la Gestion de Projet Agile, illustrée par AgilePM, est une approche disciplinée mais adaptable des projets qui équilibre l'agilité avec la 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 à favoriser 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 l'orientation client, permettant aux organisations de prospérer dans l'incertitude et le changement.

Historiquement, le 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 importance au début des années 2000, influencé par le mouvement de développement logiciel Agile, et a depuis évolué pour englober des pratiques organisationnelles plus larges.

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

• Orientation client : Les organisations agiles privilégient la livraison de valeur aux clients de manière efficace, en utilisant les retours continus pour améliorer l'expérience client.
• Flexibilité et adaptabilité : Ces organisations peuvent ajuster rapidement leurs processus et structures en réponse à la fois aux variations mineures et aux changements significatifs, en s'appuyant sur des employés autonomisé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 autonomisant les équipes pour qu'elles prennent en charge leurs flux de travail.

L'agilité d'entreprise n'est pas une approche universelle ; elle varie selon les organisations et même au sein de différents domaines d'une 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 fin de compte, l'agilité d'entreprise offre un avantage concurrentiel en permettant aux organisations de répondre rapidement aux demandes du marché, d'innover continuellement et de fournir une valeur durable aux clients.

Beaucoup de personnes utilisent les termes méthodologie agile, méthode agile et cadre de travail agile de manière interchangeable. C'est acceptable – c'est ainsi que va le monde. Cela dit, je crois que la méthodologie suggère une exploration plus approfondie du pourquoi et du comment les méthodes et les cadres de travail fonctionnent.

Beaucoup obtiendront des améliorations modestes de performance grâce à une mise en œuvre relativement « automatique » d'un cadre de travail agile tel que Scrum ou AgilePM « prêt à l'emploi ». Pour beaucoup d'entre eux, cette récompense sera suffisante, mais pour ceux qui rêvent d'une amélioration radicale, « vivre agile » plutôt que « faire de l'agile » est une étape suivante essentielle.  

Cela peut être accompli en exploitant les fondements empiriques de tous les meilleurs cadres de travail – en tirant parti de la transparence et de l'apprentissage à travers l'inspection et l'adaptation expérimentale qui sous-tendent la méthode de travail agile.

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 vaut la peine de noter que l'adaptation des aspects humains de la méthode de travail plutôt que des aspects processus est susceptible de débloquer les récompenses les plus riches.