Ayant expérimenté la méthode Agile tant au niveau du développement d’applications que de la gestion de projets, je me suis demandé comment les principes Agile pouvaient s’appliquer à la gestion de services TI (ITSM). Quand on y regarde de plus près, quelle est vraiment la différence entre une liste de bogues et de demandes d’amélioration pour une application et une liste d’incidents ou de demandes de services ? La gestion des services n’est qu’une série de tâches brisées en plusieurs morceaux qui doivent être livrées une à une pour arriver à un produit final.

Que nous apprend Agile et comment les principes de cette méthodologie peuvent nous aider à livrer nos services ? À la base, l’objectif d’Agile est de satisfaire les clients par la livraison soutenue d’itérations d’un logiciel. Ce principe ressemble étrangement à celui d’une bonne gestion des services, c’est-à-dire satisfaire ses clients par la livraison soutenue de services permettant d’atteindre les niveaux de services.

Un autre principe Agile veut qu’on livre nos projets autour d’individus motivés en leur donnant l’environnement et le soutien dont ils ont besoin. Plus encore, il est important de leur faire confiance et de croire qu’ils vont être en mesure de faire le travail. Malheureusement, pour beaucoup de gestionnaires TI, ce principe est trop difficile à appliquer, mais il est pourtant essentiel. Tout le monde sait qu’une équipe motivée, avec les bons outils et en qui on a confiance, est un gage de succès, mais pourtant la microgestion a trop souvent sa place. En fin de compte, aucun service ne peut être mieux livré sans l’engagement, le travail acharné et l’expertise de son équipe.

Comment appliquer concrètement le mode Agile à notre gestion des TI ou, plus précisément, comment gérer les billets de manière Agile ? Le plus grand défi est la diminution de la liste des billets ouverts, qui a tendance à contenir des billets très âgés ou qui ne bougent pas vraiment. Avec le temps, cette liste devient toujours de plus en plus grosse et ingérable. Notre objectif est donc d’utiliser Agile pour contrôler cette liste tout en continuant de gérer nos billets entrants selon les priorités.

D’abord, débutons par une planification de sprints. Un sprint est une itération ou une livraison qui se déroule entre 1 et 4 semaine(s). Dans le contexte de la gestion des services, imaginons qu’un sprint est une période pendant laquelle nous voulons livrer un certain nombre de services. Par service, nous entendons un certain nombre de billets (incidents, problèmes, demandes, changement). Je vous recommande personnellement un sprint de 1 à 2 semaine(s) maximum, mais vous devrez ajuster selon vos niveaux de services.

La planification du sprint permettra de décider, tout simplement, quel billet doit être attaqué dans notre liste de billets ouverts. Il s’agira donc de choisir et d’assigner un certain nombre de billets aux membres de votre équipe. Un sprint doit être réaliste et faisable. Mieux vaut en assigner moins et en ajouter au besoin que de ne pas atteindre nos objectifs.

Vous choisirez vos billets selon les priorités, l’âge, l’importance, l’impact ou toute autre combinaison. Ça n’a que peu d’importance, mais comme notre objectif est de livrer notre service pour atteindre les niveaux de service, il est important de garder cela en tête en faisant nos choix.  Les ressources assignées à ces billets doivent comprendre qu’à la fin de ce sprint, ce billet doit être complété ou résolu. On doit pouvoir voir du mouvement sur ce billet. Il ne peut pas rester intouché.

Pendant le sprint vous devrez effectuer un Scrum tous les jours. Un Scrum est une courte réunion de 15 à 30 minutes. Pendant le Scrum, les questions suivantes doivent être répondues : Qu’est-ce que j’ai fait hier ? Qu’est-ce que je vais faire aujourd’hui ? Y a-t-il quelque chose qui m’empêche d’atteindre l’objectif du sprint ? Il ne s’agit pas d’une réunion technique ou l’on discute des billets. On veut simplement savoir si tout se déroule comme prévu et si une attention particulière doit être apportée à certains billets. Soyons honnêtes, c’est également une façon de nourrir l’esprit de groupe et la compétition. Personne n’aime dire qu’il n’a pas contribué.

À la fin du sprint, on pratique une revue de sprint. Cette réunion permettra de voir ce qui a été accompli et ce qui ne l’a pas été. On devra décider si certains billets non complétés doivent être reconduits dans le prochain sprint ou peut-être abandonnés. Oui, c’est possible, en gestion de services, d’abandonner des billets que l’on ne peut traiter.

Avec ces techniques en main, vous serez plus à même de livrer vos services et de contrôler votre liste de billets ouverts. Votre équipe se sentira plus impliquée et plus responsable que jamais. Cette méthode développe un sens proactif de la gestion des services : au lieu d’attendre que les billets nous reviennent à la figure, on les revoit à chaque début de sprint, on est conscient des enjeux et on prend des actions pour les adresser. C’est ce que l’on appelle prendre le contrôle. La méthode Agile ne règle pas tout, mais se sentir en contrôle, c’est déjà un grand pas dans la bonne direction.

Je vous conseille fortement de vous renseigner davantage sur la méthode Agile, car ce qui a été couvert ici ne représente qu’une partie. D’autres outils, comme le « poker planning », pourraient vous aider à mieux planifier vos sprints ainsi que la disponibilité de vos ressources. Nous y reviendrons peut-être dans un prochain article !

Benoît Tessier
Conseiller en gestion des processus chez ABna