Agile et Scrum : histoire, créateurs et idées essentielles
Agile et Scrum désignent des choses différentes
Agile est un ensemble de valeurs et de principes permettant de développer des logiciels en apprenant de l’expérience et en s’adaptant au changement. Scrum est un cadre qui donne à une équipe une structure particulière pour un travail complexe. Le lien est étroit, mais les termes ne sont pas interchangeables. Une équipe peut suivre les principes agiles sans Scrum, et programmer ses réunions ne garantit ni adaptabilité ni résultats utiles.
Une question concrète clarifie la différence : que faire lorsqu’une équipe découvre que son plan initial ne correspond plus au problème ? Une approche agile considère cette information comme une raison de réexaminer le plan. Scrum crée des occasions régulières d’inspecter le travail et de l’ajuster. Aucun des deux ne supprime le besoin d’un objectif, de jugement professionnel ou d’attention à la qualité.
Pourquoi une autre approche était nécessaire
Les projets logiciels commencent souvent avec des connaissances incomplètes. Les utilisateurs peuvent difficilement expliquer un besoin avant de voir une solution possible ; les développeurs découvrent parfois des contraintes techniques seulement en essayant une réalisation. Si tous les besoins sont considérés comme définitivement fixés au départ, une équipe peut exécuter fidèlement un plan qui ne produit plus le résultat le plus utile. Découvrir tard ce décalage rend les corrections plus coûteuses et perturbatrices.
La réponse n’était pas d’abandonner la planification, mais de réduire le délai entre une décision et la découverte de son efficacité. Au lieu d’attendre une grande livraison finale, les équipes pouvaient créer de petits résultats utilisables, recueillir des retours et actualiser leurs priorités. Ce raisonnement s’est développé dans plusieurs approches avant qu’Agile devienne leur nom commun. Il n’est pas apparu en un jour comme l’invention complète d’une seule personne.
Les racines de Scrum précèdent le Manifeste agile
Un jalon important est l’article de 1986 de Hirotaka Takeuchi et Ikujiro Nonaka, The New New Product Development Game. Sa métaphore du rugby a aidé à concevoir le développement de produits comme un mouvement collectif coordonné plutôt qu’une simple succession de transmissions. L’article concernait le développement de produits au sens large ; il ne faut pas le confondre avec le cadre logiciel ultérieur dans sa forme entièrement définie.
Ken Schwaber et Jeff Sutherland ont développé Scrum au début des années 1990 et l’ont présenté ensemble à la conférence OOPSLA en 1995. Ils sont reconnus comme ses cocréateurs, même si d’autres praticiens ont également contribué. Le premier Scrum Guide est paru en 2010. L’ordre compte : Scrum existait avant le Manifeste agile, puis est devenu l’un des cadres les plus connus du développement agile.
La rencontre de 2001 donne une identité commune à Agile
Du 11 au 13 février 2001, dix-sept praticiens du logiciel se sont réunis à Snowbird, dans l’Utah. Ils représentaient des approches différentes, notamment Extreme Programming, Scrum et Crystal. Selon le récit officiel de la rencontre, ils cherchaient entre autres un terrain commun au-delà des processus lourds et centrés sur les documents. Il en est sorti le Manifeste pour le développement agile de logiciels, généralement appelé Manifeste agile.
Les dix-sept signataires étaient Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland et Dave Thomas. Agile possède donc une origine collective. Les deux cocréateurs de Scrum comptaient parmi les signataires, mais le mouvement plus vaste ne peut leur être attribué exclusivement.
Quatre valeurs, avec une précision importante
Le Manifeste accorde davantage de poids à la collaboration humaine qu’à une dépendance rigide aux procédures, au logiciel opérationnel qu’aux descriptions exhaustives, à une relation client continue qu’au marchandage contractuel, et à l’adaptation aux circonstances qu’au maintien mécanique d’un ancien plan. Ces priorités aident à résoudre les tensions rencontrées dans les projets réels. Elles n’interdisent ni outils, ni contrats, ni documentation, ni plans.
Cette précision est essentielle. Un produit réglementé peut exiger une documentation importante ; une équipe distribuée peut dépendre fortement des outils. La question est de savoir s’ils servent le travail et les personnes qui en attendent les résultats. Les douze principes complémentaires abordent livraison fréquente, rythme soutenable, soin technique et réflexion régulière. Agile demande d’examiner les pratiques, pas seulement d’adopter un vocabulaire à la mode.
Ce que Scrum ajoute à ces idées
Scrum organise le travail autour d’une petite équipe, d’une direction produit partagée et de périodes répétées appelées Sprints. Un Sprint dure au maximum un mois. L’équipe y poursuit un Objectif de Sprint et crée un ajout utilisable au produit. Le cycle court limite la durée pendant laquelle des hypothèses restent sans examen, à condition d’inspecter réellement les résultats plutôt que de simplement décrire l’activité.
Le Scrum Guide définit trois responsabilités. Le Product Owner répond de la maximisation de la valeur et de la gestion du Product Backlog ordonné. Les Developers créent le résultat utilisable et organisent leur travail. Le Scrum Master aide à établir Scrum et à améliorer l’efficacité de l’équipe. Il n’est pas défini comme un chef distribuant les tâches quotidiennes, et le Product Owner est une personne plutôt qu’un comité décisionnaire.
Un cycle de travail, pas seulement un calendrier de réunions
Le Sprint Planning établit pourquoi le prochain Sprint est important, ce que l’équipe peut prendre en charge et comment elle compte avancer. Pendant le Sprint, le Daily Scrum donne aux Developers quinze minutes pour inspecter leur progression vers l’objectif et adapter le plan. La Sprint Review examine le résultat avec les parties prenantes et éclaire les travaux futurs. La Sprint Retrospective vise à améliorer la collaboration de l’équipe.
Ces événements ont des finalités distinctes. La Review n’est pas simplement une étape d’approbation, et la rétrospective ne sert pas à reprocher une semaine difficile à quelqu’un. Une réunion quotidienne ne devient pas efficace du seul fait que les personnes restent debout. Le lien entre observation et action compte davantage que l’apparence : lorsqu’un obstacle ou une hypothèse erronée apparaît, l’équipe doit pouvoir réagir concrètement.
À quoi ressemble cette approche dans un produit ordinaire
Imaginons une équipe construisant un site pédagogique. Plutôt que de créer une plateforme complète avant de montrer quoi que ce soit, elle pourrait livrer une petite expérience de leçon utilisable. Les apprenants ouvrent une leçon, lisent son contenu et la marquent comme terminée. Leurs retours peuvent montrer qu’une progression compréhensible importe davantage que le tableau de bord sophistiqué prévu au départ. Cette découverte peut changer l’ordre des travaux suivants.
C’est un exemple illustratif, pas un projet historique. Il montre deux idées complémentaires : le développement incrémental ajoute des capacités utilisables, tandis que le développement itératif réexamine et améliore ce qui a été appris ou construit. Un prototype destiné à explorer une idée peut être précieux, mais ne constitue pas automatiquement un ajout produit terminé. Dans Scrum, le travail doit satisfaire la Definition of Done de l’équipe pour appartenir à un Increment achevé.
La place des autres pratiques et personnes
Agile dépasse Scrum. Extreme Programming insiste particulièrement sur les pratiques d’ingénierie logicielle ; Kanban se concentre sur la gestion du flux et la limitation du travail en cours. Les équipes peuvent aussi utiliser récits utilisateur, techniques d’estimation ou tableaux visuels. Ces outils peuvent aider, mais Scrum n’impose ni récits utilisateur, ni points, ni planning poker. Confondre recommandation courante et règle officielle rend le cadre artificiellement plus compliqué.
Des formateurs et auteurs ont ensuite contribué à diffuser ces idées. Mike Cohn, par exemple, a proposé des explications influentes des récits utilisateur et de la planification agile, sans être signataire du Manifeste. CI/CD appartient au versant technique : intégration fréquente, contrôles automatisés et processus de publication fiables soutiennent des retours rapides. Ce n’est ni un autre nom d’Agile ni un élément obligatoire de Scrum.
Ce que devrait réellement signifier la réussite
Agile et Scrum ne promettent pas que tout projet sera facile ni que toute échéance sera juste. Ils rendent l’incertitude gérable par le travail visible, les retours et l’adaptation. Cela demande des conditions dépassant la salle de réunion : accès aux utilisateurs, priorités claires, pouvoir de décision et attention durable à la qualité. Modifier les intitulés de postes sans changer ces conditions peut laisser les problèmes initiaux intacts.
Le test utile est donc concret : l’équipe découvre-t-elle plus tôt les malentendus, réagit-elle aux observations et produit-elle quelque chose d’utilisable ? Un calendrier chargé et un tableau rempli ne répondent pas à cette question. L’histoire aide à conserver la finalité : Agile a exprimé des priorités communes, tandis que Scrum a donné un cadre pour inscrire apprentissage et livraison coordonnée dans un rythme reproductible.
