dimanche, août 28, 2016

Découverte et Déploiement continus de produits



1. Introduction



J’ai profité de l’été pour lire un certain nombre de livres et regarder quelques talks comme les deux que je vais évoquer. Il m’apparait un mouvement important de convergence autour des idées que je présente dans ce blog, qu’il s’agisse d’entreprise 3.0, de lean startup, de design thinking ou de déploiement continu. Plus précisément, les pièces du puzzle commencent à se mettre en place et c’est une approche complète qui émerge.
Commençons par évoquer l’excellente intervention de Marty Cagan à l’USI 2016 intitulée « The Root Cause of Product Failure ». Je vous laisse découvrir le style inimitable et provoquant de Marty Cagan, leader du Silicon Valley Product Group, qui commence son exposé en challengeant les entreprises françaises sur nos méthodes de travail – « French companies operate the wrong way, change the way you work ». Il y a de la caricature dans ses propos, et il faut prendre le tout avec un grain de sel, mais on trouve également des idées clés, exposées avec force. Ces idées sont la conséquence de la complexité croissante et du rôle de l’usage, dans la droite ligne du Lean Startup et des thèmes de ce blog.  La première est qu’il faut prendre de la distance avec les roadmaps, puisque 50% de ce qu’elles contiennent ne sera pas utilisé pas les clients et l’autre moitié va nécessiter des itérations multiples de mise au point. Le second conseil est de se concentrer sur les « outcome » - lié à l’usage - et pas les « outputs », ce qui est bien sûr plus difficile et exige de renoncer aux anciennes méthodes velléitaires de contrôle. La troisième idée est qu’il faut maitriser et combiner deux processus parallèles et itératifs : « continuous product discovery » et « continuous product delivery ». C’est une idée que j’avais commencé à développer dans mon exposé au Xebicon dont l’illustration (simplifiée) à droite est extraite. Cette slide intitulée « Lean Startup and Lean Software Factory » pourrait également s’appeler « Product Discovery and Product Delivery


L’édition 2016 de l’USI recèle de nombreuses pépites, je vous recommande également l’exposé de John Kolko  intitulé  « Well-Design : How to use empathy to create products people love ».John Kolko est un des « apôtres » du Design Thinking.  Son exposé mérite une écoute attentive, notamment la seconde partie qui fourmille d’exemples pratiques. Le thème général est la convocation de l’émotion et de l’empathie dans le design des produits, ce qui résonne avec l’exposé que je viens de mentionner. L’empathie s’exprime par des histoires et le « product manager » doit être un « story teller ».  Le message principal est l’importance de l’observation - « observe and listen » - en allant « vivre l’expérience de ses futurs utilisateurs le plus tôt possible ». On retrouve le rôle de « Product anthropologist » cher à Richard Sheridan. Ces témoignages utilisateurs sont collectés et mis à la disposition de toute l’équipe en utilisant la force du management visuel (i.e., l’affichage sur les murs – « the great wall of utterance »). Cela souligne l’importance de la sérendipité dans le design thinking : il ne s’agit pas simplement de recueillir des « feedbacks » pour valider ou invalider des hypothèses : il faut écouter. La construction des hypothèses, des « behavioral insights » se fait de façon émergente. Et tout cela prend du temps et demande beaucoup de travail

Mais ma plus grande découverte de cet été est le livre “Lean Enterprise – How High Performance Organizations Innovate at Scale » qui va être le sujet du billet de ce jour.

2. Lean Entreprise


Ce livre est présenté en préface comme « Reingineering the Corporation for the digital age ». C’est à la fois un livre de synthèse, très à jour dans ses références, et un livre assez personnel sur l’importance de relier les deux flèches présentées dans l’introduction : le « product discovery » et le « product delivery ». C’est clairement un livre écrit avec un parti-pris informatique et logiciel, même s’il s’agit d’un livre généraliste pour un public large. Je vous recommande cet petit compte-rendu si vous voulez vous faire une idée avant de vous plonger dans ce qui va suivre. Vous pouvez aussi jeter un œil sur les recommandations.
J’ai lu ce livre cet été sur mon iPad, et je surligne comme chaque fois tout ce qui me semble intéressant. Dans ce cas précis, j’ai obtenu plus de 20 pages de citations ! La double conséquence est que mon petit résumé de lecture va être un peu plus long qu’à l’habitude …. Et qu’il s’agit bien d’un choix éditorial et personnel. Même si j’ai quelques petits sujets de divergence, ce livre est la meilleure version en anglais des idées présentées dans ce blog. La raison est double. D’une part ce livre est une synthèse, et la bibliographie dont sont partis les auteurs est la même que la mienne. On va retrouver des noms et des titres connus. La seconde raison est la proximité culturelle, les auteurs et en particulier Jez Humble ont une forte expérience, et culture, en IT et en architecture, ce qui transparait dans cet ouvrage. Suivant mon habitude, je vous propose un petit décalogue des idées principales, émaillé de citations extraites de cet ouvrage.

2.1   Il existe un ensemble de principes et de méthodes adaptés aux défis des entreprises plongées dans un monde numérique 


 L’objectif de ce livre est d’aider les entreprises qui cherchent à mettre en places les deux démarches évoquées dans l’introduction : “When Continuous Delivery (Addison-Wesley) and The Lean Startup (Crown Business) were published, we saw an enormous amount of demand from people working in enterprises who wanted to adopt the practices described in these books”. Une petite partie du livre est donc consacrée à une explication pédagogique des démarches de Lean Startup -avec son vocabulaire, ses principes et ses objectifs, fournir de la valeur au client en résolvant un vrai problème – et de « Continuous Delivery » (de façon simple, puisque qu’il existe un autre livre qui traite de ce sujet de façon unique). La partie la plus importante donne des conseils de mise en œuvre et surtout souligne les difficultés et les écueils à éviter. On peut donc dire que l’idée centrale est l’utilisation de méthodes incrémentales pour s’adapter de façon continue à un monde qui change (homéostasie). C’est plus général que le sujet du développement produit :  “However, the principles behind the Lean Startup can be applied to all kinds of activities within the enterprise, such as building internal tools, process improvement, organizational change, systems replacement, and GRC (governance, risk, and compliance) programs”. 
Les auteurs expliquent en détail une des conséquences clés de l’approche Lean Startup : le “business case” est le résultat du processus d’innovation (dans sa partie de product discovery), pas la condition. Bien sûr, il existe dès le début du processus d’innovation des hypothèses de création de valeur (à valider ou invalider) et un budget à respecter (cf. affordable loss), mais un business case produit trop tôt relève de la fantaisie : “Thus the business case essentially becomes a science fiction novel based in an universe that is poorly understood — or which may not even exist!”. D’un point de vue systémique, Lean Startup est vu comme un processus pour réduire l’incertitude : « The job of an experiment is to gather observations that quantitatively reduce uncertainty”. Ce principe s’applique à la première source d’incertitude qui est l’usage des clients, mais également pour d’autres incertitudes liées au développement exponentiel des technologies, ce qui conduit à incuber les innovations technologiques avec des principes semblables (nous allons en reparler dans la section 2.6). Je ne vais pas ici faute de temps vous résumer les différentes illustrations, mais elles font partie de l’intérêt du livre, comme l’exemple du « HP LaserJet Firmware Team », pour lequel de nombreux détails et chiffres clés sont fournis.


2.2   Le Coeur de la démarche est une vision “globale” du Lean Startup, qui va du Design Thinking au Growth Hacking



La vision Lean Startup des auteurs est une vision globale, très semblable à celle de Nathan Furr et Jeff Dyer – « The Innovator’s Method » , qui couvre les trois boucles : design thinking,  Minimum Viable Product, Growth. Sans surprise, on trouve donc dans ce livre des multiples références au Design Thinking – cf. le propos introductif avec John Kolko - et aux principes du Lean UX. Je cite par exemple : « In Lean UX: Applying Lean Principles to Improve User Experience, Jeff Gothelf and Josh Seiden state, “Design thinking takes a solution-focused approach to problem solving, working collaboratively to iterate an endless, shifting path toward perfection. It works towards product goals via specific ideation, prototyping, implementation, and learning steps to bring the appropriate solution to light. … By combining the principles of design thinking with Lean Startup practices, we can build a continuous feedback loop with real users and customers into our development cycle.”  Dans le détail, on retrouve l’importance de choisir “one metric that matters » avec la référence attendue aux Pirate Metrics :  « Dave McClure’s “pirate metrics”7 are an elegant way to model any service-oriented business, as shown in Table 5-2 (we have followed Ash Maurya in putting revenue before referral). In the early stages, we must spend less time worrying about growth and focus on significant customer interaction”. Le thème général de l’importance de la mesure, du recours au A/B testing est abondament représenté : « Ronny Kohavi, who directed Amazon’s Data Mining and Personalization group before joining Microsoft as General Manager of its Experimentation Platform, reveals the “humbling statistics”: 60%–90% of ideas do not improve the metrics they were intended to improve.” D’autres exemples, par exemple chez Amazon, illustrent la même conviction que l’intuition est mauvaise conseillère. Ce qui ne veut pas dire qu’il s’agit de remplacer le jugement par l’analyse : “Big data is a tool, not a solution. Crucially, it does not replace empathy. We still need human intuition and innovation to improve the problem definition and identify customer and user needs and problems, so as to form hypotheses that can be tested against the data”
J’ai retrouvé avec plaisir les principes du Customer Feedback Learning Loop (CFLL) que nous pratiquons à la Digital Agency d’AXA : « This customer feedback loop is essential for improving the quality of the service”, avec en particulier l’utilisation d’un plan d’action au format A3 hérité de la culture lean : «  A3 Thinking is a logical problem-solving tool to capture critical information and define the focus and constraints of the team. Later, it becomes a measure to test our outcomes against. An A3 report (so called because it fits on a piece of A3-size paper), composed of seven elements, embodies the Plan-Do-Check-Act cycle of experimentation”. Pour finir sur ce sujet, je vous recommande la section “Customer Intimacy » - un des objectifs cardinaux des entreprises dans le monde numérique -  qui exprime avec beaucoup de force le principe « nail it then scale it » : “By keeping our initial customer base small — not chasing vanity numbers to get too big too fast — we force ourselves to keep it simple and maintain close contact with our customers every step of the way”.


2.3   La réussite d’une stratégie numérique passe aussi par l’adoption d’une approche DevOps


Comme je l’ai indiqué, le livre est un plaidoyer pour le déploiement de DevOps, dans la continuité des arguments de Marty Cagan. L’idée fondamentale est que dans le monde numérique, les entreprises n’ont pas le choix, elles doivent s’adapter au développement incrémental et au déploiement continu de produits. D’un point de vue systéique, c’est l’application du principe lean des « small batches » pour augmenter la capacité d’adaptation. C’est difficile et ce n’est pas le cas de la majorité des entreprises : « They still apply top-down thinking and tend to batch up work into releases with long cycle times, thus limiting the use of the information collected to guide future decisions.”  Le livre donne de nombreux conseils sur l’intégration continue – la capacité à reconstruire tous le jours un système qui fonctionne et surtout à donner la priorité au maintien de la cohérence du système global sur l’ajout de fonctionnalités -, les tests automatisés – qui sont la condition sine qua none de ces pratiques d’intégration et développement continus – et le déploiement continu : “There are two golden rules of continuous delivery that must be followed by everybody: (1) The team must prioritize keeping the system in a deployable state over doing new work. (2) The solution is for all developers to work off trunk and to integrate their work into trunk at least once per day.”  Les auteurs citent les exemples connus – Google, Amazon, Facebook, cf. Les Geants du Web – pour conclure que : Not only is continuous integration possible on large, distributed teams — it is the only process that is known to scale effectively without the painful and unpredictable integration, stabilization, or “hardening” phases associated with other approaches, such as release trains or feature branches”.  Le déploiement continu ne signifie pas que le client est impacté de façon continue:  “The most important principle for doing low-risk releases is this: decouple deployment and release”. Il existe de nombreuses approches – cf. le “dark launching” -  pour mettre des produits en production avec des nouvelles capacités sans que celles-ci soit systématiquement disponibles pour les utilisateurs, ce qui permet de faire des tests “en production” dans des conditions réelles d’utilisation.

2.4   “IT matters because Software is eating the world”


L’ensemble du livre s’inscrit dans le prolongement du célèbre billet de Marc Andreesen. Les auteurs rapportent également cette citation de Jeff Immelt : « In an industrial company, avoid software at your own peril . . . a software company could disintermediate GE someday, and we’re better off being paranoid about that”. Une des sources principales d’information pour les auteurs est une étude “2014 State of DevOps Report »  qui leur permet de conclure : “A key premise of this book — supported by the experience of companies such as Tesla, among many, many others — is that the flexibility provided by software can, when correctly leveraged, accelerate the innovation cycle”. L’étude de 2014 est très détaillée (9600 participants) et montre que les pratiques qui sont le plus corrélées avec des hautes performances (“throughput” et “stability”) sont la gestion versionnée des configurations, le monitoring et l’alerting en temps reel, le fractionnement en petits lots, l’intégration continue journalière.  Pour résumer : “The researchers concluded that to achieve high performance, companies that rely on software should focus first and foremost on their ability to execute, build reliable systems, and work to continually reduce complexity.” Si la cible est claire (pas de surprise), ce qui rend le livre intéressant est une très bonne analyse de ce qui rend le changement vers DevOps/Continuous delivery difficile. La première difficulté est la gestion de la complexité : « Building complex systems, however, these forces inevitably lead to system bloat, increased complexity and dependency management, inefficiency, and poor quality”. Les auteurs parlent, sans surprise non plus, des difficultés à mettre en place des projets de remplacement et refonte des grands systèmes techniques. Il est clair que le changement de paradigme - passer de “construire de façon répétée et fiable des systèmes stables” à “construire de façon continue un système qui change constamment”- est difficile pour la plupart des entreprises.
La seconde difficulté est l’impérieuse nécessité d’aligner tous les stakeholders sur cette approche de “continuous delivery”.
Lorsque les demandes métiers suivent des approaches “classiques”, on obtient des “hybrides” peu efficacies : “ Even in organizations which have adopted “agile” development methods, the value stream required to deliver a project often resembles Figure III-1, which we describe as “water-scrum-fall.”  Je vous laisse découvrir le “water-scrum-fall” … toute ressemblance avec une situation ayant existé n’est pas fortuite. Les auteurs ont un parti-pris très clair qui rappelle également les recommandations des “Géants du Web”: “In most enterprises, there is a distinction between the people who build and run software systems (often referred to as “IT”) and those who decide what the software should do and make the investment decisions (often called “the business”)  … In high-performance organizations today, people who design, build, and run software-based products are an integral part of business; they are given — and accept — responsibility for customer outcomes.” 
J’ai lu avec beaucoup d’intéret le “témoignage” de Suncorp, un assureur Australien qui applique ces approaches à son informatique : “Suncorp is successfully applying agile and lean approaches to the “big iron” world of mainframe systems. During the first year of the simplification program, testing was extended to support integration of the mainframe policy system with the new digital channels and the pricing systems. In the process, Suncorp has reduced 15 complex personal and life insurance systems to 2 and decommissioned 12 legacy systems”.

2.5   Mettre en place le déploiement continu est un problème de culture


Ce point est suffisamment important aux yeux des auteurs pour que je le sépare du paragraphe précèdent. Même si la mise en place du déploiement continu est un chantier technique, avec des investissements, des outils et des pratiques d’ingénierie, les choix technologiques ne sont pas le facteur de succès le plus important. C’est avant tout une question de “mindset” et de “culture”: “The purpose of this chapter is to show that while these obstacles are indeed challenges, the most serious barrier is to be found in organizational culture, leadership, and strategy”. A plusieurs reprises, les auteurs évitent de donner des conseils technologiques : “First, we think that tool choice is actually not a tremendously important decision (so long as you avoid the bad ones). Many organizations moving to agile methodologies spend an undue amount of time on tool choice hoping to magically solve their underlying problems”. Si la mise en oeuvre est une question de culture, c’est donc une question de femmes et d’hommes. C’est ce qui conduit à la place importante qu’occupent l’organisation et le management dans ce livre, ce que nous allons voir dans les sections suivantes: “The only path to a culture of continuous improvement is to create an environment where learning new skills and getting better at what we do is considered valuable in its own right and is supported by management and leadership, thus reducing learning anxiety
L’adoption des pratiques de développement et déploiement continu est un challenge interne, pour les collaborateurs de l’entreprise, qui relève de l’émergence. Je vous recommande de lire l’argumentWhy You Cannot Simply Hire or Acquire Your Way to Innovation”.  Un des corolaires est qu’il ne s’agit pas d’un problème de talents qu’il faudrait trouver à l’extérieur: The “talent shortage” problem is solved by creating an environment in which people can learn on the job, and hiring people with a growth mindset.” Les auteurs citent Carol Dweck: “We should not hire people solely on the basis of the skills they already possess. This is particularly short-sighted in the software industry”. Parmi les exemples illustratifs, j’ai beaucoup apprécié l’histoire de Martha Lane-Fox, qui a travaillé en 2010 avec le gouvernement anglais sur la numérisation des services publics. Ses préconisations ne sont pas sans rappeler le travail d’Henri Verdier à EtaLab (lien), avec une stratégie “open data” rendue visible par l’exposition d’APIs. Le résumé de cette approche est une excellente méthode de conduite de la transformation numérique : “First, starting small with a cross-functional team and gradually growing the capability of the product, while delivering value iteratively and incrementally, is an extremely effective way to mitigate the risks of replacing high-visibility systems, while simultaneously growing a high-performance culture.

2.6  Une organisation en équipes autonomes, alignées sur un même objectif, défini du point de vue du client


Une partie importante du livre fait la liaison entre le mode de fabrication des innovations, autour du Lean Startup, le mode de production numérique, selon les principes de DevOps et du déploiement continu et le mode d’organisation de l’entreprise. Sans surprise, on y retrouve des thèmes de l’Entreprise 3.0 et des références citées dans ce blog, comme par exemple l’holacracie et l’effectuation. Le premier sujet est l’importance du « purpose », du but de l’enpreprise en tant que fédérateur du système complexe qu’elle représente : « Creating, updating, and communicating the company’s purpose is the responsibility of the enterprise’s executives”. Un chapitre très intéressant propose une revisite de l’histoire des organisations militaires et de l’émergence du  “Mission Command: an alternative to Control and Command”. Ce mode d’organisation s’appuie sur des équipes autonomes et des ordres dans lesquels le pourquoi remplace le comment : « The higher the level of command, the shorter and more general the orders should be. The next level down should add whatever further specification it feels to be necessary, and the details of execution are left to verbal instructions or perhaps a word of command. … Crucially, orders always include a passage which describes their intent, communicating the purpose of the orders”. Les auteurs remarquent que cette organization remplace le conrôle-commande classique et ne peut pas co-exister. Le développement sur la nécessité de travailler en équipe autonomes et cross-fonctionnelles ne surprendra personne, c’est le coeur des methods incrémentales comme Lean Startup ou DevOps: “Finally, taking a scientific approach to customer and product development requires intensive collaboration between product, design, and technical people throughout the lifecycle of every product. This is a big cultural change for many enterprises where technical staff do not generally contribute to the overall design process”. Je vous laisse lire et découvrir les nombreuses critiques faites sur les entreprises d’aujourd’hui dont le fonctionnement est resté séquentiel et Taylorisé : “Organizations using the phase-gate paradigm (described in Figure III-1 at the beginning of Part III) will find the principles described in the following chapters increasingly hard to implement without fundamentally changing their organizational structure.” Le ton général n’est pas sans rappeler celui de “The Lean Enterprise” que j’avais commenté dans un billet precedent. Il y a également beaucoup de références systèmiques – avec un lien évident à faire avec le livre de Jurgen Appelo – ce qui conduit à tisser les liens entre Lean Startup, DevOps et Lean au sens de TPS et du Toyota Way. J’y reviendrai à la fin de ce billet mais voici deux citations qui donnent une bonne idée de la proximité avec les thèses de ce blog : « Slack is also essential to provide time for process improvement work. Since 20th-century Taylorist theories of management emphasize maximizing employee utilization, this requires a significant change in thinking for many organizations”, qui conduit un peu plus loin à: “ High utilization means work involving collaboration takes longer to complete, because the people you need to work with are always busy with other priorities” – on pense ici à la citation d’Yves Morieux : “coopérer, c’est mettre ses marges de manoeuvre au services des autres”.
J’en profite ici pour indiquer que, si je suis à 95% aligné sur le contenu de cet ouvrage, il y a quelques sujets qui me font prendre un peu de distance – même et surtout s’ils sont également parmi mes sujets d’intérêt. Par exemples il y a quelques références à la théorie des jeux et à la simulation de type Monte-Carlo que je trouve rapides, voire simplistes. De même il y a quelques pages qui expliquent qu’on peut piloter un backlog de façon scientifique grâce au « Cost of Delay », ce qui est un peu facile et contradiction avec l’hypothèse d’incertitude et d’aléas.


2.7   L’importance fondamentale de la motivation intrinséque face à la complexité


Ce point nourrit le paragraphe précédent, mais l’importance que les auteurs lui accordent mérite que je le souligne: « Decades of research have shown that these intrinsic motivators produce the highest performance in tasks which require creativity and trial-and-error — where the desired outcome cannot be achieved simply by following a rule”. On aura reconnu bien sûr la pensée de Daniel Pink, qui est abondament cité dans ce livre : « As Dan Pink argues in Drive,2 there are three key elements to consider when building an engaged and highly motivated team … 1. Autonomy — the desire to direct our own lives. 2. Mastery — the urge to get better and better at something that matters. 3. Purpose — the yearning to do what we do in the service of something larger than ourselve.” La seconde dimension – mastery – est fondamentalement liée à l’apprentissage permanent, que nous avons déjà évoqué comme facteur de succès. Une organisation de développement et de déploiement continu est un processus auto-apprenant. On trouve dans le livre également de nombreuses références à la différence entre « Single-Loop Learning and Double-Loop Learning” pour reprendre les concepts de Chris Argyris. Pour faire simple, l’apprentissage en boucle simple permet d’apprendre à corriger une situation désagreable, tandis que l’apprentissage en double boucle permet d’apprendre à éviter que la situation ne se reproduise : « Double-loop learning occurs when error is detected and corrected in ways that involve the modification of an organization’s underlying norms, policies and objectives ». Pour illustrer cet différence dans le monde du lean, le Kaizen a pour effet (simple boucle) de résoudre un problème, mais surtout (seconde boucle) de créer la collaboration d’équipe – la compréhension des points de vue – qui permet de se débarrasser des causes profondes de ce problème.  Et comme cela est connu depuis des décennies dans le monde du lean manufacturing, « Running experiments is hard and requires great discipline. Coming up with good experiments requires ingenuity and thought. By nature, people tend to jump straight to solutions instead of first agreeing on measurable target objectives”.

2.8 On ne peut pas innover sans gérer des échelles de temps multiples


La vision systémique se développe en accordant beaucoup d’importance aux échelles de temps et à l’équilibre nécessaires entre les différents horizons, en particulier long et court-terme : « Ensure people are rewarded for favoring a long-view system-level perspective over pursuing short-term functional goals ». Il est fait dans le livre de multiples références à Geoffrey Moore, qu’il s’agissent du célèbre best-seller « Dealing with Darwin » de 2006 ou du livre plus récent « Escape Velocity : Free Your Company’s Future from the Pull of the Past ». Les auteurs empruntent à ce deuxième livre une décomposition en trois horizons : « horizon1 », celui du court-terme (0 à 12 mois), de l’atteinte des résultats opérationnels, « horizon 2 », de 12 à 36 mois, celui de la croissance, de la construction de ce qui permet cette croissance ou de l’élimination de ce qui la bloque, et « horizon 3 », de 36 à 72 mois, le temps de l’exploration des options, pour déterminer ce qui sera construit en horizon 2. On reconnait la pensée de Geoffrey Moore lorsque les auteurs écrivent : « Too many enterprises kill innovation by trying to manage horizon 2 and 3 investments using the strategies of horizon 1”.  Cette stratégie multi-échelle est fondamentale pour préparer ses capacités (capabilities), y compris celle de réagir rapidement en « horizon 1 ». Rappelons-nous de la citation de Pasteur : « le hasard ne sourit qu’aux esprits bien préparés ». La sérendipité (sur l’horizon 1) se prépare pendant les horizons 2 et 3, pour construire le potentiel de situation dont parle Francois Julien. Il y a une vraie synergie entre ce que peut faire une équipe agile en temps court et ce que l’entreprise a assemblé en termes de potentiel sur le temps long : « : Autonomous teams will make little difference to customer outcomes if the enterprise architecture prevents teams from running experiments and responding quickly to customer needs ». Ce jardinage du potentiel, pour suivre la métaphore de François Julien, est en pleins et en creux : en ajout de capacités et en réduction de la dette technique, en simplification de la complexité : « The moment a product (if we are in Horizon 3) or feature (in Horizon 2) goes from being an experiment to validated, we need to start aggressively paying down technical debt”.


2.9   Se concentrer sur les l’impact (outcome) et pas sur la production (output)


Cette idée, «Define, measure, and manage outcomes rather than output”,  développée par Marty Cagan dans son exposé à l’USI se retrouve également dans de nombreuses pages de ce livre. La principale différence est qu’il n’y a pas de chaîne causale simple entre nos actions et les outcomes, alors qu’elles existent pour les outputs. Le mode de management, et le mode de contrôle est forcément différent (cf. le point 2.6). Les auteurs développent l’argument que le mode traditionnel de contrôle commande hiérarchique est contre-productif pour gérer les outcomes. Accepter, pour un membre de l’équipe cross-fonctionnelle, d’endosser la responsabilité d’un outcome auquel il participe mais qui le dépasse, exige une culture différente des indicateurs de performance. Lorsque ce n’est pas la cas, « dysfunctional behavior is ubiquitous and systemic, not because people are wicked, but because the requirement to serve the hierarchy competes with the requirement to serve customers…people’s ingenuity is engaged in survival, not improvement”.  Il ne s’agit nullement d’une reduction des exigences, bien au contraire: « Remember, metrics are meant to hurt — not to make us feel like we are winning”. Mais ces metriques servent à guider et valider l’apprentissage, pas à évaluer de façon directe la performance de l’équipe. On retrouve la discussion sur les métriques de développement agile que j’avais commencé dans le billet précédent (dernière section) : « Managers should never attempt to compare velocities of different teams or aggregate estimates across teams. Unfortunately, we have seen team velocity used as a measure to compare productivity between teams, a task for which it is neither designed nor suited.”

2.10  L’heritage de Taichi Ohno dans toutes ces approches


Pour conclure, je voudrai souligner le nombre élevé de références à TPS (Toyota Production System) et Taiichi Ohno. TPS est pris comme un système de management qui dépasse le Taylorisme : « The way the TPS works is in sharp contrast to the traditional US and European management practice based on the principles of Frederick Winslow Taylor, the creator of scientific management”. Les caractérisques principales sont le travail en équipe – avec des témoignages très intéressants issu du déploiement de TPS aux US dans le cadre de NUMMI -, le travail en petit lot – « Uncertainty is an important argument for working in small batches »,  l’amélioration  continue et l’importance stratégique de la formation des femmes et des hommes : « That is what allows an organization to adapt rapidly to its changing environment. Toyota calls this “building people before building cars.””. Je vous recommande la lecture de l’anecdote qui se passe au début de l’histoire de Toyota, lorsqu’ils fabriquent des métiers à tisser. Un concurrent vient de voler le design du produit courant, et la réaction du CEO est d’expliquer que non seulement dans une course continue à l’amélioration, le temps qu’il faudra au concurrent pour implémenter le design qu’il vient de voler fait qu’ils seront en retard sur le prochain produit de Toyota, mais que surtout ce qui est important ce n’est pas l’ensemble des choix contenus dans un design, mais l’accumulation de la connaissance – dans la tête des collaborateurs – qui ont conduit à faire ces choix à un instant donné mais qui pourront conduire à d’autre choix dans un contexte différent. Cet argument est lumineux et encore plus pertinent dans le monde numérique. Conduire une transformation digitale, c’est créer des bases de connaissances incarnées sous formes d’équipes.
Parmi les autres emprunts à la culture lean, on retrouvre sans surprise l’utilisation du Kanban : « In the context of product development, the Kanban Method provides principles and practices to support this goal, as described in David J. Anderson’s Kanban: Successful Evolutionary Change for your Technology Business…. The Kanban Method offers a comprehensive way to manage the flow of work through the product development value stream” qui permet entre autres de limiter le “Work in Process”.  On trouve également la mise en valeur du “genchi genbutsu”: « At Toyota, genchi genbutsu (“go and see”) allows leaders to identify existing safety hazards, observe machinery and equipment conditions, ask about the practiced standards to gain knowledge about the work status, and build relationships with employees”. Et pour finir, sans surprises, on trouve en bonne place le livre « Toyota Kata » de Mike Rother – que j’ai mentionné brièvement sans prendre le temps de le résumer : « The Improvement Kata, as described by Mike Rother, is a general-purpose framework and a set of practice routines for reaching goals where the path to the goal is uncertain ... Teams that use flow-based methods such as the Kanban Method (for which see Chapter 7) and continuous delivery (described in Chapter 8) can create Improvement Kata iterations at the program level”. Le concept des « improvement Kata » a eu une forte influence dans le développement de la Lean Software Factory à Bouygues Telecom, pour changer la culture et les comportements au travers de pratiques qui deviennent des rituels (cf. 2e Partie de l’exposé au Lean IT Summit). Une idée qui n’est pas neuve puisque Aristote nous disait déjà : « Nous sommes ce que nous faisons de façon répétée. L’excellence n’est donc pas une action, mais une habitude ».



jeudi, juin 30, 2016

Lean et Agile d'un point de vue métier


Le billet de ce jour est une réflexion personnelle sur les principes et valeurs qui sous-tendent les démarches lean et agile, indépendamment du domaine d’application, qu’il s’agisse de production, de service, de logiciel ou d’innovation. Tout comme le mot « lean » est souvent utilisé à contre-emploi pour désigner des politiques de réduction de coûts qui réduisent également les capacités d’apprentissage et de coopération, le mot « agile » est également mis à toutes les sauces, quelque fois sous forme de véritable contre-sens.
Je vais commencer par un rapide tour d’horizon de l’utilisation du lean dans les processus de ventes (lean sales). Lorsque j’ai écrit mon livre « Processus et Entreprise 2.0 – Innover par le lean et la collaboration » en 2010, j’ai été frappé par les résultats spectaculaires dans d’autres domaines, tels que le « lean healthcare » ou le « lean sales ». Je ne suis pas un spécialiste, donc je ferai juste un bref résumé des idées principales tirées de quelques lectures. Cela me conduira à une deuxième section sur les quelques principes fondamentaux, de mon point de vue, lorsque j’applique le lean au développement logiciel (Lean Software Factory) ou à l’innovation (Lean Startup).
La troisième section portera sur l’agilité, vue d’un point de vue métier. J’ai plusieurs fois raconté la visite de Spotify par l’équipe de direction de Bouygues Telecom il y a quelques années comme un moment pivot dans ma compréhension de l’agilité : le CEO nous a défini l’agilité comme une réaction adaptative à l’environnement, d’un point de vue stratégique. L’agilité informatique devient une conséquence de l’agilité métier, et non pas l’inverse. Je vais de la même façon décrire ma vision personnelle de l’agilité dans la section suivante, du point de vue des objectifs et de ce qu’il convient de mesurer – ou non – pour progresser.
Il y a un lien fort entre les deux parties : tels que je les définis, le lean et l’agile sont compatibles, complémentaires et se renforcent. Ce n’est pas forcément le cas si le lean est pris comme une volonté de contrôle et de réduction (qui se heurte à l’adaptabilité de l’approche agile) ni si l’agile est pris comme une méthode d’ubérisation du travail – dans une vision pseudo-moderne du travail fondée sur les nouvelles technologies de communication – qui se heurte à la dimension fondamentale de l’apprentissage collectif par équipe.

1 -  “Lean Sales”

Je commence par une photo du livre “Lean Thinking” car c’est la référence que l’on trouve dans tous les articles que je vais citer sur “Lean Sales”. Les deux livres de James Womack et Daniel Jones, « Lean Thinking » et « Lean Solutions » sont les premières étapes fondamentales pour comprendre le sujet que je vais évoquer brièvement. Il y a trois très bonnes raisons d’appliquer le lean à la vente : (1) il s’agit bien d’un processus, avec des étapes bien définies et qui est assez facile à mesurer – et cette pratique de la mesure est ancienne dans les équipes de vente (2) c’est un travail d’équipe – c’est plus ou moins visible selon l’activité et la forme de relation entre le client et le vendeur, mais c’est toujours le cas (3) la satisfaction du client est, par essence, au cœur du processus de vente – cela ne veut pas dire que ce soit l’objectif du processus, loin s’en faut ! Mais une grande partie des fondamentaux du lean – le centrage sur la valeur apportée au client – est depuis longtemps ce qui caractérise les « bons vendeurs » sur le long terme. Je ne vais pas donner les détails d’une approche lean sales, je vous renvoie par exemple au slideshare de David Brunt et John Kiff, mais souligner sept idées intéressantes de l’approche Lean Sales :
  • La première idée essentielle du lean est de se centrer sur la valeur fournie au client par le processus de vente. Il s’agit donc – sans surprise – de se mettre à la place du client. L’approche du « Value Stream Mapping » s’applique parfaitement au processus de vente (voir par exemple la formalisation dans l’article de Simon Elias et Richard Harrison). L’analyse passe bien sûr par l’écoute et l’observation des clients, avec des projets de type « Voice of the Customer (VoC) », un des classiques des approches Lean Six Sigma.
  • Une fois la valeur définie du point de vue du client, l’approche lean cherche à optimiser le processus en supprimant tout ce qui est inutile – le  « muda », en notant que gaspillage est une mauvaise traduction. En particulier, le lean s’intéresse à la suppression des temps morts (ceux qui n’apportent pas de valeur client), ce qui est remarquablement en ligne avec l’impératif du 21e siècle de traiter le temps du client comme la chose la plus précieuse.  Pour faire cette optimisation, le lean apporte tout un ensemble de techniques et de méthodes, depuis le kaizen sur lequel je vais revenir jusqu’à l’analyse des causes profondes avec la pratique des « Five Whys ». Je vous recommande le billet de Mark Preston, « My Top 10 Secrets of Lean Manufacturing Sales ».
  • Cet allègement du processus permet progressivement d’appliquer un autre principe lean, le « streamlining », ou l’optimisation du flot. Au-delà de la suppression du « muda », on cherche également la réduction de « mura » et « muri », c’est-à-dire la stabilisation du flot  -atténuer les irrégularités - et éviter les périodes de surcharge. Ici le lean sales se démarque d’un certain nombre de pratiques de ventes qui sont marquées par des fortes irrégularités amplifiées par le calendrier de l’entreprise (le « closing » de fin de période n’est pas une approche centrée sur le client). Ce sujet est abordé dans l’article de Brian Maskell, « Lean Sales & Marketing ». 
  • Une fois le processus « réorganisé par streamlining », on inverse la logique de déclenchement et on passe du « push » au « pull ». Autrement dit, les signaux pour passer d’une étape à une autre ne sont plus produits par la complétion d’une étape (vers la suivante), mais c’est le besoin d’une étape qui déclenche l’étape précédente. De la sorte la vie du processus n’est plus rythmée par la capacité de production, mais par la demande client, en tenant compte des capacités propres à chaque étape (à travers un kanban). C’est, à mon avis, une des raisons principales pour laquelle le Lean Sales va devenir de plus en plus populaire au 21e siècle, en particulier dans le monde digital. Je vous renvoie aux différents articles de ce blog sur « The Intention Economy » ou sur « Le Marketing Synchronisé ». Nous sommes entrés dans l’ère du « pull », lorsque l’entreprise écoute les besoins et les moments du client, et avons quitté – pour les entreprises avancées – l’ère du push publicitaire de masse.
  • Toutes ces étapes précédentes – ce qui constitue le lean sales - s’appuient sur une approche d’optimisation continue, fondée sur la mesure. Les mesures sont collectées et partagées de façon continue par les équipes, en utilisant des approches de management visuel.  Le travail d’amélioration est fait en pratiquant le kaizen, en équipe. Les chiffres sont ceux de l’équipe, ils servent à comprendre et améliorer les techniques de ventes. Il ne s’agit pas de supprimer les « objectifs de vente » qui sont consubstantiels à la profession, mais de comprendre que le « standard » appartient à l’équipe et qu’une partie des indicateurs ne sont pas de KPI, mais des outils de progrès  (je reviendrai sur ce point clé dans la Section 4).
  • Le lean est ancré dans une approche du management de la qualité totale, parce que Taiichi Ohno a été influencé par W.E. Deming. L’objectif d’un processus lean est d’être « Right on the first time, every time ». Cet objectif, lié au premier sujet de la satisfaction du client, alimente de façon constante le kaizen. Une fois de plus, il faut souligner l’importance du temps du client, qu’il faut donc mesurer pendant les différentes étapes du processus. Comme dans la plupart des sujets d’optimisation de processus de service, le temps d’attente est une des premières causes d’insatisfaction des clients ou prospects.
  • La dernière idée commune aux articles que je viens de citer – souvent exprimée dans leurs titres – est qu’il faut traiter l’ensemble du processus « Marketing & Vente » dans une démarche unifiée.  Pour travailler efficacement en kaizen, il faut que les différents acteurs du processus commun soient organisés en équipe. Je vous renvoie à l’article de Brian Haskell sur l’importance du kaizen et du travail d’équipe.   



2.                  Les fondations du « Lean Thinking » 




Je vais poursuivre cet exercice d’abstraction en soulignant 5 principes que l’on vient de voir dans la section précédente et qui sont commune aux démarches « lean software » et « lean startup ». Ce sont également des principes que j’applique dans le self lean et que j’ai retrouvé avec plaisir dans l’excellent livre « Personal Kanban » que je viens de terminer et que je vous recommande. A ce niveau de synthèse, il s’agit forcément d’un exercice très subjectif et très incomplet.


  • La satisfaction du client/utilisateur est le « true north » d’une démarche lean, c’est le but commun à toutes les équipes et le terrain d’entente pour arbitrer les différences d’opinion. Cette satisfaction se mesure – qualitativement et quantitativement – et la mesure est partagée par tous les acteurs.
  • L’organisation a pour objectif de fluidifier le processus, en relaxant les contraintes de ressources, en fragmentant la charge (les « petits lots »), réduisant les enchaînements pour avoir un fonctionnement le plus continu possible.
  • L’approche « pull », dirigée par la demande client, donne le tempo commun à l’ensemble de l’organisation. Le mode « pull », matérialisé par le kanban, suppose une simplification et une fluidification du processus, c’est un objectif de long terme. L’objectif systémique de cette approche est la résistance aux aléas, qui permet justement de s’adapter à son environnement.
  • Le fonctionnement fluide en flux tirés, tout comme la satisfaction totale du client, est un objectif asymptotique qui s’approche par amélioration continue, grâce au travail de kaizen d’équipes autonomes. Les équipes progressent et capitalisent grâce à une standardisation de leurs pratiques, mais c’est leur standard. Le kaizen est un outil pour apprendre à travailler ensemble via la résolution de problèmes.
  • Le lean est, en effet, une méthode pour l’apprentissage collectif de la complexité. C’est pour cela qu’il repose sur le management visuel, sur l’inspection en équipe de la réalité et qu’il se méfie de l’abstraction (cf. le genchi gembutsu). La pratique continue des 5 pourquoi (la recherche des causes profondes) est également une méthode de formation pratique à la systémique de l’environnement.


Tout ceci reste encore un peu long et compliqué :) Je vous propose ma vision globale comme résumé – et clin d’œil -  de l’ensemble de ce blog en trois points :

  • Le sujet clé des entreprises au 21e siècle est le conflit entre engagement et complexité. L’accroissement de la complexité est inexorable - car il vient de l’environnement - et produit du désengagement (remarquablement expliqué par Yves Morieux, mais globalement un fait incontestable).
  • La seule façon de retrouver de l’engagement est de favoriser la motivation intrinsèque, autour du triplet : autonomy / mastery /purpose (emprunté à Daniel Pink, mais également un résultat avéré)
  • Le lean est fondamentalement adapté au 21e siècle car il répond à ces trois besoins : le besoin de sens vient de la satisfaction client partagée avec tous les acteurs, le besoin de « mastery » (difficile à traduire, un mélange de maîtrise, de confiance en soi et de sentiment de progression) est obtenue par la pratique du kaizen, et enfin l’autonomie des équipes est valorisée par la priorité au terrain (gemba) et aux faits (mesures) sur le contrôle externe.

https://lh4.googleusercontent.com/-mnE-WpoSdq5cIxJM4_5v1t6Q0yqp-M4IO5kja3dP0M1OXZN2OPzGHzeFHEdB-C41fdhWRZQ-_dO3rmEoBor3PK3obRgIkJjZhqINYJNDwM-K5hTOgLxWv_QaiHDWCsVqKMfEr5O




3.                  Manifeste Agile et Contre-Manifeste Agile

     

Pour comprendre ce qu’est l’agilité, en tant que mode d’organisation, il faut remonter aux sources, c’est-à-dire au « agile manifesto » et son apparition dans le monde du logiciel il y a une vingtaine d’années. Le mouvement agile est une réaction systémique à l’inefficacité des projets informatiques confrontés à une complexité croissante, en particulier à cause du rôle de plus en plus important de l’utilisateur. Le mouvement agile prône quatre valeurs. La première est que dans un contexte complexe et changeant, les hommes et les femmes sont plus importants que les processus et les outils (« individuals over tools »).  Pour moi qui pratique l’informatique depuis longtemps, ce changement depuis l’unité d’œuvre banalisé (le jour-homme de développement) à la reconnaissance du talent est un changement majeur, indissociable du fonctionnement agile. La seconde valeur affirme la primauté de ce que l’on construit sur sa description (« working software over documentation »). Dans un monde complexe, il est souvent plus facile de faire que décrire; dans un monde changeant, la description est au service de la réalisation (pour la capitalisation, le partage, la maintenance, etc .) mais elle ne précède pas cette réalisation. La troisième valeur dit qu’il faut préférer la collaboration avec le client (« customer collaboration over contract »). Dans le contexte du manifeste agile, on parle du client « interne », mais ceci s’étend facilement au client utilisateur). La dernière valeur est celle qui justifie le terme d’agilité : il faut accueillir les changements à bras ouverts au lieu de vouloir suivre un plan fixé à l’avance (« responding to change over following a plan »).  L’objectif de l’organisation agile est de pouvoir répondre efficacement à ces changements pour s’adapter de façon continue à l’environnement, externe et interne.  Les changements continus du monde externe entrainent qu’il faut réviser de façon fréquente ce qu’on produit. Les changements internes viennent de la complexité de ce qu’on cherche à fabriquer (des expériences qui satisfont totalement l’utilisateur), et il convient par conséquent de s’adapter aux difficultés rencontrées. Pour cela, le manifeste agile (dans une version française empruntée ici) propose douze principes du fonctionnement agile :

  1. Satisfaire le client est la priorité
  2. Accueillir les demandes de changement « à bras ouverts »
  3. Livrer le plus souvent possible des versions opérationnelles de l’application
  4. Assurer une coopération permanente entre Client et Equipe projet
  5. Construire des projets autour d’individus motivés
  6. Privilégier la conversation en face à face
  7. Mesurer l’avancement du projet en termes de fonctionnalités de l’application
  8. Faire avancer le projet à un rythme soutenable et constant
  9. Porter une attention continue à l’excellence technique et à la conception
  10. Favoriser la simplicité
  11. Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.
  12. Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus efficace


Je ne m’intéresserai pas aujourd’hui à l’agilité dans le développement logiciel. Une grande partie de ces principes sont plus profonds et plus large que le simple domaine du développement logiciel. Comme je l’ai dit en introduction, la démarche agile est une adaptation systémique de l’organisation de l’entreprise à son environnement. Le point de départ de l’argument du CEO de Spotify  est que les technologies – compression audio, stockage, recommandation – changent à une vitesse élevée qui augmente constamment, mais surtout que les usages changent constamment. En particulier l’adoption de pratiques ou de nouveaux comportements numériques suit des lois sociologiques de réseaux, avec des phénomènes d’amplification non linéaires qui sont la signature des succès du monde numérique. Le succès de Spotify vient de sa capacité à « lire son environnement » de façon continue et à s’y adapter de façon constante, au moyen d’une organisation agile.  Je ne m’étends pas d’avantage sur la dimension systémique, je vous renvoie au livre de Jurgen Appelo « Management 3.0 - Leading Agile Developers, Developing Agile Leaders »  qui explique cela en détail. L’agilité est une méthode pour d’adapter à un besoin instable (soumis à des changements) et incertain (à cause de la complexité de l’environnement, il suffit de relire Taleb ).
Dans l’esprit de la section précédente, voici les cinq principes qui caractérisent, selon moi, un fonctionnement agile :

  • La satisfaction du client est le fondement d’une démarche de développement produit (Principe 1). Ce pilier est partagé avec le lean, c’est l’outil principal d’alignement d’équipes autonomes
  • Ceux qui construisent (un produit, un service, une expérience) doivent être responsable du processus de construction. C’est la conséquence de la complexité : l’expérience ne se délègue pas (d’où l’insistance sur le « gemba » dans le lean). Dans le monde logiciel, l’équipe de développement maîtrise son calendrier, même si le « quoi » est confié au « product owner » (Principe 4).
  • La communication personnelle, face à face, est le ciment de la méthode agile (Principe 6). D’une part, parce que les sujets sont complexes et que la formalisation écrite est coûteuse et imparfaite ; d’autre part, parce que la dimension corporelle de la communication est indispensable à la véritable synchronisation.
  • Les rituels d’équipes utilisent les tableaux et les murs pour favoriser la communication. Le maximum de chose est affiché, en utilisant la puissance du management visuel comme « radiateur d’information ».  Ce partage et autocontrôle de l’équipe assure le bon rythme de travail (Principe 8).
  • Les défis complexes requièrent des équipes cross-fonctionnelles qui travaillent ensemble, de façon synchronisée et itérative (Principe 11).


J’ai déjà évoqué dans ce blog différents travaux sur le futur du travail. Certains travaux du MIT ou de Digiwork décrivent un mode de travail éclaté sur des plateformes technologiques, de type Uber. Je vais ici caricaturer quelque peu, mais voici ce que le « travail de demain » pourrait proposer comme nouveau manifeste :
  • « Nous n’avons plus besoin de rencontres face à face, les outils de communication électroniques nous suffisent »
  • « les espaces physiques ne sont plus nécessaires, nous sommes des travailleurs nomades capables de travailler n’importe où »
  • « Nous n’avons pas besoin d’organisateurs, il nous suffit d’une plateforme électronique pour décomposer nos projets en tâches bien précises » (note : on hésite entre le triomphe d’Uber ou de Taylor)
  • « Nous avons aboli la contrainte du temps partagé, chacun travaille quand il veut, d’où il veut, selon son biorythme et en fonction de ses contraintes personnelles »
  • Nous exigeons une définition précise des rôles de chacun qui nous permet de digitaliser la collaboration – chacun de nous est un expert

Je ne vais pas répéter les arguments de mon billet précédent, mais il est facile de voir que cette approche constitue, pour moi, un manifeste anti-agile. Je recommande également la lecture de « How Google Works » de et Eric Schmidt et Jonathan Rosenberg.


4.                  Les fondations du “Agile Thinking”


Pour terminer, je vais essayer de répondre brièvement à la question : comment savoir et mesurer si on travaille de façon agile ? Appliquer des principes n’est clairement pas un objectif en soi. Le but de la démarche agile est de mieux travailler dans un environnement  complexe et incertain. Dans le cas contraire, lorsque les besoins sont clairs et stables, les méthodes  classiques et taylorisées (cycle en V par exemple) restent redoutablement efficaces. Mesurer la valeur produite par le développement logiciel a toujours été difficile, mais mesurer l’impact des aléas et de la complexité l’est encore plus. Définir une mesure de la valeur apportée par l’agilité n’est donc pas une chose simple, et cette démarche relève le plus souvent d’une démarche de conviction.

La première idée fondamentale est de bien traiter l’organisation agile comme un système, en incluant la demande (les équipes « métier »). Il reste encore des entreprises qui demandent à leur IT de « devenir agile » sans changer l’ensemble de l’organisation en général, et sans changer la gestion de la demande en particulier. Les résultats sont piètres (très faibles progrès en vélocité et flexibilité) lorsqu’ils ne sont pas inexistants (souvent les coûts augmentent pour une satisfaction client qui n’augmente pas). D’une part c’est l’ensemble métier + développement qui peut former un système véritablement agile qui s’adapter au changement, mais de plus une équipe de développement agile qui exécute dans le cadre classique de spécifications contractuelles part avec un gros handicap.

La deuxième idée que je retiens de mon expérience est qu’il est plus facile de caractériser la non-agilité que l’agilité. J’ai participé à plusieurs audits et évaluation des pratiques agiles, ce que les experts recherchent sont trois défauts qu’il est possible d’identifier et qui montre la faible adaptabilité au changement constant de la demande et à sa complexité : (a) le « rework », c’est-à-dire le nombre de fois ou le même fragment de code est repris/ re-codé, parce que la spécification n’est pas conforme au besoin, (b) le temps de déploiement trop long par rapport aux besoins du marché, malgré tous les efforts de priorisation  (c) le code non déployé, qui est un cas limite des deux précédents, et un bon indicateur de dysfonctionnement. Le code non-déployé est à la fois un gâchis de ressource et une véritable plaie pour le moral et l’engagement des équipes. C’est pourtant un problème fréquent des grandes organisations.


Mesurer l’efficacité d’une démarche agile peut se faire de façon globale – extrinsèque par rapport au processus de développement -, à partir de l’analyse de la valeur, ou de façon intrinsèque, en mesurant « le bon fonctionnement ». La mesure de la valeur est possible, mais c’est un sujet difficile que j’ai traité dans mon second livre et que je ne vais pas aborder ici. Ce n’est pas par simple paresse ou manque de temps, je pense que la complexité des métiers du 21e siècle rend l’analyse très complexe et demande une maturité difficilement atteignable. La valeur créée se mesure fort bien, mais elle s’analyse et se prédit difficilement, ce qui en fait un mauvais critère d’efficacité. Je préfère une approche plus globale centrée sur la satisfaction du client, dont la création de valeur – au sens financier du terme – devient un bénéfice collatéral et essentiel, mais pas l’outil de pilotage. Je n’ai pas le temps ici de développer d’avantage. Je vous renvoie à la lecture de « Joy Inc. – How we built a workplace people love » de Richard Sheridan pour comprendre l’intrication entre la méthode de travail agile et la création de valeur du point de vue métier.  La mesure de l’efficacité intrinsèque peut se faire au moyen des trois indicateurs évoqués plus haut :  la quantité de « rework » (j’ai découvert cette approche lors de mon premier audit en tant que DSI par CSC il y a 10 ans), la quantité de code non livré (qui est facile à mesurer lorsqu’on se place dans une approche de développement industriel de type « software factory »), et le TTM –time to market/to delivery, que l’on mesure comme le temps entre la rédaction d’une « user story » et le moment où cette expérience est livrée entre les mains des utilisateurs. Le TTM/TTD est fortement lié au cadencement du déploiement, c’est-à-dire le rythme des mises en production (le « takt time » du lean). La démarche DevOps vers le déploiement continu représente une transformation globale, de grande ampleur, de la chaine de développement.

La mesure de l’efficacité, lorsqu’on est en présence d’un système complexe – non-linéaire- de création de valeur est pleine de piège. Par exemple, il est judicieux de mesurer la rapidité sous forme de TTM d’une modification élémentaire. L’expression classique est le « temps qu’il faut pour déployer une modification de 10 lignes de code ». En revanche, la mesure de la vélocité (ratio du nombre de « user story » / « points »  par unité de temps) a rapidement un effet pervers, puisque la méthode agile repose sur l’auto-évaluation du poids des tâches par l’équipe elle-même pour obtenir un fonctionnement lissé (selon les principes lean évoqués plus haut). Faire de la vélocité un KPI (Key Performance Indicator) conduit à une dérive des estimations. La vélocité est un indicateur de fonctionnement, très utile à l’équipe pour évaluer ses propres axes de progrès. Je vous renvoie au chapitre deux de mon dernier livre sur la différence entre les KPI (qui sont globaux, compris de tous, et dont la recherche de l’amélioration est vertueuse par définition – comme par exemple la satisfaction client) avec les indicateurs de performance et de fonctionnement, qui permettent à une équipe de mieux évaluer son fonctionnement ou son efficacité, dans un contexte global où il convient de trouver un équilibre entre des indicateurs contradictoires (comme le célèbre compromis coût / délai). Pour prendre un autre exemple, le « rework » n’est pas un KPI : s’il est rendu trop visible, le rework disparait … il est trop facile de le maquiller. Pour qu’une équipe (globale, c’est-à-dire métier et IT) évite le rework, il faut en faire un indicateur « local » (dans l’esprit de la célèbre citation de Deming qui nous dit qu’il faut chérir ses erreurs pour progresser). Les « candidats KPI » sont de mon point de vue: la satisfaction client/utilisateur, la qualité (défauts par « user story »), le TTD et le temps moyen de déploiement des « user stories » validées. Ce dernier KPI a trois bénéfices : il évite le code jamais livré, il soutient la démarche DevOps vers le « continuous delivery » et il pousse les équipes à construire des « user stories » de taille modérée (dans l’esprit lean des « small batches »). En revanche, le « taux de rework », la vélocité, le taux d’automatisation des tests, le rythme des sprints sont des indicateurs internes qui sont plus utiles s’ils sont laissés au contrôle des équipes de façon autonome. Dans ces cas, l’objectif premier est la recherche du « mastery » - une tâche qui est confiée aux équipes et aux kaizen – et l’amélioration de la performance est une conséquence. Pour citer Francois Jullien une fois de plus : « ce n’est pas en tirant sur la tige qu’on fait pousser la plante plus vite ». Ceci me conduit pour terminer à vous proposer de prolonger la réflexion sur la mesure par la lecture de l’excellente édition n°19  de la revue de Kea Partners.