Lors de la transformation numérique des entreprises historiques, dites brick-and-mortar (Banques, Retail, Telecommunications, ...), une grande majorité des entreprises rencontre une problématique qui se résume en une phrase :

Les entreprises font de l'agilité Projet au lieu d'être agile à l’Échelle.

Deux notions très fortes sont à la fois les symptômes de l’échec et les clés de réussite :

• Absence d'incarnation de transformation agile :

Les entreprises qui "font" de l'agile ont conservé leur culture d'entreprise historique, avec un découpage verticalisé des fonctions, des méthodes de travail, des responsabilités : chacun est maître sur son royaume. C’est ce qu’on pourrait appeler le changement dans la continuité. Chacun pilote son budget en fonction des priorités de son propre périmètre. L'ambition "d'ouvrir les silos" n'est pas incarnée et la pensée du produit final n'est pas présente.

Il est important de se rendre compte du nombre d’UX travaillant au sein des entreprises. L’expérience utilisateur n'est pas encore perçue et intégrée comme créatrice de valeur alors que c'est exactement ce que cherchent les consommateurs d'aujourd'hui et de demain : vivre une expérience. Ces entreprises perdent donc les bénéfices du cycle en V abandonné à toute hâte, responsable de tous les maux, au profit des "méthodes agiles" plébiscitées, résolvant à elles seules tous les problèmes !

• Absence de pilotage des dépendances/adhérences entre équipes :

Il n’existe aucun produit, que nous utilisons au quotidien, qui n’ait pu être réalisé par une seule et même équipe de 10 personnes et livrée dans un temps cohérent avec les attentes du marché. Ne cherchez pas d'exemple, c'est impossible !

Tout produit et projet informatique met en action une myriade de fonctions et d'équipes différentes au sein des organisations de nos clients : Utilisateurs finaux, Métiers, Portefeuille projet et pilotage des investissements, Urbanistes SI, Architectes techniques, Fonctionnels, Développeurs, Exploitants, ... des fonctions potentiellement transverses, potentiellement présentes dans chaque grand domaine fonctionnel de l'entreprise. Créer des équipes pluridisciplinaires, allant du Dev à l'Ops, ne sert en rien si les dépendances entre ces équipes ne sont pas pilotées et suivies. Et l'agilité projet (Scrum, Kanban) ne le permet pas. Comment avancer à la réalisation d'un produit final sans savoir si les équipes sur lesquelles nous nous appuyons ou qui s'appuient sur nos réalisations sont au courant de nos avancées et en capacité de les intégrer et de les maintenir ?

Que faire face à ce constat ?

Qu'elle soit orchestrée par la mise en œuvre par des framework SAFe®, Spotify®, LeSS® ou Scrum of Scrum®, elle semble la bonne réponse aux besoins de pilotage transverse d'une transformation numérique. Dans cet état d'esprit systémique, on ajuste la focale non plus sur le travail réalisé au sein d'une équipe mais sur l'identification et le pilotage des dépendances inter-équipes ayant un but commun : le produit final. On prend donc du recul pour augmenter le champ de vision.

L'agilité à l'échelle, c'est donc le retour en grâce du pilotage par le chemin critique et donc par les risques. On ne suit que ce qui est sur ce chemin critique, où tout écart fait tomber en intégralité le plan imaginé collectivement et met en péril la réalisation du produit final. Chaque équipe contributrice est alors autonome dans sa manière de tenir ses engagements, fonction de ses compétences et ses contraintes.

Dans un modèle d'agilité à l'échelle, vous retrouverez donc des équipes en Scrum®, des équipes en Kanban, des équipes avec leur méthode de travail faite-maison ... Une autonomie qui amène de plus une meilleure acceptabilité du changement et une meilleure capacité d'adaptation à ce changement.

Si je devais résumer l'agilité à l’Échelle en une image, je choisirais sans hésiter cette illustration du résultat d'un PI Planning SAFe® : le Program Board est parfaitement représentatif de la valeur et de la puissance ce pilotage par les dépendances.

 (crédit photo : blog.myagilepartner.fr)

Explications sur le Program Board :

Au regard de l'objectif collectif porté (le produit final), chaque équipe contributrice (en ligne) détaille le contenu de ses réalisations par Sprint (en colonne). Par l'échange et le fait que les parties prenantes sont disponibles au même endroit au même moment pendant le PI, chaque équipe identifie en rouge les contributions qui seront utiles aux autres équipes. Une ficelle rouge est alors tirée entre ces équipes (celle qui produit, celle qui utilise) : notre chemin critique est identifié selon les grands jalons du projet/fonctionnalités du produit final.

Ne reste plus qu'à piloter les risques sur ces ficelles rouges, au travers d'une revue fréquente de ce Board. L'organisation devient donc en capacité de piloter le travail de 200 personnes grâce à une réunion hebdomadaire de 1h ! Cela fait rêver non ? Ce rêve existe et de nombreuses grandes entreprises ont franchi le pas, dont plus de 70 en France.

Merci à Maxime Toupet, auteur de cet article.