Comment promouvoir l’informatique Lean et Agile face à la complexité et à l’inertie ?

1.     Introduction

Nous vivons une période paradoxale de montée en force de l’approche agile et d’une dénaturation progressive des termes et des idéaux du manifeste agile . On retrouve le terme « agile » partout depuis 10 ans dans la littérature sur le management, dans toutes les déclarations stratégiques des entreprises et dans les principes modernes d’organisation. Dans son article « The State of Agile Software », Martin Fowler dresse un réquisitoire éclairant contre le « faux-agile », que je trouve remarquablement pertinent.  Pour résumer, le « faux agile » est un abus de procédures  et d’outils (baptisés le « complexe industriel ») conduisant  à un abus de structuration et d’organisation au détriment de l’autonomie des équipes. Les processus de développements deviennent fixes et universels, alors qu’ils devraient s’adapter et évoluer en continu.  La compétence technique passe au second plan, alors qu’elle est essentielle dans l’approche agile, et la culture projet reste prédominante au lieu d’évoluer vers une approche produit.

Au fur et à mesure que l’approche agile est devenue « incontournable », elle s’est vue souvent mariée à l’approche « lean ». Lean et agile sont à la fois proches et complémentaires : ils sont très compatibles car construits sur des principes « souches » communs et ils s’enrichissent car ils ne répondent pas aux mêmes questions. Il y a eu de nombreux débats il y a dix ans sur le positionnement relatif, lorsque le « lean software » a commencé à être formalisé, mais aujourd’hui la plupart des organisations revendiquent la double influence. Ce mouvement s’est accéléré avec la montée en visibilité de DevOps  et de l’approche CICD (Continuous Integration and Continuous Delivery), qui sont clairement sous la double influence du lean et de l’agile. Grace aux travaux de Nicole Forsgreen et Jez Humble, dont l’excellent livre « Accelerate », nous avons maintenant les preuves d’efficacité de ces approches « lean / agile » du développement logiciel.   
         

L’approche « Lean Software », telle que magistralement popularisée par les livres de Mary et Tom Poppendieck  est une évolution logique, et une approche complémentaire, qui renforce une démarche agile. Par exemple, on y retrouve des éléments clés qui sont prônés par Martin Fowler dans l’article précédent : l’importance du refactoring continu, l’importance du développement continu des compétences ou l’approche produit. Mais la double mise en œuvre des principes, des rituels, des pratiques lean et agile n’est pas simple et pas forcément intuitive. Il s’agit d’une démarche de transformation émergente, ce qui signifie que sa mise en œuvre est entre les mains des acteurs, par opposition à une approche volontariste et descendante. Tout n’est pas non plus simplement entre les mains des équipes, l’environnement joue également un rôle critique dans la faisabilité de la mise en place.

Ce qui m’intéresse précisément dans ce billet est la complexité et la difficulté de mise en œuvre d’une approche véritablement lean et agile dans une organisation de développement. Je vais chercher à caractériser les conditions nécessaires pour faire émerger cette transformation. Il faut en premier supprimer les contraintes qui bloquent cette émergence parce qu’elles invalident les principes lean et agiles. L’autonomie, les marges de manœuvres, la flexibilité et l’accès continu à la boucle de feedback sont nécessaires pour que la transformation lean et agile puisse commencer. Pour que cette transformation émergente progresse et devienne systématique, la gouvernance doit aussi évoluer : ce qui est mesuré et ce qui est apprécié doit changer par rapport à la conduite standard des projets telle qu’on la pratiquait il y a 20 ans.

Ce billet est organisé comme suit. La section 2 revient sur ce que le lean peut ajouter à l’agile, même si ce thème est maintenant un peu éculé. Je n’ai pas la prétention de couvrir le sujet ici – cela demanderait plus de place et plus de compétences – mais simplement de faire quelques rappels et poser les concepts nécessaires pour la suite de mon propos. La section 3 considère l’entreprise comme un système et se pose la question des conditions nécessaires pour que la transformation lean et  agile puisse s’accomplir. Certains aspects tels que la « customer centricity » sont maintenant bien compris –même si cela reste une démarche difficile  -, d’autres comme l’acceptation de l’incertitude restent plus difficiles. La dernière section rassemble quelques conseils sur les modes de pilotage – comment mesurer et évaluer les résultats. Sans surprise, il existe une synergie entre des nouveaux modes d’organisation – ce que j’ai appelé l’entreprise 3.0 dans des billets précédents  – et les nouvelles approches de développement de produits logiciels ou numériques.

2.  Ajouter des racines Lean à la pratique agile

Je commence tout de suite par poser mon parti pris : lorsque je parle de « lean agile », je m’intéresse à l’enrichissement de la méthode agile par des principes, des méthodes et des rituels tirés du lean. C’est parce que je considère le « lean management » comme une approche plus fondamentale et plus générale, qui s’applique à un processus, tandis que l’agile est plutôt  une modalité de fabrication d’un artefact (logiciel, projet ou produit, mais ceci se généralise à d’autres développements).

Ce n’est pas la première fois que j’aborde ce sujet dans mes blogs. Le premier billet date de 2012, il était fortement inspiré par la lecture de Mary and Tom Poppendieck. Ce billet est construit autour d’un enrichissement progressif des principes, en partant du manifeste agile pour l’enrichir avec des principes lean. J’ai également abordé la combinaison lean et agile en 2016 en l’observant du point de vue métier. Dans ce billet, je décris (sommairement) l’Agile de la façon suivante : «  La satisfaction du client est le fondement d’une démarche de développement produit. Ceux qui construisent (un produit, un service, une expérience) doivent être responsables du processus de construction. La communication personnelle, face à face, est le ciment de la méthode agile. Les rituels d’équipes utilisent les tableaux et les murs pour favoriser la communication. Les défis complexes requièrent des équipes cross-fonctionnelles qui travaillent ensemble, de façon synchronisée et itérative. » De façon symétrique, le lean me semble caractérisé de la façon suivante : « La satisfaction du client/utilisateur est la fondation d’une démarche lean, c’est le but commun à toutes les équipes. L’approche « pull », dirigée par la demande client, donne le tempo commun à l’ensemble de l’organisation. Elle est matérialisé par le kanban, et suppose une simplification et une fluidification du processus, c’est un objectif de long terme. Les équipes progressent et capitalisent grâce à une standardisation de leurs pratiques. Le kaizen est un outil pour apprendre à travailler ensemble via la résolution de problèmes. Le lean est une méthode pour l’apprentissage collectif de la complexité. C’est pour cela qu’il repose sur le management visuel, sur l’inspection en équipe de la réalité et qu’il se méfie de l’abstraction (cf. le genchi gembutsu). »

L’influence du Lean dans le monde digital est devenue de plus en plus visible au cours de la dernière décennie. Cette observation était déjà bien visible dans le livre de référence « Les Géants du Web ». Mais avec DevOps, avec le développement du Lean Startup  les emprunts au lean management « façon Toyota Way » sont particulièrement saillants.  Je vous recommande par exemple la lecture du billet de César Gon, le CEO de CI&T dans « planet lean » intitulé « With digital lean finally reaches CEOs ».  J’ai également fortement insisté sur les principes lean présents dans le livre « Accelerate » précédemment cité. Cette intensification des racines lean dans le développement digital permet de souligner trois apports essentiels par rapport aux pratiques agiles :

• Le lean conduit à développer l’anticipation en pensant sur une échelle de temps plus longue, celle de la construction de compétences. Ceci ne signifie pas développer des choses inutiles en cherchant à prévoir le futur mais bien à réfléchir à son potentiel de situation, avec une véritable démarche d’architecture. Je vous renvoie ici à mon billet sur « Lean Architects – Do we need abstraction ?». Cet apport de l’approche lean à l’architecture dans les développements agiles est le sujet du livre de de James Coplien and Gertrud Bjørnvig « Lean Architecture for Agile Software Development ».
• Le lean développe la pensée systémique, ou plus précisément l’apprentissage collectif du fonctionnement du système et sa capitalisation sous forme visuelle. Je vous renvoie ici au livre magistral de Michael Balle, « The Lean Manager». Pour prendre un exemple différent et plus proche du logiciel, je vous recommande les interventions de Paul Allspaw dans lesquelles il enseigne de « rendre les problèmes visibles », dans la plus pure tradition lean.
• La puissance du kaizen comme démarche d’amélioration et d’apprentissage continu va bien plus loin que les pratiques de rétrospectives et de résolution de problèmes propres aux démarches agiles.

Un thème commun aux trois apports du lean que je viens de mentionner est la maitrise de la complexité. C’est particulièrement important avec les méthodes agiles puisque l’approche incrémentale produit de la complexité (c’est pour cela que Martin Fowler insiste sur le refactoring).  Le lean dispose de plusieurs outils propres pour lutter contre la complexité. Premièrement le value stream mapping (l’obsession de la valeur crée pour le client) et son complémentaire, l’élimination des muda, mura and muri  est une combinaison vertueuse pour alléger de façon continue et simplifier. Deuxièmement, la construction et la pratique du standard – propre à chaque équipe, comme l’explique très bien Martin Fowler, et comme me le répète Michael Ballé – est également un outil de prévention de la complexité. L’utilisation du standard est un filtre qui, combiné à la pratique du kaizen dont il est l’outil de capitalisation, produit de la simplification. Notons pour terminer, en écho à l’article de Martin Fowler, que les experts du lean qui ont beaucoup pratiqué sont suprêmement modestes dans leurs conseils sur les rituels et les outils. Lorsque nous avons commencé à développer l’approche du Lean Software Factory à Bouygues Telecom en 2012, mon sensei m’a forcé à me limiter à quatre pratiques : Team problem solving, Project Room, Reduce WIP & Love your code. 

Mon tropisme personnel pour la fiabilité des systèmes me pousse à voir dans le lean un apport fondamental aux méthodes agiles dans le domaine du « system engineering ». S’il est vrai que dans certains cas, en particulier dans le domaine des interfaces utilisateur, il vaut mieux coder et itérer plutôt que de chercher une spécification parfaite et abstraite, il existe également des situations inverses. Ayant commencé ma vie logicielle en programmant des compilateurs, j’ai à l’esprit des multiples exemples un peu anciens, mais mes dix dernières années d’expérience de conception de services fournissent également des situations où les problèmes de conception se résolvent à l’avance avec un tableau, des feutres, des schémas et des équations. Dans ces situations, le principe lean de détection de la non-qualité au plus tôt passe par l’abstraction et la formalisation, plutôt que l’expérimentation qui est très coûteuse. Je ne recommande pas de résoudre des équilibrages de files d’attente par essai/erreur, comme le montre le célèbre exemple du Beer Game.

Je ne suis pas forcément très satisfait de ma caractérisation de la combinaison lean+agile (c’est effectivement un sujet complexe), mais l’expérience m’a montré qu’il était facile de voir si cette transformation combinée avait « pris » de façon efficace en regardant trois critères. Lorsque ces trois pratiques sont présentes sur un plateau de développement, c’est en général un très bon signe d’appropriation en profondeur qui est corrélé avec d’excellents résultats (en termes de satisfaction client, bien sûr) :

• La « voix du client » est présente sur le plateau de développement, sous la forme de témoignages rassemblés et de métriques détaillées d’usage. Je vous renvoie par exemple à la pratique du Customer Feedback Learning Loop.
•  Le visual management fait la part belle à des schémas systémiques qui expliquent le fonctionnement du produit en cours de fabrication. Je vous recommande à ce sujet le billet « arrêtons de confondre le management visuel et le reporting au mur » de Catherine Chabiron.
• Le suivi des plans d’action issus du kaizen est matérialisé par un document du type A3 de Toyota, dont la vie (des ratures jusqu’aux mises à jour régulières) témoignent de l’utilisation réelle.

3. Les conditions systémiques du Lean & Agile

La première chose évidente que je souhaite souligner c’est qu’il est impossible à une organisation de développement d’être « agile toute seule ». Paradoxalement, on peut appliquer le lean à petite échelle et en réaction isolée par rapport à son environnement (penser au self-lean). Cela marche moins bien, mais ça marche quand même. On peut également appliquer l’approche lean à des cycles non-agiles : on peut faire du « lean waterfall » et du « lean CMMi ». A contrario, pour tirer les bénéfices systémiques de la démarche agile d’adaptation continue et itérative vers une cible incertaine, c’est le système entier qui doit comprendre les fondamentaux : nous vivons dans un monde marqué par la variabilité et l’incertitude, où l’action prime sur l’idée et dans lequel la vitesse de changement s’accélère par rapport aux décennies précédentes. Par système entier, je pense aux parties prenantes principales : les directions métiers, la direction générale, les utilisateurs. L’importance de l’adhésion globale aux principes agiles n’est pas une nouveauté : si on lit le manifeste agile attentivement, il est clair que ce n’est pas simplement une histoire d’informaticien mais de collaboration entre parties prenantes. On pourrait même dire que le premier prérequis pour fonctionner de façon agile, c’est l’envie. La gouvernance et les règles dont nous allons parler ensuite ne sont que des conséquences.

Pour que les équipes s’approprie des modes de fonctionnement lean et agile, il faut qu’elles disposent de marges de manœuvre. Je retrouve ici ma citation favorite d’Yves Morieux « Coopérer, c’est mettre ses marges de manœuvres au service des autres » et des idées que j’ai développées dans mon livre en 2010  et qui sont magistralement exposée par Reinertsen dans « The Principles of Product Development Flow». Le fonctionnement lean évite les taux de charge de 100% qui conduisent inexorablement à une amplification des aléas. Cette règle est d’autant plus importante que l’incertitude propre aux domaines complexes et digitaux produit du stress chez les parties prenantes, qui se traduit à la fois par le fait d’être pressé et velléitaire, ce qui produit alors une surcharge par rapport à la capacité de l’équipe et qui conduit à la fois à l’inefficacité et la conclusion fausse que les méthodes agiles ne fonctionnent pas vraiment. Fonctionner de façon lean demande donc une certaine maturité sur sa propre capacité, pour ménager de façon continue et durable les marges de manœuvre qui vont permettre d’absorber les aléas et de progresser de façon continue. Tout ce qui permet d’apprendre et de progresser, depuis la formation à la rétrospective en passant par le kaizen réclame un mode de fonctionnement « non-saturé ». Ce « buffer » doit être piloté et utilisé par l’équipe, puisque c’est elle qui conduit sa transformation lean & agile et prend en charge son amélioration continue. De plus, une équipe qui fonctionne en surcharge devient autiste (cf. Yves Morieux), elle n’écoute plus ses clients et coupe sa boucle d’adaptation, produisant in fine moins de satisfaction client et donc moins de valeur.

Pour fonctionner efficacement en mode lean & agile, il faut pouvoir mesurer la valeur créée en continu et dès que possible, afin de profiter de la force systémique de la rétroaction en boucle courte. Cela suppose deux choses : d’une part un accès régulier et simple aux utilisateurs pour collecter ce feedback le plus tôt possible , et d’autre part la véritable délégation de responsabilité qui fait que le product owner – membre de l’équipe – est habilité à tirer les conséquences de ce feedback, sans avoir à attendre la validation d’un comité d’hippos.  On retrouve ici le rôle fondamental de l’autonomie et la responsabilisation (empowerment) de la  « squad agile ».  Dès que le projet ou produit atteint une certaine taille et qu’il est nécessaire de faire collaborer plusieurs squads, il est fondamental d’aligner toute l’organisation sur la satisfaction du client pour optimiser l’expérience utilisateur. Cette obsession de la satisfaction client a le grand avantage d’être mesurable (et donc relativement objective), de donner du sens et de fédérer les énergies grâce à l’empathie dont nous sommes tous dotés.  C’est la raison, fondée sur mon expérience, pour laquelle je considère que la présence de la « voix du client » est fondamentale sur les plateaux de développement. Cette obsession de la satisfaction client explique également le rôle fondamental des designers dans les squads.

Une démarche agile permet de mieux gérer les surprises, les bonnes comme les mauvaises découvertes au cours du développement, mais encore faut-il les accepter. Comme le remarque Philippe Silberzahn, l’agilité est un moyen. Dans l’esprit de l’effectuation, il faut savoir accepter l’incertitude et les surprises (ce qui matérialise l’incertitude : s’il n’y avait pas de surprise il n’y aurait pas d’incertitude) - je vous renvoie ici au livre de Philippe Silberzahn « Bienvenue en incertitude » - et c’est bien entendu l’affaire de tous. L’agilité n’est pas une technique pour absorber les incertitudes du développement logiciel pour les masquer au métier. Plus généralement, cette solidarité des parties prenantes  est nécessaire parce que le fonctionnement agile n’est pas « un long fleuve tranquille » et demande plus d’engagement de la part des équipes que le mode « bureaucratique » des organisations Taylorisées de type « waterfall ». Essayons de l’illustrer en comparant deux méthodes de travail. La première est une méthode d’agence, qui est fondée sur l’encapsulation des objectifs et activité, cherche à masquer la complexité, fonctionne avec des échanges asynchrones, une priorisation établie par le donneur d’ordre (le métier), une vision statique et absolue de la « voix du client ». La seconde est une méthode de partenariat, qui suppose la transparence, l’exposition de la complexité, qui exige des échanges synchrones, donne à l’équipe qui fait la capacité de prioriser et considérer la « voix du client » comme une conversation dynamique. Les sociologues nous ont appris que la deuxième méthode est plus engageante, donc plus fatigante. On parle souvent du « droit à l’erreur » nécessaire dans les environnements complexes, ce n’est pas simplement parce que se tromper permet d’apprendre ! C’est parce que le refus de l’erreur conduit à des méthodes du premier type, qui favorisent des solutions médiocres qui évitent les risques, et produisent alors une satisfaction client médiocre.

4. Gouvernance Lean & Agile : Pratiquer le « lâcher prise » sans dériver ni abdiquer

L’émergence des modes de travail lean et agile passe par une évolution de la gouvernance des projets et processus de développement. Avant de donner cinq illustrations concrètes, je rappelle que ce thème est également développé dans le livre de Jurgen Appelo « Management 3.0 – Leading Agile Deloppers, Developing Agile Leaders ». Je reprends de mon compte-rendu précédent les deux citations suivantes qui résument bien le propos : « One of the things I learned in this past decade is that Agile Software development is the best way to develop software. But I’ve also learned that old-style management is the biggest obstacle to the adoption of Agile software development around the world” ; “The real reason for empowerment is the manageability of the complex system itself. Smart managers don’t just empower people to enjoy the radiant faces of employees. They empower people to prevent the whole system to break down”.

La première idée importante pour la gouvernance est qu’il est nécessaire de combiner le temps court et le temps long. L’agilité, d’un point de vue stratégique, s’exprime sur le temps court, mais elle se prépare sur le temps long. L’introduction d’une perspective lean permet de mieux comprendre ce paradoxe et d’apprécier les différents rythmes d’apprentissage. La pratique de l’anticipation et de la planification ne sont pas forcément obsolètes, mais elle s’applique à la construction du « potentiel de situation », des « capacités » (capabilities) communes. Cette activité de temps long peut être centralisée et planifiée car il y a finalement peu d’incertitude. En revanche, la réalisation de l’opportunité exige le temps court, celui de la réaction et de la délégation. Comme les opportunités ne se prévoient pas (ou mal), le domaine d’exercice de l’agilité n’est pas celui de la planification. C’est aussi pour cela que l’injonction « fail fast » s’applique au cycle court de saisie de l’opportunité et elle n’exclue pas la persévérance dans la construction des capacités.

La deuxième règle de gouvernance est de pratiquer une véritable distribution du pouvoir de décision vers des équipes autonomes. C’est une des idées forces de Jurgen Appelo dans son livre, qu’il relie très justement à la complexité des situations – c’est bien entendu un des six principes de l’entreprise 3.0 que je développe dans ce blog. Cette organisation en réseau d’équipes distribuées et autonome, maillées par des organisations transverses (chapitres et guildes) qui favorisent l’apprentissage sur des échelles de temps différents est ce qui a rendu le modèle Spotify célèbre dans le monde agile. Mais on pourrait tout aussi bien ici invoquer les principes du Betacodex qui reposent précisément sur l’adéquation entre un modèle distribué « biologique » et la complexité de l’environnement. La responsabilisation n’est pas une décision, c’est la conséquence d’un certain nombre de prérequis de gouvernance : l’autonomie, l’accès aux moyens et l’orientation vers le client en particulier et l’extérieur en général.

Une troisième observation essentielle sur notre environnement complexe, qui est fondamentale lorsque l’on parle de transformation numérique, est qu’il faut laisser le client choisir l’écosystème logiciel dans lequel l’entreprise va apporter sa valeur. C’est vrai dans le grand-public, puisque les écosystèmes de services dominants sont imposés par quelques grands acteurs et qu’il convient d’aller à la rencontre des utilisateurs là où ils se trouvent. C’est également vrai dans le monde B2B, dans lequel les entreprises clientes construisent leurs propres plateformes par agrégation et orchestration de service (avec une accélération liée au Cloud, au SaaS et au XaaS). Ce n’est pas une coïncidence si les notions d’exposition de services et d’API jouent aujourd’hui un rôle clé dans le développement. L’histoire des APIs permet d’apprécier cette forme de « lâcher prise » qui consiste à laisser d’autres écosystèmes, externes à l’entreprise (ceux d’une entreprise cliente en B2B), prendre la responsabilité de la composition, et de l’expérience utilisateur, des services fournis par cette entreprise. Cette observation a une conséquence essentielle sur la gouvernance : il faut associer aux décisions ceux dans l’entreprise qui connaissent les écosystèmes logiciels. Autrement dit, la technologie n’est pas un élément de l’exécution, mais une compétence stratégique.

La gouvernance des projets et produits développés de façon lean et agile doit d’adapter au rythme rapide et incrémental qui est nécessaire pour créer plus de valeur. La fréquence des échanges et des décisions doit augmenter, et les parties prenantes doivent le plus possible adopter les modes de travail des équipes : une chose à la fois, communiquer de façon synchrone, se déplacer là où l’action se passe (le célèbre « genchi genbutsu » du lean). Cette contrainte n’est pas simple et conduit forcément à la délégation et l’autonomie. En effet, comme je l’ai remarqué dans un billet précédent, le produit du temps passé par sujet, du nombre de sujets traité par une personne et du taux de compression (du niveau d’abstraction auquel ce sujet est traité) est plus ou moins constant. Cela force les managers dont le « scope » augmente à choisir entre plus d’abstraction (au risque de ne comprendre que superficiellement) ou une fréquence faible (ce qui ralentit la pertinence du processus adaptatif de la démarche agile). On en déduit que dans un monde complexe (qui rend l’abstraction difficile et dangereuse), moins un manager passe de temps sur un sujet, plus il doit rester humble et réduire sa voix dans le processus de décision.

La cinquième conséquence sur la gouvernance est également inspirée des principes de l’entreprise 3.0 : « L’entreprise doit disposer d’une vision unique, comprise et partagée par tous, distribué à tous les composants de l’entreprise. Une finalité unique, que chacun décline localement en fonction de son contexte et ses moyens, en vertu du principe d’holomorphisme des systèmes complexes ». Pour pouvoir faire fonctionner efficacement un réseau distribué d’équipes autonomes, il faut une stratégie exprimée en termes de finalité (le fameux « start with why »). Sur l’importance de cette finalité claire, je vous renvoie à l’excellent livre de Cecil Dijoux « Ce que signifie l’avènement du numérique ». Dans le monde logiciel, on parle de programme « déclaratif » par opposition à « impératif ». Comme le souligne Isaac Getz, « l’autonomie sans vision partagée, c’est le chaos ».

5. Conclusion

Ce billet est, sous une forme détournée, une réflexion sur trois de mes thèmes préférés :

• La mise en place des « usines logicielles » autour de Dev0ps, telles que décrites dans « Accelerate ». Depuis 10 ans, je revendique le terme d’usine car il est pour moi porteur de rigueur, d’effort et d’outillage (par opposition au « mindset » et aux « soft skills »), rencontrant de temps à autre une certaine résistance. Les dernières années et les derniers témoignages des acteurs que j’admire semblent me donner raison.
• Le « Software craftmanship », c’est-à-dire la reconnaissance et le développement (conjoint) de l’expertise technique dans le développement logiciel. C’est pour moi la racine « extreme programming » de l’approche lean agile. On peut invoquer le « dieu de la transformation digitale » autant de fois qu’on le souhaite chaque jour, sans « l’amour du code », il est difficile d’être compétitifs face aux acteurs innovants du 21^e siècle.
• Le pilotage des transformations émergentes, autrement dit l’efficacité au sens de François Jullien.

Ces trois dimensions se combinent pour tisser un lien entre les nouvelles formes d’organisations et l’efficacité des processus de développement numérique. Il y a un lien fort entre ce qui est dit dans ce billet et celui sur l’Entreprise 3.0 qui est, de beaucoup, l’article le plus consulté sur ce blog. Le moment se rapproche où je pourrai mettre mes idées au clair sous la forme d’un nouveau livre, dédié à ces nouvelles formes d’organisations de développement logiciel.