Chez Deepki nous cherchons avant tout à construire des équipes. Pour cela nous nous appuyons sur des valeurs (autonomie, auto-organisation, responsabilité) que nous mettons au service de l’intelligence collective. Cependant, dans un contexte de forte croissance, il est indispensable de remettre en cause notre organisation afin d’être toujours en capacité de livrer de la valeur de façon continue et durable. Dès lors se pose la question : comment construire la meilleure organisation pour atteindre nos objectifs tout en respectant notre culture et nos valeurs ?

L’ouvrage Team Topologies: Organizing Business and Technology Teams for Fast Flow par Matthew Skelton et Manuel Pais propose un modèle et une méthodologie qui s’appuient sur des typologies d’équipes et sur leurs interactions. Cette lecture constitue un véritable guide pratique pour la création de nouvelles équipes ou pour l’amélioration de notre organisation actuelle. J’ai trouvé que les idées avancées par les auteurs faisaient écho à ce que l’on pratique/défend chez Deepki et je vous propose de revenir sur les principaux concepts abordés à travers une série d’articles. Vous trouverez donc ci-dessous, mes notes de lecture de la première partie de cet ouvrage.

Teams as the means of delivery (les équipes comme moyen de livrer)

L’entreprise est une entité complexe constituée d’humains et de systèmes technologiques en perpétuelle interaction. Plus la complexité des systèmes augmente, plus les équipes qui construisent et font évoluer ces systèmes sont sollicitées. Cette première partie détaille différents concepts qui doivent permettre aux équipes de fournir de la valeur de manière régulière et efficace.

Exploiter la loi de Conway comme moteur de changement

Les organisations qui conçoivent des systèmes […] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation.

Loi de Conway

En énonçant cette loi, Melvin Conway identifie un pattern que l’on retrouve dans de nombreuses entreprises : leur structure de communication influence directement l’architecture logicielle. Autrement dit, nos relations, nos process et nos méthodes impactent fortement nos systèmes d’information, nos produits et nos outils. Un exemple concret : une grande entreprise très hiérarchisée disposera d’un ERP qui reflète son organisation hiérarchique. À l’inverse une jeune start-up privilégiera des outils collaboratifs de type Slack ou Basecamp pour développer des communautés de travail et des relations informelles.

Pour faire évoluer son organisation et ne pas subir un modèle d’architecture imposé, il est donc préférable de modifier la structuration des équipes et leurs interactions pour s’assurer qu’elles correspondent à l’architecture que l’on souhaite donner au système. Le véritable défi est donc d’arriver à exploiter la loi de Conway comme moteur du changement souhaité plutôt que de la subir. Mais quel modèle d’organisation mettre en place pour atteindre une cible d’architecture donnée ?

Pensez d’abord aux équipes et à leur mode d’interaction

La création et l’exploitation de systèmes logiciels complexes est toujours une activité d’équipe, qui nécessite les efforts combinés de personnes ayant des compétences variées. En outre, les organisations modernes adoptent les pratiques DevOps pour livrer et exploiter rapidement des systèmes logiciels, tout en s’adaptant aux exigences commerciales ou aux contraintes réglementaires. Malgré ces exigences, beaucoup d’entre elles continuent d’avoir une vue unique et figée de leurs équipes, c’est le fameux organigramme de l’entreprise. Ces organigrammes sont souvent très hiérarchiques et décrivent les entités organisationnelles, la manière dont elles sont liées les unes aux autres et leurs canaux de communication officiels.

En réalité, nous nous adressons d’abord aux personnes dont nous avons besoin pour accomplir notre travail. Nous créons des relations et instaurons la confiance pour que le travail soit effectué de manière décentralisée et que les délais soient réduits. C’est pourquoi le flux de communication réel est le plus souvent bien différent de l’organigramme. Dès lors, les structures des équipes dans les organisations devraient faciliter la communication et faire en sorte qu’elle fasse partie de leur ADN. Le premier pas vers cet objectif est de prendre conscience du fossé entre “le dire” et “le faire” et d’essayer de le réduire autant que possible.

Si nous voulons avoir des équipes indépendantes et auto-organisées qui peuvent collaborer efficacement, nous devons nous assurer que notre culture organisationnelle, ses valeurs fondamentales, le flux de communication, les boucles de rétroaction et les mécanismes de récompense soient en phase avec cette intention.

Limiter la charge cognitive des équipes

Les obstacles aux flux de l'équipe. Source: Team topologies

La charge cognitive correspond à la quantité de ressources cognitives investies par un individu lors de la réalisation d’une tâche. Elle dépend :

  • de la complexité de la tâche (le nombre d’éléments à traiter et à mettre en relation) ;
  • des ressources de l’individu (ses connaissances à propos de cette tâche) ;
  • de la manière dont la tâche est présentée.

Pour une équipe, la charge cognitive peut être considérée comme la moyenne des capacités cognitives de ses membres et correspond donc à la limite collective d’absorption, de stockage et de traitement de l’information dans la mémoire de travail. En cas de dépassement de cette charge l’équipe rencontre des difficultés lors de la résolution de problèmes et des difficultés d’apprentissage.

La charge cognitive doit être prise en compte si vous souhaitez que vos équipes obtiennent des résultats hautement qualitatifs sans les surcharger d’une quantité déraisonnable de tâches et de responsabilités. À ce sujet, dans son ouvrage “La vérité sur ce qui nous motive”, Daniel Pink nous rappelle les trois éléments de la motivation personnelle qui peuvent être impactés par une charge cognitive trop importante :

  • l’autonomie (trop nombreuses demandes et des priorités confuses)
  • la maîtrise (touche-à-tout, maître de rien)
  • le but (trop de domaines de responsabilité)

Un moyen simple et rapide de l’évaluer consiste à demander à l’équipe : “Avez-vous l’impression d’être efficace et capable de répondre en temps voulu au travail qui vous est demandé ?”. Si la réponse est négative, c’est probablement qu’elle est responsable d’un trop grand nombre de domaines (ou qu’ils sont trop complexes). D’où l’importance de tenir compte de la charge cognitive au moment de décider de la taille de l’équipe, d’attribuer les responsabilités et d’établir des interfaces avec les autres équipes.

Limiter le nombre de domaines de responsabilité de l'équipe pour augmenter sa capacité cognitive. Source: Team topologies

Penser son organisation nécessite une expertise technique

Si les managers décident … quels services seront construits, par quelles équipes, nous avons implicitement des managers qui décident de l’architecture du système.

Ruth Malan

En partant du principe que la loi de Conway est une réalité au sein de votre organisation, la personne qui prend les décisions sur la forme et le positionnement des équipes d’ingénieurs définit indirectement l’architecture de votre système logiciel. Il s’agit donc d’impliquer les techniciens dans les décisions relatives à l’organisation. Ainsi ils prennent part aux décisions d’architecture logicielle qui découlent de la composition des équipes.

Communiquer moins pour communiquer mieux

Toutes les formes de communication et de collaboration sont-elles bonnes ? Lorsque vous concevez un système, vous planifiez soigneusement qui “parle” avec qui et comment. Il en va de même pour la communication entre les équipes. Il est donc tout aussi important de définir les “interfaces d’équipe” et de fixer les attentes à leur égard.

Cela semble assez naturel de penser que plus il y a de communication mieux c’est, mais ce n’est pas forcément le cas. Il faut de la communication là où on le souhaite, sinon, cela peut impliquer que les équipes communiquent pour compenser le manque d’interfaces ou de process bien définis. En effet, la vitesse de livraison d’un logiciel est fortement affectée par le nombre de dépendances entre les équipes. Si elles ont besoin de communiquer entre elles alors que l’architecture logicielle a été désignée pour limiter les dépendances c’est qu’il y a un dysfonctionnement : l’API répond-elle aux besoins des équipes ? La plate-forme est-elle adaptée ? Un composant est-il manquant ? De la même façon, si une équipe intervient régulièrement sur deux parties distinctes du système, il peut être utile de la diviser en deux. A noter qu’il est tout de même important de favoriser la collaboration entre équipes dans les zones grises du développement où la découverte et l’expertise sont nécessaires pour progresser.

Si l’on se réfère à la loi de Conway il faut également être attentif aux outils de communication mis en place qui influent la façon dont les équipes interagissent. Si nous voulons que les équipes collaborent, les outils partagés ont un sens. Si nous avons besoin d’une frontière de responsabilité claire entre les équipes, alors des outils séparés (ou des instances séparées du même outil) peuvent avoir du sens. 

Développer l’esprit d’équipe en limitant sa taille

Dans le monde du développement logiciel, la vitesse, la fréquence, la complexité et la diversité des changements nécessitent des équipes stables pour maximiser la livraison. L’équipe est la plus petite entité de réalisation au sein de l’organisation. Ses membres travaillent ensemble et partagent un objectif commun. Une petite taille d’équipe permet de maximiser la confiance entre ses membres. Un haut niveau de confiance permet à l’équipe d’innover et d’expérimenter.

On pourrait penser (à tort) qu’il suffirait d’augmenter la taille d’une équipe pour augmenter la charge cognitive qu’elle peut gérer. En réalité, c’est souvent l’inverse qui se produit : en augmentant le nombre de ses membres, et sans modifier son périmètre de responsabilité, on constate que la complexité de ce que l’équipe produit augmente.

Les équipes sont responsables du produit (teams ownership). Cette responsabilité de l’équipe lui permet de penser à de multiples “horizons” - des phases d’exploration jusqu’à la production - afin de mieux prendre soin du logiciel et de sa viabilité. Chaque partie du système logiciel doit être détenue par une seule équipe. Cela signifie qu’il ne doit pas y avoir de propriété partagée des composants, des librairies ou du code. « Think of code as gardening, not policing ».

Nous devons veiller à ce que les membres de nos équipes aient (ou développent) un état d’esprit axé sur l’équipe :

  • Arriver à l’heure aux daily stand-ups et aux réunions.
  • Aller au bout des discussions et des investigations.
  • Se concentrer sur les objectifs de l’équipe.
  • Débloquer les autres membres de l’équipe avant de commencer un nouveau travail.
  • Encadrer les nouveaux membres de l’équipe ou les moins expérimentés.
  • Être ouvert à la critique, en évitant les arguments “gagnants” (tenter d’avoir systématiquement raison en écrasant le dialogue) et en accepter d’explorer les différentes options.

La diversité des parcours, des expériences et des expertises au sein de l’équipe permet de produire des solutions plus créatives. Il faut également veiller à récompenser l’ensemble de l’équipe plutôt que les individualités.

Cette première partie de Team Topologies identifie les principaux anti-patterns pour une agilité à l’échelle (les organigrammes qui s’appuient sur la hiérarchie, la loi de Conway, la charge cognitive) et rappelle les principes fondamentaux qui permettent de participer efficacement à l’élaboration d’un produit. Sans être révolutionnaires, ces premiers chapitres ont le mérite de poser par écrit ce que beaucoup pratiquent déjà peut être même sans le savoir. La seconde partie, qui fera l’objet d’un autre article, apporte un nouvel éclairage sur nos organisations et propose un framework lean et pragmatique pour redécouper nos équipes. A suivre…