Dans les deux précédents articles, nous avons commencé par faire l’amer constat de la non maîtrise des bases de l’agilité puis nous avons, ensuite , cherché à comprendre les raisons de cet échec pour enfin conclure sur une possible voie de sortie pour accompagner les entreprises sur le chemin de l’agilité. Je vous propose donc maintenant d’explorer avec moi ce chemin à travers l’article qui suit.

“Un problème créé ne peut être résolu en réfléchissant de la même manière qu’il a été créé.”- Albert Einstein

Pour bien comprendre mes propos, démarrons par un petit rappel sur l’origine de l’agilité et les promesses que cette culture porte.

Cette notion a été cristallisée à travers un manifeste signé par les leaders de différents mouvements de développement logiciel (R.A.D, Extreme Programming, Scrum, etc…). Son origine est purement issue du monde de l’IT et non de l’organisation d’entreprise.

Ce manifeste agile porte 4 valeurs et 12 principes dont on peut résumer les promesses de la façon suivante:

• Des livraisons plus fréquentes (Aller plus vite sur le marché et s’adapter rapidement)
• Des solutions plus simples (se concentrer sur ce qui a de la valeur)
• La satisfaction des clients (Avoir les fonctions qui leur sont réellement utiles)
• La satisfaction des collaborateurs (Contribuer à un objectif partagé)

Mais une entreprise n’est pas une organisation philantropique, elle se doit d’être performante. La performance dans une entreprise signifie être en capacité de créer de la valeur en continue malgré les évolutions de l’environnement dans lequel elle évolue. Des changements, il y en a toujours eu mais ils n’étaient pas aussi brusque ou rapide comme ils peuvent l’être aujourd’hui et qu’ils le seront encore demain.

Comme nous l’avons vu dans le premier article, le monde dans lequel évolue les entreprises, aujourd’hui, est volatile, incertain, complexe et ambiguë. On parle communément d’environnement VUCA.

La performance, dans un environnement VUCA, s’obtient par l’intermédiaire de plusieurs notions qui sont:

• La responsabilisation: déléguer la prise de décisions aux personnes qui sont le plus proche du terrain.
• Le droit à l’erreur: une prise de décision n’est pas toujours juste, il est donc important d’accepter l’erreur, tant tirer des leçons (amélioration continue). Mais ces erreurs ne doivent pas mettre en péril l’entreprise, il faut donc travailler sur de petit périmètre et en mode cycle court (Fail Fast, Learn Fast).
• Finir: Pour vraiment savoir, si nous nous sommes plantés ou pas, il faut avoir un vrai regard sur ce que nous venons de faire. Ce que nous venons de faire doit vraiment porter du sens en tant que tel. On doit amener quelque chose au bout afin de pouvoir dire on sait planté ou pas. D’où l’idée d’avoir quelque chose de fini. Il faut donc une approche très verticale. Prenons un exemple IT: la team crée un modèle de données et c’est tout mais pour un PO, ce n’est pas fini, il ne peut pas juger car ce n’est pas autonome, ce n’est pas quelque chose qui porte du sens. Quelque chose de fini, c’est quelque chose dont je peux exploiter l’utilité ou les bénéfices tout de suite en production.
• Lâché prise: c’est à l’opposé du management à l’ancienne qui te dis ce que tu dois faire à l’image des dessins où tu as des numéros à relier pour obtenir la forme. C’est plus on te pose un cadre associé à une mission claire et des contraintes: tu es libre de jouer dans ce cadre pour obtenir le résultat attendu.

Mais la mise en oeuvre ces notions nécessitent / exigent d’avoir un mindset, érigé en valeurs:

• L’humilité: Nul n’est un surhomme, nul ne peut prédire ce qui se passera demain et encore moins faire des plans sur plusieurs années.
• La confiance, la collaboration et la communication: Observer sans évaluer, ne pas remettre systématiquement en cause, ne pas travestir ses propres opinions.
• La transparence: Dire clairement ce qu’on fait, sortir des stratégies de calcul et de manipulation à échelle locale. Faire ce qu’on dit, tenir ses engagements.
• La rigueur: Ne jamais se satisfaire d’une demi-action: Une tâche débutée et laissée en “friches” aujourd’hui nécessitera le double du travail pour la terminer dans quelques semaines.
• La curiosité, le questionnement et l’auto-critique: Vecteur de toute progression humaine et applicable aussi en milieu professionnel.
• Faire mieux avec moins, faire simple: Sortir de la culture gloutonne symptomatique de nos sociétés occidentales, remettre la simplicité et le bon sens au cœur de nos relations humaines et de notre travail quotidien.

Pour une entreprise, cela demande une véritable mue de sa culture, de son ADN. Vous comprenez mieux maintenant les résultats de l’enquête, exposés dans le premier article, ainsi que mes certitudes exposées dans la conclusion du second article:

• une approche standard de conduite de changement ne suffit pas,
• un processus « d’agile washing » non plus,
• le simple déploiement d’un célèbre framework comme si l’on suivait le guide de construction d’un meuble d’un célèbre vendeur Suédois, encore moins.

Mais alors comment ré équilibrer la balance entre “Améliorer l’efficacité opérationnelle”, garantie de la performance, et “Créer de la valeur et l’amener au plus vite au client final”, permettant de faire perdurer la performance? Rappelez vous, mes derniers propos de l’article 2: “il est nécessaire d’aborder cette mutation en parlant le seul langage qu’une entreprise comprend, celui de la gestion des risques”,

La supposition, tu supprimeras

Une entreprise, pour se développer, émet en permanence des suppositions et contrôle ces dernières en demandant du reporting pour affiner au fur et mesure ces suppositions. En demandant régulièrement du reporting, elle cherche deux choses: la première est de réduire sa boucle de feedbacks pour transformer ses suppositions en validation, la seconde est d’avoir de la visibilité sur ce qui est train de se passer car c’est de cette façon qu’elle gère son risque.

Dans l’industrie logiciel, réduire la boucle de feedback, consiste à délivrer en permanence un produit fonctionnel. A partir du moment où nous livrons, l’entreprise peut valider le produit et arrêter de supposer, le risque de supposition a alors disparu.

La première boucle de feedback à mettre en oeuvre est le continuous delivery. Mais elle ne se suffit pas à elle seule, il est nécessaire de multiplier ces boucles de feedbacks pour valider au plus vite les suppositions que nous émettons.

Dans le développement logiciel, la multiplication des boucles de feedbacks se fait à plusieurs niveaux:

• En utilisant un bon IDE qui va vous aider en vous poussant la bonne syntaxe du langage que vous utilisez,
• En faisant du pair programming, pour s’assurer de rendre son code intelligible par n’importe qui,
• En faisant de la pair review, on s’assure de faire du code propre et qui respecte les patterns.

Kent Beck, Ward Cunninghal et Ron Jeffries, l’ont mis en oeuvre à travers l’Extreme programming, et cela fonctionne. La multiplication des boucles de feedback permet, à tous les niveaux, de transformer une supposition en validation et de limiter le risque de supposition. Plus vous réduisez vos boucles de feedbacks, plus vite vous passez du statut supposition à validation.

La prédictibilité, tu amélioreras

A l’heure actuelle, dans la majorité des cas, les entreprises ont perdu la capacité de modifier l’existant car les fameuses documentations n’ont pas été maintenue, les personnes ayant travaillaient dessus sont partis. La conséquence directe et lorsqu’il y a une demande de modifications, les équipes ne savent pas où elles mettent les pieds, combien de temps cela va prendre. Et il n’y a rien de plus stressant que de voir une même demande prendre parfois 2h, une autre fois 2 jours.

Comment améliorer la régularité des prédictions? Je peux vous affirmer que ce n’est pas en utilisant un outil de planification. Tout le monde sait que faire de la planification revient à empiler des hypothèses et statistiquement, on s’approche d’une probabilité de réalisation proche de zéro.

La seule solution est d’avoir un logiciel et un code source de qualité irréprochable. Pour cela, il est nécessaire d’instaurer:

• Du TDD et BDD car un code testé permet d’éviter les régressions
• Du pair programming car en codant à deux on partage la connaissance et on s’assure d’avoir un code intelligible
• Du Clean code et du refactoring pour éviter les redondances inutiles

Si, vous ne faites pas cela, la mise en place d’un continuous Delivery ne servira à rien. Ceci est vrai pour toute nouvelle application que vous souhaitez créer mais aussi pour celle que vous devez reprendre. Vous devez garder ou reprendre le contrôle de votre code source pour garantir votre prédictibilité.

Il faut être capable de livrer régulièrement…. Car tant qu’on ne livre pas, on ment à l’entreprise… et on retombe alors dans le risque de supposition.

Pour faire tomber le risque de supposition, vous devez faire disparaître le risque de prédictibilité.

Ton approche du run, tu changeras

L’ensemble des acteurs de l’économie traditionnelle aborde toujours pour des raisons comptables, les projets sous deux angles:

• Le build: phase où l’entreprise investit dans la création de son produit.
• Le run: phase où l’entreprise passe le produit en phase d’exploitation et comptablement cela entraine une phase d’amortissement. Et qui dit amortissement dit que le coût du produit en exploitation doit diminuer donc sa maintenance aussi

Pour cela, il faudrait que votre produit possède un code source irréprochable !!! Mais malheureusement, dans la majorité des cas présent, ce n’est pas le cas.

Le logiciel mis en production n’a pas la qualité requise, il contient des bugs car des concessions sur la qualité ont dû être faite pour tenir le périmètre fonctionnel validé en tout début de projet (Souvenez vous du fameux triangle de fer de la gestion de projet). On met donc mécaniquement une pression important sur un logiciel pas fini et dont on va attendre un seuil minimum de rentabilité.

En basculant dans un mode run, l’entreprise estime qu’il n’y a plus de risques qui pèse sur son produit alors qu’en réalité le risque est énorme. On a donc un désalignement complet entre la vision budgétaire de l’entreprise et la réalité du terrain. Garder cette approche va à l’inverse d’une maîtrise des risques.

Vous devez donc arrêter cette approche en passant dans une culture produit, où c’est une même équipe qui développe l’application tout au long de sa vie. L’application n’est donc plus vue comme un projet mais comme un produit, qui va donc vivre et évoluer en fonction de son utilisation par les clients et de son obsolescence technique.

Vous devez donc mettre en oeuvre une vrai logique de product management.

La confiance, tu restaureras

Un collaborateur engagé est un collaborateur qui va s’impliquer et être performant. En 2013, un sondage de l’institut Gallup avait indiqué que 65% des salariés Français étaient désengagés. Pourtant, les acteurs de l’économie traditionnelle font tout pour rendre heureux leurs collaborateurs:

• Borne d’arcade, Baby foot
• Salle de sieste Cours de yoga
• Ré aménagement des locaux pour etre plus dans une ambiance “startup” (c’est à dire des open spaces avec des plantes et des bureaux qui se montent….)
• Des séminaires team building pour apprendre à se connaitre où l’on va faire des serious games…

Mais rien à faire, cela ne change rien, le désengagement continu. Pourquoi? Car les entreprises sont incapables de faire confiance à ceux qui sont sur le terrain au quotidien. Culturellement, les sachants sont les managers, c’est eux qui décident…..

Or faire réellement confiance au collaborateur et le responsabiliser, c’est obtenir son engagement. Il y a une entreprise dans le monde qui a bien compris cela. Cette entreprise, c’est Toyota.

Toyota, a travers son Toyota Processing System, a mis en place une pratique baptisée le jidoka qui permet à tout ouvrier qui travaille sur la chaîne de production et qui constate un défaut d’arrêter cette dernière. Autrement dit un ouvrier peut arrêter la production de l’usine!!

Vous imaginez le niveau de confiance du management de Toyota qu’il faut pour autoriser les ouvriers à stopper la production de l’entreprise. Sauf que cette confiance est intelligente car il est pragmatique de détecter les défauts au plus tôt et pas en bout de chaine.

Toyota évite ainsi le passage à la casse de plusieurs dizaines de voitures et de perdre de l’argent. En responsabilisant, ces ouvriers, Toyota a gagné en qualité et en engagement.

La différence entre le développement logiciel et la construction automobile, c’est que ce n’est pas tangible donc les défauts que vous empilez ne sont pas visibles. Donc si vous voulez faire de l’agile, faites confiances à vos collaborateurs, faites leur confiance au point d’arrêter la production si jamais ils vous disent “on ne peut pas continuer la production”.

Faites confiance aux développeurs et donner leur ce droit d’arrêter la production. Quand ils vous disent: “on a de la dette technique, il faut que nous la traitions maintenant sinon on va avoir des problèmes de qualité”.

Ecoutez les et faites leur confiance et ne dites pas “on a entendu, on sait qu’on aura de la merde en fin de chaine et qu’on va devoir la jeter mais on s’est engagé à produire”. En faisant cela vous détruisez tous les efforts cités précédemment.

Cette confiance, dans les développeurs, ne s’arrête pas à l’arrêt relance de la production mais elle doit être sur l’ensemble de la chaîne (de la conception au Delivery en passant par le développement du soft). Cela veut dire que tous ceux qui ne codent pas n’ont pas leur mot à dire sur comment il faut faire:

• Donc Mesdames, Messieurs les architectes d’entreprises qui définissent les standards, les bonnes pratiques et les technos à utiliser pour le bien des projets, stop!
• Donc Mesdames & Messieurs les Product Owners et Scrum Master qui expliquent comment il faut faire techniquement, stop! Bien évidemment, on arrête de dire aux développeurs que faire des tests, du pair programming ou de la pair review, c’est une perte de temps.

En faisant cela, tous les efforts pour diminuer les risques de supposition et de prédictibilité seront réduit à zéro.

La mentalité, tu modifieras

Même si l’on traite correctement tous les risques précédent, les entreprises vont toujours à avoir tendance à basculer vers le côté obscur de la force. Pourquoi? Car les développeurs ont toujours été vu comme les ouvriers qui sont à la chaine. On leur donne les ordres à travers les spécifications détaillées et on s’attend qu’ils crachent le code sans réfléchir.

L’emplacement des équipes IT est trés symbolique pour cela:

• Avec un peu de chance, ils sont deux étages en dessous,
• Mais plus généralement, ils sont dans un autre batiment qui n’est généralement pas à 2 min à pieds
• (Et vous, lecteur, elle est où votre IT?)

L’IT, c’est sale, faut la cacher, et mettre le plus de couches possibles entre eux et nous ( BA, MOA, etc …). Mais quand on multiplie les couches entre l’émetteur et le destinataire, on a toutes les chances d’avoir une déformation de l’information.

Il faut donc rapprocher les teams, et pas en faisant du team building…. Mais en les mettant dans un même lieu, sur le même étage. Il faut créer des équipes intégrées, les fameuses features Team où l’on va mettre ensemble Product Owner, UX, Scrum Master, Développeurs, OPs pour réaliser les actions.

Mais attention, il ne suffit pas de mettre les gens ensemble et de leur changer le nom… Depuis le début du déroulement de mon raisonnement, vous vous êtes sans doute rendu compte que l’agilité horizontalise le pouvoir en le redistribuant sur différents rôles:

• Au product Owner, la responsabilité de la vision et du backlog produit
• Au Scrum Master, la responsabilité de la bonne utilisation des rituels agile pour garantir la création de valeur
• A la dev team, la responsabilité de produire une application de qualité à travers ses choix techniques et sa maitrise des valeurs du Software Craftsmanship
• Au manager, la responsabilité de faire tomber les obstacles empêchant les disparitions des risques cités précédemment
• A l’équipe infrastructure de mettre en place les modules nécessaires pour la mise en place de Continuous Delivery Il n’y a donc plus une personne qui dirige une équipe mais un groupe d’individus oeuvrant pour un objectif commun avec chacun des responsabilités bien définis. On casse donc la notion de hiérarchie et dans les organisations, c’est le plus dur car c’est quelque chose de culturel!!!

En effet, en France, on mesure l’avancement en nombre de personnes que l’on contrôle. On a une vision trés moyen-âgeuse du petit seigneur local avec ses cerfs!!!

Regardez les Cv que vous recevez, je parie que dessus est bien souvent affiché les choses suivantes:

• Chef de projet de 3 personnes puis,
• Chef de projet de 10 personnes puis,
• Directeur de projet de 2 équipes de 5 personnes puis,
• Directeur de projet de 5 équipes de 10 personnes puis,
• etc…

La majorité des entreprises se sont construire sur cette culture du command and control, du management …. Il faut donc accompagner vos collaborateurs pour les aider à évoluer dans ce changement de posture. Si vous ne le faites pas, vous vous retrouverez avec:

• Des Products Owners qui se prennent pour le contremaitre de l’équipe de développement
• Des Scrum Masters qui jouent les Chefs de projets

Vous devez former vos collaborateurs à ces nouveaux métiers pour faire tomber ce risque “Des Devs et les autres”. Vous devez aussi, vous former, vous le Top Management car ce changement de posture commence par la tête de l’entreprise. C’est à vous de montrer l’exemple.

Un modèle de Product Management scalable, tu construiras

Si vous avez traité l’ensemble de ces risques, vous commencez à être sur la bonne voie. Mais il reste une chose à mettre en oeuvre proprement, pour être sur de produire les bons éléments tant attendus par vos utilisateurs. Cet élément s’est le product management.

Dans la majorité des entreprises de l’économie traditionnelle, la notion de product management n’existe pas même si elles ont mis de « l’agilité » dans leur structure.

On a généralement un ersatz avec des équipes MOA qui servent de caisse d’enregistrement des idées, features ou tâches émisent par les différentes BU de l’entreprise. Ces équipes tentent d’organiser péniblement toutes les infos, déversées par toutes les entités de l’entreprise, avant de les transférer vers l’équipe de Développement accompagnée d’un proxy Product Owner, qui délivre vers le client final sans être sûr que les fonctions développées apportent de la valeur….

Deux changements majeurs sont à mettre en place:

• L’entreprise ne déverse plus d’idées mais pose une vision et défini le budget associé
• Création d’une cellule de Product Management qui aura pour responsabilité de mettre en musique cette vision en fonction du budget associé et des feedback client reçus pour le développement du produit pour alimenter le pipeline de développement (NB: une cellule de product management par produit)

A partir de ce moment là, vous pouvez commencer à scaler:

• Si votre produit grandit, vous pouvez multiplier les équipes de développement pour gérer une fonctionnalité par équipe
• Si vous avez un nouveau produit, vous créer une nouvelle cellule de Product Management avec une nouvelle équipe de développement

Conclusion

A travers ce troisième volet de cette série sur l’agile@scale, j’espère que vous aurez compris qu’il ne suffit pas simplement de choisir un modèle et de le déployer pour être à l’échelle. Si vous faites cela, c’est l’échec assurer. Avant de scaler, il faut mettre les risques sous contrôle tel que je viens de vous le décrire.

Passer à l’agilité, c’est à la fois du technique, surtout du culturel et le chemin peut être long. Ne copier pas bêtement et simplement les modèles connus (SAFe, LESS, Scrum@scale, etc…) vous courrez à l’échec. Faites vous aider par des personnes formées à la culture agile, au Devops, au Software Craftsmanship et enfin n’hésitez pas à tatonner.

Liens vers les autres articles de la série

• Faire de l’agilité à l’échelle de l’entreprise - Part I - Le constat
• Faire de l’agilité à l’échelle de l’entreprise - Part II: Les raisons d’un échec annoncé