Contrairement à ce que l’on peut lire ici ou là, la méthode agile n’existe pas. L’agilité est avant tout un état d’esprit basé sur des valeurs et des principes. Il existe différents frameworks et méthodes qui vont aider à implémenter ces valeurs et principes agiles, et non une méthode agile unique. Tel framework agile sera plus adapté à tel contexte que tel autre framework. Ces méthodologies ne sont d’ailleurs pas exclusives ; il est tout à fait possible, voir même encouragé de les combiner pour tirer le meilleur parti de chacunes en fonction des problématiques posées par le contexte.

Il existe de nombreux frameworks et méthodes qui s’intéressent à l’organisation et au fonctionnement d’une équipe agile. Toutefois, certains sont plus connus que d’autres et plus répandus.

Scrum est la méthodologie agile la plus connue et la plus répandue. C’est d’ailleurs certainement pour cela qu’il y’a souvent un amalgame entre Scrum et « la méthode agile ». Très adapté à la construction d’un produit logiciel ou non, Scrum se définit comme un cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes. Pour cela, Scrum définit :
• Des rôles : Scrum Master, Product Owner et Developer qui forment à eux trois une équipe Scrum
• Des rituels qui rythment le travail d’une équipe Scrum tout au long des itérations qu’on appelle des sprints : le Sprint Planning, le Daily Scrum, la Sprint Review et la Sprint Retrospective
• Des artefacts : le Product Backlog qui permet de structurer, découper et ordonner selon la valeur qu’ils apportent les besoins auxquels le produit en construction doit répondre, le Sprint Backlog qui rassemble le « pourquoi » (l’Objectif de sprint), le « quoi » (les éléments du Product Backlog embarqués dans un sprint) et le « comment » (le plan de réalisation de l’incrément de produit à développer lors du sprint) de chaque sprint, l’incrément de produit qui est le résultat du travail de l’équipe Scrum lors de chaque sprint

Kanban est une approche moins normative que Scrum dans le sens où elle ne définit pas de nouveaux rôles ou des rituels comme Scrum. Kanban est basé sur le concept de flux tiré, c’est-à-dire que l’objectif est de tirer au plus vite les besoins à réaliser d’un état « A faire » vers un état « Fini » et non de pousser des éléments à faire comme dans Scrum. Contrairement à Scrum qui définit des blocs de temps rythmant l’équipe (les sprints), Kanban fonctionne sur un mode flux continu. Kanban revient à gérer le travail d’une équipe comme un flux et utilise de nombreux indicateurs et outils liés au flux pour aider l’équipe à optimiser son travail et son organisation : le débit, le temps de cycle, la limitation du travail en cours… Kanban est mieux adapté que Scrum dans certains contextes, comme les activités de support, mais pas que.

Scrumban, comme son nom l’indique, mixe Scrum et Kanban. L’idée est de profiter de l’avantage des deux méthodologies. Il existe plusieurs applications possibles de Scrumban : par exemple, utiliser Scrum pour la partie développement de produit et Kanban pour les activités de support pour une équipe réalisant ces deux activités ; ou travailler avec le cadre Scrum en introduisant des pratiques et des métriques venant de Kanban pour améliorer le flux de travail d’une équipe.

eXtreme Programming, ou plus communément appelée XP, est très complémentaire aux approches précédentes car elle met plus le focus sur les pratiques d’ingénierie logicielle qui vont améliorer la réalisation du produit logiciel. Le principe de XP est de pousser à l’extrême ce qui a été identifié comme bonne pratiques dans le développement de logiciels. Ainsi, XP implique la pratique du pair programming tout le temps ou promeut les pratiques d’intégration continue, de test first et de refactoring en continu. XP n’en oublie pas pour autant l’aspect gestion de projet. Par exemple, la pratique du poker planning très utilisé par les équipes Scrum vient à la base d’eXtreme Programming.