…les choses fonctionnent bien car tout le monde fait simplement ce qui doit être fait par pure passion, de façon si transparente qu’un observateur pourrait conclure que tout le monde a la capacité de lire dans les pensées des autres. Cependant, à mesure que l’organisation et le produit se développent, la quantité d’informations que les équipes doivent maîtriser, gérer et partager pour accomplir leur travail augmente également. Les décisions sont de plus en plus sensibles au contexte (à la fois des équipes et des produits), avec une complexité qui exige une certaine forme de structure pour que les choses se déroulent sans heurts à mesure que l’organisation mûrit. Vous recherchez une structure organisationnelle qui optimisera la capacité de l’équipe à faire les choses pour créer la plus grande valeur.

✥ ✥ ✥

Une communication et un feedback efficaces sont au cœur du développement efficace de systèmes complexes, et la structure organisationnelle doit être optimisée pour les voies de communication les plus cruciales. La communication et le feedback régulier, ainsi que l’auto-organisation, constituent le cœur agile. L’interaction de personnes ayant des préoccupations diverses et transversales est au cœur de l’innovation ().

Les équipes de développement travaillant sur des produits complexes luttent continuellement avec la double nature de la fonction et de la forme. Nous avons tendance à créer des frontières entre les activités de développement et les unités organisationnelles selon ces lignes. Pourtant, la fonction et la forme ne sont que des catégories socialement construites et quelque peu arbitraires : la fiabilité peut être une préoccupation tout aussi impérieuse pour un système donné, tandis que la beauté, la rétrocompatibilité ou une autre préoccupation peut dominer un effort de développement donné. Dans chaque cas, l’entreprise sera mieux servie si l’équipe de développement s’organise autour des préoccupations commerciales les plus cruciales – quelles qu’elles soient.

Alors que votre équipe commence tout juste à mûrir dans ses premiers jours et commence à se diriger vers la construction d’une équipe Scrum, vous avez plus de personnes qui peuvent commodément travailler en tant qu’unité organisationnelle pour couvrir toutes les fonctions d’une entreprise (planification des versions, développement et croissance professionnelle). Mais la croissance et la maturité sont également source d’inconfort, car les équipes aspirent à l’efficacité non structurée des jours simples de travail informel. Pourtant, pour croître et gérer correctement le produit sur le marché, il faut une structure organisationnelle quelque peu disciplinée et une gouvernance légère.

Les cultures ont un besoin intrinsèque de structure pour le fonctionnement efficace de l’ensemble. La communication la plus efficace se produit toujours localement dans le domaine du familier, il est donc crucial de localiser le processus de décision autour des préoccupations organisationnelles les plus cruciales. Il est important dans toute organisation sociale non triviale que les gens soient rapidement capables d’associer tout domaine d’intérêt donné à « l’endroit où aller » le plus efficace lorsqu’ils ont besoin d’informations sur ce domaine ou qu’ils doivent prendre des mesures dans ce domaine.

Un simple cloisonnement organisationnel (c’est-à-dire une hiérarchie) est suffisant dans les domaines simples qui doivent traiter un seul ensemble de préoccupations séparables. Mais l’approche hiérarchique s’effondre dans le cas plus typique des efforts de développement avec de multiples préoccupations qui se chevauchent. Cela pousse vers des unités organisationnelles plus grandes et plus complexes qui tentent de corriger le problème par des économies de gamme. Pourtant, les équipes de travail les plus efficaces sont de petites équipes, et vous devez partitionner le travail d’une manière ou d’une autre.

Cependant, aucune équipe n’est une île, et une nation de développement est plus qu’une collection d’îles. Les équipes développent individuellement leur propre identité, où un sens naturel de la xénophobie (besoin du familier) amène les équipes à n’accorder qu’une stature secondaire aux préoccupations venant de l’extérieur de leur cercle social. Si vous limitez l’entreprise à un seul ensemble d’interactions sociales, basé sur un seul cloisonnement simple, vous fermez les idées hors limites qui alimentent l’innovation.

La rapidité de la prise de décision est primordiale. Certaines questions sont urgentes (« Nous sommes attaqués par une autre tribu et devons monter une défense contre eux »), tandis que d’autres, bien qu’importantes, tolèrent ou même demandent une plus longue délibération (« Quel est le meilleur emplacement pour la nouvelle salle de réunion ? »). Le terme « couches de cisaillement » décrit des processus connexes qui se déplacent à des vitesses différentes, d’après la notion de plaques tectoniques qui se déplacent l’une sur l’autre, comme cela se produit lors d’un tremblement de terre. Les architectes des bâtiments () et le domaine de l’architecture logicielle (voir ) ont adopté cette expression pour décrire des structures ou des préoccupations ayant des taux d’évolution différents dans un système étroitement couplé. Une entreprise devrait structurer son organisation de manière à pouvoir répondre rapidement aux problèmes de la première catégorie sans détruire son efficacité pour les problèmes de la seconde.

Un autre principe agile est que nous sommes tournés vers l’extérieur : c’est-à-dire que nous nous concentrons et nous nous préoccupons de l’utilisateur final, du marché et des clients plutôt que des outils et des technologies que nous utilisons pour faire notre travail. L’organisation devrait également refléter cette préoccupation, car elle est la clé de la proposition de valeur et de la construction de l’ensemble de la Value Stream du développement.

En fin de compte, la structure de l’organisation devrait avoir autant à voir avec la structure du processus que la structure du produit.

C’est pourquoi,

Organiser la main-d’œuvre en petites équipes de plus ou moins cinq personnes, partitionnées en fonction des préoccupations les plus importantes pour la création de valeur par l’entreprise. Complétez cette structure avec un petit nombre de structures transversales pour les préoccupations secondaires mais importantes, sans jamais oublier que ces structures ne sont que des optimisations dans ce qui est par ailleurs un environnement ouvert de coopération sans contrainte.

Considérez une entreprise qui construit un téléphone mobile. Elle pourrait organiser ses équipes Scrum autour des principaux livrables ou options achetables. Ainsi, il peut y avoir une équipe pour le carnet d’adresses, une autre pour le calendrier, et une autre pour les fonctionnalités plus traditionnelles du téléphone : voir Domaine de valeur. Ce sont les principales préoccupations de l’entreprise. Mais il peut y avoir des groupes qui se réunissent pour définir les pratiques, les politiques et les normes de l’entreprise (par exemple, l’aspect et la convivialité de l’interface utilisateur), comprenant des représentants de chaque équipe Scrum. Ces groupes ne créent pas de produit mais servent d’échanges d’informations et de sources de normes qui guident le développement. Dans les organisations saines, il existe un chevauchement presque complet entre la composition de ces derniers groupes et celle des équipes de développement.

Dans la plupart des environnements, la structure d’organisation primaire reflète la structure des parties prenantes primaires, qui est généralement le marché. Pour cette raison, nous n’organisons pas les équipes Scrum selon le partitionnement des artefacts internes, ni selon les lieux d’expertise du domaine, mais plutôt selon les livrables du marché tels que les fonctionnalités. L’organisation autour des fonctionnalités ou d’autres livrables du marché est également un avantage pour la réactivité du marché et la réduction des délais de mise sur le marché, car l’équipe est le lieu de tous les travaux nécessaires à la mise en œuvre d’une fonctionnalité. La coordination reste ainsi dans les limites de l’organisation. Si les sous-ensembles de travail ou les compétences de base dirigent la structure organisationnelle, alors les changements dans le marché ou dans la nature du livrable entraîneront probablement une coordination entre plusieurs équipes ou organisations – réduisant la réactivité et augmentant le temps de prise de décision.

Si c’est la seule structure, elle ne soutient que la vision du marché, et elle marginalise une foule d’autres préoccupations commerciales valables. Pour que cette structure fonctionne, elle doit être complétée par des structures transversales qui soutiennent un deuxième niveau d’efficacité de la communication, par exemple, celles liées aux compétences de base. Ce modèle apparaît donc presque toujours avec un modèle comme Birds of a Feather et le modèle décrit dans Domain Expertise in Roles. La structure organisationnelle des rôles abat les murs qui se forment naturellement entre les équipes. Engagez les efforts en matière de produits au sein d’une entreprise à se connecter les uns aux autres et à la direction générale par le biais de MetaScrum. Les équipes qui ont développé un certain degré de fierté d’équipe (voir Fierté d’équipe) seront plus efficaces, car cette force ou une autre force équivalente encouragera la responsabilité. Cela permet de s’assurer que ces structures restent en jeu malgré les effets xénophobes de l’appartenance à une équipe.

Tirer le tout vers un environnement ouvert, sans murs et sans portes. Les équipes de développement ne sont que des unités d’engagement de développement, et il ne devrait y avoir aucune interférence limitant le libre interfonctionnement entre les développeurs à travers les équipes. Ajoutez de petites salles à proximité pour de courtes périodes de calme, de réflexion sérieuse et de petites réunions.

Toute composante de valeur est un jeu équitable comme critère d’organisation. Par exemple, Scrum valorise fortement la collocation des membres de l’équipe, donc les limites organisationnelles les plus basiques sont susceptibles de correspondre à des équipes colocalisées.

✥ ✥ ✥

Notez qu’il y a deux niveaux de la loi de Conway dans un bon Scrum : l’un conduit par une concentration sur le produit, et l’autre conduit par une concentration sur les domaines de compétences. Au niveau de la surface, nous organisons l’équipe en fonction du processus ; c’est la préoccupation principale pour les aspects du processus orientés vers l’intérieur et vers l’extérieur. Ainsi, les trois sphères de domination du processus sont:

• l’équipe de développement qui possède les décisions sur l’utilisation appropriée de la technologie et de la technique dans la construction du produit;
• le propriétaire du produit, qui possède la définition et la direction du produit ; et,
• le ScrumMaster qui est responsable que le processus soutient la livraison régulière de l’équipe de développement.

Les équipes de développement Scrum sont des équipes de fonctionnalité (produit). C’est-à-dire que le principe d’organisation primaire d’une équipe Scrum est qu’elle s’aligne sur un train de livraisons de fonctionnalités le long d’une Value Stream. Il existe une organisation hiérarchique faible et peu profonde au sein de Scrum qui permet à plusieurs équipes de développement de chaque développement de produit de partager un propriétaire de produit commun, dans une organisation appelée Scrum of Scrums. Chaque équipe de développement au sein d’un développement de produit unique construit un ensemble de fonctionnalités à la fois. Au fil du temps, les principaux moteurs de l’entreprise, les connaissances partagées et les artefacts de la chaîne de valeur lieront ces fonctionnalités entre elles. Il n’y a pas de titres ou de subdivisions reconnus au sein de l’équipe de développement.

Il existe de nombreuses façons de diviser le travail en équipes de fonctionnalités. Une équipe de développement peut livrer des fonctionnalités à un marché donné (voir L’organisation suit le marché), ou développer un produit pour un certain sous-ensemble du spectre technologique de l’entreprise (une équipe pour les téléphones et une autre pour les tablettes, bien que les deux partagent une grande partie du même logiciel). En général, chaque équipe doit être formée autour d’un produit qui représente une composante de la valeur de l’entreprise : voir aussi Value Stream Fork. Cependant, Scrum décourage une structure d’équipe de développement où chaque équipe est propriétaire d’une partie du produit, ou seulement d’un sous-ensemble du produit. Si les membres d’une même équipe ne peuvent développer qu’une seule partie du système, ils devront alors coordonner davantage de décisions de développement avec les autres équipes. Il devient difficile pour les équipes de prendre des décisions localement, et les résultats incluent un retour d’information et des transferts retardés.

Au deuxième niveau de la loi de Conway dans Scrum, les gens s’organisent autour de domaines de compétences dans lesquels la compétence génère de la valeur. Ces Birds of a Feather aident les membres à approfondir leur installation dans un certain domaine professionnel ou technique lorsqu’ils partagent des idées ou suivent des formations. La plupart des gens ont un désir inné de s’améliorer (voir ), et ces groupes alimentent la fierté individuelle à mesure que les membres de l’équipe apprennent et se développent. Mais là encore, ces groupes ne forment pas une structure hiérarchique, et tout membre de l’équipe peut appartenir à plusieurs Birds of a Feather ainsi qu’à sa propre équipe Scrum. Voir également l’expertise de domaine dans les rôles.

Les limites et l’identité de l’équipe de développement, ainsi que les limites et l’identité de l’équipe Scrum, sont explicites. La notion d’identité de l’équipe est essentielle à la fierté de l’équipe et au fonctionnement efficace de l’organisation, car l’identité de l’équipe apporte le contexte social qui permet d’optimiser la prise de décision. Toute notion d’identité organisationnelle au-delà de ces deux-là doit être tacite plutôt qu’explicite ou administrée. Encore une fois, il n’y a pas de titre officiel au sein de l’équipe de développement autre que « Développeur ». S’il n’y a qu’une seule règle inviolable, c’est qu’aucun individu ne peut utiliser son poste tacite d’expertise pour passer outre un consensus d’équipe ou diminuer de quelque manière que ce soit l’esprit de travail d’équipe, comme dans L’esprit du jeu. Des normes de conduite élaborées conjointement sont un signe avant-coureur fort de l’identité de l’équipe.

Il peut y avoir une expertise dans les rôles au niveau individuel, mais il est important de compléter ce schéma par des équipes interfonctionnelles chaque fois que cela est possible pour optimiser la possibilité de prise de décision locale.

La loi de Conway originale est issue d’un logiciel (voir , pp. 28-31). Il existe de nombreux mythes associés à l’origine et à la pratique de la loi de Conway. On a longtemps pensé que l’orientation objet soutenait la loi de Conway en localisant les préoccupations du marché à l’intérieur des classes. C’est à moitié vrai ; les classes ont tendance à encapsuler les préoccupations à long terme de la compétence centrale de l’organisation. Cependant, l’orientation objet semble se concentrer sur la connexion entre l’expertise des développeurs et les artefacts qu’ils développent plutôt que sur toute connexion au marché ou aux cas d’utilisation. Les préoccupations pour l’alignement avec la structure du marché devraient l’emporter sur les préoccupations pour la vision du monde des développeurs sur leur processus et leur produit.

Le style de développement en cascade a eu son heure de gloire. Dans les organisations en cascade, la structure organisationnelle primaire suivait les étapes du processus : analyse des besoins, conception, mise en œuvre et test (, p. 1-9). Selon la loi de Conway, la structure organisationnelle reflétait ces processus. Le logiciel pourrait très bien refléter ces phases également : par exemple, une architecture orientée services (SOA) mettra en évidence la plupart des exigences à valeur ajoutée dans la couche d’intégration des services, tandis que les services individuels se trouvent dans une autre couche. Waterfall met toutes les fonctionnalités dans les mains des développeurs en une seule fois, ce qui permet de raisonner sur les interactions entre les fonctionnalités. Alors que les approches de conception logicielle de l’ère Waterfall tentaient d’aligner les préoccupations du marché (cas d’utilisation) sur l’architecture, la structure organisationnelle a coupé court à cette taxonomie. On peut dire la même chose de l’organisation de la chaîne de montage dans les usines.

Parce que les équipes de développement sont des équipes de fonctionnalités, elles doivent se concentrer sur une fonctionnalité à la fois (comme dans Swarming). Le principal livrable du marché de Scrum est une fonctionnalité, et en ce sens, il y a un bon alignement entre la structure de l’équipe et le marché. Scrum est silencieux sur la forme de l’architecture du produit, mais dans l’esprit de l’agile, il tend à décourager la propriété individuelle du code. Chaque équipe de développement a le droit de travailler sur n’importe quelle partie du produit. Nous pouvons dire que Scrum équilibre les avantages organisationnels de l’encapsulation avec les avantages de l’alignement de l’équipe avec le livrable du marché. Le propriétaire du produit, avec le soutien de l’équipe de développement, gère la façon de gérer les interactions entre les fonctionnalités qui émergent au fil du temps.

Pensez, par exemple, qu’une équipe peut mettre en œuvre la fonctionnalité d’appel en attente pour un système de télécommunications tandis qu’une autre met en œuvre le renvoi d’appel. En raison de l’émergence, vous ne pouvez pas toujours prévoir le coût de la résolution des dépendances entre deux éléments du Backlog de produit (PBI) donnés, il est donc, en général, impossible de surmonter ce problème en assignant les PBI aux équipes. Dans tous les cas, l’attribution prématurée du travail aux équipes peut empêcher les gens de travailler efficacement sur les parties difficiles (en particulier celles liées à l’interaction entre les parties) et limite l’auto-organisation au niveau de l’équipe Scrum. Les deux caractéristiques peuvent être fortement interdépendantes, mais la structure Scrum ne donne pas une stature de premier ordre à ces interactions. Dans ce cas, il serait probablement préférable qu’une seule équipe développe les deux fonctionnalités. La manière de répartir le travail entre les équipes repose sur une planification continue et une prise de décision partagée, en commençant par la planification du sprint. Une bonne équipe Scrum s’efforce de répartir le travail entre les équipes de développement par le biais d’interactions intimes, mais encadrées dans le temps, entre le propriétaire du produit et l’équipe de développement, comme dans les événements visant à rétablir continuellement un Backlog de produit raffiné ainsi que par la planification des sprints.

La gestion est généralement un composant du mélange organisationnel, bien qu’il existe des développements Scrum qui fonctionnent sans aucun gestionnaire (par exemple, voir la récente vidéo sur la transformation agile chez Bosch Software Innovations. ) La philosophie Scrum tend à se concentrer sur les personnes et le produit, et cette concentration est incarnée par les rôles Scrum et les organisations (comme l’équipe de développement et l’équipe du propriétaire du produit) qu’ils représentent. Si une organisation disposant déjà de gestionnaires entreprend d’introduire Scrum, il est trop facile pour l’effort de Scrum de rejeter la partie gestion de l’organisation comme étant d’un autre monde. Dans ces situations où une organisation sans gestionnaires n’est pas une option, il est crucial d’impliquer les gestionnaires.

Steven Johnson. D’où viennent les bonnes idées. New York : Riverhead Trade, 2011.

Stewart Brand. Comment les bâtiments apprennent : Ce qui se passe après leur construction. New York : Penguin, 1995.

Brian Foote et Joseph Yoder.  » Big Ball of Mud « .ˮ In Pattern Languages of Program Design 4, Brian Foote et al, eds. Londres : Pearson, 2000.

Daniel Pink. Drive : L’étonnante vérité sur ce qui nous motive. New York : Riverhead Books, 2011.

Melvin E. Conway. « Comment les comités inventent-ils ? « ˮ In Datamation 14(4), avril, 1968, pp. 28-31.

Dr. Winston W. Royce.  » Managing the Development of Large Software Systems « .ˮ In Proceedings IEEE WESCON, août 1970, pp. 1-9. (Publié à l’origine par TRW.)

Bosch Software Innovations.  » Leçons apprises : Organisation agile chez Bosch Software Innovations.ˮ YouTube.com, 15 juin 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Crédits photographiques : Images fournies par PresenterMedia.com.