Quatre erreurs commises fréquemment lors de la phase préparatoire peuvent pénaliser lourdement un projet agile dès la première itération.
Ces erreurs sont difficiles à corriger une fois que les itérations sont lancées. Il est donc primordial de les connaître et de savoir comment les éviter.
En tant que Scrum Master ou coach agile, vous êtes garant du bon déroulement de la phase préparatoire.
Vous devez vous assurer que votre équipe sera dans les meilleures conditions possibles pour commencer à délivrer de la valeur au 1ᵉʳ jour de la 1ʳᵉ itération.
Cet article vous présente les 4 erreurs les plus fréquentes avec les conséquences associées et vous propose des bonnes pratiques à adopter pour éviter de reproduire ces erreurs dans vos contextes.
Travailler avec des éléments petits est une solution. Mais cela n’est possible que si l’ensemble des activités (build, packaging, déploiement, mise en service…) permettant d’apporter de la valeur aux utilisateurs finaux sont automatisés.
Toutes ses activités constituent le pipeline de delivery continu.
Qu’est-ce que la phase préparatoire ?
Pour que l’équipe soit en capacité de créer de la valeur dès le premier jour de la première itération, une phase préparatoire est nécessaire en amont des itérations.
Cette phase préparatoire est souvent appelée à tort « sprint 0 », ce qui laisse penser qu’elle dure le même temps qu’une itération.
En réalité, elle dure en moyenne un mois et regroupe une multitude d’activités regroupées en 3 volets :
1) Volet fonctionnel
Le Product Owner construit le Product Backlog.
Il définit la vision du produit, liste les User Story et les priorise en prenant en compte la valeur métier de chaque User Story.
Il détaille suffisamment de User Story pour les premières itérations afin d’alimenter correctement l’équipe.
2) Volet méthodologique
Le Scrum Master ou le coach agile forme l’équipe à l’agilité.
Il aide l’équipe à définir :
- les rôles et responsabilités de chacun
- la durée des itérations
- le calendrier des évènements agiles
- le DoR
- le DoD
- le flux de travail
3) Volet technologique
Le Tech Lead définit le squelette technique de l’application et son architecture.
Il met en place le pipeline de livraison continue et sensibilise les développeurs sur les normes de codage.
Erreur #1 : L’équipe n’a pas été formée à l’agilité
Voici pourquoi c'est une erreur fréquente et comment y remédier.
1) Pourquoi cette erreur est-elle fréquente ?
Aujourd’hui, le management considère trop souvent l’agilité comme une compétence acquise, à tel point qu’il ne comprend pas pourquoi il est nécessaire de consacrer du temps à la formation.
Pourtant, même si les valeurs et les principes sont globalement maîtrisés, la formation reste indispensable.
En effet, elle doit aussi servir à adapter les pratiques au contexte de l’équipe.
Par ailleurs, la formation est la première étape d’un accompagnement agile.
Elle permet de construire l’équipe en apprenant à se connaître (« Team Building ») et marque le lancement officiel du projet.
Pour un Scrum Master ou un coach agile, ces deux journées sont riches d’enseignements :
- Prise de connaissance du contexte de l’équipe
- Mesure du niveau d’agilité de chacun
- Adaptations nécessaires à réaliser
- Identification des ateliers à prévoir post formation
2) Quelles sont les conséquences ?
Lancer un projet agile sans formation préalable a des conséquences particulièrement néfastes :
- Un niveau agile hétérogène dans l’équipe, un manque de vocabulaire agile commun, des écarts de perception concernant l’objectif des évènements, les rôles et plus globalement le fonctionnement de l’équipe,
- Un accompagnement plus difficile et moins efficace pour le Scrum Master ou le coach agile, car la montée en compétences de chacun prend plus de temps,
- Pas de « Team building » et donc pas de dynamique instaurée pour l’équipe,
- Des pratiques inadaptées au contexte.
3) Quelles bonnes pratiques permettent de l’éviter ?
Vous devez insister auprès de votre management en précisant que ces 2 journées sont clefs pour la réussite du projet.
Commencez par partager les conséquences néfastes listées ci-dessus.
Utilisez le terme « lancement de projet », plus vendeur que le terme « formation ».
Le premier évoque une séance de travail alors que le second peut faire penser à de simples rappels théoriques.
Partagez avec votre management l’agenda des 2 journées en mettant en évidence les créneaux consacrés à l’adaptation des pratiques au contexte.
Erreur #2 : Les rôles ne sont pas bien définis
Voici les raisons qui expliquent la fréquence de cette erreur, ses conséquences et comment l'éviter.
1) Pourquoi cette erreur est-elle fréquente ?
Chaque équipe agile est différente.
Les rôles Scrum traditionnels sont très souvent complétés par d’autres rôles.
Les plus fréquents sont les suivants :
- Business Analyst (BA), un expert fonctionnel destiné à renforcer le rôle de Product Owner,
- Tech Lead (TL), un expert technique qui est souvent le développeur le plus expérimenté,
- Quality Analyst (QA), un expert des tests et de leur automatisation.
Comment ces rôles complémentaires interagissent-ils avec les rôles Scrum traditionnels ? Qui fait quoi ?
Beaucoup d’équipes agiles se lancent sans avoir défini précisément le rôle et les responsabilités de chacun.
C'est le cas parce que nous considérons trop souvent que le nom d’un rôle suffit pour connaître ses activités.
La performance d’une équipe réside dans les interactions entre ses membres.
Il est donc préférable d’analyser les activités d’une équipe au sens large, et non individu par individu.
2) Quelles sont les conséquences ?
Dès les premières itérations, une mauvaise compréhension des rôles peut engendrer des effets négatifs :
- des User Story incomplètes, des incompréhensions concernant le travail à réaliser,
- des bugs résiduels, une application fragile, un niveau de qualité faible,
- des mauvais choix de conception, une augmentation de la dette technique,
- beaucoup de User Story non terminées, une vélocité faible.
3) Quelles bonnes pratiques permettent de l’éviter ?
La formation dont nous avons parlé au chapitre précédent est une bonne pratique, mais elle doit être complétée par un atelier dédié à la définition précise des rôles.
L’atelier « matrice des attendus » consiste à demander à chacun ce qu’il attend de tous les autres rôles.
Après un temps de réflexion individuelle et silencieuse, le Scrum Master ou le coach agile demande à chacun de venir coller ses idées sur la matrice en explicitant ses attendus vis-à-vis des autres.
Ensuite, il s’agit de vérifier la cohérence de l’ensemble et de faciliter les discussions concernant les éventuels manques et doublons identifiés.
Parfois, plusieurs personnes contribuent à un même rôle Scrum.
Par exemple, le Product Owner (PO) et le Business Analyst (BA) constituent un dispositif « Product Owner ».
Dans ce cas, pour préciser les mécanismes de délégation au sein du dispositif, il peut être intéressant d’animer un Delegation Poker.
Une excellente pratique est de mener votre phase préparatoire en agile !
Donnez ainsi l’occasion aux membres de votre équipe de jouer leur rôle dès maintenant, sans attendre le démarrage des itérations !
Pour cela, proposez un cadre de travail simple, mais structuré, composé des éléments suivants :
- Un backlog des éléments de la phase préparatoire (DoR, DoD, créer le Product Backlog…),
- Des itérations volontairement courtes (1 semaine),
- Un kanban simplifié (à faire, en cours, terminé) pour introduire la notion de flux de travail,
- Des réunions quotidiennes pour instaurer une dynamique et habituer l’équipe à la démarche,
- Un Sprint Planning pour définir les travaux de la semaine,
- Une démonstration à chaque fin de semaine pour voir l’avancement des travaux,
- Une rétrospective pour mieux travailler ensemble dès la semaine suivante.
Erreur #3 : L’industrialisation des développements n’est pas opérationnelle
Voici pourquoi cette erreur est fréquente, quelles en sont les conséquences et comment faire pour l'éviter.
1) Pourquoi cette erreur est-elle fréquente ?
Travailler avec des éléments petits est un accélérateur du flux du travail. Mais cela n’est possible que si l’ensemble des activités (build, packaging, déploiement, mise en service…) permettant d’apporter de la valeur aux utilisateurs finaux sont automatisés.
Toutes ses activités constituent le pipeline de delivery continu.
En agile, nous livrons des incréments de valeur plusieurs fois par itération.
Nous avons donc besoin du pipeline de delivery continu dès la première itération !
Cela nécessite des outils, des environnements, des droits administrateurs. Et tout cela prend généralement beaucoup de temps, particulièrement dans nos grandes entreprises organisées en silos.
Beaucoup d’équipes agiles n’ont pas véritablement conscience de tout ce qui est nécessaire pour délivrer de la valeur dès la 1ʳᵉ itération.
Et le manque d’anticipation des demandes d’outils, d’environnements et de droits conduit bien souvent les équipes à démarrer les itérations alors que le pipeline de delivery continu n’est pas opérationnel.
2) Quelles sont les conséquences ?
Tous les manques identifiés concernant le pipeline de delivery continu vont devoir être traités pendant les itérations, ce qui entraîne une forte perte de productivité.
Ces manques représentent par ailleurs des risques majeurs pour le projet.
Voici quelques exemples :
Risque de mise à disposition d’une fonctionnalité défaillante à l’ensemble des utilisateurs
Manques identifiés | Risques majeurs |
|---|---|
Pas d’environnement de démonstration. Le PO ne peut pas montrer l’application à ses clients pour recueillir des feedbacks sur les fonctionnalités développées. | Risque d’augmentation de l’écart entre les fonctionnalités réalisées et ce qui est souhaité par les clients. Si l’écart devient trop important, il y a un risque de ne plus pouvoir le combler. |
Pas d’environnement iso-production. | Risque de détection tardive des éventuels problèmes de performances de l’application. |
Pas d’outils d’automatisation des tests. | Risque de régressions fonctionnelles. |
Pas d’outils de mesures de la qualité de code. | Risque d’augmentation de la dette technique. |
Pas d’outils de mesures business. Pas de feedbacks sur le nombre d’utilisateurs, les fonctionnalités les plus utilisées, etc. | Risque de continuer à investir sur des mauvaises priorités. |
Pas de mécanismes pour activer / désactiver une fonctionnalité auprès d’un panel d’utilisateurs. | Risque de mise à disposition d’une fonctionnalité défaillante à l’ensemble des utilisateurs |
3) Quelles bonnes pratiques permettent de l’éviter ?
Pendant la phase préparatoire, une bonne pratique est de sélectionner avec votre Product Owner une fonctionnalité simple du Product Backlog.
Ensuite, demander à votre équipe d’en faire l’implémentation, puis une démonstration sur un environnement iso-production.
Ainsi, votre équipe va devoir construire son pipeline de delivery continu au plus tôt, rencontrer tous les écueils habituels au plus tôt et les résoudre au plus tôt !
Puisque vous menez votre phase préparatoire en agile, votre équipe ne manquera pas de soulever en réunion quotidienne tous les obstacles liés à la construction de son pipeline de delivery continu.
En tant que Scrum Master ou coach agile, utilisez votre réseau interne pour être facilitateur auprès de votre équipe et tentez de lever le maximum d’obstacles.
Erreur #4 : Le Product Backlog n’est pas prêt
Commençons par les raisons pour lesquelles cette erreur est fréquente.
1) Pourquoi cette erreur est-elle fréquente ?
La qualité principale attendue chez un Product Owner est la communication.
Pour réussir sa mission, il doit être un véritable polyglotte pour collaborer efficacement avec une multitude d’acteurs.
Les anomalies les plus fréquemment identifiées dans un Product Backlog sont dues à des problèmes de collaboration et de communication entre :
- Le Product Owner et les métiers / utilisateurs : utilisateurs mal ciblés, manque d’empathie, mauvaise compréhension des besoins, éléments structurants manquants (gestion des langues, gestion des rôles utilisateurs, gestion des erreurs, ergonomie, charte graphique, maquettes d’écran).
- Le Product Owner et l’équipe : vision produit et Product Backlog non partagés, séances de backlog refinement sans l’équipe, User Story non estimées, MVP non estimé.
- Le Product Owner et le chef de projet : exigences non fonctionnelles manquantes (performance, sécurité, maintenabilité, plateformes cibles), mauvaise prise en compte du triptyque (budget, périmètre, délai).
- Le Product Owner et le Scrum Master : bonnes pratiques de rédaction des User Story non maîtrisées, critères I.N.V.E.S.T non respectés, mauvaise compréhension des techniques de découpage des User Story, défauts de priorisations, éléments prioritaires pas suffisamment détaillés.
2) Quelles sont les conséquences ?
Le but de l’agilité est de délivrer des produits utiles.
Un Product Owner sans approche « customer centric » prend le risque de livrer des fonctionnalités inutiles, voire un produit qui ne répondra pas du tout aux besoins.
Par ailleurs, le fait de ne pas embarquer l’équipe dans la construction du Product Backlog peut aboutir à des mauvais choix de conceptions et d’implémentations.
Cela va avec un risque de surcoût important si trop d’éléments pourtant structurants sont découverts en cours de route.
Enfin, si le Product Backlog ne contient pas suffisamment de User Story prêtes, les développeurs peuvent se retrouver sans travail à faire.
3) Quelles bonnes pratiques permettent de l’éviter ?
Sensibilisez votre Product Owner à l’importance d’embarquer les clients dans la démarche.
Menez avec lui les ateliers qui permettent de se mettre à la place des utilisateurs et de capter leurs besoins (gemba walk, personas, empathy map, story map).
Demandez à vos développeurs d’expliquer à votre Product Owner quels sont les éléments qui peuvent être les plus pénalisants en termes d’implémentation s’ils ne sont pas connus au démarrage du projet.
Assurez-vous que ces éléments sont bien priorisés dans le Product Backlog.
Ceci afin que les risques de refactoring tardifs et par conséquent coûteux soient sous contrôle.
Accompagnez votre Product Owner dans la maîtrise de son Product Backlog en rédigeant avec lui les premières User Story et en utilisant les techniques de découpage.
Insistez sur l’importance de partager au plus tôt le fruit de son travail avec son équipe, notamment pour les estimations.
Ne lâchez pas votre Product Owner durant toute la phase préparatoire !
Profitez des démonstrations de chaque fin de semaine pour mesurer ses progrès et l’avancement du Product Backlog.
Conclusion
Les erreurs commises lors de la phase préparatoire ont de fortes conséquences dès la première itération.
Elles coûtent très cher et sont très difficiles à corriger une fois que les itérations sont lancées.
Mener la phase préparatoire en agile pour instaurer une dynamique avec des itérations courtes d’une semaine est un levier très important pour réussir une phase préparatoire.
Si tout n’est pas prêt au premier jour de la première itération, listez vos manques et alertez votre management sur les risques associés.
Il prendra ainsi ses responsabilités de manière éclairée.
Il pourra décider de démarrer les développements malgré tout ou bien de reporter le démarrage le temps de combler les manques et ainsi augmenter les chances de succès du projet.
