Sac de noeud et Cie : comment gérer les dépendances fatales ?

Toute croissance des systèmes logiciels amène à considérer également la croissance des effectifs qui les réalisent et les maintiennent opérationnels. C’est bien souvent là que les ennuis commencent. :)

Quand davantage de personnes doivent collaborer ensemble, la complexité de leurs interactions augmente progressivement.

Les pratiques sociotechniques nous permettent d’optimiser la structure d’organisation (c’est-à-dire l’organisation des personnes sous forme d’équipes) de façon à maximiser le flux de delivery global.

Cette structure d’organisation se configure en fonction de 5 contraintes complémentaires :

• Technique : quelle structure d’organisation mettre en place pour encourager l’émergence d’une architecture cible (cf. Loi de Conway) ?
• Sociale : comment maximiser l’efficience de la collaboration au sein de chaque équipe et entre les équipes ? Comment prendre en compte la disponibilité des compétences dans les choix d’organisation ?
• Stratégique : comment répartir la capacité de l’entreprise pour porter les efforts sur les endroits qui accentuent la différenciation business. (cf. Core Domain Chart) ?
• Opérationnelle : comment faire en sorte que le système s’anime et évolue de façon cohérente ? Quelles interactions pour mettre en mouvement le système ?
• Historique : les choix d’organisation et de systèmes techniques antérieurs ont été réalisés en fonction des 4 contraintes ci-dessus ; ils impactent et déteignent sur les choix présents.

Dépendances fatales

Une fois cette optimisation “structurelle” réalisée, nous aboutissons à plusieurs équipes qui sont liées par des dépendances résiduelles, qui ne peuvent pas être supprimées car elles maintiennent la cohérence du système technique. Nous les appellerons “dépendances fatales”.

Ces dépendances fatales sont de 2 natures différentes :

• Avérée : il s’agit d’équipes qui partagent un ou plusieurs assets techniques : dans une majorité de leurs activités, elles devront prendre soin de synchroniser leurs actions ensemble. Il s’agit d’une situation subie, cette décision de design d’équipe a dû se faire pour des raisons de nécessités (rareté des compétences, territoires managériaux, contraintes budgétaires…) qui viennent s’ajouter aux différentes contraintes décrites plus haut (techniques, sociales, stratégiques, opérationnelles) . Ce genre de couplage rend difficile l’identification des limites de responsabilité et nécessite un surcroît d’énergie pour gérer la complexité induite par cette dépendance. Exemple : 2 équipes développent un ERP avec des frontières floues en termes de responsabilité sur l’asset. Si l’équipe A développe une fonctionnalité, il y a fort à parier que l’équipe B doive être au courant, voire associée. Et vice versa.
• Potentielle : il s’agit d’équipes dont certaines décisions d’implémentation peuvent requérir une adaptation de la part d’une autre équipe. Exemple : l’équipe A (front) consomme l’API de l’équipe B. Pour afficher une nouvelle info sur le front, elle a besoin que l’équipe B lui expose un nouveau champ dans la sortie de l’API. Et a contrario, si l’équipe B introduit une rupture de rétrocompatibilité (breaking change) dans le format de son API, elle devra tenir au courant les équipes consommatrices de ses services, y compris l’équipe A.

Comment organiser la gestion des dépendances fatales ?

Ci-dessous vous découvrirez une proposition de modèles de gestion des dépendances fatales : il s’agit de 6 façons de collaborer pour que l’actif logiciel de l’équipe B soit modifié, et ainsi permettre la mise en œuvre d’une fonctionnalité dont l’équipe A a la responsabilité.

InnerSource A > B

L'Équipe A développe une fonctionnalité et soumet une Pull Request (PR) du code source sur la base de code détenue par l'Équipe B.

Pré-requis : l’équipe A possède les compétences pour modifier le produit de B, l’équipe B est OK pour accueillir des suggestions dans sa base de code (pré-requis culturel), gestion de version du code ouverte en lecture + PR, des standards partagés (definition of done, technos, architectures, documentation, processus de release), du temps dédié de l’équipe B pour relire et valider les PR.

Effets de bord :

• diminution de la capacité de l’équipe B à réaliser, car elle doit consacrer un effort important et permanent à la mise à disposition d’un environnement propice à la contribution d’autres équipes (documentation, sécurité, processus de revue, édition et publication de standards, …)
• L'équipe B doit adopter, clarifier et rendre explicite ses standards, ce qui tend à améliorer le niveau de qualité logiciel de l’équipe B
• Faciliter l’onboarding de nouveaux équipiers dans l’équipe B
• Davantage de fluidité dans la conception technique des systèmes de l’équipe A qui devront communiquer avec les systèmes techniques de l’équipe B.

Délégation de composant B > A

L’Equipe A est responsable du build et de la maintenance d’un composant du produit détenu par l’Equipe B.

Pré-requis : architecture du produit permettant la non-contamination entre le composant et le reste de l’application, rituels d’alignement A+B sur l’archi et le fonctionnel, Equipe B a les moyens de faire le run du composant.

Effets de bord :

• Le système technique de l’équipe B gagne en modularité, et donc en capacité d’adaptation.
• L’équipe B consacre davantage d’effort à rendre son système technique “délégable” à une équipe tierce.
• Un effort additionnel est nécessaire pour synchroniser les standards d’architecture et l’intégration entre l’équipe A et l’équipe B.
• L’équipe B exploite un code qui ne lui appartient pas ; motivation en berne et rejet de responsabilités possibles.

Délégation de personne A > B

L’équipe A délègue une personne à temps plein qui vient renforcer l’équipe B et monte en compétence sur le produit de l’Equipe B et augmente la capacité de l’Equipe B.

Pré-requis : capacité de l’Equipe A à déléguer un ETP, disponibilité de l'Équipe B pour accueillir, former et encadrer l’équipier délégué.

Effets de bord :

• Accélération des boucles de feedback entre l’équipe A et B
• Perturbation des 2 équipes qui provoque la diminution de leur efficience (diminution de la prédictibilité de la capacité à réaliser, formation nouvel équipier dans l’équipe B, …)
• Partage de la connaissance du système et du processus de l’équipe B au sein de l’équipe A à travers l’équipier délégué.
• Ne passe pas à l’échelle : il y a une limite au nombre de membres de l’équipe A qui peuvent être délégué à d’autres équipes. Et réciproquement, l’équipe B ne pourra accueillir qu’un nombre limité de contributeurs d’autres équipes.

Délégation de personne A < B

L’équipe A accueille un équipier de l’équipe B à temps plein, qui développe, sur le produit de l’Equipe B, une fonctionnalité dont dépend l’Equipe A.

Pré-requis : l’équipe B peut diminuer sa capacité d’un ETP, la fonctionnalité à ajouter sur le Produit de B est assez conséquente pour un transfert de capacité à court/moyen terme, l’équipe B met à disposition un moyen pour qu’un contributeur externe puisse intégrer ses développements dans le flux de travail de l’équipe B.

Effets de Bord :

• Accélération des boucles de feedback entre l’équipe A et B
• Perturbation des 2 équipes qui provoque la diminution de leur efficience “locale” (diminution de la prédictibilité de la capacité à réaliser, formation nouvel équipier dans l’équipe A, mise en place d’un processus de contribution externe par l’équipe B …)
• Expérimentation d’un mode de contribution externe à l’équipe B, première étape vers de l’Inner Source.
• Ne passe pas à l’échelle : il y a une limite au nombre de membres de l’équipe B qui peuvent être délégués à d’autres équipes. Et réciproquement, l’équipe A ne pourra accueillir qu’un nombre limité de contributeurs d’autres équipes.

Impact Team AxB

L’équipe A et l’équipe B délèguent temporairement quelques équipiers à temps plein pour la mise en œuvre conjointe d’une solution impactant les actifs logiciels détenus et opéré par chacune des équipes.

Pré-requis : Les 2 équipes peuvent se séparer d’un ETP chacuneLes 2 équipes sont dotées d’un processus de contribution externe

Effets de bord :

• Coût important à la création de l’impact team (social, technique, organisationnel,...) même si elle n’est que temporaire et hors organisation officielle
• Prémisse à la création d’une nouvelle équipe dans le cadre d’une trajectoire d’architecture.
• Haut niveau de collaboration, faible niveau de couplage entre les équipes
• Renforcer les liens entre les membres des 2 équipes, partager les pratiques de code.

Délégation de réalisation A > B

L’équipe A demande à l’Equipe B de mettre en œuvre une modification dans le produit qu’elle détient. C’est le mode standard utilisé notamment lors des PI Plannings et autre événement de résolution des dépendances d’équipes.

Pré-requis : Un système de gestion de la demande permet à une équipe de faire une demande à une autre équipe.Les 2 équipes partagent un objectif commun.

Effets de bord :

• La réussite de l’équipe A repose sur l’alignement des priorités et la réussite de l’équipe B à réaliser la fonctionnalité dont dépend A.
• Effort supplémentaire à fournir entre A et B pour s’assurer que ce qui est livré correspond aux attentes de l’équipe A (conformité) et/ou que l’équipe A s’adapte à ce qui est livré (adaptation)
• Les délégations portées par le système de gestion de la demande nécessitent une énergie supplémentaire pour être maintenue à jour (synchronisation, partage d’avancement, ...)
• L’équipe A peut se désengager de la réalisation de la fonctionnalité déléguée à l’équipe B : moins de disponibilité, moins d’apprentissage, moins d’empathie.

Quand et comment décider du mode de gestion de dépendance à utiliser ?

Quelques guides pour bien choisir son mode de gestion de dépendances :

Rechercher l’optimisation globale plutôt que locale

La gestion des modes de dépendances amène à se poser 3 questions :

• Où se trouvent les goulots d’étranglement dans les équipes de delivery ?
• Quels modes de délégations permettent à mon organisation d’améliorer durablement sa capacité à livrer des fonctionnalités ?
• Quels modes de délégation permettent à mon organisation de se transformer de façon à supporter l’émergence de l’architecture technique adéquate.

L’ensemble de ces questions permettent de prendre du recul et de considérer l’optimisation globale de l'organisation.

Conserver un système stable - changer le moins souvent possible

La stabilité de la structure d’organisation est un des facteurs clés qui permettent aux équipes d’atteindre un haut niveau de collaboration. La modification du mode de gestion des dépendances est un facteur de perturbation du système ; il est donc indispensable de le stabiliser dans le temps de façon à ce que les équipes découvrent puis perfectionnent leurs habitudes de collaboration.

Par ailleurs, certains modes de gestion des dépendances ont un coût de mise en place (recevoir et former l’équipier d’une autre équipe, définir et partager des standards de contribution de code,...).

Aller au-delà de la gestion de dépendance par délégation de réalisation

Biberonnés à SAFe et à son “PI Planning”, nous voyons bien souvent la délégation de réalisation comme la seule façon de résoudre les dépendances entre les équipes. Il s’agit d’un moyen opérationnel ‘intellectuellement’ séduisant, qui respecte les limites de responsabilité des équipes mais qui couple fortement les capacités de réalisation, et qui nécessite un surcroît d’énergie pour maintenir et opérer un système de gestion des demandes. Ce mode de gestion de dépendance met le bénéficiaire d’une fonctionnalité à distance de l’équipe de réalisation.

L’ouverture à d’autres modes de gestion de dépendance permet à l’organisation de gagner en souplesse et d’amener de la porosité entre les équipes ; la culture et les connaissances circulent ainsi plus facilement au sein de l’organisation, les liens se tissent, les responsabilités se partagent.

Remerciements chaleureux à mes collègues Augustin Grimprel, Amal Tahri, Simon Lefort, Cecil Dijoux et Basile du Plessis pour nos échanges et leur relecture attentive de cet article.