À la fin des années 90, le développement logiciel est organisé selon des méthodes de gestion de projet lourdes :
documentation interminable, des années de développement avant le déploiement en production, des réunions en silo à rallonge...
Tout est trop long, trop rigide, trop éloigné du client final. Beaucoup de projets sont abandonnés avant même d'être livrés.
En février 2001, 17 développeurs et consultants se retrouvent dans une station de ski à Snowbird, dans l'Utah.
Ils ont tous des expériences, des méthodes de travail et une vision différentes.
Tous partagent néanmoins la même frustration et veulent remettre l'humain et la collaboration au centre du développement.
En un week-end, ils débattent et formulent ce qui deviendra le Manifeste pour le développement Agile de logiciels.
Le Manifeste Agile
Ce manifeste propose 4 valeurs clés et 12 principes généralistes autour desquels organiser les projets et équipes.
Les 4 valeurs de l'Agile :
- Les individus et leurs interactions plus que les processus et les outils.
- Des logiciels opérationnels plus qu'une documentation exhaustive.
- La collaboration avec les clients plus que la négociation contractuelle.
- L'adaptation au changement plus que le suivi d'un plan.
Les 12 principes sous-jacents au manifeste :
- Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
- Accueillez positivement les changements de besoins, même tard dans le développement. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
- Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
- Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
- Réalisez les projets avec des personnes motivées. Fournissez-leur l'environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
- La méthode la plus efficace pour transmettre l'information à l'équipe de développement et à l'intérieur de celle-ci est le dialogue en face à face.
- Un logiciel opérationnel est la principale mesure d'avancement.
- Les processus Agiles encouragent un rythme de développement soutenable. Les commanditaires, les développeurs et les utilisateurs doivent pouvoir maintenir indéfiniment un rythme constant.
- Une attention continue à l'excellence technique et à une bonne conception renforce l'Agilité.
- La simplicité – c'est-à-dire l'art de minimiser la quantité de travail inutile – est essentielle.
- Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
- À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
C'est tout ce que contient le manifeste ! Juste une ligne directrice à suivre.
Le nom Agile est écrit en tant que nom propre pour désigner l'ensemble de la philosophie.
Il vient directement du concept d'agilité, dont l'étymologie résume parfaitement ces valeurs et principes.
Agilis en latin : rapide, vif, qui se meut facilement, qui agit avec facilité.
Qui vient lui-même du verbe "agere" : agir, pousser, faire avancer.
L'évangélisation et la transformation
Suite à l'écriture du manifeste, les 17 signataires repartent chacun dans leurs entreprises et communautés avec
pour objectif de faire vivre Agile.
Le mouvement reste d'abord technique, transmis lors de conférences, sur les blogs et dans les équipes de développement.
Peu à peu, il gagne du terrain et de nouveaux concepts sont développés.
Les entreprises réorganisent alors les équipes techniques et ajustent les autres directions pour fluidifier la communication.
Ce qui n'était que des rôles finit par devenir des métiers à part entière.
La fin des années 2000 voit ainsi l'émergence des scrum masters, coachs Agile, release managers et product owners.
Agile a changé les visions et mentalités sur les façons de travailler, mais aussi et surtout sur ce qui doit être
délivré. On a commencé à mieux se poser les questions sur le produit lui-même.
Qu'est-ce qui apporte réellement de la valeur à l'utilisateur ? Comment le mesurer ? Comment le faire évoluer ?
Au fil du temps, la science du produit est devenue un domaine métier à part entière dans les entreprises :
chefs de produit, designers d'expérience utilisateur... Jusqu'à former une direction autonome, avec autant de poids
que les directions marketing et technique.
Dans les années 2010, Agile devient un mouvement culturel. Les entreprises organisent de grands plans au nom d'une
"transformation Agile". Les coachs Agile sont là pour accompagner les équipes et former les managers.
Les post-it commencent à recouvrir le moindre mètre carré de mur.
Pour les développeurs, tout semble enfin se mettre en place... jusqu'à ce que le rêve tourne au cauchemar.
Agile, qui n'est à la base qu'une philosophie, tourne au dogme dans la majorité des entreprises.
Elles commencent à se copier entre elles et à appliquer bêtement des processus de plus en plus rigides et chronophages.
Les développeurs deviennent minoritaires, entourés de profils qui justifient leur temps en
organisant réunion sur réunion.
On entre dans une période de flicage permanent, avec chaque jour des courbes générées pour tenter de mesurer précisément
un peu tout et n'importe quoi, avec l'obligation de maintenir de multiples tableaux de bord de post-it et de nombreux outils.
La vélocité de développement devient un objectif influençant les salaires, au détriment de la qualité.
La période Covid a calmé les choses. Depuis 2020, les entreprises entrent dans la seconde étape de leur transformation,
l'accent est maintenant mis sur la personnalisation des process.
Les équipes adaptent leurs rituels et leurs méthodes de travail selon leur métier et leur taille.
Elles reviennent peu à peu aux sources de l'agilité, en itérant jusqu'à trouver leur propre organisation optimale.
Agile, un regroupement de pratiques
Avant Agile, les entreprises fonctionnaient surtout en mode projet.
Les décisions venaient de la maîtrise d'ouvrage ou des chefs de projet, qui traduisaient des besoins métiers en spécifications.
Nous avions des décisionnaires et des exécutants.
Chacun restait dans son silo. Les développeurs respectaient bêtement
les spécifications sans rien remettre en cause. Après des mois de travail commençait la phase de tests et de validation.
Et c'est seulement à la fin qu'une première version était poussée aux utilisateurs. C'est ce qu'on appelle un cycle en V.
L'Agilité préconise au contraire une communication constante entre les développeurs et les commanditaires et entre
les développeurs et les utilisateurs. L'organisation des projets et de la conception produit en itérations courtes permet d'avoir
le plus tôt possible des retours sur ce qui fonctionne ou ce qui doit être modifié. Les développeurs peuvent plus facilement
suggérer des améliorations et aider à cette pensée itérative : "telle fonctionnalité ça peut être cool et elle nécessite très peu de travail",
"c'est mieux de sortir ça d'abord, techniquement ça nous fait gagner trois semaines de travail", "attention si on travaille sur ces deux sujets en même temps, on va se marcher sur les pieds"...
Le grand mix
Les équipes souhaitant gagner en Agilité ont pioché dans des pratiques et méthodologies vieilles parfois de plusieurs décennies :
-
Scrum (la mêlée) : cadre de travail formalisé en 1995. Il permet la mise en place d'itérations et de feedbacks rapides.
Scrum découpe le développement en cycles courts appelés sprints, généralement de deux à quatre semaines. À la fin, on livre un incrément fonctionnel, c'est-à-dire une version du produit qui fonctionne réellement.
Scrum est aujourd'hui la structure de référence dans la majorité des équipes produit et technique. C'est de là que proviennent notamment les rôles de Product Owner, de Scrum Master ainsi que la majorité des rituels les plus courants. -
Lean : née du système de production Toyota dans les années 1950, c'est une philosophie visant à éliminer le gaspillage et à se concentrer sur la valeur réelle pour l'utilisateur.
Aujourd'hui, elle inspire la chasse aux tâches et pratiques sans impact : réunions sans objectif, tickets inutiles, code jamais utilisé ou documentation obsolète. Le Lean encourage à mesurer en continu pour apprendre et s'améliorer, que ce soit par des A/B tests sur le produit ou des ROTI en fin de réunion pour évaluer la valeur du temps investi. -
Kanban : lui aussi vient du Toyota des années 50, c'est une application concrète du Lean.
Il repose sur la visualisation du flux de travail et la limitation du nombre de tâches en cours pour éviter l'encombrement. Aujourd'hui, il se traduit par des tableaux où les tâches avancent de colonne en colonne, sur des outils comme Jira ou Trello, permettant de mieux équilibrer la charge et de repérer les blocages en temps réel.
C'est lui le responsable des milliers de post-it qui ont envahi les open-spaces. -
Extreme Programming : créée en 1999 par Kent Beck, l'un des signataires du Manifeste Agile, c'est une méthode centrée sur la qualité du code et le feedback technique rapide.
Elle a mis en lumière certaines des pratiques de développement les plus utilisées aujourd'hui : livrer souvent, intégrer en continu, revoir le code des autres, traiter les problèmes à deux (pair programming) et concevoir le code via des tests (TDD). -
LeSS / SAFe : ce sont des cadres de travail pour une agilité à grande échelle.
Ils introduisent des rituels et tableaux de bord supplémentaires pour que les équipes se coordonnent entre elles et pour que les décisionnaires puissent suivre l'avancée et prendre des décisions avec une vue macroscopique. -
Modèle Spotify : popularisé à partir de 2012, il propose une organisation centrée sur des équipes autonomes, appelées squads, elles-mêmes regroupées par domaines dans des tribes.
Par exemple, je fais actuellement partie d'une squad dédiée au paiement en ligne et à la gestion des abonnements. Elle est elle-même une sous-partie de la tribu qui traite tout ce qui est lié au compte client.
Chaque squad fonctionne comme une mini-startup : elle conçoit, développe et livre son produit de bout en bout. Ce modèle a popularisé l'idée d'équipes produits indépendantes et responsables, capables d'avancer à leur rythme tout en restant alignées sur une vision commune.
Les rituels
La plupart des équipes de développement s'inspirent de Scrum dans leur vie quotidienne, notamment en ce qui concerne les rituels. Le Guide Scrum de 2010 en décrit cinq :
-
Daily : une réunion quotidienne d'une dizaine de minutes pour synchroniser l'équipe, partager les avancées et identifier les blocages.
Le format du daily est l'un des sujets les plus débattus dans les squads. Est-ce que chacun doit raconter sa journée à tour de rôle ? Est-ce qu'au contraire on ne parle que pour partager quelque chose d'important ? Est-ce qu'on le fait à 9h, à 14h ? Est-ce qu'on affiche le tableau de bord des tâches en cours ? - Sprint Planning : à chaque début de sprint, l'équipe choisit les tâches qu'elle embarque et se fixe des objectifs clairs.
- Sprint Review / démo : en fin de sprint, la squad présente le travail réalisé. Le public est généralement composé des demandeurs directs des nouvelles fonctionnalités, mais certains en profitent pour élargir le cercle et partager les avancées avec l'ensemble de l'organisation.
-
Rétrospective : l'équipe se réunit pour identifier ce qui a bien ou mal fonctionné et décider ensemble des actions d'amélioration.
Ce rituel prend souvent des formes originales pour stimuler la participation et la créativité. Quelles sont les voiles et les ancres de notre voilier ? Qu'est-ce qu'on met dans notre maison de paille, de bois ou de pierre ? Chaque fois, l'idée reste la même : revenir sur les points positifs, les difficultés rencontrées et les pistes de progrès pour la suite.
Au fil du temps, les équipes ont ajouté leurs propres rituels en complément de ceux définis par Scrum. Ces moments ne font pas partie du cadre officiel, mais ils sont devenus essentiels dans la pratique quotidienne. Parmi les plus répandus :
-
Refinement : l'équipe challenge le besoin, découpe et estime les tâches, lève les prérequis et s'assure que tout est prêt à être embarqué dans un prochain sprint.
L'estimation est l'un des points de friction les plus courants entre les développeurs et les décisionnaires. C'est un exercice difficile, certains diront même impossible. En 1979, Hofstadter a d'ailleurs énoncé sa loi éponyme : "Il faut toujours plus de temps que prévu, même quand on tient compte de la loi de Hofstadter".
Ces erreurs d'estimation viennent autant de biais humains, comme l'optimisme ou la difficulté à prévoir les imprévus, que de facteurs plus concrets : des tâches qui en cachent d'autres, du temps passé sur autre chose que du code, des jours moins productifs...
Depuis des années, les développeurs tentent ainsi de ne plus exprimer leurs estimations en temps. Au lieu de dire simplement "ça prend 3 jours", ils considèrent d'autres composantes comme la complexité et l'incertitude. Est-ce que le code déjà existant est maîtrisé par l'équipe actuelle ? Est-ce que le besoin est clair ? Est-ce qu'on a confiance dans la documentation du partenaire à intégrer ? En posant les bases d'un système de notation, les développeurs votent en utilisant des tailles de tee-shirts ou la suite de Fibonacci. De mon expérience personnelle, les équipes ont énormément de mal à s'accorder sur une échelle et à garder le cap. Au final, on revient toujours sur un équivalent de jours de travail.
Puisque les développeurs ne sont pas capables d'estimer, pourquoi continuer ? C'est le point central du mouvement NoEstimates. Ses partisans partent du principe que les estimations prennent beaucoup de temps et d'énergie, sans forcément améliorer la prévisibilité. Elles donnent souvent une illusion de contrôle, mais le résultat reste aléatoire avec des projets qui dépassent presque toujours les prévisions. En NoEstimates, plutôt que d'essayer d'estimer chaque tâche, on accentue nos efforts sur le découpage pour livrer en continu de petits incréments.
Personnellement, j'aime pratiquer un mix des deux mondes. Je donne d'abord une estimation à la louche, pour que les décisionnaires se fassent une idée de l'ordre de grandeur et puissent prioriser. Ensuite, j'entre dans un cycle de livraison continue, en cherchant à apporter de la valeur le plus tôt possible, même si le produit n'est pas final. - Communauté de pratique / Guilde / Chapter : dans la vie quotidienne, les membres de la squad et de la tribu partagent un domaine métier (paiement, relation client...). Les guildes et chapters sont d'autres types de regroupements issus du modèle Spotify, mais cette fois par centres d'intérêt. Il peut y avoir le collectif de tous les développeurs frontend de l'entreprise, de tous ceux qui s'intéressent à l'accessibilité... Ça permet d'harmoniser les pratiques et de faire circuler la connaissance inter-équipes.
Tous ces rituels sont aujourd'hui tellement ancrés dans notre quotidien que beaucoup les considèrent indissociables de l'agilité.
Rien n'est plus faux !
Les équipes les plus matures remettent en cause continuellement leurs rituels. Elles ont compris que la véritable philosophie Agile, c'est l'adaptation des processus à
ce qui fonctionne pour elles.