Un nouvel article lié à notre thématique sur le changement dans un monde agile. Les méthodes agiles ont prouvé leur supériorité pour sécuriser la construction de produits SI en maximisant leur valeur. Mais elles s’appuient sur un postulat organisationnel sous-jacent : une équipe de taille limitée (voir notre article sur le sujet), indépendante et auto-organisée, avec un Product Owner souverain sur la définition de son produit et sur la priorisation des fonctionnalités à développer. Mais comment faire si l’application n’est que le sous-ensemble d’un tout plus grand ? Comment gérer les dépendances ? C’est cette problématique qui a fait naître, avec plus ou moins de bonheur, des frameworks traitant de « l’agilité à l’échelle »

Pourquoi y aurait-il un problème ?

Dans les grandes entreprises, le système d’information est composé d’applications multiples, chacune gérée par une équipe dédiée, en mode agile ou non. Les processus métiers sont rarement déroulés au sein d’une application unique. Bien plus souvent, ils sont transverses et nécessitent de faire à plusieurs d’entre elles.

Cas classique : une équipe gère un portail utilisateur, une autre gère une application gérant certains types de transactions que déclenche l’utilisateur depuis son portail, une autre gère l’ERP (souvent en mode non agile) qui fournit des données et des transactions dont le portail a également besoin.

Si chaque Product Owner développe sa brique applicative avec ses propres priorités sans concertations avec ses voisins, grand est le risque de divergence, et donc d’incohérence dans le processus proposé aux utilisateurs finaux au moment de la réconciliation. Et quel résultat si chacun met en production à son rythme, sans avoir vérifié que les prérequis d’autres briques sont bien en production, ou qu’il n’a pas altéré une fonction qui était pourtant essentielle à d’autres ? Ou si les contrats d’interface entre chaque brique n’ont pas été clarifiés et qu’elles ne peuvent soudain plus dialoguer entre elles ?

Une bonne architecture peut simplifier grandement les problèmes

Grâce aux standards des architectures internet, une bonne partie des problèmes peut être simplifiée. Si la modularité a bien été conçue au départ, si l’architecture est orientée ressources comme pour tous les services de l’internet, si les services de données sont séparés des services transactionnels, qu’ils sont gérés comme des ressources et utilisent des API REST, chaque équipe retrouve déjà une grande part d’autonomie.

Mais ce n’est pas toujours le cas. Et par ailleurs, le besoin d’une conception générale globale qui évite que chaque brique diverge fonctionnellement demeure.

Coordination des PO et/ou framework « à l’échelle » ?

Dans un monde idéal, les PO travaillant tous pour un but commun qui est la prospérité de leur entreprise, ils disposent d’une forme de coordination qui leur permet de s’aligner entre eux et de s’assurer que les briques ne divergent pas fonctionnellement, éventuellement avec l’aide d’un architecte d’entreprise. Et les Scrum Master organisent des « Scrum de scrum » pour traiter les problèmes d’adhérences et de coordination. Et comme dans ce monde idéal l’architecture a été bien pensée, les problèmes d’interfaces et d’adhérences techniques sont également réglés.

Dans la vraie vie, les PO dépendent de Directions différentes, ont chacun des objectifs non nécessairement alignés, et sont peu enclins à prendre en compte des besoins liés à d’autres problématiques que la leur. Et quelle que soit leur bonne volonté, ils ont par ailleurs une vision parcellaire de la photo d’ensemble, qui les rend inconscients des effets de bords de leurs microdécisions.

C’est pour cela que sont apparus des Framework comme SAFE, qui est le plus connu. Ils tentent de mettre un cadre organisationnel pour assurer une coordination entre les équipes et garantir la cohérence et l’intégration de l’ensemble. Le but de ce court article n’est pas de les détailler ici.

Les agilistes disent à longueur d’articles que ce n’est plus de l’agile (perte d’autonomie du PO, nombreuses couches entre le client et le développeur, système d’engagement qui limite fortement la capacité d’adaptation de sprints en sprints, etc…). Ils ont raison. Mais tendre vers ce type de fonctionnements, probablement par cherry picking opportuniste, est néanmoins un compromis jugé nécessaire par de nombreuses organisations.