Itil et agile enfin compatibles ?

Quelles sont les difficultés rencontrées ?

Des nombreux échanges que j'ai pu avoir au cours de mes missions, il faut bien noter que la difficulté à mettre en œuvre l’agilité dans un contexte Itil (ou l’inverse) tient d’abord et essentiellement au fait qu’Itil est vu par beaucoup d’équipes applicatives, premières utilisatrices des méthodes agiles, comme destiné à la « production ». Entendez « non adaptable aux équipes applicatives ». Cela vient principalement du fait qu’aucun processus ne prenait en charge la récupération des besoins clients - couverts désormais par la pratique de Business Analysis.

Le deuxième point de blocage et qui rendait toute discussion compliquée, venait du goulot d’étranglement que représentait le Comité d’Approbation des Changements, augmentant les temps de traitement et de mise en production des modifications applicatives… avec pour conséquence d’être moins agile.

Il faut surtout garder en tête de trouver le juste équilibre entre la protection des environnements de production et la capacité à proposer régulièrement des nouveautés aux différents métiers. Alors, comment réussir à concilier ces deux objectifs ?

La preuve par l’exemple, optimiser le partage des processus

Le plus simple pour réussir cette démarche est de bien comprendre les enjeux et méthodes de travail de chacun des métiers adressés.

Pour détailler le principe, je m’appuie sur le cas d’une entreprise qui avait pour enjeu de faire converger dans un même processus des équipes utilisant des méthodes de travail différentes, afin de sécuriser les mises en production sans pénaliser le cadencement des déploiements. Le tout en respectant les bonnes pratiques Itil.

Au commencement, coexistaient des méthodes de gestion de déploiements variées :

• Déploiement suite à des projets en cycle en V,
• Déploiement de projets en mode agile,
• DevOps

Comment procéder ?

Premier conseil : ne surtout pas parler d’Itil. Aborder d’entrée de jeu le référentiel de bonnes pratiques est souvent un frein plus qu’un atout, étant perçu comme trop bureaucratique. 

Ensuite, il est important d’identifier quelles sont les méthodes de travail de chacune des équipes concernées et notamment comment s’organisent leurs activités. Si l’on se place d’un point de vue purement Itil, la mise en production s’articule autour de différentes étapes : identification/regroupement des besoins, planification, construction de la réponse, packaging de l’ensemble, tests, déploiement et clôture. La première étape pose question dans le mode agile où la partie identification/regroupement des besoins n’est pas figée et où la partie construction, packaging et test se fait de façon relativement groupée. S’il faut retenir une chose ici, c’est qu’il est crucial de tomber d’accord sur les activités, plus que sur leurs enchaînements et regroupements.

Aller à la rencontre des équipes Qualité nous a permis d’identifier avec elles les jalons obligatoires à franchir pour être autorisés à passer notre package applicatif en production. Ces jalons s’avèreront utiles à notre processus de Release Management sachant que ces points de contrôle doivent être validés par le contrôle des changements. Une fois ces éléments partagés et actés, il faut savoir précisément comment se feront les validations.

Vers moins de centralisation des validations

Il faut donc identifier, pour chacune de ces validations, si elle sera faite manuellement ou automatiquement. Cette compréhension des méthodes de validation permettra demain de considérer, si l’ensemble des jalons sur un domaine particulier est 100 % automatique, de passer automatiquement le CAB (Change Advisory Board). Cela tombe bien, ITIL4 parle désormais d'Autorité des Changements qui n’est pas nécessairement un CAB mais peut-être un automate qui accélère le traitement ou un expert pouvant prendre la décision rapidement.

A la fin de ce travail, mené en corrélation avec l’ensemble des équipes, le résultat a été le suivant :

• Une validation de l’ensemble des étapes sur une Release,
• Une compréhension commune des activités devant être menées (intégrant entrants, sortants et contrôles),
• Une liste des jalons de qualité devant être passés,
• et donc un processus commun.

Ce qui est vrai pour « Agile » est vrai pour DevOps

La dernière version d’Itil parue début 2019 permet de régler un certain nombre de « reproches » qui étaient adressés aux précédentes versions. En réconciliant bonnes pratiques et gestion de projet désormais pilotés en mode agile, l’IT travaille en co-création en tirant le meilleur des deux côtés avec plus de souplesse. Les itérations sont plus rapides mais néanmoins sécurisées avec rigueur répondant ainsi aux nécessités des entreprises qui doivent se montrer réactives.

• La prise en compte que la création de valeur n’est plus l’apanage de l’IT avec une notion forte de co-création,
• Un principe directeur centré sur l’agilité : progressez de façon itérative en vous appuyant sur le feedback,
• La création de la pratique Business Analysis donne un cadre à la collecte des besoins,
• La séparation des pratiques de Release Management et de gestion des déploiements,
• L’introduction de l’autorité de changement avec une vraie volonté de casser la centralisation du CAB telle que vue auparavant.

Les apports d’ITIL4 ne se limitent bien-sûr pas à ce seul périmètre et tout l’intérêt de la nouvelle version est aussi dans l’intégration d’une vision plus globale et transverse à l’IT, intégrant notamment des pratiques autour de la gestion des talents ou encore le Business Analysis par exemple. Un nouveau champ de possibles à explorer pour améliorer la qualité des services.

Allan Dujiperou, Manager Process Advisory - Offer Unit IT Service Excellence de Devoteam.