L’organisation en sprints

Quand on a organisé son équipe en se basant sur une méthode agile, on utilise bien souvent la notion de sprints. Les deux vont tellement de pair de nos jours que l’un semble forcément impliquer l’autre, sans qu’on y pense vraiment.

Pourtant, il y a de vraies raisons à s’organiser en sprints − que l’on ait mis en place une méthodologie agile ou pas.

Qu’est-ce qu’un sprint ?

Un sprint correspond à une durée de longueur limitée, durant laquelle est réalisé un ensemble de tâches.Cette durée doit être à la fois assez courte pour favoriser les avancées incrémentales, et assez longue pour qu’une quantité suffisante de travail ait pu être effectuée. La plupart du temps, les sprints durent deux semaines, mais on voit parfois des durées différentes (d’une à six semaines).

Si on privilégie les avancées incrémentales, c’est évidemment parce que les pratiques agiles incitent à découper les développements en tronçons les plus élémentaires possible, pour qu’à chaque modification on puisse évaluer la pertinence du résultat et décider de l’évolution suivante.
Avec des sprints de courte durée, on évite l’effet tunnelinhérent aux tâches qui s’étirent dans le temps.

En même temps, les sprints ne doivent pas être trop courts, d’où la durée standard de deux semaines.Il doit être possible de réaliser l’intégralité d’un travail sur la durée du cycle: kick-off avec le client, développement, tests (par le développeur), démo, validation (par le client), déploiement, rétrospective (ou post-mortem).
Si l’ensemble de ces étapes s’étire sur plusieurs sprints, la gestion des développements risque de devenir exponentiellement complexe, sans oublier l’effet tunnel qui se fera vite sentir de nouveau. Il est toutefois possible de prévoir que certains développements soient sur des « doubles-sprints » ou des « triples-sprints » ; mais ces cas doivent rester l’exception plutôt que la norme, car ils sont symptomatiques de projets insuffisamment découpés.

S’organiser autour de sprints

Suivant les entreprises, les équipes et les méthodes utilisées, il y a plusieurs moyens de s’organiser autour de la notion de sprints.

L’organisation la plus simple − et la plus courante − est d’enchaîner les sprints les uns à la suite des autres. Sur la même période, il faudra donc mener de front deux types d’activités :

• La conception, qui peut comprendre la conduite d’études et d’analyses, l’écriture de spécifications ou de user stories, la réalisation de wireframes et/ou de maquettes…
• Le développement, avec toutes les étapes précitées (codage, tests, démo, validation, déploiement).

Dans ce type d’organisation, le tout premier sprint de développement sera précédé d’un « sprint zéro » qui aura pour seul but de définir le travail qui sera réalisé lors du premier sprint.
De la même manière qu’un sprint doit pouvoir contenir toutes les étapes d’un développement, il faut que toutes les étapes de conception puissent (idéalement) tenir dans la durée d’un sprint. En cas de dépassement sur un ou plusieurs sprints supplémentaires, le développement sera repoussé d’autant et cela doit être géré convenablement.

L’autre type d’organisation possible est basé sur des cycles dont les sprints sont l’élément de base. Il est alors possible d’imaginer des cycles de durée plus longue (entre deux semaines et trois mois), constitués de sprints dont les rôles ont été définis.

Par exemple, un cycle d’un mois et demi pourrait être défini de la sorte :

• un sprint de conception de deux semaines
• un sprint de développement de trois semaines
• un sprint de validation et déploiement d’une semaine

La difficulté avec ce type d’organisation, c’est qu’il faut s’assurer que les membres de l’équipe sont occupés durant toutes les phases. Ce but peut être atteint en prévoyant du temps pour des tâches nécessaires mais souvent oubliées ; ainsi les développeurs peuvent faire des débogages et des refactorings pendant le sprint de conception, ou encore les équipes de conception peuvent mettre à profit le temps de développement et de validation pour mener leurs études préliminaires.

La mise en place de sprints

Il peut y avoir plusieurs raisons pour ne pas utiliser les sprints. Le plus souvent, il s’agit d’entreprises ou d’équipes qui travaillent en mode « best effort » : chacun fait alors de son mieux pour mener les projets à bien le plus vite possible. C’est d’autant plus commun dans les équipes qui doivent réaliser plusieurs projets en parallèle, chacun ayant des dates de début et de fin différentes.

En privilégiant la réactivité plutôt que la planification, on adopte un fonctionnement similaire à celui d’une startup, ce qui peut être très efficace dans certaines conditions. Néanmoins, cela s’avère contre-productif à la longue. Lorsque le seul objectif est de terminer les projets au plus vite, on se retrouve à prendre des raccourcis dangereux ; soit les besoins réels des clients passent après le respect du cahier des charges, soit la qualité de réalisation en pâtit, soit c’est au contraire les délais qui finissent par ne pas être respectés à cause du manque d’agilité de l’organisation.

Il est assez compliqué de passer brutalement d’une organisation « classique » à un système à base de sprints. Cela est possible, à la condition d’une complète collaboration de l’ensemble des équipes.
Pour faciliter la transition, on peut procéder en quatre étapes :

1. Définir des sprints dont les dates de début et de fin sont faciles à retenir. Cela peut être des sprints de deux semaines (parfois trois) qui commencent au début et au milieu de chaque mois calendaire.
2. Lorsqu’un contrat est signé (ou qu’un projet interne est entériné), ne pas lancer les équipes immédiatement dessus, mais attendre le début du prochain sprint.
   Cela peut sembler mettre les projets inutilement en retard, mais c’est à cette condition que les projets pourront être gérés plutôt que subis. Et concrètement, cela ne posera problème à aucun client dans la mesure où cela leur aura été expliqué préalablement.
3. Durant les phases de conception, si un élément est manquant à cause d’un retard du client, le projet est gelé jusqu’au début du sprint suivant.
   Là encore, il s’agit de pouvoir gérer les ressources sans subir les aléas extérieurs ; et accessoirement, d’éduquer les clients en leur faisant prendre conscience qu’ils ont leurs propres responsabilités.
4. Exprimer la fin officielle d’un projet à la fin du sprint durant lequel le projet a été livré puis validé par le client, et non pas dès que le projet est validé. Cela afin de dérouler l’ensemble des étapes prévues, notamment la rétrospective de fin de cycle ou le post-mortem de fin de projet.

Les inconvénients des sprints

De manière générale, le découpage temporel en sprints n’est pas une chose intrinsèquement positive ou négative. C’est un outil qui, suivant la manière dont il est mis en œuvre, pourra s’avérer pratique ou défavorable.

Le principal défaut est inhérent au terme desprintlui-même. Il induit une course effrénée, avec le risque d’avoir une barque surchargée et une équipe étouffée par des deadlines hypercourtes qui s’enchaînent à un rythme trop soutenu.
Pour rester sur une analogie sportive, le travail est une course de fond. Il faut pouvoir garder la cadence dans la durée, sans s’épuiser.

Le risque inverse est aussi présent, dans le cas où des éléments seraient manquants et empêcheraient les développements d’être effectués. Si cela arrive trop souvent dans le même cycle, on peut se retrouver avec de nombreux projets mis en suspens ; au final, l’équipe est sous-employée (ce qui peut s’avérer tout aussi destructeur que d’être continuellement submergé).

Ces deux écueils sont le reflet d’une mauvaise gestion. La principale responsabilité d’un chef de projet (ou d’un Scrum Master, d’un manager…) est d’anticiper pour éviter les mauvaises surprises en cours de projet, tout en prévoyant une utilisation saine des ressources (notamment humaines).