Cela ne marchera pas : Dissiper le mythe de l'agilité dans les services partagés

"Cela ne marchera pas".

En tant que consultant Agile, c'est ce que j'entends assez régulièrement de la part des équipes des services partagés.

Bien sûr, c'est formidable de voir que nos partenaires AppDev peuvent apporter de la valeur de manière itérative sur un seul produit. Nous soutiendrons même ces efforts d'un point de vue back-end. Mais notre travail est trop fluide, trop dynamique. Nous n'avons pas un seul produit. Nous soutenons de nombreux produits et de nombreux outils répartis dans l'ensemble de l'entreprise.

Nous sommes un animal différent. L'approche Agile ne fonctionnera pas ici. La liste des raisons est longue. En plus des raisons ci-dessus, vous pourriez inclure : 

• Nous sommes traditionnellement perçus comme une dépense opérationnelle plutôt que comme une organisation à valeur ajoutée.
• Nous sommes stratégiquement organisés en silos de connaissances.
• Nos priorités peuvent changer d'une minute à l'autre, si bien qu'il est pratiquement impossible de s'engager dans un travail qui ne changera pas.
• Nous devons travailler la nuit et les week-ends, si bien qu'il est tout simplement impossible de maintenir un rythme soutenu.

Si l'on regarde de l'extérieur, il peut sembler que ce que nous appelons "Agile" n'est pas une bonne façon de construire un environnement de services partagés. Mais il est important de comprendre ce qu'est réellement l'Agile.

L'agilité est un ensemble de quatre valeurs et 12 principes conçu pour changer la façon dont nous envisageons la création de valeur, quelle que soit la définition que vous donnez de la valeur.

Peut-on faire preuve d'"agilité" dans le cadre d'une gestion de projet "en cascade" ou traditionnelle ? Oui, c'est possible ! C'est juste que la "chute d'eau" ne soutient pas l'état d'esprit agile de la même manière que d'autres cadres tels que Scrum ou Kanban (et la chute d'eau peut encourager de mauvais comportements).

Et si je vous disais que les méthodes agiles peuvent être, et ont été, appliquées dans les services partagés et les groupes d'infrastructure avec un énorme succès ? Ils ont même été en mesure de le faire en utilisant certaines des mêmes méthodes que celles utilisées dans d'autres secteurs de l'entreprise.

Examinons quelques-uns des problèmes les plus courants et les techniques utilisées pour gagner en agilité.

Demandes de travaux urgents

Défi : Revenons à cette tornade de demandes qui hante les équipes d'infrastructure et de services partagés. C'est tout simplement la nature du flux de travail. Pour ces équipes, le changement se produit au jour, à l'heure, parfois à la minute.

Lorsque votre travail nécessite 80% de support (ou plus) qui change à la minute et 20% d'activités de projet statiques, il peut être difficile de se concentrer sur un corpus de travail unique ou même d'avoir la capacité de s'engager sur un Sprint Backlog de 2 semaines Scrum.

Solution : Il existe plusieurs façons d'aborder ce problème dans un cadre Agile. Scrum, qui reste le cadre le plus utilisé, dispose de ce que l'on appelle le "tampon d'interruption". Ce petit outil est conçu pour rendre transparents tous les changements en cours et créer un espace pour ce qui prend votre temps en dehors du travail engagé. Il vous aide à le mesurer et à planifier ce que l'on peut appeler "le temps d'hier". Comment pouvons-nous utiliser ces informations pour nous améliorer et devenir plus prévisibles ?

Certaines régions ont réussi à utiliser Kanban comme un mode de fonctionnement en flux continu ou en production allégée. 

Bien que cela élimine le besoin d'itérations et la possibilité de changer le travail et les priorités en cours de route, l'équipe doit se rappeler qu'il est toujours important d'avoir une voix unique sur les priorités du carnet de commandes, un propriétaire et un coach de notre processus, le temps de s'arrêter et de s'adapter à l'amélioration continue et de planifier en tant qu'équipe. Ce ne sont là que de bonnes idées, quel que soit le cadre.

Mesurer l'impact des services partagés sur une organisation

Défi : Pouvez-vous attribuer une valeur à la création d'un nouveau type de volant sur la valeur globale d'une voiture nouvellement conçue ? À moins d'être actuaire, probablement pas.

Pourtant, ce nouveau volant a apporté une valeur ajoutée d'une manière ou d'une autre. Quel est le rapport avec les services partagés ou les équipes d'infrastructure ?

Tout.

Comme je l'ai déjà dit, ces équipes ne possèdent souvent pas leur propre produit ou service - elles renforcent celles qui le font. Elles renforcent les autres équipes en leur apportant leur expertise et leurs compétences spécialisées. Donner du pouvoir aux autres est une chose puissante. Mais cela peut rendre difficile de montrer comment ces équipes ont aidé l'organisation dans son ensemble (ou des sous-ensembles de l'organisation) à atteindre leurs objectifs de produit.

Les mesures sont importantes. Comment mesurer la valeur d'un service partagé ou d'une équipe d'infrastructure ?

Solution : Pour mesurer l'impact des services partagés, il est important d'avoir des objectifs clairs et partagés. OKR (objectifs et résultats clés) sont justement des outils utilisés par un nombre croissant d'organisations.

Les équipes chargées de l'infrastructure et des services partagés ont pour mission de faire avancer les choses dans des domaines spécifiques. 

Fournir des services spécialisés que personne d'autre ne peut offrir. Cependant, si votre organisation a des objectifs clairs et partagés, la mesure de l'impact est aussi simple que de montrer que l'équipe a ajouté de la valeur en aidant à atteindre des objectifs spécifiques de manière spécifique. Votre équipe ne conçoit peut-être pas l'ensemble de la nouvelle voiture, mais votre nouveau volant a apporté une valeur ajoutée et a été un élément clé dans la réalisation de l'objectif produit.

Silos de connaissances

Défi : Nous avons l'équipe serveur, l'équipe réseau, l'équipe données, l'équipe télécom, l'équipe sécurité, etc. Le problème est qu'il est de plus en plus fréquent de voir un ensemble de services commerciaux répondre aux besoins de tous ces groupes qui doivent collaborer dans de nombreux domaines de valeur. En outre, lorsqu'un ticket d'assistance arrive, il passe invariablement d'une équipe à l'autre tandis que tout le monde pointe du doigt l'origine du problème. Cela crée une insatisfaction massive chez les clients.

Solution : Équipes de soutien aux services commerciaux - Les petites équipes interfonctionnelles promues dans Scrum sont créées avec succès en faveur des silos de connaissances pour fournir à la fois du travail de projet et du soutien aux services commerciaux spécifiques fournis ; ce qui n'est pas sans rappeler une équipe interfonctionnelle pour soutenir un seul produit dans AppDev.

Les membres de chacun des groupes décrits, selon les besoins, sont placés dans une seule équipe, qui travaille en équipe et développe une "forme en T" pour soutenir un domaine de service commercial. Cela signifie qu'un ticket est transmis à une seule équipe disposant de toutes les compétences nécessaires pour le résoudre, ce qui élimine pratiquement le carrousel de tickets d'assistance.

N'oubliez pas que les méthodes agiles ont été mises au point pour aider à résoudre les problèmes liés aux domaines de travail typiquement marqués par le changement. Si l'infrastructure et les opérations sont quelque chose, c'est qu'elles sont lourdes de changements. Jetez un coup d'œil plus approfondi aux méthodes et aux cadres proposés par la méthode Agile.

Des parties de ce billet ont été initialement publiées dans un blog pour l'Agence européenne pour l'environnement. Alliance Agile également écrit par Robert Woods.