Quand une organisation décide d’adopter une approche agile, le réflexe le plus courant consiste à déployer Scrum. Ce n’est pas un mauvais choix, mais c’est rarement un choix éclairé. Scrum s’est imposé comme le framework agile par défaut grâce à sa simplicité apparente et à la puissance de son écosystème de certification, pas parce qu’il répond à tous les contextes. Plusieurs alternatives méritent d’être examinées avant de s’engager.
Pourquoi un seul framework ne suffit pas
La gestion de projet agile repose sur un ensemble de principes formalisés dans le Manifeste Agile en 2001: collaboration, adaptation, livraison incrémentale et réponse au changement. Ces principes sont universels, mais leur mise en œuvre varie considérablement selon la taille de l’équipe, la nature du projet et la culture de l’organisation.
Un framework agile est une manière concrète d’appliquer ces principes: il définit des rôles, des événements, des artefacts et des règles du jeu. Le problème survient quand une équipe adopte un framework sans vérifier qu’il correspond à son contexte. Un service de maintenance industrielle qui veut améliorer sa réactivité n’a pas les mêmes besoins qu’une équipe de développement qui livre toutes les deux semaines.
Scrum: le standard, ses forces et ses angles morts
Scrum structure le travail en sprints de durée fixe (généralement deux semaines), avec des rôles définis (Scrum Master, Product Owner, développeurs), des cérémonies régulières et un backlog priorisé. Sa force réside dans la cadence prévisible et la transparence qu’il impose.
Ses limites apparaissent dans les contextes où le travail n’est pas facilement découpable en sprints: maintenance, support, projets de recherche ou activités où les priorités changent quotidiennement. Forcer ces activités dans un cadre de sprint crée de la friction sans apporter de valeur.
Kanban: le flux plutôt que le sprint
Kanban, issu du système de production Toyota, ne prescrit ni sprints, ni rôles, ni cérémonies obligatoires. Son principe central est la limitation du travail en cours (WIP, Work In Progress): chaque étape du processus ne peut contenir qu’un nombre défini de tâches simultanées. Cette contrainte rend les goulets d’étranglement visibles et force leur résolution.
Kanban convient particulièrement aux équipes qui traitent des flux continus de demandes plutôt que des projets délimités: équipes de support, services internes, bureaux d’études. Il s’adapte également bien aux organisations qui veulent améliorer leurs processus existants sans tout restructurer, car il ne demande pas de réorganisation des rôles.
OpenUP: le processus unifié allégé
OpenUP est un framework moins connu, issu du Rational Unified Process (RUP) d’IBM et géré par la Fondation Eclipse. Il conserve les quatre phases du RUP (inception, élaboration, construction, transition) mais les simplifie pour des équipes de 3 à 6 personnes avec des cycles de 3 à 6 mois.
Son intérêt réside dans l’accent mis sur l’architecture dès les premières itérations, ce qui en fait un choix pertinent pour les projets où les décisions techniques structurantes doivent être prises tôt. Il organise le travail sur trois niveaux: le cycle de vie projet (phases), les itérations (semaines) et les micro-incréments (heures à jours).
Les critères de choix qui comptent
Plutôt que de sélectionner un framework sur la base de sa popularité, trois critères méritent une analyse sérieuse.
Le premier est la nature du flux de travail. Si l’équipe travaille sur des projets avec un début et une fin clairs, un framework itératif comme Scrum ou OpenUP s’impose. Si elle gère un flux continu de demandes sans périmètre projet défini, Kanban est plus adapté.
Le deuxième est le degré de maturité agile de l’organisation. Scrum demande un engagement fort: rôles dédiés, cérémonies régulières, réorganisation potentielle. Kanban peut se superposer aux processus existants avec un investissement minimal, ce qui en fait souvent un meilleur point d’entrée pour les organisations qui débutent.
Le troisième est la taille et la distribution de l’équipe. Les frameworks légers fonctionnent bien avec des équipes co-localisées de 5 à 9 personnes; au-delà, la coordination inter-équipes exige des mécanismes supplémentaires que les cadres de base ne fournissent pas.
L’approche hybride: souvent la plus réaliste
En pratique, peu d’organisations appliquent un framework unique dans sa pureté. La combinaison Scrum + Kanban (parfois appelée Scrumban) est courante: les sprints structurent le rythme, les limites WIP de Kanban contrôlent la charge. Certaines équipes utilisent Scrum pour le développement et Kanban pour la maintenance au sein du même programme.
Cette hybridation est saine à condition d’être délibérée et non le résultat d’une adoption partielle par manque de discipline. Choisir consciemment quels éléments de chaque framework adopter, et documenter ces choix, permet de créer un système cohérent adapté au contexte réel de l’équipe.