Scrum

La brique de base de Scrum, c'est le sprint : une période courte et fixe, une à quatre semaines, pendant laquelle l'équipe s'engage à produire quelque chose de fini et de montrable. Fixe est le mot important. On ne rallonge pas un sprint parce qu'on n'a pas terminé — on livre ce qui est prêt et on repousse le reste au suivant. Sutherland insiste : c'est le temps qui commande, pas la liste des tâches. Cette contrainte oblige à découper le travail en morceaux assez petits pour tenir dans la fenêtre.

Avant chaque sprint, l'équipe choisit dans une liste de priorités — le backlog, l'inventaire de tout ce qui reste à faire, classé du plus au moins important — ce qu'elle pense pouvoir livrer. Pas ce qu'on lui impose : ce qu'elle estime réaliste. Sutherland tient à cet engagement pris par l'équipe elle-même, parce qu'une équipe qui décide de sa charge tient parole bien mieux qu'une équipe à qui on dicte un rythme.

Scrum tient sur trois rôles, et pas un de plus. Le premier, c'est l'équipe de développement — petite, sept personnes plus ou moins deux, selon Sutherland, parce qu'au-delà la communication explose et le groupe ralentit. Cette équipe est pluridisciplinaire : elle contient tout ce qu'il faut pour livrer sans dépendre de quelqu'un d'extérieur. Et elle s'auto-organise. Personne ne lui distribue les tâches en interne ; elle décide seule qui fait quoi. Sutherland y voit la condition de la vitesse : une équipe qui doit demander l'autorisation à chaque étape n'avance pas.

Le deuxième rôle est le Product Owner. C'est lui qui tient le backlog, qui décide de l'ordre des priorités, qui incarne ce que veulent les utilisateurs et le marché. Il répond à une question, sans arrêt : parmi tout ce qu'on pourrait faire, qu'est-ce qui apporte le plus de valeur maintenant ? Il ne dit pas à l'équipe comment faire — ça, c'est son affaire à elle. Il dit quoi, et dans quel ordre.

À la fin de chaque sprint, deux rendez-vous ferment la boucle. Le premier, la revue de sprint, consiste à montrer ce qui a été fait — pas à en parler, à le démontrer, en état de marche, devant ceux que ça concerne, y compris les clients ou les utilisateurs quand c'est possible. Sutherland y tient beaucoup : une fonction dont on dit qu'elle est prête mais qu'on ne peut pas montrer n'est pas prête. Cette exigence de démonstration tue les faux avancements et ramène tout le monde au réel.

La revue produit un retour immédiat, et ce retour nourrit le backlog. On découvre que ce qu'on a construit ne servait pas tout à fait, ou qu'un besoin qu'on n'avait pas vu émerge maintenant qu'on a quelque chose de concret sous les yeux. C'est le cœur de l'argument de Sutherland contre la planification totale : personne ne sait vraiment ce qu'il veut avant de le voir. Livrer tôt et souvent, c'est se donner la chance de corriger la trajectoire tant qu'elle coûte peu, plutôt que de découvrir l'erreur au bout de trois ans.

Sutherland referme son livre là où il l'a ouvert : sur l'idée que le principal ennemi d'un projet n'est pas sa difficulté mais notre habitude de croire qu'on peut le figer d'avance. Sentinel n'a pas été sauvé par de meilleurs programmeurs, mais par un changement de rythme — livrer un peu, montrer, corriger, recommencer. Le sprint, les trois rôles, la revue et la rétro ne sont que les rouages d'une même intuition : mieux vaut se tromper toutes les deux semaines que se tromper une seule fois, au bout de dix ans, sur toute la ligne.