Faites-vous des sprint zéro pour ? Par exemple pour construire la CI/CD, le poste de dev, ou encore l’architecture du socle technique ?
Oui ? Ah ! et du coup, quand est-ce que vous envisagez de quitter le Waterfall pour passer à l’agilité ?
Parce que oui, le sprint zéro c’est faire du waterfall.
Définition
C’est quoi un sprint zéro ? Ça pourrait être le premier sprint, puisque les devs comptent à partir de zéro, c’est bien connu. Le Sprint zéro peut être un sprint normal, de la même durée que les sprint suivant. Je ne vais pas parler de ce cas là ici, même si je remet volontier en question la nécessité de différencier ce sprint des autres si c’est un sprint normal.
Je vais parler ici du cas où le sprint zéro est une période de temps qui se déroule avant les vrais sprints, qui sont les sprints de développement, et dont, la durée est souvent sans relation avec la durée des sprints de développement. Par exemple, le sprint zéro dure deux ou trois semaines, puis les sprints “normaux” une semaine. C’est oublier pourquoi on fait des sprints !
Ce moment – qu’on appelle aussi parfois “la période de cadrage”- est celui pendant lequel beaucoup d’équipes préparent le terrain, les fondations pour l’application. Comme si c’était un bâtiment (en fin d’article, vous trouverez un lien vers un article de Jean-Pierre Lambert sur cette notion). C’est le moment que les architectes informatique à l’ancienne aiment bien; on prévoit, on prédit, on construit pour le futur.
Socle
J’ai été récemment challengé là-dessus sur la partie qu’on appelle “socle technique”.
Ma réponse est souvent : “Et pourquoi l’archi ne peut-elle pas se construire au fur et à mesure, en réponse au besoin fonctionnel de l’objectif de sprint ?”. Ce à quoi je reçois régulièrement la réponse : “Nan mais il faut la penser l’architecture, avant”.
Oui, une architecture doit être pensée, mais elle doit surtout être discutée et réfléchir ne veut pas dire faire. Quelle est la valeur d’un plan, voire d’une archi mise en place pour quelque chose qui n’est pas encore à faire et qui, potentiellement, ne sera pas à faire ?
Quelle place cela nous laisse pour changer, choisir ? Après tout, si on ne peut plus changer, on n’a plus de choix possible.
“Décider, c’est renoncer” © Marilyn Kol
La réponse est à chaque fois : “nan mais ça, même si on le fait pas tout de suite on fait l’archi car on est sûr de le faire”. Ah bah si on est sûr, alors y’a plus de débat.
Du coup, est-ce qu’on l’aura fait parce qu’on était tellement sûr de devoir le faire qu’on ne s’est plus posé la question de savoir si c’était pertinent ?
Ou bien parce qu’on avait déjà l’archi de faite, donc on fait la fonctionnalité ?
Ou alors parce que c’est toujours un besoin des utilisateurs ?
Et dans ce cas, les utilisateurs ont-ils eu le choix de tester plusieurs solutions ? Ou bien seulement celle dont le socle était déjà fait ? (puisqu’il était déjà fait !)
Dans la plupart des cas, l’équipe ne se pose même pas la question. Ne veut pas se la poser. La remise en question constante est en effet épuisante pour l’esprit, on cherche à l’éviter.
Ma conviction est que pour éviter de se remettre en question tout le temps, nous devrions prendre nos décisions “au dernier moment raisonnable” (c’est une notion souvent utilisé en agilité, dans kanban et scrum par exemple).
Faire un sprint zéro, c’est prendre des décisions structurantes, au moment où nous en savons le moins sur le produit.
“Just get to work” © Allen Holub
Pourquoi établir un sprint zéro qui ne répondrait pas aux règles des autres sprints ? Parler archi, sécurité, conformité, apprendre à se connaître, à connaître le produit, est-ce que ça s’arrête après le sprint zéro, comme si c’était incompatible avec un sprint 1 ?
Intégration Continue qu’on intègre au début
Le sprint zéro, c’est aussi souvent le moment pendant lequel on installe la CI/CD (Intégration continue/Déploiement Continu). Pour rappel, c’est le fait d’automatiser l’intégration du code et/ou son déploiement (si possible jusqu’à la prod).
Aujourd’hui on m’a fait remarquer qu’un nouveau tweet d’Holub contredit le précédent sur le sprint zéro (que vous trouverez au début de l’article) :
En effet, une interprétation peut-être que si on veut avoir une boucle de feedback rapide (”Est-ce que le travail que vous avez fait hier est visible par les utilisateurs aujourd’hui ?”), alors il faut commencer les développements avec la CI/CD ! CQFD.
Mon interprétation est différente. Au début du produit (car on parle de sprint zéro, donc début du développement), nous avons un produit petit; minuscropique même !
C’est une jeune pousse alors franchement, tout un système de déploiement à construire pour ça ? N’y-a-t-il pas plus simple ?
“On n’a pas besoin des fonctionnalités pour savoir comment choisir ou faire la CI/CD, on peut donc le faire avant que le backlog soit prêt, ça” m’a-t-on dit aussi, avec l’argument que ça permet de produire donc plus pendant les premiers sprint. Je ne suis pas d’accord. Déjà, produire plus vite mais en commençant plus tard, ne fait pas gagner de temps, car oui, le sprint zéro décale les premiers sprints. De plus, la façon dont vos utilisateurs sont atteignables ou peuvent tester doit faire réfléchir sur votre façon de déployer, le sprint zéro empêche l’empirisme pour ça.
Sprint zéro (pointé ?)
Je comprends parfaitement la tentation du sprint zéro. Ça rassure souvent les managers, le Product Owner et même les développeurs (surtout les architectes). C’est rassurant car ça nous permet de revenir dans une zone de confort : la prédictibilité. On a prévu, donc on est safe (joke).
“Mais alors si ça rassure tout le monde, c’est bien, non ? L’équipe s’auto-organise, après tout !”
Oui c’est bien que l’équipe s’auto-organise, mais non, car cette assurance n’est qu’une façade et donne de mauvais réflexes à l’équipe.
Nous pensons que nous assurons nos arrières, alors que bien souvent nous mettons en place des solutions à des problèmes qui n’existent pas encore. L’anticipation peut avoir de la valeur, mais elle doit être efficace. Si vous mettez 2 semaines pour mettre en place votre CI/CD ou pour installer un poste de dev, oui, vous aurez besoin d’un sprint zéro rien que pour pouvoir faire ça. C’est la réponse facile mais peu efficace si vous devez réitérer ça plusieurs fois. Pourquoi ne pas passer du temps à adresser ces problèmes ? Si votre process (technique ou pas) vous empêche d’être efficace, les principes agiles doivent pousser à corriger le process.
Ron Jeffries a écrit que Scrum ne règle pas vos problèmes, Scrum met vos problèmes en lumière. *Vous* êtes supposé régler vos problèmes.
C’est comme un château de cartes sur lequel on a mis de la colle pour le faire tenir. Le challenge du château de cartes est de réussir à trouver l’équilibre. Avec la colle, nous n’avons pas créé un château de cartes, nous avons perdu l’objectif de vue.
Si le château ne s’est pas effondré, tiendrait-il aussi sans la colle ?
L’arbre pourri qui cache la forêt
Dans le développement, si finalement on développe une fonctionnalité pour laquelle on avait préparé le socle, comment savoir si la fonctionnalité est ce qu’elle aurait dû être, ou bien si elle est ce qu’on a prévu qu’elle soit ?
L’objectif du sprint zéro, c’est d’améliorer la productivité de ce qui est prévu. Quand vous faites un sprint zéro, vous ne réglez pas les problèmes, vous faites avec. Vous achetez une certaine tranquillité aux dépends de votre produit, de votre équipe et de votre efficacité à long terme. C’est un choix.
Pourquoi ne pas penser la CI/CD, l’architecture, etc., dans un sprint normal, le sprint 1 ? Et dans ce sprint, forcez-vous à apporter de la valeur à l’utilisateur. Tout de suite.
Et en contrat agile, vous feriez un sprint zéro ?
Encore une fois, vous pouvez appeler votre premier sprint, celui qui vous permettra de faire votre story mapping, vos discussions d’archi et tout le reste sprint zéro. Ou sprint 1. Ou peu importe.
Ce qu’il ne faut pas faire, c’est construire une architecture, un design, etc. en avance. Sinon, vous faites du Waterfall. Et faites en sorte de livrer quelque chose pour avoir du feedback. N’oubliez pas qu’un incrément n’est pas forcément du code.
Si vous êtes en prestation, imaginez que le contrat qui vous lie au client soit basé sur la valeur produite. C’est une bonne idée non ? Meilleure peut-être que sur des temps de présence ou sur une vélocité.
Donc si vous n’êtes payé que sur la valeur produite, il vous coûte combien votre sprint zéro ? N’auriez-vous pas tendance à vouloir livrer de la valeur dès le premier sprint ?
Si vous pensez que faire un sprint spécial pour préparer votre projet est indispensable, si vous pensez qu’il est impossible de sortir de la valeur pour l’utilisateur dès le premier sprint, même court, alors je vous invite à me contacter; je ne demande pas mieux que vous me prouviez que j’ai tord et que c’est infaisable sans.
Voici les liens dont je vous parle dans l’article : The Agile way: grow instead of build par Jean-Pierre Lambert, le blog de Marilyn Kol et les liens (1, 2) vers les Tweet d’Allen Holub que j’affiche. Scrum Life a parlé un peu du sprint zéro ici (à 3min), et pointe un article de Maarten Dalmijn qui en parle. Quant à moi j’ai parlé du sprint d’une semaine dans une vidéo, et dans un article.
Edit : Je vous rajoute un ancien article de Ron Jeffries concernant ce qu’on appel le Design Archi, c’est à dire préparer l’architecture en avance.
L’image de la vignette de l’article vient de Jared Erondu