dimanche, juin 03, 2018

La transformation numérique émerge de l’excellence logicielle




1. Introduction


Une idée clé de ce blog, comme de son cousin anglophone, est que la transformation numérique est une affaire de compétences. Autrement dit ce qui détermine en premier lieu le succès d’une stratégie numérique est son exécution, et cette exécution est avant tout une question de capacité, donc de compétences.
  • En particulier, je me suis intéressé à la synergie entre LeanStartup (« from customer to code ») et Devops (« from code to customer ») dans plusieurs de mes billets.

Le billet de ce jour est avant tout une fiche de lecture du livre de Nicol Forsgreen, Jez Humble et Gene Kim, « Accelerate ». Ce livre est la meilleure référence que je connaisse sur cette relation entre les performances des entreprises dans le monde numérique et leurs capacités logicielles de développement et déploiement. C’est probablement parce que les auteurs sont particulièrement pertinents et compétents sur le thème des « software factories » et des méthodes modernes de production et déploiement continus de logiciel. C’est également parce que ce livre est le résultat d’une approche quantitative et analytique, basée sur l’étude de plus de 20000 entreprises. Même si ce type d’approche est toujours soumise à questionnement, la méthode et les résultats obtenus font de ce livre une contribution fondamentale pour le dialogue entre métiers et informaticiens.

Ce billet est organisé comme suit. La deuxième partie est un résumé personnel et orienté des principales leçons que je tire de la lecture de « Accelerate ». Je l’ai structuré autout de dix points qui me semblent essentiels pour les entreprises qui sont engagées dans une « transformation numérique ». La partie suivante, beaucoup plus courte, revient sur la double flèche Lean Startup/ DevOps pour introduire la dimension fondamentale de l’effectuation. Cette partie fait suite au billet précédent sur les écrits de Philippe Silberzan. Les principes de l’effectuation capturent ce qui est dans le titre du billet : ce que l’on sait faire, ce qu’on a à portée de main, détermine le terrain de jeu que l’on peut pratiquer à une échelle de temps compatible avec le monde numérique. J’en déduis quelques conséquences sur le sujet de l’innovation numérique. Les observations contenues dans Accelerate ainsi que les lois empiriques de l’effectuation montrent à quel point la réussite d’une stratégie numérique est une question de compétences, de femmes et d’homme et d’attitude face à l’incertitude.


2. Construire des organisations digitales performantes grâce à DevOps 


Le livre qui sert de support au billet de ce jour, “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”, est remarquable à un double titre. En premier lieu, c’est une excellente synthèse de l’approche DevOps et CICD (Continuous Integration and Continuous Delivery). Ceci n’est pas une surprise puisque le deuxième auteur, Jez Humble, est un des spécialistes reconnus du sujet. Son livre « Continuous Delivery » est la référence du domaine et un « must read » pour ceux qui mettent en place une chaine CICD. En deuxième lieu, ce livre se place dans la grande tradition américaine des livres qui souhaitent ancrer leurs recommandations dans l’analyse des faits. Pas moins de 20000 entreprises ont été questionnées sur leurs pratiques de développement logiciel pour essayer de déterminer celles qui ont un impact sur leur performance. Comme le sous-titre du livre l’indique « Building and Scaling High Performing Technology Organizations», l’ambition des auteurs est de proposer une synthèse des meilleures pratiques des entreprises performantes et de relier la performance de l’entreprise à la qualité du processus de production de logiciel. Comme le montre les exemples des best-sellers célèbres « In Search of Excellence » et « Good To Great », cette approche n’est pas exempte de risque et prête facilement le flanc à la critique (comme toujours, « corrélation n’est pas causation »). Néanmoins, comme pour ces deux livres, je pense que nous avons ici un ouvrage remarquable et très utile. Même si la démarche de démontrer les liens entre pratique logicielle et efficacité économique des entreprise numérique est éminemment complexe, cette approche est nécessaire et utiles pour ceux qui doivent convaincre les « parties prenantes » de l’entreprise.
Selon mon habitude, je propose ici un résumé illustré des quelques points qui m’ont le plus intéressé. Je vous recommande chaleureusement, on l’aura compris, de lire ce livre en entier et tranquillement.  La partie méthodologique,  que je n’aborde pas ici, cherche à nous convaincre de la validité de cette approche fondée sur l’analyse de réponses à des questionnaires détaillés. La dernière partie, que je ne fais qu’effleurer, est un témoignage détaillé de la banque ING aux Pays-Bas.

  1. La capacité à construire et déployer du logiciel est la fondation sur laquelle se construit le succès des entreprises numériques. Le monde est en accélération permanente à cause de la technologie, et au cœur de cette accélération se trouve le logiciel. Cela concerne toutes les organisations dans tous les secteurs d’activité. L’excellence logicielle est par conséquent un enjeu de compétitivité pour les entreprises : “This is true because software delivery is an exercise in continuous improvement, and our research shows that year over year the best keep getting better, and those who fail to improve fall further and further behind”. Ce message s’adresse à toutes les entreprises, puisque “software is eating the world”: “In all of our research, one thing has proved consistently true: since nearly every company relies on software, delivery performance is critical to any organization doing business today”. Cette excellence logicielle s’exprime et se mesure en termes de capacités. Les auteurs ont une profonde méfiance à l’encontre des modèles de maturités, parce qu’ils enferment ceux qui les pratiques dans le faux confort d’un horizon borné, tandis que le monde des capacités numérique est en bouleversement perpétuel : «  Maturity models define a static level of technological, process, and organizational abilities to achieve. They do not take into account the ever-changing nature of the technology and business landscape”. Faire de ses capacités numérique le premier enjeu d’une stratégie numérique implique de se concentrer sur les femmes et les hommes de l’entreprise, et de construire un “capital humain”. Maitriser les processus de développement et déploiement devient un tel levier de performance qu’il est essentiel d’associer ces compétences de la façon la plus intime possible avec le « core business » de l’entreprise : « The fact that software delivery performance matters provides a strong argument against outsourcing the development of software that is strategic to your business, and instead bringing this capability into the core of your organization”.

  2. La  « transformation digitale » n’est pas un objectif ou une destination, c’est un état d’esprit et une attitude. On retrouve ici une idée brillamment exprimée par Fred Cavazza dans son billet «La transition numérique a commencé il y a 20 ans, nous sommes maintenant dans une phase d’accélération digitale ». Le livre contient plusieurs exemples de mise en garde sévère contre une vision “mécanique” de la transformation consistant à implémenter des nouveaux processus, comme le développement agile, de façon uniforme, sans se soucier des changements culturels et du fort besoin de leadership pour créer une organisation apprenante. Cela d’autant plus que ces pratiques agiles sont souvent mal comprises pour produire ce que les auteurs appellent le « faux agile » : “However, much of what has been implemented is faux Agile—people following some of the common practices while failing to address wider organizational culture and processes. …Many development teams working in organizations that claim to be Agile are nonetheless obliged to follow requirements created by different teams. This restriction can create some real problems and can result in products that don’t actually delight and engage customers and won’t deliver the expected business results”. Beaucoup de ces entreprises n’ont pas modifié leur façon de voir le monde et continuent à produire des spécifications qui sont envoyées à des équipes de développement qui produisent des projets avec une forte granularité et, par conséquence, un lead time qui reste long : “In this model, employees feel little control over the products they build and the customer outcomes they create, and little connection to the organizations they work for ».

  3. L’approche DevOps est le socle commun des entreprises qui excellent dans le développement et déploiement de logiciel. DevOps a émergé comme une pratique commune à un petit nombre d’organisations qui avaient le même problème de produire de façon scalable et répétable des systèmes distribués sûrs, résilients, et capables d’évoluer à une fréquence rapide. DevOps a conduit à formaliser les processus de construction, d’intégration et de déploiements continus (CICD : Continuous Integration and Continuous Delivery ) : « Continuous delivery is a set of capabilities that enable us to get changes of all kinds—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely, quickly, and sustainably”. Ces objectifs sont des objectifs “systémiques” – qui caractérise le système complet de la “software factory” – et ils ne peuvent être atteint qu’au moyen d’une collaboration étroite entre tous ceux qui sont impliqués dans les différentes phases du processus de construction/livraison du logiciel (d’où le nom de DevOps). Ces pratiques CICD permettent d’atteindre la régularité « industrielle » que l’on attend d’une « usine » logicielle : « CD helps us achieve one of the twelve principles of the Agile Manifesto: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. Un des indicateurs les plus efficaces pour évaluer la distance qu’il reste avec cet état de “sustainable development” est ce que les auteurs qualifient de “peur du déploiement”: “The fear and anxiety that engineers and technical staff feel when they push code into production can tell us a lot about a team’s software delivery performance. We call this deployment pain, and it is important to measure because it highlights the friction”. Pour développer la capacité de CICD il faut travailler sans relâche sur la suppression de cette “douleur du déploiement”. Cela passe bien sûr, dans une approche résolument lean, sur l’accélération du rythme des déploiements. On retrouve par ailleurs les bonnes recettes de la construction de systèmes résilients qui facilitent le travail de mise en œuvre et de pilotage :  « In order to reduce deployment pain, we should: Build systems that are designed to be deployed easily into multiple environments, can detect and tolerate failures in their environments, and can have various components of the system updated independently; Ensure that the state of production systems can be reproduced (with the exception of production data) in an automated fashion from information in version control; Build intelligence into the application and the platform so that the deployment process can be as simple as possible.”  Pas de surprise ici, je vous renvoie à mon cours sur « QoS et performance des systèmes distribués » – un peu ancien, mais les fondamentaux sont immuables – sur le sujet, en deux parties

  4. Les auteurs proposent de mesurer la performance des « software factories » avec un petit nombre de métriques : le « lead time » de livraison, la fréquence de déploiement, le temps nécessaire pour rétablir le service (MTTR) et le taux d’échec des procédures de changement. Dans l’esprit de la double flèche “from customer to code” et “from code to customer” ils décomposent le lead time en deux parties : le temps de concevoir et valider un produit ou une fonctionalité, puis le temps pour le mettre entre les mains des clients. Pour réduire la fréquence de livraison, il faut bien naturellement travailler par « petits lots » : “ Reducing batch size is another central element of the Lean paradigm—indeed, it was one of the keys to the success of the Toyota production system.” Ces quatre métriques sont à contraster avec les 24 pratiques qui ressortent de l’analyse statistique de la performance des 20000 entreprises étudiées. Je vous renvoie au schéma complet qui se trouve ici. Une partie des résultats de l’analyse statistique de la corrélation pratique/performance est tout à fait attendue et sans surprise. Par exemple, l’utilisation efficace des outils de contrôle de versions est fortement corrélée avec la performance. Ces pratiques sont majoritairement inspirées du Lean Software management et de DevOps. Le point fondamental est qu’il s’agit de pratiques, qu’il faut du temps et de la patience pour mettre en œuvre : « Practice patience. Your current way of work took decades to entrench. It’s going to take time to change actions and thought patterns until they become new habits and, eventually, your new culture. Practice practice. You just have to try it: learn, succeed, fail, learn, adjust, repeat. Rhythm and routine, rhythm and routine, rhythm and routine”.

  5. L’analyse proposée des bonnes pratiques des organisations logicielles performantes s’articule autour des concepts du « Lean Manufacturing».  Un des intérêts du livre est la sélection de 24 pratiques qui sont validées par leur corrélation avec la performance des entreprises qui les pratiquent. On retrouve des pratiques tirées du monde agile, du « Lean Software » à la Mary & Tom Poppiendieck, du « Lean Product Development » et de DevOps. Les auteurs expliquent les concepts communs tirés du Toyota Way et leur interprétation scientifique dans un contexte de pilotage de files d’attentes. Par exemple : « Once utilization gets above a certain level, there is no spare capacity (or “slack”) to absorb unplanned work, changes to the plan, or improvement work. This results in longer lead times to complete work.” Pour les auteurs, les éléments principaux du lean qui s’appliquent au logiciel sont : la limite du “work in progress”, le management visuel, le feedback de la mise en œuvre (production), et les processus allégés d’approbation du changement. L’exemple d’ING qui est développé dans la deuxième partie du livre permet d’apprécier des exemples de mise en oeuvre de ces pratiques de management visuel : “ Four distinct zones are visualized: strategic improvement, performance monitoring, portfolio roadmap, and leadership actions, each with current information about targets, gaps, progress, and problems ». Les techniques de visualisation et pilotage de résolution de problèmes sont variées et ont évolué au cours du temps: « Over the years, they have experimented with different problem-solving methods, including A3, Kata, Lean startup, and others, and finally settled on a blend of elements that they found helpful, creating their own approach. In our walk today, we have seen evidence of multiple problem-solving initiatives in flight and visualized on the walls.”

  6. Dans une perspective Lean, les tests et la sécurité doivent être introduits le plus tôt possible dans le processus de développement. Les résultats confortent le fait que dans CICD, il y a « continuous testing », à chaque étape du cycle de production déploiement : « Testers serve an essential role in the software delivery lifecycle, performing manual testing such as exploratory, usability, and acceptance testing, and helping to create and evolve suites of automated tests by working alongside developers”. Le panel d’entreprise étudié comprenait différentes formes de production des jeux de test automatisés, intégrées à la chaîne de développement ou séparées, et l’analyse montre que les deux formes sont possibles et également efficaces, du moment que l’exécution des tests automatiques est systématique et fréquente. Les auteurs ont également étudié la façon dont les entreprises intègrent, testent et valident les exigences de cybersécurité. Leur recommandation est très claire, il faut intégrer la sécurité dès le début dans l’ensemble du cycle de développement : « High-performing teams were more likely to incorporate information security into the delivery process. Their infosec personnel provided feedback at every step of the software delivery lifecycle, from design through demos to helping with test automation”. Les développeurs, par conséquent, sont des acteurs actifs de la cybersécurité du système d’information, et doivent connaitre les différentes recommandations de l’état de l’art, comme par exemple celles de l’OWASP.  C’est ce que les auteurs appellent le « shiftleft » de la sécurité : « We found that when teams “shift left” on information security— that is, when they build it into the software delivery process instead of making it a separate phase that happens downstream of the development process—this positively impacts their ability to practice continuous delivery. This, in turn, positively impacts delivery performance.”
  7. Toujours dans cette perspective Lean, les organisations efficaces sont en premier lieu des organisations apprenantes. Comme cela a été dit plus haut, la performance numérique passe en premier lieu par le capital humain : « People are at the heart of every technology transformation. With market pressures to deliver technology and solutions ever faster, the importance of hiring, retaining, and engaging our workforce is greater than ever”.  Le rythme d’évolution exponentiel des technologies oblige à adresser l’apprentissage permanent des employés (c’est une question de flux, un rythme aussi rapide ne peut pas se traiter simplement par attrition et embauche). C’est ce qui conduit irrémédiablement au principe de l’organisation apprenante, dans un monde numérique ou apprendre signifie faire : « Our analysis is clear: in today’s fast-moving and competitive world, the best thing you can do for your products, your company, and your people is institute a culture of experimentation and learning, and invest in the technical and management capabilities that enable it”. Cet objectif de progrès continu se traduit dans l’organisation mais surtout dans la culture et la pratique quotidienne, avec un fort emprunt aux approches Lean et à l’héritage de Deming : “This practice of rapid exchange of learning, enabling the frontline teams to learn about strategic priorities and the leaders to learn about customer experience from frontline team customer interaction, is a form of strategy deployment (Lean practitioners use the term Hoshin Kanri). It creates, at all levels, a continuous, rapid feedback cycle of learning, testing, validating, and adjusting, also known as PDCA”.  L’exemple détaillé de l’organisation d’ING montre également des emprunt au modèle « distributed agile » de Spotify : « There are also chapters, comprised of members of the same discipline (for example, the Data Analytics Chapter), who are matrixed across squads and bring specialized knowledge to promote learning and advancement among squad members".

  8.  Performance et résilience riment dans un monde complexe. Les auteurs font plusieurs fois référence au mouvement « Rugged software movement ». Si ce mouvement n’a pas connu un grand succès, son manifeste reste un document très pertinent et utile. Comme cela a été dit plus tôt, la résilience fait partie des objectifs initiaux du mouvement DevOps. Comme les systemes numériques modernes sont complexes – fréquence et richesse du changement et complexité des interactions avec les utilisateurs - , les pannes sont également complexes et leur traitement relève de l’émergence . Prévenir et traiter les erreurs est donc une pratique qui nécessite de l’entrainement. On trouve donc sans surprise des recommandations pour faire des exercices fréquents de validation de plan de « disaster recovery »: « Use Disaster Recovery Testing Exercises to Build Relationships … Creating a training budget and advocating for it internally. Emphasize how much the organization values a climate of learning by putting resources behind formal education opportunities” - ma reference sur ce sujet est le livre de Klaus Schmidt, « High Availability and Distaster Recovery ».  La resilience s’obtient également en favorisant l’automatisation et le monitoring proactif permanent. Ces recommandations sont dans la ligne directe du livre de référence de Google « … » dont je ferai une synthèse dans un prochain billet. « Make monitoring a priority. Refine your infrastructure and application monitoring system, and make sure you’re collecting information on the right services and putting that information to good use …  Practices like proactive monitoring and test and deployment automation all automate menial tasks and require people to make decisions based on a feedback loop. Instead of managing tasks, people get to make decisions, employing their skills, experience, and judgment”.

  9. La culture des organisations logicielle performantes est fondée sur l’autonomie et l’intégrité. On retrouve ici le message principal de “Good to Great” – la première marque des organisations performantes est la culture d’intégrité, le fait de dire « les choses telles qu’elles sont » et de faire circuler les mauvaises nouvelles le plus rapidement possible. Le premier adversaire de l’intégrité c’est la peur : “As Deming said, ’whenever there is fear, you get the wrong numbers’. Before you are ready to deploy a scientific approach to improving performance, you must first understand and develop your culture”. Comme la culture se construit au moyen de l’exemplarité, le leadership du management est essentiel dans une usine logicielle. Il faut, selon l’expression de Deming, « chérir ses erreurs » et accepter les difficultés telles qu’elles se présentent. Il faut aussi savoir prendre le recul pour permettre aux squads de travailler dans un contexte de charge « lean » qui permettent cet apprentissage et amélioration continue :  « A courageous and supportive leader is crucial to help teams “slow down to speed up,” providing them with the permission and safety to put quality first (fit for use and purpose) which, in the long run, improves speed, consistency, and capacity while reducing cost, delays, and rework”. La deuxième charactéristique des organisations performantes dans un environnement complexe – on retrouve ici une des idées fondamentales développées dans ce blog et le pilier de l’Entreprise 3.0 – l’autonomie laissée aux équipes. L’autonomie des équipes est une conditions essentielle de l’agilité et de la performance: «  Our analysis showed that the ability of teams to try out new ideas and create and update specifications during the development process, without requiring the approval of people outside the team, is an important factor in predicting organizational performance as measured in terms of profitability, productivity, and market share”.  Les auteurs constatent que les entreprises dans lesquelles les équipes ont des processus d’approbation/validation très légers voire inexistants sont celles qui ont également les meilleures performances en termes de déploiement logiciel. Cette autonomie s’exprime de multiples façons, et particulier et cela mérite d’être souligné, dans le choix des outils « Our analysis shows that tool choice is an important piece of technical work. When teams can decide which tools they use, it contributes to software delivery performance and, in turn, to organizational performance”. L’autonomie ne signifie pas l’autarcie, les équipes doivent partager et apprendre les unes des autres (d’où le modèle Spotify avec ses guildes et ses chapitres). Les ressources logicielles partagées facilitent cette organisation. Par exemple, le développement sur un « tronc commun » est un facteur d’efficacité : « Our research also found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance”. Les mouvements latéraux sont fortement encouragés: « Encouraging practitioners to move between departments. An admin or engineer may find as they build their skills that they’re interested in a role in a different department. This sort of lateral move can be incredibly valuable to both teams”.

  10. Du point de vue de l’architecture, il faut rechercher la modularité qui permet de donner l’autonomie requise aux équipes et la flexibilité nécessaire aux systèmes. Le livre brièvement d’architecture, en faisant surtout – sans surprise – un plaidoyer pour la modularité : « Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams” La partie la plus intéressante sur l’architecture est la référence à la Loi de Conway  qui stipule que l’architecture des systèmes d’information est liée aux flux interne d’information et se calque par conséquence sur l’organisation de l’organisation. Il ne faut pas ignorer la Loi de Conway : soit on joue avec en modifiant fréquemment l’organisation, soit on lutte contre en favorisant les rotations fréquentes des collaborateurs. Cette dépendance entre communication et architecture est également une difficulté lorsqu’on pratique l’ « agile distribué » : « Another challenge the coaches are experimenting with is dispersed teams. With recent restructuring, some squads now have members from more than one country, so the coaching team is experimenting with, and measuring, ways to maintain the same high level of collaboration and learning among cross-border squads (it’s very hard to virtually share two pizzas)”. La combinaison du management visuel partagé et des rites communs permet de palier une partie de ces difficultés.  

3. Lean Startup, DevOps and effectuation


Le schéma de la figure suivante est tiré d’une présentation à Xebicon en 2015 et représente la double nécessité pour les entreprises de maîtriser à la fois les méthodes d’innovation centrée sur le client du Lean Startup et les capacités de déploiement de DevOps. Il faut à la fois savoir concevoir, exécuter et déployer ses produits dans un cycle permanent et rapide. Les auteurs de « Accelerate » arrivent à la même conclusion:  « In the following year, we flipped the model and confirmed that software delivery performance drives Lean product management practices. Improving your software delivery capability enables working in small batches and performing user research along the way, leading to better products




Depuis 2015, j’ai évolué dans cette analyse et il me semble maintenant important d’introduire dans ce schéma l’influence de l’effectuation. L’effectuation est une « boucle de retour » du bas (développement) vers le haut (conception). Autrement dit, il faut tenir compte de ce que l’on sait faire lorsqu’on imagine le produit de demain. C’est la conséquence naturelle des idées de Philippe Silberzahn développées dans le précédent billet. Il y a une double boucle de retour qui doit influencer le processus d’innovation : la boucle de retour client – ce que le client pense de ce qui lui est proposé – et la boucle de retour de sa propre réalité de ses capacités. L’effectuation traduit précisément que la stratégie numérique est ancrée dans les capacités numériques. Il ne sert à rien – même en écoutant religieusement ses clients selon un processus LeanStartup exemplaire – de concevoir des produits pour lesquels on ne dispose pas des compétences numériques nécessaires.

Un corollaire de cette observation est que la l’apprentissage continu des compétences qui définit le « terrain de jeu de l’effectuation » a des conséquences importantes sur la mise en place de la « transformation numérique » souhaitée par les entreprises :
  •   L’  « Innovation as a Service” est principalement un mythe. La pratique de l’apprentissage continue a un coût et représente un risque. Si ce n’était pas le cas, le modèle de « marketplace » des expertises aurait déjà triomphé. Cela ne signifie pas qu’innover se fait de façon autonome et sans appel à l’extérieur ! Cela signifie que le lieu de création de valeur est le lieu de l’apprentissage. C’est ce qui explique la guerre des talents, par exemple dans le domaine du Machine Learning.
  •  Pour reprendre un aphorisme de « Skin in the game » de Nassim Taleb, « no pain, no gain » : les entreprises ne peuvent pas externaliser leur apprentissage. Il y a ici une extension de la « théorie de l’entreprise » de Coase : l’entreprise permet d’internaliser les coûts de de l’apprentissage (en addition aux coûts de transaction).



La combinaison des deux principes fondamentaux de l’effectuation et le modèle distribué de l’organisation face à la complexité implique qu’il existe une forme inévitable de redondance : l’apprentissage se fait à plusieurs endroits. On ne peut pas éviter que dans le « learn by doing », il y ait une certaine répétition des « doing ». Comme les équipes sont différentes, ce n’est pas le même « learning ». Je suis frappé de voir le nombre de directeurs de l’innovation dont la première tâche dans leur poste est de « rationaliser les POC », c’est-à-dire supprimer les redondances. Ce qui est dommage, c’est de faire la même chose à plusieurs endroits dans le savoir et sans profiter de l’opportunité de créer une communauté de savoir, de pratique et de partage. En revanche, dans une Entreprise 3.0 articulée autour d’une finalité unique, fonctionnant en un réseau d’équipe autonomes dans un mode d’apprentissage permanent, il est naturel et logique que ces équipes sélectionnent des terrains d’apprentissage semblables pour entretenir et développer leurs compétences techniques.