September 20, 2022

Exemple d’animation de daily avec gestion du RUN

publié : September 20, 2022

Il existe beaucoup de documentation sur l’organisation des daily d’équipe agile, les bonnes pratiques associées mais moins sur la gestion de la maintenance, des incidents de production, la correction du problème, son impact sur l’organisation de la journée de travail et le bon usage des outils de ticketing, nous allons évoquer un exemple d’animation de daily avec gestion du RUN.

L’urgence matinale : un incident de production à traiter

L’équipe est réunie autour du tableau de post-it à traiter, Pierre annonce que l’assistance utilisateur a reçu des dizaines de ticket d’incidents à cause d’un problème sur le serveur de production, d’ailleurs Paul n’est pas la car il est déjà sur le coup (donc on aura pas les infos sur ce qu’il a fait hier et qu’il devait partager); “ça semble urgent il faut s’en occuper!”.

D’ailleurs le chef est exceptionnellement venu car il a reçu des emails pressants sur le sujet et veut vérifier “qu’on est sur le coup” pour rassurer ses interlocuteurs. Ensuite on aura deux variantes de déroulement du daily entre le débat monopolisé par le sujet pour débattre de la cause et l’origine du problème, et celui avec une part significative de l’équipe qui disparait pour aller traiter le sujet.

Les incidents bousculent ainsi le fonctionnement de l’équipe en préemptant les ressources compétentes pouvant s’occuper du sujet. Ils mettent notamment en oeuvre le rôle du sauveur et sont aussi un potentiel échappatoire aux sujets en cours. Il faut donc revenir aux fondamentaux de la maintenance et de l’agilité.

Qu’est-ce que la maintenance ?

Le but principal de la maintenance est d’assurer une bonne disponibilité des services proposés pour le périmètre concerné conformément aux niveaux de service attendus par le client et les utilisateurs ; que cela soit en préventif (réduire la probabilité de défaillance ou de dégradation de service sur base de critères prédéterminés) ou en correctif (intervention après défaillance) ou en adaptatif (rester compatible que ce soit fonctionnellement ou réglementairement) ou en évolutif (améliorer le fonctionnement).

Ainsi le dispositif de maintenance doit se concevoir dans une logique d’amélioration continue du service rendu (moins de pannes, meilleure réactivité, moins cher…). Dès lors cela présuppose une analyse des demandes et tickets reçus AVANT de lancer des travaux, pour vérifier la gravité du problème remonté avec les engagements de service qui ont été pris.

J’ai par exemple connu des clients refusant de payer les niveaux d’hébergement ou de maintenance qu’ils auraient souhaité en fonctionnement régulier de leur produit… Il faut savoir le rappeler le moment venu.

Ceci ne concerne bien évidemment pas les ruptures graves de service pour lesquelles une intervention immédiate est requise, mais cela devrait rester des cas exceptionnel et non récurrent (sinon je vous invite à mettre en place une cellule de traitement du problème).

Bien répartir les rôles

Le premier conseil est d’avoir pour objectif est d’éviter de perturber autant que possible la journée de travail qui aura été établi lors du daily. On peut ainsi désigner, avec une rotation quotidienne ou hebdomadaire pour impliquer tous les équipiers, un chargé de suivi des événements de production qui sera le point de contact unique (SPOC : Single Point Of Contact) pour la journée de toutes les sollicitations de type “urgence”. Son rôle sera à la fois d’analyser les sujets remontés mais aussi de préserver les autres des interruptions.

Ce responsable temporaire du RUN devra ainsi préparer un compte rendu de sa journée pour le daily suivant avec les points majeurs à remonter et étudier les effets sur le sprint en cours pour proposer des ajustements ou scénario de traitement. Il pourra notamment vérifier la tenu des engagements de service AVANT de solliciter l’expert incontournable : si le sujet peut attendre alors il saura l’identifier, à défaut il pourra arbitrer entre les deux demandes.

En bref le point quotidien permettra d’aborder les sujets de maintenance de manière apaisé et en dehors d’un contexte d’urgence et de pression, tout en sécurisant la participation de tous.

A propos de l'auteur

Olivier est ingénieur en systèmes d'information d'entreprises (Industrialisation, technologies informatique et méthodes associées).
Il est spécialisé dans le pilotage de projets IT stratégiques et l'accompagnement de clients souhaitant optimiser leur processus, mieux piloter leurs portefeuilles de projets (Portfolio Management - PPM) ou construire et mener une transformation digitale ou agile.

ARTICLES PUBLIÉS

Qu’est-ce que le “mode produit” ?

Qu’est-ce que le “mode produit” ?

Exemple d’animation de daily avec gestion du RUN

Exemple d’animation de daily avec gestion du RUN

Comment initialiser un backlog agile

Comment initialiser un backlog agile

Comment prioriser son backlog : 3 erreurs à éviter

Comment prioriser son backlog : 3 erreurs à éviter
Insert About the Author
>