Faire des sprints, ce n'est pas être agile

Faire des sprints, ce n'est pas être agile

Les personnes qui ont démarré leur vie professionnelle alors que l'Agilité était déjà mainstream ne mesurent pas les bienfaits qu'elle apporte. Parce qu'elles n'ont connu que ça, elles ne s'interrogent pas sur sa nécessité profonde et font des sprints parce qu'on a toujours fait comme ça. Et c'est ainsi, chemin faisant, qu'on en vient à faire des sprints de durée variable, ou de l'inter-sprints 🫣

Mettons d'abord les choses au clair : les sprints sont une unité de temps. "Les Sprints permettent la prédictibilité en assurant l'inspection et l'adaptation de la progression vers l'Objectif de Produit", précise le Scrum Guide. Sous des dehors un peu cryptiques, cette phrase recouvre des réalités très concrètes :

  • Les sprints permettent de focaliser l'effort de l'équipe sur un objectif partagé, l'objectif du sprint. Ainsi, tout le monde tire dans le même sens sans se disperser et l'engagement est maintenu au plus haut. Parce qu'il se traduit par une valeur ajoutée concrète pour l'utilisateur, l'objectif du sprint favorise également l'empathie des développeurs, si importante dans nos métiers.

  • Les sprints permettent de pallier l'effet tunnel, en augmentant l'observabilité du travail. L'effet tunnel, c'est le "tout ou rien" : tant que tout n'est pas fait, c'est comme si rien n'était fait. S'il faut attendre 3 mois pour avoir quelque chose en production et se rendre compte que ça n'est pas exactement ce dont les utilisateurs ont besoin, c'est pas très très bien.

  • Les sprints permettent enfin de pallier la loi de Parkinson, qui observe qu'un travail prend tout le temps qu'on donne aux personnes pour le faire : donnez-leur 2 fois plus de temps, vous n'aurez pas 2 fois plus de travail mais… peu ou prou la même quantité ! C'est humain, et il y a un peu de procrastination là-dedans 😉

Les sprints sont donc là pour donner la cadence, pour imprimer le rythme. Et de toute évidence, ils doivent être courts. Des sprints longs annulent leurs propres bienfaits, comme le souligne le Scrum Guide : "Lorsque l’horizon d’un Sprint est trop lointain, l’Objectif de Sprint risque de ne plus être le bon, la complexité augmente et, avec elle, le risque. Les Sprints plus courts raccourcissent le cycle de l’apprentissage, limitant ainsi les risques liés aux coûts et à l’effort."

Cependant, là où le Scrum Guide suggère "une durée fixe d'un mois ou moins", m'est avis que 2 semaines est un maximum. A contrario, des sprints trop courts peuvent donner l'impression que l'on passe beaucoup de temps en réunion (sprint planning, démo, rétro), puisque ce temps est quasi-incompressible.

Une fois qu'on a dit ça, on n'a rien dit. Il faut ensuite une méthode pour inscrire des User Stories au backlog du sprint.

  • La majorité des équipes se base sur des estimations de complexité et la vélocité mesurée. Par exemple : 30 points de complexité par sprint, donc on peut y inscrire des User Stories de complexité 3 + 1 + 5 + 5 + 1 + 2 + 1 + 2 + 3 + 5 + 2 (suite de Fibonacci) ou 1 + 2 + 2 + 4 + 1 + 4 + 2 + 1 + 2 + 4 + 2 + 2 + 1 + 1 + 1 (puissances de 2) ;

  • Une approche concurrente est le No-Estimate, qui ne fait que compter des User Stories toutes similaires en taille : 15 User Stories par sprint, donc on peut y inscrire… 15 User Stories. Si cela paraît simple, il faut voir que le présupposé (des User Stories de tailles similaires) est très fort. Vous devez êtres des as du découpage !

Dans tous les cas, ce qui ne marche pas, c'est d'inscrire des User Stories au backlog du sprint sans aucune forme de rationalité, au petit bonheur la chance. Quand on procède ainsi, la charge de travail se retrouve fatalement poussée d'un sprint à l'autre, autant dire qu'il vaudrait mieux ne pas faire de sprints…

En passant, signalons que les sprints n'ont rien de nécessaire : une équipe aguerrie qui va en production plusieurs fois par jour aura probablement moins besoin de sprints qu'une équipe qui démarre dans l'agilité et pour laquelle chaque mise en production reste un objectif ambitieux, voire une épreuve.

Chaque équipe doit donc s'interroger périodiquement sur la pertinence de ses pratiques, au travers d'une rétrospective, par exemple. La rétrospective, qui est LA chose à conserver si toutefois vous décidiez de travailler sans sprints.

Subscribe to Mathieu Eveillard

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe