Que faire en cas d’imprévus ou d’urgence au cours d’une itération ? – Crédit : Pexel

Dans le quotidien d’une équipe agile, un imprévu prend souvent la forme d’une tâche urgente demandée à un ou plusieurs membres de l’équipe. Et, évidemment, cette demande impromptue n’a pas été identifiée lors de la réunion de début de sprint (soit le sprint planning).

Prendre en compte un imprévu et engager un plan d’actions lié en cours de sprint va souvent causer des dysfonctionnements, notamment dans le rythme de l’équipe et dans le non-respect de l’engagement pris par l’équipe agile.

Et pourtant, la plupart du temps, la nature de cet imprévu nécessite une réaction rapide, voire immédiate. Je vous livre ici ma manière de gérer ce type de situation.

Etape #1 : Avant tout, triez vos urgences !

Faites le tri ! Crédit : Daniel Reche – Pexel

L’imprévu dans un sprint peut être dû à plusieurs causes : un dysfonctionnement majeur (ex : un bug bloquant) ou une évolution fonctionnelle de dernière minute ajoutant un élément primordial au produit/service. Ces perturbations et ses aléas n’ont pas les mêmes impacts dans l’équipe. Il est donc nécessaire de faire le tri.

Il existe 3 niveaux de criticité pour les bugs / anomalies :

• Niveau Critique
  Ils peuvent relever d’un défaut « critique», c’est à dire qui impact le fonctionnement du produit.
  Exemple : plus de connexion possible, outil de paiement défectueux, problème de base de données…
• Niveau Majeur
  Cela peut aussi être ce que j’appelle un défaut « majeur». Celui-ci fait perdre une grande valeur au produit mais permet quand même son utilisation.
  Exemple : un ralentissement important d’affichage d’un site ou la connexion par Touch ID sur une app ne fonctionnant plus sont des bugs majeurs.
• Niveau Mineur
  Lorsque le bug est « mineur » c’est qu’il fait perdre un peu de valeur au produit mais n’empêche pas son bon fonctionnement. Une faute d’orthographe, une erreur d’image sont des défauts mineurs.

Pour les évolutions fonctionnelles, nous pouvons les répertorier ainsi :

• Demande de la hiérarchie
  L’évolution demandée peut être due à une décision hiérarchique. Il arrive que le management pousse à l’intégration rapide d’une nouvelle fonctionnalité. Cela peut être le cas lorsqu’il faut répondre au besoin d’un utilisateur « VIP » par exemple.
• Changement de direction
  Un changement dans les besoins des utilisateurs peut aussi inciter l’équipe à revoir totalement sa vision produit. Par exemple, lorsque les néo-banque ont envahi le marché. Les banques Françaises historiques aurait dû adopter un virage important dans leur stratégie afin de rester compétitives.
• Retour utilisateurs
  Enfin, notre travail étant de satisfaire les utilisateurs, leurs retours à la suite de tests ou à l’utilisation du produit peuvent être à la source de modifications urgentes à intégrer rapidement.

Toutes ces urgences représentent tout un tas de raisons qui poussent le Product Owner (PO) et à l’équipe à renoncer à ses principes, au moins temporairement, pour accepter de changer le périmètre d’un sprint en cours, en fonction des impacts rencontrés.

Etape #2 : Intégrez les urgences prioritaires !

Restez dans le cockpit ! Crédit : Pexel

À la suite de cette analyse et de ce tri, le Product Owner (PO) a toutes les clés en main pour juger de la pertinence des imprévus.

Dès lors, les bugs deviennent plus faciles à prioriser. Les bugs critiques devant être corrigés le plus rapidement possible et devront être intégrés dans le sprint afin d’être livré au plus vite.
Les autres bugs sont intégrés dans le sprint par la suite si l’équipe a encore suffisamment de capacité à faire. Le cas échéant ces éléments seront traités ultérieurement.
Il est donc recommandé à l’équipe, pour chaque sprint, de réserver du temps de travail pour la résolution de ces bugs.

Pour ce qui est des nouvelles fonctionnalités à intégrer en urgence cela reste, je vous l’accorde, bien plus compliqué. Ces urgences-là varient selon les équipes et les entreprises, laissant la place à la subjectivité de chacun.
Par exemple : une fonctionnalité à développer en urgence pour un utilisateur ou une typologie d’utilisateur peut s’avérer très prioritaire si l’utilisateur en question est l’utilisateur cible du produit. Dans le cas où celui-ci représente la cible secondaire de votre produit, alors sa priorité sur le reste est à remettre en question.

Dans tous les cas pour chaque développement à intégrer dans un sprint, il faudra rédiger la user story et l’estimer. Cela permettra à l’équipe de replanifier son sprint en cours afin de faire de la place aux urgences.

Etape #3 : Enfin, rejetez !

Dire non et rejeter – Crédit Pexel

Le Product Owner détient un rôle essentiel dans le bon fonctionnement agile de l’équipe. Son secret est de savoir dire non aux ingérences incessantes qui nuisent à la phase amont des développements (phase clé des méthodes agiles). Pour la « santé » de l’équipe, la vision produit et la qualité de son travail, il est important que le PO maintienne un périmètre de sprint ferme.

Il faudra donc, à la suite de l’étape de triage et une fois les fonctionnalités urgentes ordonnancées, que le Product Owner soit capable de rejeter les autres imprévus. Cette tâche peut être une des plus délicates du Product Owner. L’importance ici est que chacun comprenne pourquoi cette urgence a été prise en compte plutôt qu’une autre, pour éviter toute frustration. Impliquer les parties prenantes dès l’étape de triage des urgences ainsi que tout au long de la prise de décision est une solution que j’encourage vivement.

J’aime utiliser un atelier de priorisation «  ROI (Return Of Investment) »  avec les parties prenantes (souvent les acteurs « métiers ») que j’aurai exécuté seule avant, afin d’arriver avec une idée de backlog en tête. En ayant mené ma réflexion auparavant, cela me permet d’être plus à l’écoute des parties prenantes et d’affiner mon esprit critique.

Mon Oeil de Coach 🧐

Dans mon équipe, nous avons choisi de miser aussi sur le management visuel. Dans notre board KANBAN nous avons implanté une zone dite « expedite », réservée aux urgences.

Voici un schéma pour vous expliquer :

Kanban board avec expedite

Lorsque le Product Ower prend la décision de faire entrer une US dans cette zone, toute l’équipe se rassemble devant le board.

Nous estimons si besoin ce ticket et nous choisissons, ensemble, qui est le responsable de cette tâche. Le déplacement de l’US dans les différentes zones du KANBAN (en cours, review, etc..) peut être suivi par toute l’équipe et augmente la rapidité de son passage de “ready “ à “done”.

Par le management visuel, on responsabilise ainsi l’équipe et on donne le sentiment à tout le monde de former un équipage soudé pour braver toutes les tempêtes.

🎁 BONUS : Atelier ROI qu’est ce que c’est ?

L’atelier ROI ou « return on investment » permet de classer et prioriser les différentes fonctionnalités par la valeur métier (la valeur que les parties prenantes attribue à une user story) et l’effort de développement (le niveau de complexité l’équipe technique donneront à la user story).

Le ROI se calcule ainsi : valeur métier / complexité de développement

Il suffit aux parties prenantes et à l’équipe technique de prendre un jeu de poker planning et estimer les différentes US selon leur valeur métier et la complexité (pouvant être aussi nommé « effort »). Ensuite, le PO pourra calculer le ROI de chacun de ces US. Dans une équipe agile l’objectif est de donner le maximum de valeur le plus rapidement possible à son produit.

► Ce sont donc les US avec l’indice de ROI le plus élevé qu’il faudra traiter en priorité ! 😉

Avez-vous aimé cet article ? Partagez-le !
Une question ? Un mot doux ? Une remarque ? Commentez, ci-dessous !

……… ✂……………………………… ✂………………………………… ✂………

Envie d’aller plus loin ?

• Comment estimer un produit en Agile ?
• Comment comprendre l’intérêt de la coopération et de l’auto-organisation ?
• Mythe Agile : Scrum génère de la réunionite aigüe
• [LIVRE] Kanban – L’approche en flux pour l’entreprise agile de Laurent MORISSEAU
• Prioriser avec la business value

……… ✂……………………………… ✂………………………………… ✂………

En quoi puis-je vous aider ?

Je suis Agathe PENVERNE.

« Mon aspiration est d’aider mes semblables et mes équipes à s’épanouir dans des environnements agiles et à s’organiser autour de la résolution de problèmes. Je suis particulièrement intéressée par le coaching des organisations et des équipes géographiquement dispersées pour contribuer à la création de produits d’exception. »

Je suis une adepte des concepts et des pratiques du « Lean » et de l’Agile, de la création d’équipes hautement performantes, de l’introduction du remote dans les entreprises et de bien d’autres sujets d’amélioration des équipes et des produits.

Contactez-moi pour en parler :

🚀 Linkedin : https://www.linkedin.com/in/agathe-penverne-a696a190/