Nos MOA et MOE sont-elles agiles ?

Nous sommes en comité de pilotage et la tension est montée d’un cran. Dans notre agence de voyages, le sujet du moment c’est l’ajout des possibilités de location de vélos à nos offres. Au comité précédent était remontée l’importance de définir une grille tarifaire claire, déterminante pour la suite de notre projet. Mais maintenant que les choix de tarification sont arbitrés émerge un nouveau risque sur la complexité de mise en œuvre de ces tarifs dans l’application de réservation en ligne. Les managers ne se comprennent plus et tout le monde se demande combien de temps on va continuer à tergiverser sur cette offre très attendue par nos clients ? La maîtrise d’œuvre (MOE / la technique) n’a qu’à être plus agile, on ne va quand même pas remettre en question les choix fonctionnels validés par les personnes compétentes ! À moins qu’il ne s’agisse encore d’une décision de la maîtrise d’ouvrage (MOA / le métier) totalement irréaliste ? Établissons une bonne fois pour toute qui est fautif dans cette histoire.

Limites de responsabilités

Ces oppositions entre responsabilité du métier et de la technique datent probablement du premier projet de l’histoire de l’informatique. Les organisations traditionnelles basées sur un découpage de l’équipe projet entre MOA et MOE sont vouées à des querelles de responsabilités entre ces deux pôles. On observe un jeu de ping-pong où chacun se renvoie la balle et le temps de prise de décision s’allonge. Cette opposition est d’autant plus forte qu’elle est entérinée dans les organigrammes, voire dans les territoires, le modèle classique en France étant une direction métier qui trône à Paris, et des équipes techniques qui exécutent en province.

Par ailleurs, de ce découpage dérivent certains comportements, car il constitue un levier de déresponsabilisation très facile à actionner par les équipes. Si les délais s’allongent, ou que la satisfaction des utilisateurs n’est pas au rendez-vous, les techniciens pourront toujours répondre que les demandes sont irréalistes. Le métier se plaindra des contraintes techniques qu’on leur impose, incompatibles avec leurs attentes. D’autant plus que l’on peut jouer à l’infini sur les nuances sémantiques : pour certains la signature d’une API ou la conception d’une base de données peuvent relever du métier, pour d’autres les règles de fonctionnement d’une application existante relèvent de la technique … le débat peut être sans fin. Un système où personne ne se sent responsable arrange tout le monde, ce qui garantit qu’il va perdurer, alors qu’il ne sert pas la stratégie de l’entreprise. Mais l’agilité a sifflé la fin de la récréation, il est temps de travailler en équipe unie, sans cloisonnement, vers le but commun de la satisfaction des utilisateurs.

Tous ensemble

La réponse agile à ce dilemme entre métier et technique est simple : ces distinctions n’ont pas lieu d’être. Dans notre monde complexe, il n’y a pas de solution toute faite au problème que l’on cherche à résoudre pour notre utilisateur. Le produit est nécessairement le résultat d’un compromis entre l’expérience utilisateur souhaitée et les possibilités techniques disponibles, dans un cadre délimité de temps et de budget.

La solution pour aboutir à ce compromis c’est un dialogue, réitéré, dans lequel chacun est force de proposition et permettant de faire émerger des solutions inédites. Ces solutions ne sont pas attribuables au métier ou à la technique, elles sont nécessairement une fusion de ces deux composantes. Ce qui permet ce dialogue, c’est l’ingrédient de base de l’agilité : une petite équipe réunissant toutes les compétences utiles, sans cloison entre ses membres qui viendrait polariser les échanges. Chacun est invité à dépasser sa zone d’expertise habituelle, les développeurs expriment leur point de vue sur l’expérience utilisateur, les experts du métier s’approprient les contraintes techniques pour faire naître des solutions innovantes. Cette dynamique permet des cycles de décisions courts, pour apporter de la valeur plus rapidement aux utilisateurs. C’est une approche qui responsabilise l’équipe, où l’on reste soudés face aux difficultés, et surtout où l’on gagne ensemble.

Mais ce que je constate souvent dans les organisations qui mettent en place une approche agile, c’est une forme de cohabitation entre la cohésion apportée par l’agilité, et les reliques des anciennes divisions. Le comité de pilotage imaginaire que je vous décrivais au début de cet article pourrait tout à fait concerner un projet mené par une équipe Scrum de nos jours. La plupart des équipes restent encore préoccupées par la définition de rôles et responsabilités bien délimités, quand il faudrait s’en affranchir. Pour raccourcir les cycles de décision, apporter de la valeur rapidement aux utilisateurs, identifier des solutions innovantes … bref pour que l’agilité prenne sa pleine mesure à l’échelle de l’ensemble de l’organisation, il est indispensable de mettre fin à ces divisions. Alors que faire ?

Éliminons ces divisions

On peut d’abord agir au niveau de l’équipe. Pour les responsables de produits, il s’agit de ne plus se poser en prescripteurs de solutions, mais de faire émerger différentes pistes en bénéficiant de l’intelligence collective. C’est ce que l’on attendra d’un atelier d’affinage du backlog : commencer par le pourquoi, l’impact que l’on veut produire pour l’utilisateur, et définir en équipe des solutions de mise en œuvre et leurs complexités relatives. Pour les développeurs, il s’agit de porter une réelle attention aux attentes des utilisateurs, et ainsi de contribuer à la feuille de route du produit. C’est ce changement d’état d’esprit que décrit Barry Overeem dans son article Programmer- or Product Developer? Why The Difference Matters!.

Pour aller au-delà, l’agilité vient remettre en question les fonctionnements à l’échelle des organisations. En premier lieu, cela signifie plus de délégation vers les équipes, en permettant au processus d’intelligence collective dont je viens de parler de se produire. Et aussi, il s’agit de revoir la structure hiérarchique de nos organisations pour l’adapter à cette nouvelle autonomie donnée aux équipes. Si la séparation entre MOE et MOA n’a plus de sens dans nos équipes agiles, elle n’en a plus non plus dans nos organigrammes. C’est un point où je suis en désaccord avec SAFe, qui propose d’installer l’agilité comme un deuxième système d’exploitation parallèle à la structure hiérarchique existante, ne faisant qu’ajouter plus d’acteurs et de complexité. Il est temps de réunir les expertises du métier et de la technique dans des structures communes, avec un management commun, et surtout des objectifs communs. Pour aller plus loin sur ce sujet, je vous renvoie à cet article de Jurgen Appelo, et à son modèle unFIX qui nous fournit les briques de base de conception d’une organisation agile à l’échelle.

Pour conclure

Dans cet article, j’ai voulu pointer l’incohérence que j’identifie aujourd’hui entre nos équipes agiles pluridisciplinaires, et les anciens silos qui persistent entre métier et technique dans la structure hiérarchique de nos organisations. J’espère vous avoir donné quelques pistes pour dépasser ces silos, que ce soit dans nos comportements en équipe, ou dans la nécessaire réflexion sur la structure de nos organisations.