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 tribes, chapters 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 :
- 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.
- 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 ».
- 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 »
- 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
Merci pour cet article Yves ! Dans "Decoder les développeurs" l'analogie qui m'a le plus intéressé est celle de considérer les développeurs du 21ème Siècle non pas comme des ouvriers (intégrés à une chaîne de production et sous management de tâche) mais comme des artisans (autonomes, responsables et valorisant le travail bien fait plus que le volume). Le chapitre sur la place des femmes dans le développement informatique est aussi très bien faite, en ces temps de circulaire sexiste chez Google.
RépondreSupprimerDans cette mouvance centrée sur la résolution des problèmes, je retiens Olivier Zara qui me semble le plus attentif aux retours d'expérience et à la mise en place du "management de l'intelligence collective". Son livre "La stratégie du thé" me semble incontournable pour qui s'intéresse à ce sujet.
RépondreSupprimerMerci ! je vais aller regarde cela tout de suite :)
Supprimer