3 ateliers agiles pour accélérer le déploiement de votre première pratique ITIL !

ITIL et pratiques agiles sont-ils réconciliables ?

Tout le monde le sait, certains termes tels que ITIL ou IT Service Management (ITSM) ne sont pas du genre à émoustiller les esprits créatifs, ni à faire saliver les papilles des geeks qui fourmillent d'idées technologiques au sein des services IT.

Pour autant, et n'en déplaise aux technophiles et agilistes de tous poils, chaque entreprise atteint tôt ou tard un cap où il devient nécessaire de « professionnaliser »  les services IT qu'elle délivre. Cette nécessité est incontournable pour répondre aux objectifs de croissance, avec pour sous-jacent, le besoin continu d'améliorer l'image de marque via la qualité et la disponibilité des services exposés aux clients.

A titre d'illustration, je prendrai le cas de mon fils lorsqu'il emménagé dans son premier appartement en France. Il a choisi son opérateur de gaz et d'électricité, non pas sur la base des coûts, mais sur la qualité de service et l'expérience utilisateur proposé par l'un des opérateurs :

• Étape 1 - présentation du produit : présentation d'un tableau comparatif des tarifs suite à une sélection très rapide d'une poignée de critères (surface de l'habitation, type de chauffage, nombre d'habitants)
• Etape 2 - conversion : un formulaire simplifié (nom, adresse, numéro de téléphone et adresse email) permettant d'enclencher le processus de conversion suivi par la mise à disposition automatique d'un devis PDF.
• Etape 3 - acquisition : via un rappel téléphonique dans la minute, fixation du rendez-vous pour le passage du technicien dans le nouveau domicile dans une plage horaire réduite.

Le tout aura duré une dizaine de minutes à peine. Les écarts de tarifs entre les opérateurs se jouant plusieurs chiffres après la virgule, c'est la bien qualité de service qui aura finalement fait la différence.

Chacun pourra facilement imaginer les différentes équipes IT cachées derrière ces étapes (DEV et OPS). Prenez le risque de retirer ou de dégrader la qualité d'un seul des services fournis par l'une de ces équipes et c'est toute l'expérience utilisateur qui est compromise.

Dans ce cas, comment faire pour aligner toutes les équipes (agiles et non agiles) sur des pratiques et des processus communs et standardisés (release management, change management ou incident management) quand on sait que les pratiques agiles sont synonymes d'autonomie, d'auto-organisation, et de cycles courts ?

Je répondrai avec cette métaphore : "les plus belles photos sont shootées par les meilleurs photographes. Pas par les meilleurs appareils photos."

Dans les services IT comme en photographie, il est important de ne pas confondre les intentions avec les moyens. Un photographe s'intéresse au sujet, au cadrage, à la composition, à la lumière : en bref, à l'image qu'il veut obtenir et à l'intention artistique qu'il veut lui donner (dramatique, chaleureuse, intrigante, ...). L'appareil photo n'est qu'un outil pour atteindre et restituer l'intention. La niveau de sophistication de l'appareil photo permet de faciliter ou d'accélérer le processus de production, mais ce n'est pas pour autant une baguette magique.

Aujourd'hui, l'apport principale de la photo numérique, c'est le résultat immédiat, et la capacité à recommencer le cliché jusqu'à obtention du résultat attendu, par l'adaptation de tel ou tel paramètre, avec beaucoup plus de facilité et de rapidité qu'avec un système argentique et pour un coût largement inférieur.

Les pratiques agiles sont elles aussi un moyen, un outil permettant de faciliter ou d'accélérer le processus de production. Comme en photographie, les résultats visibles rapidement (inspection), la culture du feedback (transparence) et l'adaptation aux changement en sont les ingrédients principaux.

Les pratiques agiles au service d'ITIL !

Par conséquent, l'agilité est un excellent moyen pour déployer des pratiques ITSM ou ITIL, tant qu'on la considère comme un outil et non comme un objectif à part entière.

C'est dans un contexte agile que je suis intervenu en tant que Coach Agile pour accompagner une Product Owner et un Scrum Master dans le cadre de l'amélioration et du déploiement de pratiques ITSM adaptées aux contextes et aux spécificités d'une entreprise dans le secteur de l'assurance.

Au total, il aura fallu 3 ateliers de 2 heures pour mettre à l'étrier le processus « incident management », outillage exclus.

Avant de présenter le déroulé de ces quatre ateliers, je rappelle l'importance de certains pré-requis qui ont été produit en amont en collaboration entre la Product Owner, le Scrum Master et management IT :

• Production de la « vision » du projet, permettant au management IT et aux équipes IT d'être aligné sur les objectifs du déploiement des pratiques ITSM

• Présentation par la P.O des objectifs et de la vision à une trentaine de collaborateurs (DEV, OPS, métiers). Cette étape a aussi permis d'identifier les personnes intéressées et motivées pour contribuer aux différents sujets (release management, change management, incident management, ...)
• Constitution de l'équipe :
  • 1 Product Owner - entièrement dédiée au projet, disposant d'une forte expérience ITSM et novice dans les pratiques agiles ;
  • 1 Scrum Master
  • 1 équipe, constituée d'une douzaine de personnes, issues des différentes équipes (DEV, OPS, métier) intéressées pour collaborer à la rénovation du processus de gestion des incidents.

• Contraintes : disponibilité très limitée des membres de l'équipe, l'enjeux étant la capacité de les réunir en mode "pick up" sur des périodes aussi courtes que possible.

Atelier n°1 - Event Storming

• Durée : 2h
• Nombre de participants : 12
• Format : Event Storming (Like)

En tant que Coach Agile, j'ai proposé au P.O et au S.M de conduire un event storming, avec un double objectif :

• Récolter les « douleurs » constatées ou subies par les différentes équipes dans leurs activités quotidiennes lorsqu'elles se retrouvent face à un incident

• Réaliser un alignement sur les douleurs prioritaires à corriger. En effet, toutes les fois où on offre la possibilité d'exprimer « ce qui ne va pas », on ouvre la boite de Pandore. Chacun perçoit ses propres difficultés comme prioritaires. Rassemblées ensemble autour d'une même table et d'un même sujet, chacun peut « relativiser » ses propres problèmes face à ceux des autres.
• Résultats obtenus
  • Production d'un workflow générique de résolution des incidents, adaptés aux besoins de l'entreprise. Il a permis à l'équipe de se mettre d'accord sur une séquence commune et standardisée à tout le service IT, visant à mieux traiter les incidents dans le futur

• • Une liste priorisée des « douleurs » que l'équipe souhaite corriger dans le futur

• • Une liste de termes à éclaircir ou redéfinir : incident mineur VS incident majeur ; niveau de service, ...

Je ne veux pas détailler ici le déroulé d'un event storming, il existe beaucoup de littérature sur ce sujet sur le net.

Atelier n°2 - User Story Factory

• Durée : 2h

• Nombre de participants : 12

• Format : User Story Factory

L'objectif du deuxième atelier était d'enrichir la qualité du premier workflow pour permettre à l'administrateur Jira de construire une première ébauche. Pour cela, il avait notamment besoin d'informations telles que : Qui est responsable de chaque étape (= quel rôle dans l'organisation) ? Quelles informations faut-il pour pouvoir traiter l'incident et le faire avancer dans le workflow de résolution ? Quels autres rôles dans l'organisation sont  potentiellement intéressées par cet incident et sa résolution ? Etc.

Les membres de l'équipe étant familiers avec le format User Story (« en tant que, je souhaite, afin de »), nous avons imaginé un atelier collaboratif où l'intelligence collective permettrait de co-construire rapidement des US, chacune associée à une étape du workflow. L'idée était que l'administrateur JIRA puisse s'appuyer sur le contenu de ses US pour construire un MVP.

Pour ce travail de production, nous avons scinder l'équipe en deux groupes, et nous leur avons demandé de trouver les réponses à ces questions :

• En tant que : identifier qui (= rôle) est responsable de traiter l'incident dans l'étape en cours ?

• Je souhaite : quel est le nom de l'étape en cours ?

• Afin de : quel est le but ultime de l'étape, quelle est sa plus value attendue dans le processus de résolution ?

• Données à collecter : quelles sont les informations manquantes et utiles à cette étape pour contribuer à résoudre l'incident ?

• Comment : quelles sont  les actions à faire ?

• Feedback et communication : qui (= autres rôles) est susceptible d'être intéressés par le suivi et la résolution de l'incident ?

• Ce qui ne va pas : quelle est la douleur que cette étape va corriger ?

L'atelier a été conduit en mode "plan de vol" pour s'assurer que chaque participant avait collaboré sur l'ensemble du workflow, et pas uniquement sur un sous-ensemble.

Résultats obtenus

• Alimentation ultra rapide d'un premier backlog.

• Les US produites n'ont pas atteints une qualité « académique » mais cela a permis de générer à nouveaux des discussions et un alignement, et cela a surtout permis d'aider l'administrateur Jira (inclus dans l'atelier) à comprendre et capturer les besoins les plus importants.

• Les discussions ont contribué à l'amélioration du workflow, le faisant passer d'un aspect très linéaire à une version plus évoluée, incluant des bypass et des raccourcis.

Atelier n°3 - Ajustement

• Durée : 2h

• Nombre de participant : 11

• Format : Review

Au cours des 2 ateliers précédents, certains participants avaient exprimés - à juste titre - leurs craintes vis-à-vis du risque à passer trop de temps à se mettre d'accord sur des workflows, à "pinailler" sur les détails et perdre le focus sur l'essentiel. Par ailleurs, les participants venant du développement ou de la production, et en ce sens habitués à itérer sur des sujets relativement concrets, travailler une matière abstraite telle que la gestion des processus risquait de devenir un gouffre chronophage où s'exprime des avis purement théorique plutôt que des arguments éclairés et objectifs. L'heure était donc au constat qu'il fallait présenter rapidement des éléments plus concrets et factuels.

L'objectif de cet atelier était donc de présenter aux participants les premiers résultats concrets (une démo) de ce que l'administrateur Jira avait réalisé suite au deuxième atelier.

• Résultats obtenus
  • Récolte des feedbacks,

• • Amélioration du backlog

• • Prise de conscience des liens et limites entre processus et outil : les deux se nourrissent mutuellement et doivent respectivement s'ajuster en conséquence

Bilan et regard critique

D'autres ateliers de travail ont suivi ces 3 premiers, avec un nombre de participants plus limité (tel qu'expliqué en amont : la disponibilité était une des contraintes fortes). Ils ont permis à la P.O de documenter et d'outiller le premier processus ITIL, et d'accompagner les équipes.

Bilan : un an après ces 3 ateliers et compte-tenu des contraintes de départ (faible disponibilité, délais réduits), voici les éléments notables :

• Processus de gestion des incidents implémenté, documenté, et supporté par un outil dans une première version

• Le processus a été partagé, mais le temps faisant, les équipes rencontrent encore parfois quelques difficultés et ont parfois besoin d'améliorer leur collaboration

• Une rétrospective inter-équipe a permis de mettre en exergue les nouvelles douleurs et les nouveaux besoins