Scrum est-il soluble dans ITIL?

Fraichement certifié ITIL Foundation, la préparation de cette certification m'a amené quelques réflexions autour de l'agilité. Je les livre ici à chaud:

Au-delà de la question ITIL est-il agile, je me posais la question d'utiliser Scrum au sein d'une DSI implémentant ITIL?

On peut déjà se poser la question pourquoi cette réflexion puisqu'ITIL adresse essentiellement la gestion de la production informatique. Cependant, un pont est jeté avec les études et développements au travers du processus change management.


On peut partir d'un socle commun à tous ces processus et normes: La roue de Deming.
C'est la partie la plus évidente. Pour Scrum, on pourrait rapidement faire les liens:

• Plan: Sprint Planning
• Do: le Sprint en lui-même
• Check: Le Daily Scrum
• Act: La retrospective

La roue de Deming est un fondement d'ITIL, on la retrouve plus précisément dans le Service level Management avec le programme d'amélioration des services dans une démarche cyclique.

Puis vient le principe de remettre le client au centre des préoccupations avec tout ce que cela implique (besoins métiers, feedback, responsabilisation,...). Même idée pour Scrum ou XP. Cependant, l'implémentation me pose plus de problème. Le change manager consolide toutes les demandes d'évolutions logiciels provenant de la direction métier ou des utilisateurs via le service desk. Avec ma compréhension, il pourrait avoir le rôle de Product Owner cependant ce n'est pas le client final.

La product Backlog existe aussi côté ITIL sous une autre forme avec également une notion de priorisation.


A ce point on rentre sur une zone de divergence entre les approches:

Scrum est l'art du possible. Un but d'ITIL est de remplacer le domaine du possible par des contrats de services. On retombe ici sur une problématique récurrente de contractualisation de projets agiles.

Un autre point de divergence sur les messages forts véhiculés, est la réactivité de Scrum ou d'XP et la proactivité d'ITIL. Cependant, ce point est à mon sens un faux problème car la proactivité s'adresse plutôt à l'aspect production du SI (gestion des problèmes, suivi des performances, plan de capacité, ...).

Remarque XP: Le Test-driven development amène de la proactivité sur l'assurance qualité.

ITIL propose de responsabiliser et professionnaliser les rôles. Ce qui peut sembler contradictoire avec une équipe scrum regroupant tous les rôles. Cependant, on parle ici de processus transverse pour décloisonner les services. Je n'y vois donc pas de contradiction puisque Scrum est également un processus transverse pour le développement.

La professionnalisation des rôles et des équipes permet d'augmenter la productivité en diminuant les bruits, c'est également un des indicateurs que l'on suit avec la velocité.

En terme de scalabilité de projet, je n'ai pas eu de réponse claire pour une démarche ITIL alors que Scrum y répond clairement avec les Scrums de Scrums.

A première vue, il semble possible de faire cohabiter un projet Scrum ou XP dans un processus global ITIL en adaptant le rôle du product owner et le contrat de service pour ce projet.