Avant que notre équipe de développement puisse embrasser l’agilité et entrer dans leur premier Sprint, il nous a semblé important de réaliser une phase d’initialisation. Cette étape, que l’on appelle communément le Sprint 0, n’a pas pour objectif de livrer un incrément de produit. Mais de mettre en place les bases pour que l’équipe Scrum puisse produire sereinement les fonctionnalités demandées durant les prochains Sprints.
On retrouve en général dans ce Sprint 0 :
Le partage d’une vision commune du futur produit
La préparation de l’environnement de développement
La construction d’une première version du backlog de produit
La réflexion sur l’architecture cible
Même si un besoin de préparation se fait souvent sentir, cette notion de Sprint 0 est un sujet à controverse au sein de la communauté agile (son nom et son contenu y sont pour beaucoup).
En effet, de multiples interrogations émergent de cette notion de Sprint 0 :
Est-ce que la dénomination de Sprint est réellement adaptée ?
Est-il toujours nécessaire d’aborder tous les points prévus dans le Sprint 0 ?
Quand faut-il arrêter le Sprint 0 pour ne pas tomber dans une approche trop prédictive, donc moins agile ?
Il est clair que le contenu de ce Sprint est, encore une fois, à adapter au contexte. Dans notre cas, nous avons choisi de nous concentrer sur trois points durant cette phase d’initialisation :
La formalisation des besoins en cours pour avoir une première version de nos backlogs de produits
Le partage d’une vision commune du futur de nos produits
Un alignement des Product Owners et de l’équipe de développement sur la Definition Of Done
Cette phase n’a pas été des plus simples pour deux raisons principales :
Il a fallu prendre en compte l’existant de nos produits et de leurs backlogs de développement respectif. Lorsque l’on décide de mettre en place une transformation agile, on part rarement d’une feuille blanche. L’existant est là et il faut le prendre en considération. Vous avez été ou vous serez certainement confronté à un existant dans votre transformation.
Structurer un backlog et écrire des User Stories, qui est la composante élémentaire d’un backlog de produit, ne sont pas choses faciles. Un accompagnement de terrain est souvent nécessaire pour apprendre par l’exemple les principes qui régissent cette nouvelle façon de spécifier un besoin.
Cet article a pour objectif de mettre en avant, au travers de notre expérience de transformation, les points qui nous ont semblé importants dans la phase d’initialisation d’un premier sprint :
Comment gérer au mieux les backlogs existants ? Faut-il les conserver ou pas ? Une réécriture de ces backlogs est-elle nécessaire ?
Comment accompagner les Product Owners dans leur tâche principale. La formalisation des besoins utilisateurs en User Stories ? Les grands principes à respecter lorsque l’on spécifie sous la forme de User Stories ? Comment construire et partager la vision produit ?
L’importance d’avoir une Definition Of Done
Préambule sur quelques unes de nos spécificités et comment nous les avons gérées
Les spécificités principales de notre contexte sont :
Le développement de plusieurs produits, dont un produit servant de socle aux autres
Une volonté forte de conserver une équipe de développement unique
Pourquoi une telle volonté ?
Comme nous l’avions déjà abordé lors de l’épisode III, le fait de maintenir une seule équipe de développement capable de travailler sur l’ensemble de nos produits permet de :
Maximiser les opportunités de partage de connaissances et de compétences sur les différents produits au sein de l’équipe de développement et ainsi éviter l’effet silotage dans l’organisation.
S’adapter facilement aux fluctuations de priorités entre produits d’un sprint à un autre sans que la livraison de valeur n’en pâtisse.
Le choix de n’avoir qu’une seule équipe de développement multiproduits nécessite :
Un backlog de produit unique matérialisant l’ordre de priorité des User Stories sur l’ensemble des produits,
Un backlog de Sprint unique rassemblant l’ensemble des User Stories de chaque produit.
De plus, nous avons la volonté à terme de faire converger l’ensemble de nos produits en une plateforme unique, d’où l’importance de tendre vers un backlog de produit unique permettant d’aligner les visions de chaque Product Owner.
Comment avons-nous décidé de gérer les backlogs de nos produits ?
Deux options nous ont paru possibles dans notre contexte :
Partir dès le début sur un backlog de produit unique rassemblant l’ensemble des besoins sur nos différents produits
Conserver un backlog indépendant pour chaque produit et créer une vision agrégée de ces backlogs. Cette agrégation a pour but de rassembler en un lieu unique la vision de tous les produits et servir d’artefact de communication entre les Product Owners et l’équipe de développement durant les cérémonies Scrum.
La première solution avait l’avantage d’inciter chaque Product Owner à avoir une vision sur l’ensemble des produits et donc de permettre un alignement plus rapide vers un produit unique. En revanche, la croissance de ce backlog pouvait vite devenir exponentielle, avec toutes les difficultés de gestion que cela impliquait à plusieurs Product Owners.
Vous l’avez compris, nous avons préféré la deuxième approche. Elle permettait une gestion plus simple des backlogs tout en conservant une vision unique et partagée à destination de l’équipe de développement. En contrepartie, pour assurer un alignement entre les différents produits, nous avons favorisé une proximité quotidienne entre les Products Owners pour encourager une communication régulière entre eux. De plus, une cérémonie d’arbitrage supplémentaire a été instaurée en amont de chaque Sprint planning pour aligner les priorités entre les Product Owners.
Comment gérer au mieux les backlogs existants ?
Comment partir d’un backlog existant ?
Dans la plupart des cas, à moins de commencer une transformation à partir d’une page vierge (ce qui entre nous est rarement le cas), un existant est présent. Nous parlons ici de l’existant en termes de fonctionnalités en cours de développement ou prévues à court ou plus long terme. Dans le meilleur des cas, cet existant est déjà matérialisé sous la forme de documents de spécification, d’une liste de tâches à faire ou d’un backlog de produit. Dans le pire des cas, il existe seulement à travers les personnes déjà présentes dans l’organisation. L’existant peut donc être plus ou moins structuré. Dans tous les cas, il faut le considérer avant d’aller plus loin, soit en décidant de ne pas le prendre en compte pour la suite, soit en le restructurant pour qu’il aille dans le sens de la transformation initiée.
La première option est rarement celle retenue car elle exclut de facto les choix faits jusqu’à présent et peut entraîner des frustrations chez les personnes déjà présentes dans l’organisation. Cela ne serait certainement pas un bon point de départ pour cette dernière. Il nous semble donc primordial de conserver l’existant, mais pas nécessairement l’exhaustivité, en le restructurant.
Comment restructurer un backlog existant ?
La revue d’un backlog peut être complexe, surtout quand celui n’a pas été initié par le Product Owner en place. Une revue globale est souvent nécessaire, mais le Product Owner ne pourra pas forcément prendre les bonnes décisions seul. Il est donc nécessaire d’inclure les personnes sachants du produit.
Dans notre cas, un de nos produits avait un backlog :
Très fourni (plus de 300 User Stories)
Très hétérogène (User Stories « techniques » et « fonctionnelles », parfois obsolètes)
Axée sur les fonctionnalités et non le besoin
Peu structuré (Sans Thème, avec des Epics représentant des Thèmes)
La revue du backlog s’est faite en 3 temps :
Une revue globale du backlog produit avec des membres de l’équipe pour décider de conserver ou non les User Stories.
Nous avons choisi de passer en revue chaque User Story en appliquant une règle de suppression simple : chaque User story avec une priorité, réévaluée en séance par l’équipe, inférieure stricte à Medium, ou une date de création antérieure à 6 mois, ou une description insuffisante pour expliquer le besoin est systématiquement annulée. Ainsi, nous avons orienté la revue de notre backlog pour ne conserver que les éléments apportant le plus de valeur pour nos utilisateurs.
Une restructuration du backlog en Thème/Epics
Une réécriture des User Stories (au fil de l’eau, en fonction des priorités remontées par le Product Owner) pour expliciter plus le besoin et moins la solution
Comment faire vivre un backlog ?
La tâche la plus complexe pour un Product Owner n’est pas d’initier un backlog, mais de le faire vivre et d’en faire émerger une vision produit.
Pour cela, deux modèles se dégagent :
Le backlog exhaustif qui consiste à lister et détailler tous les Thèmes, Epics et User Stories afin d’en ressortir une vision produit la plus complète possible.
Le backlog incrémental qui consiste à ne détailler que les Thèmes, Epic et User Stories les plus prioritaires et à lister seulement les Thèmes qui seront abordés à plus long terme.
Le premier modèle a le mérite de donner une vision détaillée du produit, ce qui permet :
D’avoir un référentiel complet du produit, donc une vision produit complète.
De préserver les connaissances sur le produit en cas de changement d’équipe.
On peut cependant s’interroger sur cette démarche qui semble :
Très lourde à mettre en place. La charge de travail pour lister et détailler l’exhaustivité d’un backlog produit peut être très chronophage.
Peu en ligne avec les préceptes de l’agilité. En effet, l’agilité nous enseigne la nécessité de réévaluer le besoin à chaque itération, ce qui semble orthogonal avec le modèle de backlog exhaustif.
Une potentielle perte de temps. A chaque réévaluation du produit et des priorités, une partie du backlog produit peut devenir de facto obsolète.
Pour pousser plus loin la réflexion, si l’on se retrouve dans le cas où le Product Owner est dans la capacité de détailler dans son ensemble le produit et que le besoin de réévaluation n’est pas applicable (dans le cas d’un projet réglementaire par exemple ou le scope est figé par la régulation), on peut s’interroger sur la pertinence de réaliser ce produit en agile.
Si l’on se réfère à la matrice de Stacey qui est utilisée pour évaluer la complexité d’un produit, l’agilité apporte un maximum de valeur aux produits catégorisés complexes, c’est-à-dire aux produits où il y a suffisamment d’incertitude sur les besoins auxquels doit répondre le produit et/ou sur les choix technologiques à faire pour construire le produit. Si l’ensemble des fonctionnalités peut être détaillé dès le début, une méthodologie projet plus traditionnelle comme le cycle en V ou le cycle en V itératif serait plus adaptée.
Dans notre cas, nous nous situons clairement dans la zone dite « complexe ». En effet, en tant qu’éditeur de logiciel, il est clairement impossible de prévoir à l’avance l’ensemble des besoins de nos clients actuels et de nos futurs clients, d’où une certaine incertitude sur le « quoi » de nos produits. D’autre part, pour les fonctionnalités nécessitant une certaine dose d’innovation, il est clair qu’une incertitude existe aussi sur l’axe technologique. Nous nous sommes donc orientés sur le modèle incrémental pour construire nos backlogs.
Comment apprendre à spécifier sous forme d’User Stories ?
Quelles sont les principales difficultés pour spécifier un produit sous forme de User Stories ?
Ce n’est pas en expliquant à un Product Owner, en un atelier, comment écrire une User Story qu’il va savoir construire seul un backlog de produit. Le passage d’une fonctionnalité spécifiée dans un document au format User Story n’est pas une chose facile à réaliser. Un accompagnement sur le terrain, en travaillant sur des cas concrets, est indispensable. C’est pour cela qu’après une session de présentation des grands principes à respecter pour rédiger une User Story, nous avons mis en place des ateliers de revue collective des premières User Stories.
Première difficulté : décrire le besoin plutôt que la solution
Dès le premier atelier, les principaux travers dans lesquels il ne faut pas tomber se sont bien sûr présentés. Parmi ces travers, le principal est celui de décrire dans la User Story une fonctionnalité sans parler du besoin auquel elle répond. Selon nous, une User Story peut décrire la fonctionnalité attendue (Cette proposition faite par le PO pourra servir de base de discussion avec l’équipe de développement), mais il est fondamental qu’elle décrive avant tout le besoin qui explique son existence (besoin client, besoin lié aux tendances du marché …), et ceci pour différentes raisons :
Donner de la visibilité sur le pourquoi de la fonctionnalité à l’équipe de développement, et ainsi garder l’équipe impliquée dans la vision produit
Bénéficier au maximum des compétences de l’équipe de développement. Un développeur proposera certainement une solution plus adaptée s’il a une bonne compréhension du besoin.
Eviter de développer une solution qui ne répond pas réellement au besoin initial, donc sans valeur. En s’interrogeant sur le pourquoi d’une User Story, on limite le risque de partir sur une solution toute faite qui ne résout pas le problème initial.
L’approche que nous avons pour se concentrer sur le besoin lors de l’écriture d’une User Story est d’utiliser la technique des « 5 Pourquoi » (ou 5P). Cette approche consiste à se poser la question « Pourquoi » 5 fois de suite sur la description d’une User Story de façon à être certain de pointer le réel besoin.
La User Story solution : une dérive à bannir
La User Story qui décrit la solution technique à mettre en place est souvent le second travers que l’on rencontre. Les éléments d’un backlog de produit sont là pour décrire le « quoi » du produit et non le « comment ». Il s’agit ici d’une dérive extrême du premier travers décrit plus haut. Encore une fois, l’approche des « 5 Pourquoi » limite ce risque. Il est possible de proposer une solution ou un début de solution dans une User Story. Mais cela doit rester une proposition ou une piste de réflexion. L’équipe de développement choisira la solution la plus adéquate.
INVEST : une ligne directrice pour de bonnes User Stories
Les autres problèmes que nous avons rencontrés lors de notre expérience de transformation sont liés aux propriétés INVEST, vers lesquelles doivent tendre au maximum chaque User Story, et particulièrement les propriétés d’indépendance, de testabilité, de taille, et dans une moindre mesure d’apport de valeur.
La recherche d’indépendance entre les User Stories est importante pour fluidifier au maximum le flux de construction et de livraison de valeur. Dans ce sens, il est important de sensibiliser les Product Owners à cette notion d’indépendance. Même si l’indépendance totale est parfois un vœu pieux, il est important que le Product Owner se pose la question des dépendances de sa User Story et comment les adresser (ordre de développement, possibilité de simuler une User Story pour en tester une autre…)
La taille d’une User Story pose souvent un problème pour les équipes qui passent à Scrum. Les Product Owners ont souvent tendance à écrire des User Stories trop grandes. Pour remédier à cela, nous invitons nos Product Owners à discuter périodiquement des User Stories avec l’équipe de développement de façon à travailler ensemble sur leur taille, et ainsi permettre une co-construction du backlog.
La testabilité d’une User Story est fondamentale. Une User Story non testable ne pourra pas être livrée. Il est donc très important de se poser la question des tests le plus en amont possible dans la rédaction d’une User Story. Et, encore une fois, l’équipe de développement doit être impliquée dans cette réflexion, surtout si les tests doivent être automatisés.
Enfin, même si la notion de valeur parle à la plupart des gens, elle est souvent subjective. Il est important de sensibiliser les Product Owners à l’importance de la valeur que doit apporter une User Story aux utilisateurs finaux en laissant de côté leur propre subjectivité. Dans le cadre de notre transformation, nous avons sensibilisé nos Product Owners à l’importance de la valeur, mais des ateliers spécifiques sur cette notion seront certainement nécessaires pour avoir un meilleur alignement sur cet aspect. Ce sera certainement l’occasion de partager avec vous cette expérience dans un prochain article.
Comment faire coexister les besoins clients et les besoins produits ?
Cette question est propre à notre contexte d’éditeur de logiciel. Si vous êtes dans cette position, ce qui suit pourrait vous intéresser.
En tant qu’éditeur de logiciel, les besoins qui alimentent nos produits peuvent provenir de différentes sources :
nos clients actuels qui utilisent déjà nos produits en production.
des prospects pour qui on peut développer des besoins intéressants pour le produit et qui permettraient de les convertir en clients.
les tendances du marché sur lequel sont positionnés nos produits.
Nos backlogs de produit doivent donc refléter l’ensemble de ces sources.
Pour réaliser cela, différentes approches sont possibles :
Avoir des User Stories pour répondre à des besoins clients et d’autres User Stories pour des besoins d’autres sources.
Profiter d’un besoin client pour apporter une solution plus générique à l’ensemble du marché.
Ces deux approches ne sont pas orthogonales et nous les mélangeons en fonction des priorités.
Nous parlons ici de priorité et c’est un point important qu’il faut adresser pour bien faire coexister nos différentes sources de besoins. Pour cela, nous avons défini un modèle de priorisation unique partagé entre tous nos produits et entre tous les intervenants :
Priorité n°1 : satisfaire nos clients actuels
Priorité n°2 : gagner de nouveaux clients
Priorité n°3 : être attractif et à l’écoute des tendances du marché
Priorité n°4 : Préparer le futur de nos produits
Nous vous invitons à réfléchir à un modèle de priorisation partagé qui facilitera grandement la coexistence de vos différentes sources de besoins, sans frustration.
Comment construire et partager la vision produit via le backlog de produit ?
Comme nous l’avons déjà évoqué, le backlog de produit doit faire émerger une vision sur le futur d’un produit et cette tâche incombe au Product Owner. Selon nous, la vision produit doit passer par plusieurs éléments que nous avons déjà commencé à aborder plus haut dans cet article :
L’importance d’indiquer le « pourquoi » de chaque User Story
L’importance d’utiliser des Thèmes et des Epics pour donner une vision macro du produit. Un backlog ne contenant que des User Stories est difficilement lisible dans sa globalité du fait de la granularité fine d’une User Story.
L’importance de communiquer sur le backlog de produit avec les différentes parties prenantes (équipe de développement, client, direction…)
Pourquoi avoir une Definition Of Done est-il si important ?
Pour rappel, la Definition Of Done est l’ensemble des critères qui permet de déclarer une User Story terminée.
La notion de fini sur une tâche peut rapidement être soumise à interprétation. Afin d’éviter toute subjectivité pour déclarer une User Story finie, il est primordial de se mettre d’accord sur tous les critères attendus. Une Definition Of Done complète et partagée entre tous les acteurs de l’équipe Scrum (Product Owners et équipe de développement) permet d’éviter :
Des User Stories qui ne se terminent jamais ou qui trainent en longueur de sprint en sprint
De la frustration, que ce soit côté PO ou côté équipe de développement
En résumé, la Definition Of Done permet de mettre un cadre partagé pour fluidifier au maximum le travail de l’équipe Scrum. Et c’est en cela qu’il est important de la définir de manière collégiale et le plus tôt possible. Nous préconisons donc de la définir dès la phase d’initialisation, avant de commencer le 1er sprint. Bien sûr elle pourra évoluer dans le temps tant que ces modifications sont décidées collectivement.
Pour en revenir à notre contexte, nous avons décidé de retenir les points suivants dans notre Definition Of Done :
Un développement terminé répondant à tous les points de la description de la User Story
Des tests réalisés côté équipe de développement
Une revue de code systématique par une autre personne de l’équipe de développement
Des tests utilisateurs réalisés par le PO en charge du produit, sur un environnement dédié à ces tests
Cette Definition Of Done n’est qu’un exemple. Elle doit être adaptée au contexte du produit.
La Definition Of Done passe aussi par les critères d’acceptance d’une User Story. Il s’agit des points importants pour accepter ou pas les développements liés à une User Story. Nous préconisons d’y indiquer des critères spécifiques à une User Story et non spécifiés dans la Definition Of Done générale.
Enfin, la Definition Of Done est souvent décidée au sein de l’équipe de développement. Dans notre cas, nous avons décidé d’intégrer nos Products Owners dans ce processus pour :
Etre le plus transparent possible
Avoir une Definition Of Done la plus complète possible en évitant de la voir que sous le prisme du développement
Conclusion
Avant de se lancer tête baissée dans un premier Sprint, nous avons vu à travers cet article qu’il est nécessaire de se préparer pour avoir des Sprints qui débutent sur de bonnes bases pour la suite. Que vous appeliez cette phase d’initialisation Sprint 0 ou autrement, ce n’est pas le plus important. Ce qui compte, c’est de réfléchir au minimum nécessaire dans votre contexte pour commencer un premier sprint afin de délivrer un premier incrément de produit apportant de la valeur.
Attention à ne pas faire trop durer cette phase d’initialisation pour ne pas perdre de vue l’approche agile. Elle doit mettre en place juste le minimum pour commencer. Pour nous, le minimum était :
De nettoyer et restructurer nos backlogs existants,
Créer un backlog avec une profondeur d’un ou deux sprints pour les produits qui n’en avaient pas,
Définir notre Definition Of Done de manière collégiale.
Et pour vous, quelle serait votre phase d’initialisation minimale ?
Dans le troisième et dernier article de cette trilogie, nous ferons un retour sur le déroulé de nos premiers Sprints, les premiers problèmes auxquels nous avons dû faire face et comment nous les avons adressés.
