6 bonnes pratiques pour un Service Management agile

Vous avez dit agile service management ? Bien que reconnues « d’utilité publique », les démarches agiles ont parfois du mal à prendre dans les équipes production, soucieuses de risques et de stabilité… Et cela se reflète dans les projets et pratiques de Service Management.

Chez Timspirit, nous sommes convaincus de l’apport de l’agile dans le Service Management et ce, aussi bien dans les projets de déploiements et processus outillés que dans les processus eux-mêmes. L’agilité doit également perdurer au delà des projets pour s’installer durablement dans la gestion des services, histoire de ne pas perdre les bonnes habitudes acquises lors de la phase de déploiement. Mais ne nous égarons pas…Ceci fera l’objet d’un article à venir. Commençons par nous intéresser à l’intérêt d’instiller de l’agilité dans les projets de refonte des outils et processus ITSM.

Dis, c’était comment avant l'agile service management ?

Lorsqu’il s’agit de mettre en œuvre un projet d’ITSM, la DSI n’est pas épargnée par les difficultés classiques d’un projet d’amélioration et/ou de refonte des processus.

Autrefois, refondre son ITSM commençait presque toujours par : « Faut choisir un outil ! ». Mais choisir son outil ITSM avant d’analyser les processus revenait un peu à trouver la solution avant de poser le problème.

À partir de l’an 2000, tout change (ou presque) avec l’irruption d’ITIL qui mettait l’accent sur le contenu de ce qui devait être outillé. Un travail préalable était alors préconisé afin de mieux définir les besoins et cadrer le projet – en définissant d’abord les processus et/ou les services, généralement via des ateliers, de façon d’abord macroscopique puis de plus en plus détaillée. Une fois calés sur les processus, les protagonistes choisissaient l’outil. Une deuxième série d’ateliers sur l’outil était alors organisée.

Résultat de courses : la plupart du temps, l’équipe était confrontée à deux écueils typiques des cycles en V : d’une part, à une inflation des délais et des efforts de conception, et d’autre part, à un écart flagrant entre le processus rêvé et son implémentation dans l’outil.

Cet écart entre rêve et produit réalisé était accentué par la méconnaissance de l’outil en amont de la définition des processus, les apports ergonomiques et les fonctionnalités

Depuis quelques années, la démarche agile a changé cette approche en permettant de sécuriser mais aussi d’accélérer le cycle du projet. Comment faire de « l’agile » dans un projet ITSM ? Tout d’abord en acceptant de mettre de l’agilité dans tout le cycle, y compris dans le pré-cadrage et dans l’expression des besoins. Rassurez-vous, nous n’allons pas vous faire un cours théorique sur les méthodes agiles mais plutôt explorer les spécificités des projets IT SM en mode agile, vu du côté développement et maîtrise d’ouvrage.

Bonne pratique n°1 : Structurer les sprints autour de livraisons fonctionnelles successives pour s’adapter au contexte

Le principe du sprint est de découper un projet en livraisons successives de logiciels opérationnels.

Comme dans tout projet agile, se pose la question : « opérationnel jusqu’ou ? ». Faut-il mettre le sprint en production en mode pilote, ou pas ?

Dans le cadre d’un projet ITSM, dans 95% des cas, une solution plus ancienne est déjà en place. Il n’est pas toujours facile de réduire le périmètre de déploiement d’un nouveau système ITSM, par essence fait pour relier toutes les équipes, surtout quand il doit cohabiter avec l’ancien... La solution ? Structurer les sprints en double boucle : des sprints mineurs sans mise en production pour itérer la conception de la solution, et des sprints majeurs avec déploiements successifs de processus de plus en plus nombreux et enrichis, sur un périmètre qui s’élargit au fur et à mesure.

Bonne pratique n°2 : Le Product Owner ITSM, un rôle clé

La priorité est traditionnellement donnée à la formalisation détaillée des processus. Leur implémentation dans l’outil doit respecter ces spécifications.

Dans une démarche agile, l’accent est mis sur la solution opérationnelle cible, c’est-à-dire sur les règles et workflows effectivement implémentés dans l’outil d’ITSM, et, bien sûr, leur adoption par les opérationnels.

L’implication continuelle des opérationnels, et plus particulièrement des Key Users, dans les différents cycles du projet (spécification, développement, sprints) garantit la prise en compte des contraintes opérationnelles plutôt que des processus élaborés sur papier. L’implication d’un véritable chef d’orchestre, capable d’aider à la constitution et la priorisation des fonctionnalités à développer est alors primordiale. Et ce chef d’orchestre, capable de coordonner l’ensemble des intervenants et de veiller à la collaboration avec les opérationnels, c’est le Product Owner. Ce dernier assure le leadership et dispose d’une vision globale équilibrée entre les aspects fonctionnels (processus), techniques (outil) et organisationnels (personnes). Dans le cadre des projets ITSM, il veille au traitement rationnel des demandes spécifiques qui pourraient amener à des développements spécifiques éloignant la solution du Saint Graal, de « l’out-of-the-box ».

Dans une grande organisation, le Product Owner peut déléguer une partie de sa responsabilité – typiquement vers les process ou service managers, s’ils existent, et souvent en organisant les « sous-produits » par processus. Conserver la cohérence de l’approche comme savoir prioriser les besoins face à un budget limité devient évidemment son rôle premier.

Bonne pratique n°3: Penser un sprint 0 très compact pour mettre de l’agilité dans l’expression des besoins en se concentrant sur la valeur

Nous l’avons tous constaté au moins une fois : définir des processus ITSM nécessite la coordination de nombreux acteurs (Qualité, Production, Gestion des services, Helpdesk, etc.) que l’on réunit sous forme d’ateliers de travail afin de définir des spécifications très précises. Avec, très souvent à la clé, une multiplication des séances de travail.

L’idée est donc de procéder avec un sprint 0 très compact, en comité restreint, dont l’objectif sera de définir les grands enjeux et objectifs du projet. Lors de ce sprint 0, les participants définissent les grandes orientations et les choix régaliens sur les processus. Le rôle de l’expert est d’aider à l’identification rapide des besoins « différenciants », qui permettront ensuite de choisir la meilleure solution lors d’un appel d’offre.

En résumé, cette pratique permet de gagner en réactivité et en qualité et de poser les grandes bases du projet ITSM.

Bonne pratique n°4 : Utiliser l’outil comme source d’inspiration pour travailler sur des « use cases » concrets

L’idée principale est d’offrir la possibilité de découvrir la solution et d’identifier ses points forts et ses limites avant d’avoir totalement défini les spécifications. Certaines solutions se déploient aisément et intègrent des processus prêts à l’emploi, permettant ainsi de procéder à un prototypage et à un enrichissement successif en s’appuyant sur des use cases très concrets.

Cette méthode contraint à charger des données de base (« Data Foundation »), à intégrer le catalogue de services. A la fin de chaque sprint, tout le monde dispose d’une vision à la fois concrète et globale de la solution cible.

Bien sûr, dans le cadre d’un projet ITSM, il est possible que le volume, la quantité et la qualité de données à charger soit problématique mais qu’importe … Le principe du mode agile reste le même : on livre, on améliore, on itère le déploiement… Et ce mode permet de prendre conscience très tôt des problématiques d’intégration de données, souvent sous-estimés et traditionnels gâcheurs de date butoir…

Grâce à cela, les spécifications tiennent compte des caractéristiques de l’outil et ce dernier devient une réalité plus concrète pour les futurs utilisateurs.

Bonne pratique n°5 : Faire œuvre de paresse intelligente pour limiter le nombre de livrables

Dans un projet ITSM, les livrables sont souvent un sujet critique. Nous avons pu compter, sur un projet en cycle en V, jusqu’à 300 livrables alors qu’une vingtaine auraient suffi. Soit 15 fois moins !

La nature ayant horreur du vide, le projet a tendance à produire à chaque étape des livrables. A l’étape suivante, elle retravaille sur de nouveaux livrables, bref on réinvente la poudre à chaque étape !

L’idée est d’avoir un même et unique document en première itération sur le macro-cadrage de chaque processus, puis de l’enrichir au fur et à mesure de l’avancée du projet.

Ce document de référence, devenu « bible » de chaque processus, fournit naturellement une belle matière première pour les tests, les formations et la communication sur la solution. Et hop ! De 20 livrables par processus, on passe à 1 ou 2 ! Cela permet également de faciliter la « maintenance » des documents produits, de limiter le nombre de livrables et les faire vivre au rythme du projet.

Bonne pratique n°6 : Mettre en place des rituels

L’agilité, c’est aussi l’adaptation au changement et dans cette optique, le suivi d’un plan projet rigide est voué à l’échec ! La méthode agile, plus ludique, plus interactive et plus participative permet de travailler sur du concret. Voici deux pratiques agiles qui se révèlent particulièrement bénéfiques dans le cadre de projets ITSM :

• La mise en place d’une gestion de projet visuelle, par exemple à l’aide de cartes Kanban, afin de focaliser les participants sur les réalisations prioritaires et formaliser l’avancement.
• L’instauration de Stand-Up meetings quotidiens de 5 à 15 minutes qui contribuent notablement aux échanges entre les acteurs du projet et à la résolution des éventuels points de blocage. Ceux-ci favorisent également la maîtrise du projet par le Product Owner en focalisant sur la vision globale et partagée.

Conclusion : l’agilité, goûtez-là, vous n’en reviendrez pas !

L’adoption d’une démarche agile pour les projets d’implémentation de solutions logicielles ITSM se révèle, dans la pratique, particulièrement bien adaptée. C’est la garantie de la mise à disposition d’un produit centré sur les fonctions essentielles, totalement adapté au contexte et aux besoins.

Elle constitue, bien sûr, une vraie rupture pour des directions production/infrastructure moins aguerries que les équipes développement. Une sensibilisation et un coaching des acteurs projet à la dynamique de la méthode, à ses rituels et son vocabulaire, sous forme de sessions mixant théorie et pratiques sous la forme de Serious Games, permettent de mieux gérer cette conduite du changement.

Enfin, l’apport d’une culture et de pratiques agiles en mode projet permet de préparer la prochaine étape : intégrer l’agilité dans la culture de « Run » des services et des processus… Mais, patience, ce sera l’objet d’un prochain article de cette série…