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
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 Andreessen. 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”.
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’argument “Why 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 ».
tombée sur votre article par hasard et ravie de la synthèse intelligente. Pleins de pépites concentrées pour mon chantier de transformation. Merci !
RépondreSupprimerMerci pour cet article et cette analyse globale !
RépondreSupprimermerci pour ces feedbacks :) il reste beaucoup de choses à creuser, ce sont plus des pistes que des réflexions abouties, mais je vois un chemin humaniste qui se dessine dans un paysage mouvementé...
RépondreSupprimer