dimanche, juillet 30, 2017

Américains et Japonais : Culture logicielle et apprentissage par la pratique et la résolution de problème



1. Introduction


Mon livre de 2011, « Processus et Entreprise 2.0 – Innover par la collaboration et le lean management » devait s’appeler « Lean Entreprise 2.0 » mais ce titre a été jugé comme trop obscur. Pourtant, le livre est construit autour de la complémentarité de deux cultures très différentes, la culture collaborative « du Web 2.0 » venue des Etats-Unis et la culture d’amélioration et d’apprentissage continus du « Toyota Way ». Le chapitre 9 est consacré à cette double provenance de cultures différentes, avec des tensions et des apports, et aussi des éléments communs puisque des racines du « Toyota Way » viennent des idées et travaux autour du TQM (Total Quality Management) rendus célèbres par Edward Deming. Ce livre a été écrit il y a sept ans mais j’ai continué depuis à m’intéresser, et à pratiquer, des approches mixtes qui combinent ces deux influences à la rencontre du lean et de la culture logicielle. C’est très clairement le cas du Lean Startup, qui a été le cœur de mon attention depuis 2012. C’est également vrai pour l’approche « lean software development » que j’ai implémenté au sein des différentes « lean software factories » auxquelles j’ai contribué.

Le titre de ce billet est évidemment un clin d’œil au billet précédent, mais c’est bien la combinaison de traits culturels issus du monde japonais du Toyota Way et du monde américain de la culture du logiciel qui va me servir de fil rouge. Les deux livres dont je vais parler dans ce billet sont eux aussi placés sous le signe de la double culture … Ce thème n’est pas nouveau, on le trouve déjà dans d’autres ouvrages dont j’ai parlé dans ce blog (je pense en particulier à « The Lean Enterprise » -) mais ces livres apportent des éclairages originaux et rafraichissant sur le sujet.

Le livre de Cecil Dijoux est un livre sur la transformation numérique à la suite de nombreux autres tels que ceux de Gilles Babinet ou Nicolas Collin et Henri Verdier, mais sous l’angle d’analyse de la pensée Lean, ce qui conduit un ouvrage profond et décapant, une sorte de suite des « Géants du Web », dans laquelle l’importance des compétences et des pratiques joue un rôle fondamental. Dans ce livre, culture logicielle et apprentissage par la pratique et la résolution de problèmes, sont progressivement introduit comme des évidences nécessaires à l’adaptation profitable des entreprises à la vague des opportunités et défis du monde numérique.

Le livre suivant est un livre de sociologie consacré aux développeurs, proposé par l’équipe « The Boson Project ». Ici le point de départ est la culture logicielle, ce livre est une réponse logique à Cecil Dijoux qui nous invite à mieux comprendre et respecter les « doers du monde numérique ». Mais les « bonnes pratiques » du développement nous conduisent également à retrouver des racines d’apprentissage continu et de collaboration qui font un autre pont entre culture logicielle et  « lean management ».



2. Ce que signifie l’avènement du numérique


Je vous recommande très vivement de lire ce livre ! c’est un livre court, synthétique qui va droit à l’essentiel avec quelques illustrations très pertinentes autour des messages principaux. En particulier, Cecil Dijoux s’appuie sur une excellente bibliographie, une véritable curation des meilleurs livres ou articles pour comprendre les enjeux du monde modernes et des organisations. Une autre pépite du livre est la « liste de questions à se poser » fournies dans chaque chapitre, qui rend la lecture plus personnelle et plus pertinente pour chacun. Afin d’éviter que l’action de le résumer n’affadisse complètement le propos, j’ai choisi sept idées qui me semblent essentielles, mais c’est un choix éditorial et personnel.


1. Importance du “Why” et du “North Star”

Les nouvelles organisations sont construites autour du pourquoi – on retrouve ici le « start with why » de Simon Sinek. Dans le monde du lean, c’est la métaphore de l’étoile polaire qui capture l’importance vitale du but comme outil de construction de l’organisation. Le thème du livre étant la transformation numérique, Cecil Dijoux emprunte la définition suivante à Ludovic Cinquin : « La transformation numérique c’est l’exploitation radicale des possibilités d’Internet ». Le numérique n’est pas un objectif, c’est un moyen : « En d’autres termes, le numérique est un outil d’apprentissage, car il permet l’expérimentation rapide à des échelles très importantes pour valider (ou invalider) des hypothèses. L’exemple typique est celui de Facebook mettant en production une fonctionnalité pendant 45 secondes pour en valider la pertinence ». Le challenge principal des entreprises est bien celui décrit dans « Exponential Organizations » : celui de s’adapter continument et d’apprendre collectivement dans un monde qui change de plus en plus vite, soumis au flot continu de la transformation « exponentielles » des technologies, en particulier des technologies numériques. Pour saisir les opportunités du monde numérique, le premier défi à relever est celui de l’apprentissage permanent. Le pilotage par le « why » est la déclinaison dans l’entreprise du rôle fondamental de la finalité des systèmes complexes. Cette finalité doit être claire – comprise par tous – c’est le point essentiel de la métaphore de l’étoile polaire – et simple, pour résister à la complexité de l’environnement.  J’emprunte au livre cette superbe citation de Dee Ward Hock : « Une raison d’être et des principes simples et clairs font émerger un comportement intelligent et complexe. Des réglementations complexes sont émerger un comportement simple et stupide ». Pour terminer cette lecture systémique, on peut dire que le principe d’organisation proposé est la combinaison de trois choses : (a) une finalité définie par le pourquoi, de façon simple et claire (b) un chemin qui définit le comment de façon incrémentale, - par petits pas, nous allons y revenir – (c) une boucle de questionnement continue par l’écoute (des clients/utilisateur) et la mesure (avec une forte emphase sur la simplicité de ce qui est mesuré).

2. Co-développement de la stratégie et l’exécution

Le deuxième chapitre s’intitule « pourquoi l’exécution est la stratégie » et commence par cette proposition : « Car la stratégie, à l’ère du numérique, n’est pas dans les idées ou les concepts mais, bien plus qu’à toute autre époque, dans l’exécution, collée au plus près du réel opérationnel ». Un des messages constant et fort du livre est l’impérieuse nécessité de sortir du Taylorisme. Ceci de décline de multiples façons, comme par exemple dans le domaine de l’architecture : « L’architecture (technique et logicielle) n’y est pas préconçue pendant des mois. Elle émerge de la résilience du système développé grâce aux tests automatiques qui vont permettre de « refactorer » le code en permanence. Une démarche qui relève de l’impensable pour nos architectes SI imprégnés de la culture tayloriste, à savoir : « nous pensons et vous exécutez » ». Le co-développement de la stratégie et de l’exécution s’articuler autour de l’émergence et de la résilience. L’émergence désigne ici la capacité à exploiter la sérendipité, dans la droite ligne du potentiel de situation cher à François Jullien. Je vous renvoie aux exemples passionnants de la page 18 (Facebook, Twitter, etc.) qui montre à quel point le succès vient de la capacité à saisir des opportunités non anticipées – encore faut-il avoir les moyens (les compétences techniques) pour le faire (le potentiel de situation se construit par les apprentissages précédents). La résilience est une exigence fondamentale de l’excellence de l’exécution. L’idée clé du livre est de montrer que la résilience est un choix stratégique qui modèle l’organisation, le système que l’on construit et les pratiques de développement. Cela conduit, de façon paradoxale comme le souligne Cecil Dijoux, à faire des choix simples et prudents, à préférer construire sur des technologies fiables et éprouvées plutôt que de d’absorber trop de risques liés à l’effervescence du monde logiciel.


3. Racines « lean » dans les pratiques du numérique

Beaucoup des bonnes pratiques du monde numérique, en particulier dans le développement logiciel mais aussi dans l’organisation du travail et des équipes, peuvent être expliquées grâce à des « principes lean ». On retrouve des principes de flux tirés, de management visuel et de résolution de problème dans les méthodes agiles. Je partage cette analyse – avec de nombreux autres – même s’il ne faut pas aller trop loin dans le « réductionnisme » : il y a des idées du monde agile qui ne viennent pas du « Toyota Way », et à l’inverse le « lean software development » apporte des nouvelles dimensions – en particulier sur la vision produit et long-terme – aux méthodes agiles. On retrouve donc au cours du livre des « bonnes pratiques » des organisations modernes capables de profiter pleinement de la transformation numérique : organisation en squads (équipes cross-fonctionnelles autonomes), utilisation massive du visual management (à la fois pour la résolution de problème, l’apprentissage collectif du système complexe commun, de l’organisation et pilotage du travail en flux tiré et « petits lots », les « gemba walks » des managers (aller sur le terrain, écouter et voir, monter le respect). Régis Médina donne une formidable clé de lecture sur l’apport du lean : « Le Lean nous apprend qu’il faut d’abord développer le potentiel des employés pour développer de bons produits ». C’est également le message sur lequel j’avais conclu mon intervention au Lean IT Summit en 2013. Je vous recommande également les nombreux témoignages qui montrent la force de ces pratiques lorsqu’elles permettent à une équipe autonome de prendre en charge son propre apprentissage. Je reproduit ici une double citation (page 41) parce que ce thème est central : « de nombreux penseurs du Lean (Dan Jones, Michael Ballé) ont compris depuis fort longtemps qu’appliquer les seuls outils du Lean (5S, Kanban, ..) ne suffisait pas à transformer son entreprise en organisation apprenante. Ils nous rappellent sans cesse que l’efficacité du système passe par l’apprentissage permanent, de tous, chaque jour, à travers la résolution de problème par l’approche scientifique. … . Si le Lean est un mode de management parfaitement adapté au monde du numérique, c’est parce qu’il place l’apprentissage permanent au cœur de la stratégie de l’entreprise ».

4. Lean Startup

Le livre de Cecil Dijoux fait la part belle à l’approche « Lean Startup » et son cycle « Build, Measure, Learn » : « En appliquant ce modèle de boucle infinie (construire, mesurer, apprendre), les entreprises du numérique établissent un rapport objectivé à la réalité, adapté aux changements de celle-ci, en faisant levier de la radicalité d’Internet ». Je ne peux qu’applaudir à cette mise en valeur, même si je trouve que le rôle central de l’observation et de la promesse (le Unique Value Proposition de Ash Maurya) est un peu laissé de côté (il ne suffit pas de produire des connaissances validées, encore faut-il qu’elles soient utiles). Les pages qui expliquent et justifient le principe « des petits lots » - l’approche itérative – sont remarquables, tout comme l’impérieuse recommandation de mettre le client au centre de cette boucle : « En raison du principe de l’obsession du client, les équipes se doivent d’être rapprochées et reliées au client. Ce lien est incarné dans l’approche du flux tiré : les équipes ne produisent que ce que le client attend, quand il l’attend ». Je vous renvoie également à l’excellent livre de Marco Tinelli – « Le Marketing Synchronisé ». 

 5. L’importance des équipes cross-fonctionnelles et autonomes

Un autre message clé développé tout au long du livre est de s’appuyer sur la responsabilisation de ceux qui font (et donc qui savent). Voici ce que le livre propose pour réfléchir à comment inscrire l’exécution au cœur de la stratégie numérique : « Identifier dans votre organisation les doers (développeurs, designers, utilisateurs avancés des nouveaux outils numérique) et les personnes disposant de compétences en humanités pour vous entourer et vous aider à définir les premières hypothèses que vous allez tester ». Une équipe cross-fonctionnelle fonctionne mieux lorsqu’elle est co-localisée : « La encore, de très nombreuses études sociologiques démontrent l’efficacité de la co-localisation … plus des personnes sont éloignées, moins la communication est efficace ». Ce mode de travail demande une certaine prudence avec la sous-traitance – je reprends ici une citation d’Henri Verdier «  Une petite musique agaçante commence à s’instiller dans la société française, qui voit dans la sous-traitance le gage de l’efficacité. Je n’y souscris pas. » Un peu plus loin, au sujet des sociétés les plus avancées du numérique, Cecil Dijoux écrit : « Je constate qu’elles mettent en œuvre très peu, voire aucun, des conseils de l’orthodoxie de la stratégie d’entreprise – externalisation comprise ». Il y a au cours des pages (cf. page 29) de nombreux témoignages sur l’importance des développeurs, ce qui va faire le lien avec le livre suivant : « Je me rappelle ainsi d’une réunion chez un client ou le responsable des études … s’étonnait que je m’intéresse de très près aux développeurs et pas suffisamment aux managers ou chefs de projets ». Dans la tradition du Lean, les managers sont invités à changer leur regard sur les « ouvriers de production » du numérique, à savoir les développeurs – ce sera le sujet de la partie suivante.

6. Importance du temps

La prise en compte du temps, à la fois dans la chrono-analyse globale et dans l’obsession de la maîtrise des délais, est une caractéristique du lean qui est parfaitement adaptée au monde numérique. Beaucoup des questions que l’auteur pose au lecteur sont liée au temps : « Quel est le temps de réponse des outils que vous mettez à disposition de vos équipes ? Supérieur à une seconde, à 2 secondes, à 3 secondes ? Est-il acceptable pour vos employés ? Ces outils sont-ils fiables ? … ». Le livre insiste sur l’importance des outils et de l’automatisation pour raccourcir les cycles. On retrouve ici la synergie entre les méthodes modernes (et rapides) de déploiement continus de type DevOps et les méthodes de conception de produits et services numériques de type Lean Startup. Au-delà de l’outillage et des bonnes pratiques d’intégration continue, de test continu et de déploiement continu, il s’agit également d’une question d’organisation et de « mindset ». Cecil Dijoux insiste à juste titre sur le « focus », le fait de ne faire qu’une chose à la fois : « Des équipes à temps plein sur un seul sujet. De très nombreuses études de science cognitives démontrent que pour une personne en train de traiter deux sujets, le risque d’erreur est double et le temps de réalisation est doublé ». L’obsession du temps client, de la performance perçue (temps d’attente), de la fiabilité est une des caractéristiques des « Géants du Web » qui est également mis à l’honneur dans ce livre. Cela se retrouve dans le traitement de la fiabilité, avec un rappel sur les MTTR (temps moyen pour réparer) versus MTBF (temps moyen entre deux indisponibilités) qui m’a fait penser à mon cours à Polytechnique il y a 10 ans.  Les méthodes et pratiques de développement modernes contribuent à la fiabilité et à la satisfaction des clients parce qu’elles permettent de réduire significativement le temps moyen de réparation.


7. Rôle du management

Le livre consacre un chapitre entier au rôle des managers, parce qu’il ne souscrit pas – moi non plus – à la théorie d’une entreprise autoorganisée sans managers : « contrairement à ce que l’on peut prétendre, le management, et donc les managers, à toujours un rôle dans les organisations du XXIe siècle, et ce rôle est prépondérant. Toyota l’a montré au XXe siècle et Google, à travers deux études passionnantes, le montre au XXIe siècle ».  Les deux projets auxquels il est fait référence sont le projet Aristote et le projet Oxygen. Tout comme  Cecil Dijoux, je vous recommande fortement la lecture de l’article de Charles Duhigg sur le projet Artistote : « What Google Learned from its quest to build the perfect team » ainsi que l’article de David Garvin « How Google sold its engineers on management ». Le projet Oxygen permet de définir le profil du manager/coach adapté aux nouvelles formes d’organisation – et oui, ce rôle existe (« In light of this research, the Project Oxygen team concluded that managers indeed mattered »).  D’une certaine façon, il n’y pas de surprise dans la définition de ce profil (coach / support / communiquant / orienté résultats / intéressé par le développement des collaborateurs / suffisamment technique pour écouter les doers / empathique / …) mais l’intérêt vient de la méthode – rigoureuse et fondée sur les faits – et de l’origine, Google, qui n’est pas une entreprise « classique »). Le manager joue un rôle essentiel de facilitateur de l’apprentissage, individuel et collectif, même si la responsabilité de cet apprentissage revient au collaborateur et à l’équipe. « Le Lean est, comme le rappelle Michael Ballé, un système d’éducation permettant le développement des personnes jusqu’à leur autonomie ». A la fin du livre, Dan Jones insiste sur la dimension sociale du management : « J’ai toujours cru que changer d’organisation sociale était beaucoup plus lent qu’exploiter les opportunités qu’ouvrent les nouvelles technologies. L’organisation sociale est la clé. Le Lean est essentiel parce qu’il aide à créer des organisations plus agiles, capable de faire face au défi du numérique grâce à l’implication de chacun dans l’amélioration ».

Avant de passer au livre suivant, je tiens à souligner que ne suis pas d’accord avec tout ce qui est écrit dans cet ouvrage. Une partie de l’opposition un peu simpliste entre la vision du DSI et celle du digital, page 57 par exemple, me semble relever plus de la rhétorique que de la réalité (on trouve d’ailleurs, un peu plus loin page 62, des propos plus nuancés). De la même façon, la charge contre les processus est un peu caricaturale et vise plutôt l’abus des procédures que la démarche processus elle-même. Mon désaccord le plus profond porte sur la valeur de l’intégration. Je ne souscris pas à l’affirmation, page 61, que l’intégration n’apporte pas de valeur au client. Il s’agit d’une vision purement statique (à un instant t donné, l’intégration est une fonction cachée, invisible, qui n’apporte pas de valeur perçue). Dans une vision dynamique, les capacités d’intégration sont un potentiel de situation, qui apportent une forte valeur au client.

En revanche, je suis particulièrement en phase avec l’obsession du rôle central du client qui est développée du début à la fin du livre. Je termine avec cette citation de Régis Medina, qui insiste avec beaucoup de justesse : « Rendez visibles les problèmes. Assurez-vous que les problèmes des clients sont recueillis et analysés. Sélectionnez ceux qui doivent être gérés au cas par cas. Vous n’avez nul besoin d’outils ou de statiques sophistiqués ; contentez-vous d’écouter vos clients et de traiter les problèmes les uns après les autres »



3. Décoder les développeurs



J’ai décidé de compléter ce compte-rendu par un autre, plus synthétique, du livre de Benjamin Tainturier et Emmanuelle Duez qui s’intitule « Décoder les développeurs – Enquête sur une profession à l’avant-garde ». Les auteurs commencent par définir son objectif de la façon suivante :  « Ce livre aimerait reconnaitre les mérites des développeurs, élaguer les forêts sombres du « développement », du « langage », du « code », pour éclaircir les sous-bois qui effraient les entreprises ». C’est avant tout un livre de sociologie, nourris d’entretiens et d’étude de situation, dont je vous recommande d’autant plus la lecture que je vais faire un exercice particulier de mettre en exergue quelques points qui font écho aux propos précédents. Il y a beaucoup d’autres contributions à découvrir comme par exemple une analyse du logiciel dans la typologie des services et des biens.

1. Développer c'est concevoir et exécuter à la fois 


Je commence par cette première affirmation – que je partage bien évidemment – à cause de la symétrie avec la partie précédente. Je cite : « Développer amalgame donc nécessairement concevoir et exécuter. Séparer ces deux étapes de création n’a guère de pertinence hors de l’usine taylorienne ». Les auteurs introduisent la caractérisation de « cols ciels » pour désigner les programmeurs qui sont à la fois des « cols blancs » - des concepteurs – et des « cols bleus » - des ouvriers d’un atelier industriel avec ses pratiques. L’insistance sur les pratiques (par rapport aux principes) est essentielle : « L’agile conseille les meilleures pratiques et dispense une nouvelle pensée du travail, qui s’est imposée progressivement aux développeurs. Méfiance cependant, car toute liste prétendument exhaustive de principes dit « agiles » est immédiatement caduque : en figeant l’organisation dans des commandements, cette liste perdrait sa raison d’être ». L’analyse que fait le livre de l’importance de la communication dans la pratique agile, à la fois en tant qu’outil et qu’objectif, est tout à fait remarquable (dans la droite ligne de « Processus et Entreprise 2.0 », pourrais-je dire :) ). On retrouve plusieurs points fondamentaux, tels que l’utilisation du management visuels pour rendre explicites les marges de manœuvres de chacun aux autres.


2. Les développeurs sont des ouvriers métiers du 21e siècle



Le livre propose une comparaison très intéressante entre différentes professions ouvrières et structure de compagnonnages, et le développement logiciel. Cette analogie est manifeste dans l’existence de la « conscience professionnelle » des développeurs, qui dépasse le cadre du projet ou de l’organisation à laquelle ils sont rattachés : « Les ouvriers de métier, les développeurs, bénéficient, en effet, d’une position favorable sur le marché du travail. Ce détail structure la conscience professionnelle, cette conscience de remplir une fonction essentielle, et rare, de la société ». Hors contexte, cette affirmation peut sembler surprenante, je vous engage donc à lire le livre pour la comprendre véritablement, mais disons qu’on peut l’interpréter dans le contexte du monde numérique qui a vu la revalorisation du développement. Cette conscience professionnelle fait que le lien entre le développeur et son code est fort, et dépasse un lien contractuel ou marchand. Le développeur moderne appartient à des écosystèmes et des communautés multiples, qui dépassent son entreprise. L’organisation multiple de Spotify, avec des tribeschapters et guilds tient compte de cette réalité sociologique. A titre d’illustration, le fait d’avoir commencé ma vie professionnelle en développant en LISP est un marquage fort, qui a changé ma façon de penser et crée une familiarité forte, des décennies plus tard, avec les gens qui partagent la même expérience. Cette conscience professionnelle est associée à une esthétique professionnelle – ce qu’on trouve dans tous les compagnonnages avec des « beaux gestes » et de « beaux ouvrages ». Dans le monde du développement agile, « Cet objectif commun c’est le « beau code », la bonne programmation ».  Je vous renvoie à un précédent billet dans lequel je faisais l’apologie du « beau code ». Cela conduit à la notion essentielle de « Software Craftmanship » : «  Du coté des developpeurs, le mouvement « Software Craftmanship », ou « artisanat logiciel »,  pose les principes d’un nouveau genre de programmation, promouvant l’artisanat plus que l’exécution ». Cette collection de pratiques et de savoirs organisé en artisanat apporte la flexibilité nécessaire pour apprendre et améliorer en continu, en dehors d’un cadre méthodologique trop restreint :  « Le Software Craftmanship a été créé pour combler les incohérences, les absences du Scrum, l’orientation business trop marquée du Scrum. Le Software Craftmanship recolle les morceaux techniques ».

3. Développeurs et chefs de projets / complexité et complication 

On retrouve dans ce livre, traité plus en profondeur, la question de l’opposition entre développeurs et chefs de projet. D’un point de vue sociologique, plusieurs témoignages confirme l’héritage du Taylorisme noté par Cecil Dijoux plus haut, à savoir la moindre reconnaissance des doers. Plusieurs systèmes de valeurs cohabitent, avec un hiatus « pour les développeurs les plus passionnés, devenir chef de projet, et cesser de coder, n’est pas évoluer, mais bien régresser ». Je n’ai pas le temps de rentrer dans ce débat – ce n’est pas mon objet – mais il me semble que ces deux rôles sont également nécessaires dès qu’on passe à l’échelle, et qu’il faut mélanger complexité et complication. La complexité exige de reconnaître le rôle du développeur et d’abandonner le taylorisme. La complication des grands programmes / produits / systèmes nécessite des fonctions d’orchestration, de pilotage et de communication propres aux chefs de projet. Le passage des équipes agiles à l’échelle, et l’intégration de ces équipes dans des programme de grande taille dépasse le périmètre de ce billet (et du livre). Pour aller plus loin voire SAFE (Scaled Agile FramEwork), surtout dans sa version 4.5.


4. Contrôler et mesurer le développement 


Je vous recommande particulièrement les quelques pages sur la mesure appliquée au développement logiciel, en particulier dans le contexte agile. On y retrouve, de façon plus directe et percutante, quelques idées que j’ai exprimées dans un billet précédent : « Cet ouvrage se propose d’expliquer aux néophytes pourquoi évaluer les équipes de développeurs à la quantité de code produite n’a absolument aucun sens. Les décideurs qui ignorent ce point essentiel courent à la catastrophe. Voilà ce que des développeurs doués et durs à la tâche sont en droit d’attendre : un manager sensible au talent de ses équipes ». Mesurer la création de valeur n’est pas une attente illégitime – de celui qui paye par exemple – mais il faut une grande humilité car cette création de valeur est éminemment complexe. En vertu de ce qui a été dit dans la partie précédente, il vaut mieux choisir des métriques simples et techniques au main de l’équipe de développement, et juger de la création de valeur à travers de la boucle client. Le livre donne quelques exemples très pertinents d’arrêt de projets au mauvais moment (une fois que le pire est passé) parce que les parties prenantes souffrent de « l’illusion du contrôle » et préfèrent utiliser des KPI plutôt que faire confiance.


5. Autonomie des équipes et pair -programming 

On retrouve, de façon symétrique et sans surprise, de nombreux arguments sur l’importance du travail en équipe, organisées de façon cross-fonctionnelle et autonome (ce qui va de pair). Le travail en équipe commence par le binôme et les auteurs citent de nombreuses expérience réussies de pair-programming, dans la tradition de l’extreme programming. Je vous renvoie à l’incontournable livre de Rich Sheridan sur ce sujet.  Faire du code un objet collaboratif de communication – à travers les code reviews ou le debugging partagé – est une des bonnes pratiques de l’informatique moderne. Les auteurs citent Gerald Weinberg qui « observa que dans les boites ou les programmeurs ne marquent pas le territoire de leur code et encourage les autres à y chercher les bogues et les améliorations potentielles, les améliorations sont drastiquement plus rapide qu’ailleurs ». C’est d’ailleurs ce qui fait tout l’intêret de l’open-source, à la fois en tant que source de code et que pratique communautaire. Je vous recommande en particulier le témoignage page 56 que je cite partiellement :  « Chaque équipe travaille sur ses sujets mais cela n’empêche pas de se parler : ceux qui décident font et vice-versa. Il n’y a pas des couches de management qui décident en amont de ceux qui font. Il y a des managers humains plutôt que des managers projets ».  On ne peut que souligner le principe de « ceux qui décident font et vice-versa », fil rouge de mes billets de blogs et des livres que je commente depuis 10 ans. Le livre souligne d’ailleurs que les nouvelles méthodes de développement logicielle contribuent au renouveau de l’organisation du travail : « le point capital dans l’agilité, c’est de raccourcir la boucle de feedback, et à tous les niveaux ».

 4. Conclusion


Pour conclure, voici ce qui me semble essentiel en matière de transformation numérique, à la lumière des doubles cultures du développement logiciel et de l’amélioration continue en boucle centrée sur le client. Je le résume en quatre affirmations :
  1. La transformation numérique n’est pas un objectif en soi. C’est une composante nécessaire d’une transformation nécessaire pour mieux – ou continuer à bien – servir ses clients. La transformation est dictée par le changement externe (des attentes, des usages, de ce qui est possible). C’est pour cela que j’utilise souvent le terme d’homéostasie qui est une formulation abstraite de la vision d’Henri de Castries pour AXA lors que j’ai eu le plaisir de l’écouter en 2014.

  2. La transformation numérique est une course – à cause de l’hyper compétition. Toute entreprise fait de toute façon sa transformation numérique, la question c’est à quelle vitesse ? Reprenons la définition de Ludovic Cinquin « La transformation numérique c’est l’exploitation radicale des possibilités d’Internet ». Le défi n’est pas simplement d’y arriver, c’est d’y arriver mieux et plus vite que ses concurrents, les anciens comme les modernes. Comme disent les américains, « Time is of the essense ». 

  3.  La transformation est émergente : elle se pilote en laissant une organisation responsabilisée et autonome développer son potentiel de situation, guidée par une finalité simple et claire. Réussir sa transformation c’est construire des nouvelles capacités et les « libérer » : leur donner le moyen d’agir – c’est tout l’intérêt du livre de Cecil Dijoux. Pour reprendre les idées du billet précédent, « rien ne sert de courir, il faut partir à point »
  4. Jardiner l’émergence est un mélange de culture et de pratique – dans lequel on retrouve cette double racine de la culture logicielle moderne (je continue à citer « Les géants du web » mais le temps passe vite et les paradigmes clés de 2017 pour réussir l’ambition DevOps ont déjà évolué) et des pratiques d’amélioration et d’apprentissage continu qui font la quintessence du Lean Management