Petit guide de management lean lusage des

quipes agiles
crit par un collectif de dix auteurs
sous la houlette bienveillante de Rgis Medina
Version 1.04 4 septembre 2013
Table des matires
1 Avant-propos 4
2 Inauguration du pont 5
3 Structure du livre 6
4 De Satisfaire le client Comprendre son attente 7
Pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Scne de crime : apparition mystrieuse au cabinet dentaire . . . . . . 10
Scne de crime : vie et mort dune ide gniale . . . . . . . . . . . . . 13
Scne de crime : la catgorie mystre du projet Condor . . . . . . . . . 15
Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 De Management visuel Visualiser le challenge et les prob-
lmes 25
Les pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Scne de crime : trouvez lindic ! . . . . . . . . . . . . . . . . . . . . . 30
Scne de crime : tous coupables . . . . . . . . . . . . . . . . . . . . . . 35
Scne de crime : le burdown tait rouge . . . . . . . . . . . . . . . . . 40
Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
1
6 De Lamlioration continue Trouver les leviers de lamliora-
tion 55
Les pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Scne de crime : la mise en production qui ne devait pas chouer . . . 58
Scne de crime : du ri dans mes sprints . . . . . . . . . . . . . . . . 63
Scne de crime : joue-la courte et prcise . . . . . . . . . . . . . . . . . 66
Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7 Conclusion 78
8 Livres de rfrence 79
Le management lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
La pratique du lean management dans lIT . . . . . . . . . . . . . . . 79
9 Ressources de rfrence 81
Cette uvre est mise disposition selon les termes de la Licence Creative
Commons Attribution - Pas dUtilisation Commerciale - Pas de Modication 3.0
non transpos.
2
Les auteurs web twitter
Philippe Blayo www.barreverte.fr @pblayo
Antoine Contal @antoine_contal
Dominique De Premorel @domidepremorel
Pierre Jannez @pierrejannez
Christophe Keromen www.ckti.com @ckeromen
Rgis Medina www.regismedina.com @regis_medina
Sandrine Olivencia www.leanedge.org @sandrineolivenc
Christophe Ordano @chrisordano
Raphal Pierquin ut7.fr @perafoo
Bruno Thomas www.barreverte.fr @bam_thomas
3
Chapitre 1
Avant-propos
Les pratiques prsentes dans ce guide ouvrent la voie vers une vision dirente
de lorganisation. Une vision base sur une conviction :
Le changement vers une organisation la fois plus ecace et plus
respectueuse des personnes est possible. Ce changement nat de la
somme des apprentissages individuels.
Lamlioration continue, en dnitive, est celle des comptences de
chaque collaborateur. Lapprentissage devient indissociable du travail,
et le qui doit faire quoi pour russir devient qui doit apprendre
faire quoi pour russir .
Cette transformation radicale se construit jour aprs jour, personne
par personne, en allant sur le terrain pour aider chaque collaborateur
russir sa journe. Cela amne chacun crer plus de valeur pour
ses clients, son entreprise et la socit, et trouver ainsi un sens son
travail.
Le chemin vers cet idal a t trac par nos prdcesseurs pendant plusieurs
dcennies, et consign sous la forme de principes et de pratiques qui ont pris le
nom de lean .
Ce savoir-faire prcieux nous a t transmis par Marie-Pia Ignace et Michael
Ball. Nous vous le transmettons notre tour, en esprant quil vous apportera
les mmes moments de satisfaction, les incroyables dclics qui vous feront prendre
de la hauteur.
Rgis Medina
4
Chapitre 2
Inauguration du pont
Depuis plusieurs annes, lesprit et les pratiques agiles vous ont permis damliorer
votre satisfaction professionnelle et la performance de vos quipes.
Mais voil : il reste encore des sources de frustrations. Les autres quipes rsistent,
les managers ne sponsorisent pas vos initiatives de changement, les clients se
plaignent. Il doit bien exister des moyens damliorer les choses, mais comment
les trouver ?
En vous entranant aux pratiques lean slectionnes dans ce livre, vous apprendrez
:
trouver les leviers de lamlioration qui amneront vos quipes un autre
niveau de performance ;
- rsoudre les dicults que vous rencontrez dans vos relations avec dautres
quipes ou le management ;
livrer des logiciels qui amliorent la vie de vos utilisateurs et dont vous pouvez
tre ers.
Ces nouvelles comptences vous apporteront le savoir-faire ncessaire pour
insuer les changements vitaux au sein des organisations.
Ce livre se structure autour de trois apprentissages fondamentaux. Pour cha-
cun dentre eux, des praticiens agiles vous racontent comment, en appliquant
dautres pratiques, en adoptant dautres postures, en sentranant fonctionner
diremment, ils ont trouv des solutions simples des problmes qui paraissaient
complexes.
Puis des experts dcrivent les principes lean mis en uvre dans les histoires
prsentes.
Enn, des prconisations de premiers pas vous guident vers la mise en pratique.
Ce livre est n de du dsir de praticiens agiles ayant expriment le management
lean de partager les richesses surprenantes de ce nouveau continent.
Nous souhaitons transmettre ce que nous avons appris lors de notre voyage
initiatique. Notre promesse : a en vaut la peine !
5
Chapitre 3
Structure du livre
Ce guide comprend trois chapitres :
Comprendre lattente du client
Visualiser le challenge et les problmes
Trouver les leviers de lamlioration
Chaque chapitre est organis de la faon suivante :
Une description des pratiques agiles sur le thme abord.
Trois cas rels dquipes agiles ayant intgr le management lean dans leurs
pratiques. Ils dcrivent leur contexte, les exercices quils appliquent, et ce
quils y gagnent. A la n de chaque cas, nous analysons et dveloppons les
principes lean mis en uvre.
Une description des pratiques lean sur le thme du chapitre.
Les premiers pas que nous proposons de mener pour se lancer.
Des rfrences de lecture pour aller plus loin.
Bonne lecture et du succs dans vos exprimentations !
6
Chapitre 4
De Satisfaire le client
Comprendre son attente
Pratiques agiles
Linspiration du manifeste
Le Manifeste agile (http://agilemanifesto.org/) met le client au centre des
proccupations du dveloppement Agile de logiciels. Les signataires insistent
en particulier sur la ncessit de collaborer avec le client pour rpondre son
besoin : La collaboration avec les clients plus que la ngociation contractuelle.
Dans une approche agile, le primtre du produit nest pas g. Lquipe doit
fournir au client toute linformation qui lui permette doptimiser la production de
valeur en fonction de leort fourni. En contrepartie, le client est co-responsable
de latteinte de lobjectif. Il simplique de manire rgulire dans la rednition
du primtre fonctionnel. Scrum prconise ainsi lactivit de Product backlog
grooming tout au long du projet.
Nous retrouvons plusieurs fois mentionn le client dans les douze principes :
Notre plus haute priorit est de satisfaire le client en livrant rapidement et
rgulirement des fonctionnalits grande valeur ajoute.
Les processus Agiles exploitent le changement pour donner un avantage
comptitif au client.
Les utilisateurs ou leurs reprsentants et les dveloppeurs doivent travailler
ensemble quotidiennement tout au long du projet.
Lquipe de ralisation et le client adoptent une posture dapprentissage la fois
du processus et du produit. Postulat de lagilit : le besoin nest pas compltement
identiable en amont de la ralisation et de nombreux changements ultrieurs
imposeront lensemble des acteurs de sadapter en cours de ralisation. Seule
une collaboration troite entre tous les intervenants permettra cet apprentissage.
En agilit, satisfaire le client suppose dabord de se donner la possibilit dex-
primenter, puis de tirer des enseignements du rsultat des expriences an de
7
rednir les prochains lments produire.
Focus produit
La dmarche traditionnelle prsuppose que le besoin du client peut tre captur.
Il est clairement identi, nvoluera plus et fait lobjet de spcications dtailles.
Adoptant une position trs dirente, les agilistes sont obsds par une question :
sommes-nous en train de construire le bon produit ?
Le focus est ainsi dplac du projet vers le produit. Scrum ancre encore davantage
cette importance de lorientation produit en rpartissant les responsabilits
anciennement cones au chef de projet vers un nouveau triumvirat : quipe,
Scrum Master et Product Owner.
Figure 4.1 Le Trimvirat Agile
La mise en pratique quotidienne
Le bon produit ?
Comme nous lavons rappel, lquipe agile sattle en priorit au d de livrer
rapidement et rgulirement des fonctionnalits au client. Cela permet de con-
fronter son attente la ralisation. Ensemble, ils inspectent le travail ralis,
puis dcident des adaptations ncessaires pour se rapprocher de la satisfaction
du besoin.
Itrations et approche empirique
Les quipes agiles adoptent ainsi un processus qui sappuie sur des itrations
courtes (deux quatre semaines en Scrum). Elles mettent en uvre une ap-
8
proche empirique reposant sur une succession rapide et rgulire dessais-erreurs-
corrections.
Spcier en favorisant la communication
Dans lobjectif de pouvoir livrer rapidement, les exigences fonctionnelles sont
dcoupes en petits lments qui permettront une focalisation sur de petits lots
porteurs de valeur.
Pas de spcication dtaille exhaustive en amont, mais une prcision juste
temps (au moment o les fonctions vont tre ralises) sous forme de conversation
entre le reprsentant de lquipe et le client.
Une pratique courante consiste formaliser ces lments sous la forme de User
Stories. Ces histoires utilisateur combinent une concision impose (doit tenir
sur une carte) et la dtermination de tests dacceptation par le client (doit tre
testable).
Comment maximiser la valeur ?
Pour dterminer le contenu fonctionnel de la prochaine itration, lquipe agile
collabore avec le client en vue de maximiser la valeur ajoute au produit. Ensem-
ble, ils tablissent une liste des prochains lments raliser en prcisant lordre
dans lequel ces lments doivent tre produits. Lordre dtermin tient compte
en priorit de la valeur dun lment et de leort ncessaire sa ralisation.
En agilit, lestimation de leort nest pas laaire dun seul individu. Les
personnes devant raliser sont les mieux placs pour estimer. La pratique du
Planning Poker permet par exemple dobtenir une estimation collective de leort
de ralisation, tout en contribuant diuser la comprhension du produit
raliser.
Figure 4.2 User Stories
9
Le logiciel oprationnel
Le manifeste insiste sur limportance de la production dun logiciel oprationnel :
Un logiciel oprationnel est la principale mesure davancement.
Lobtention de ce logiciel oprationnel en n ditration permet lensemble des
acteurs de se runir pour passer en revue les lments compltement termins
(conformment la dnition de termin tablie au pralable avec le client).
Cette runion permet de vrier ladquation de la production au besoin. Les
participants obtiennent des informations qui sont exploites lors de la planication
du contenu de la prochaine itration.
Le bon produit et le maximum de valeur ?
Seule la mise disposition des lments naliss auprs des utilisateurs naux
permet de dterminer si lquipe a construit le bon produit porteur de valeur.
En consquence, lobjectif ultime de lquipe agile consiste se mettre en mesure
de mettre en production immdiatement les lments valids lors de la revue
(Continuous delivery), liminant jusquau besoin de dnir des versions (releases).
Nous dcouvrons comment mieux dvelopper des logiciels
par la pratique
La communaut agile explore de plus en plus le concept du Right Product en
exprimentant des pratiques trs diverses (inspiration du Lean Startup, notion
de Minimal Viable Product), souvent fondes sur une reprsentation visuelle des
concepts (Persona, Impact Mapping, Story Mapping, Empathy Map. . . ).
Elle cherche galement tirer le meilleur parti de la spcication par lexemple
en allant jusqu lautomatisation des tests fonctionnels (BDD pour Behaviour
Driven Development , etc.)
Les sections qui suivent dcrivent les expriences de quelques praticiens agiles
qui ont mis en uvre des pratiques lean pour mieux comprendre les attentes de
leur client.
Scne de crime : apparition mystrieuse au cabi-
net dentaire
Un rseau de dentistes cherche sinformatiser pour saisir les donnes de ses
patients, aussi bien dans les tablissements daccueil spcialiss que dans les
centres de soin en ville ou lhpital.
Lors du recueil des besoins, avec mon quipe de dveloppement, nous avons
dcouvert que les dentistes sont en fait des geeks qui aiment les Macs . Nous
avons identi ce qui est important pour eux : la facilit de prise en main, la
convivialit et lutilisation de la souris.
10
Figure 4.3 Exploration du right product
Observation sur le terrain
Nous ralisons un go&see
1
en nous rendant sur le terrain (le gemba
2
, en terme
lean) pour voir comment travaille un praticien.
Le praticien interroge le patient sur ses antcdents, ses allergies puis, examiner sa
dentition, pendant quune autre personne saisit au fur et mesure les informations
donnes par le praticien : Soin conservateur en 21 !.
Cest sur le gemba que se produit le dclic. Lobjectif du dentiste est de faire
dix vacations par jour. Occup soigner le patient, il na pas les mains libres
pour eectuer la saisie. Il russit son challenge grce son assistante qui saisit
les donnes au fur et mesure de lexamen. Notre hypothse selon laquelle
lutilisateur premier tait le dentiste se rvle errone.
Or, pour aller plus vite, cette assistante nutilise que les touches du clavier : pas
une minute perdre pour enchaner ces dix vacations.
Vrication de lobservation
Ce que nous avons observ change notre perception de lusage de cette application.
1. go&see est une pratique lean : cf.la section Principe lean de ce chapitre.
2. gemba dsigne lendroit o les choses se passent. Cf. la section Principe lean de ce
chapitre.
11
Figure 4.4 Contexte dutilisation du logiciel
Une fois rentrs, nous menons une exprimentation en navigant uniquement avec
les tabulations du clavier. Cest une catastrophe ! Lutilisateur est balad de haut
en bas, le faisant tourner en girouette.
Action corrective
Lquipe change la navigation pour que les tabulations suivent lordre dans lequel
lassistante eectue la saisie.
Figure 4.5 Nouveau schma de navigation au clavier
12
Le mot de lassistante : merci Go&See
Sans cette visite au cabinet, l o les choses se passent, nous naurions pas
dtect les attentes ergonomiques spciques de lassistante. Le logiciel laide
maintenant correctement pour remplir sa mission.
Quavons-nous fait
aller voir le client, sur son lieu de travail, pour mieux comprendre son contexte ;
confronter nos hypothses avec la ralit du gemba ;
adapter loutil lusage dans son contexte
puis retourner sur le terrain pour conrmer la valeur apporte ;
Le rsultat
Nous avons dcouvert un nouvel utilisateur et ses attentes ergonomiques, ce qui
nous a amen adapter le logiciel pour lui en faciliter lusage.
Ce que jai appris
Toute hypothse sur le client doit tre confronte la ralit du gemba. Cest
une excellente pratique pour identier la valeur et les prfrences du client.
Scne de crime : vie et mort dune ide gniale
Une ide gniale
Lors dun atelier regroupant des crateurs de startups, les participants les plus
courageux pitchent leur ide. Lun dentre eux a une intuition formidable :
crer un guide touristique international, proposant les bons plans des au-
tochtones . Lorsquon visite Venise lt, plutt que de suer dans un bain de
foule sur la place Saint Marc, autant aller siroter un Spriss (la boisson locale)
au comptoir du bacaro dune petite place ombrage. Les vnitiens le savent bien.
Le touriste moyen, lui, ne sait pas o trouver ces bons plans.
Trs vite, dautres participants viennent renforcer notre petite quipe naissante
et la machine semballe. On se retrousse les manches, et on travaille dj sur les
questions fondamentales : Comment rcolte-t-on ces astuces ? Combien peut-on
vendre ce guide ? etc.
Tout le monde est motiv, prt attaquer le dveloppement du site web et de
lapplication mobile correspondante.
13
Aller voir vos clients
Lanimateur intervient en nous demandant daller la rencontre de nos futurs
clients. Le lean appelle cette pratique couter la voix du client
3
Notre
mission : comprendre comment, aujourdhui, les touristes trouvent leur bons
plans.
Protons de notre situation, en plein cur de Paris, pour rencontrer des touristes
avides dastuces de Parisiens.
Dsillusion
Deux heures plus tard, nous voil de retour, dpits.
Que sest-il pass ? Lentrepreneur explique : Je tombe des nues. On en a vu,
des touristes. Mais aucune rponse sur leur dicult trouver des bons plans
locaux, puisquils nen cherchent pas. Les plans locaux, a ne les intresse pas.
Ce qui a de la valeur pour eux, cest de trouver le bon chemin pour aller voir la
Tour Eiel.
La leon tirer
Lhistoire de cette ide gniale se termine ici. Mais pas celle de notre quipe
dentrepreneurs : quelques minutes leur ont su pour trouver une nouvelle ide
gniale. Mais cette fois-ci, en commenant par une visite terrain
4
avant de
semballer.
Voil une belle n, puisquau cours de cette histoire, aucun dveloppeur na d
dvelopper un logiciel inutile. Lentrepreneur a pu consacrer lnergie conomise
dautres projets plus prometteurs.
Lerreur de lentrepreneur peut sembler vidente, mais elle est pourtant trs
rpandue. Son ide, comme toutes les ides, reposait sur des hypothses. Lune de
ces hypothses ( les touristes recherchent les bons plans locaux ), quil consid-
rait pourtant comme une vidence, ne correspond pas la ralit. Cette illusion
dvidence, renforce par le confort du bureau, retient bien des entrepreneurs,
et au moins autant de Product Owners, daller se confronter la ralit. Ils
manquent ainsi lopportunit de valider leurs hypothses sur les besoins des
utilisateurs et les problmes que ceux-ci rencontrent dans leurs activits.
Pourtant, aller la rencontre de ses utilisateurs, actuels ou futurs,
Quavons-nous fait
aller voir plusieurs touristes, les utilisateurs potentiels ;
confronter ses hypothses avec la ralit du terrain.
3. La voix du client est une pratique lean qui permet de capturer les attentes du client. Cf.
la section Principe lean de ce chapitre
4. visite terrain se rfre une pratique lean le go & see pour se forger ses propres opinions
sur le contexte et les attentes du client. Cf. la section Principe lean de ce chapitre.
14
Le rsultat
Nous avons compris que la valeur pour cette cible est ailleurs, ce qui a vit de
perdre du temps dvelopper une application qui ne rencontre pas son march.
Ce que jai appris
La manire la plus ecace de valider des hypothses sur les attentes du client
est daller voir les utilisateurs potentiels
Plus vite nous confrontons ces hypothses la ralit du terrain, plus nous
gagnons du temps sur la cration de la valeur.
Scne de crime : la catgorie mystre du projet
Condor
Un oprateur tlcom vend aux entreprises une solution de centre dappels virtuels.
Cette solution est dveloppe par notre quipe agile de sept personnes. Nous
avons hrit dun code de mauvaise qualit que nous amliorons progressivement.
Cependant, nous sommes confronts environ deux signalisations
5
par jour de
nos utilisateurs naux. Cela provoque une tension avec le management, notre
commanditaire est furieux, et les relations avec les exploitants sont diciles.
Catgorisation des incidents
Je dcide de prendre le cas au srieux. Pour cela, je commence par lire les tickets
dincidents dans loutil de ticketing du SAV. Il y a beaucoup de types de tickets
dirents. Je les compte et les catgorise. Cela constitue un bulletin de sant
que jache sur le mur lentre de notre War Room.
Analyse du problme
Les trois catgories les plus volumineuses sont :
1. formation utilisateur : les utilisateurs ne comprennent pas comment fonc-
tionne lapplication;
2. rseau et plateforme : pas directement lie des dfauts logiciel ;
3. mystre : nous ne savons pas identier lorigine de la signalisation.
Premire surprise, le grand gagnant est la catgorie mystre . Deuxime
surprise, il y a nalement une minorit de signalisations lies la qualit logicielle.
Par ailleurs, je me rends compte que de nombreux tickets sont rests sans rponse :
ils taient abandonns dans loutil.
5. Nous appelons signalisation un incident remont par lutilisateur.
15
Figure 4.6 Bulletin de sant du projet Condor
Identier lorigine
Dsaronns par le ou de ces tickets mystre, nous dcidons davancer sur
notre problme en nous donnant les moyens didentier lorigine des prochaines
signalisations. Nous faisons un travail important damlioration des logs de
lapplication. Les rcapitulatifs quotidiens qui remontent par mail les erreurs et
les warnings contiennent plusieurs centaines de lignes htrognes. Nous donnons
un format standard ces logs, en dcrivant les informations devant y gurer
(client, identiant dappel, raison de lerreur avec un lment de contexte).
Nous nous rendons compte quil est dicile de suivre un appel tlphonique
entier car certaines logs sont sur les SVI (Systme Vocal Interactif) et dautres
sont sur les serveurs dapplication. Nous dveloppons un script dagrgation pour
consolider chronologiquement ces sources direntes.
Nous faisons alors diminuer drastiquement la catgorie mystre de 30% 5%.
Gestion du timeout
Maintenant que nous voyons plus clair, un motif important de signalisation
semble lie au protocole de communication avec le serveur du rseau tlcom
qui est bas sur de lUDP. Rien ne garantit dans ce protocole que linformation
ne soit pas perdue. Dans un certain nombre de cas, la perte dun vnement
entrane le blocage des appelants sur une le dattente du SVI. Il faut attendre
le timeout du SVI qui est de 30 mn. Cest inacceptable pour lquipe. Nous
dcidons de mettre en place un mcanisme de gestion de timeout. Cela demande
dajouter une couche de simulation du temps pour la compatibilit avec les tests
automatiques.
16
Point dtape
Lquipe est satisfaite car elle a fait diminuer les signalisations lies la perte
dappel. Elle vite des personnes de payer 30 minutes avant de se faire raccrocher
au nez.
Comme certains tickets sont toujours inexpliqus, nous dcidons denvoyer un
binme en observation chez le client ayant le trac le plus lev.
Observation chez le client
Accueillis dans une atmosphre tendue, nous allons observer les agents du centre
dappel avec leur superviseur.
Sous nos yeux, une opratrice double-clique sur le bouton de pause. Cela a
pour eet de demander une pause et de sortir de pause immdiatement. Surpris,
nous lui demandons pourquoi elle fait cette opration. Elle nous explique quelle
repasse ainsi devant ses collgues dans la le dattribution des appels, an de
prendre plus dappels. Le superviseur nous explique que les agents sont intresss
au nombre dappels traits. Sidrs, nous comprenons alors les incidents de
distribution dappels remonts par les autres, tonns que leur collgue leur passe
devant.
Devant nous, un autre agent prend un appel et souhaite appuyer sur une touche
de fonction pour acher une information de leur outil de CRM. Ce faisant,
sa main eeure le bouton raccrocher et elle perd lappel sans comprendre
pourquoi. Nous venons de rsoudre un autre ticket non reproductible. Mais pas
seulement. Le superviseur qui nous accompagne a assist la scne et comprend
que le problme ne vient pas de lapplication, mais de lergonomie des postes de
travail. Il fait rehausser les postes tlphoniques pour quils soient plus loigns
des claviers.
Plus tard dans laprs-midi, une opratrice redirige un appel vers lhtel de
Roissy. Une personne de lquipe de dveloppement qui nous assiste distance
prcise que lappel est perdu. Nous allons voir la conguration de lapplication
et ralisons que le numro de lhtel est erron. Voil lexplication des erreurs
de type RouteSelectFailure. Nous avions longtemps privilgi la fausse piste des
problmes de standard chez le client.
Nous partons dans un climat plus dtendu : les agents sont contents davoir t
couts et nous sommes soulags davoir supprim trois causes de signalisation.
Quavons-nous fait
commenc par visualiser notre problme ;
protg le client en coutant et en prenant au srieux ses plaintes ;
nous rendre sur le gemba
6
en lisant les tickets de support puis en allant voir
lutilisateur en action.
6. gemba dsigne lendroit o les choses se passent. Cf. la section Principe lean de ce
chapitre.
17
Le rsultat
Cela sest traduit par une baisse drastique de signalisations en passant de deux par
jour une par semaine. Nous avons galement ajout une couche de simulation
du temps qui nous a servi ultrieurement.
Ce que jai appris
Aller sur le gemba est inconfortable, notamment chez un client insatisfait, mais
dune grande richesse dapprentissage. Paradoxalement, cest aussi un gain de
motivation.
En sortant du primtre de lquipe pour aller voir le client, nous avons pu
aboutir la rsolution dnitive dun grand nombre de problmes qui paraissaient
hors de notre porte.
Principes lean
Comprendre le besoin profond du client
La dmarche damlioration du lean commence par la dnition dun objectif
clair et partag par tous. Cet objectif est construit en prenant comme premire
rfrence la satisfaction complte des clients du projet.
Or lexprience montre un cart frquent entre ce quun client exprime et ce qui
le satisfait rellement. Cette dicult sexplique de plusieurs manires :
Il lui est dicile de formuler les exigences du logiciel sans y ajouter ses propres
prfrences ou interprtations.
La demande le met en situation de concepteur de logiciels - un mtier pointu
auquel il nest souvent pas form.
Le lean propose un ensemble de pratiques et principes ecaces pour cibler les
besoins rels du client et aner la comprhension de ses prfrences.
Tout dabord, dans un contexte de dveloppement logiciel, il faut identier quels
sont les vrais clients du projet. Il en existe trois grandes familles :
Lutilisateur nal, celui qui va proter directement le logiciel au quotidien.
Le commanditaire, qui paie la prestation de dveloppement et en attend un
retour conomique. Sa satisfaction dpend de celle de lutilisateur nal, mais
aussi dautres paramtres qui svaluent au niveau de lentreprise.
Les quipes en aval de lquipe de dveloppement qui vont tester, exploiter, et
fournir du support.
Dans un contexte agile, il est important de ne pas considrer priori le Product
Owner comme tant le client au sens lean du projet. Dans de nombreux
cas le Product Owner dsign pour le projet est plutt un reprsentant du
commanditaire et des utilisateurs. Dun point de vue lean, il est donc plutt
du ct de lquipe, et les clients au sens lean restent principalement les
utilisateurs et le commanditaire.
18
Chacun de ces clients a ses propres attentes, quil faut identier et satisfaire. Le
lean ore une structure pour guider cette exploration, base sur cinq axes :
Figure 4.7 Les cinq attentes du client
Les pratiques qui suivent constituent un bon point de dpart pour entamer ce
travail de dtective.
Se faire sa propre opinion en allant observer le client sur le
terrain
Le vritable besoin du client ne se dniche pas dans une salle de runion. Il faut
aller le trouver sur le terrain, l o laction se passe un lieu que les praticiens
du lean appellent le gemba . Dans un contexte agile, il sagit de lendroit o
lutilisateur sera amen utiliser le logiciel.
Simple dapparence, cette observation recle toutefois un pige : le go&see
peut se transformer rapidement en go&talk , bien souvent linitiative de la
personne observe. Quelques points doivent tre respects pour viter cet cueil :
Expliquer la personne observe lobjectif et les modalits de lobservation, en
prcisant quil sagit dune observation et non dune interview. Si ncessaire, il
est possible de demander cette personne de penser voix haute pour mieux
comprendre ce quelle cherche faire.
Observer le plus longtemps possible sans parler.
Rpondre poliment ses questions et linviter reprendre son activit.
Une bonne observation doit apporter des lments de rponse deux questions :
Que cherche faire lutilisateur dans ce contexte prcis ?
Quels sont les obstacles quil rencontre pour atteindre son objectif ?
19
Les deux exemples Apparition mystrieuse au cabinet dentaire et Vie et
mort dune ide gniale illustrent les prises de conscience importantes que
provoquent habituellement des observations russies.
En termes lean, ces observations amnent lquipe observer le processus de son
client : o se trouve la valeur ses yeux et quels sont les gaspillages liminer.
Avec les quipes en aval, lexercice est quasiment identique, mais lattention porte
essentiellement sur lidentication des gaspillages que les livraisons de lquipe
agile gnrent chez ces autres quipes. Lquipe agile met-elle ces dernires en
condition de russir ?
Dans le cas du commanditaire, lexercice consiste comprendre comment il
mesure le succs et les quelques points qui sont vritablement essentiels pour lui.
Comme pour lutilisateur, le go&see nest pas un go&talk . Lobservateur
dcouvre par exemple que le commanditaire est sensible telle ligne prcise dans
un reporting comportant des centaines de pages.
Dnir le problme rsoudre et la faon de mesurer le
succs
Plutt que de dnir lattente du client sous la forme dune solution mettre en
uvre (les fonctionnalits dvelopper), le lean pose la question du problme
global auquel le projet doit apporter une solution pour satisfaire ses utilisateurs
et commanditaires.
Une fois le problme pos, il sagit de dnir la faon dont il sera possible de
20
vrier que le projet la bien rsolu. Lquipe se dote dindicateurs objectifs qui
retent ce succs.
Quelques exemples :
Amliorer la qualit : taux derreur commis par les utilisateurs, volume dinci-
dents.
Augmenter les ventes : taux dajout darticles dans un panier dun site de
e-commerce.
Augmenter la notorit : nombre de Jaime sur Facebook, nombre de
tweets.
Rduire les dlais : le temps pour acheter un billet de train, le temps pour
approuver une demande de crdit.
Eliminer des gaspillages : productivit des utilisateurs.
7
Rduire les irritants : taux de perte des visiteurs sur un site web.
Cette dmarche est fondamentale pour aligner lensemble des acteurs du projet
sur un objectif clair, objectif et indiscutable. Des conditions de succs claires
permettent de dnir des problmes clairs rsoudre ensemble, de mieux choisir
les fonctionnalits et les sujets damlioration, et de vrier que les ides damlio-
ration mises en uvre portent leurs fruits. Il sagit de la fondation de la dmarche
damlioration du lean, base sur la technique du Plan-Do-Check-Act (PDCA)
prsente plus loin dans ce guide. [principeslevier]
Exprimenter pour valider ses prfrences
Chaque fonctionnalit est porteuse dincertitude. Il se peut que :
malgr ses observations sur le terrain, lquipe ait mal compris lattente des
clients,
la fonctionnalit ne rsolve pas le problme dans le contexte de certains
utilisateurs,
la fonctionnalit cre de nouveaux problmes insouponns.
Pour viter cela, il est ncessaire de procder de nouvelles observations terrain
aprs les livraisons. Il sagit de la phase de Check de la rsolution de
problmes, qui peut tre applique la n de chaque itration.
Prendre trs au srieux chaque rclamation client
Chacune des rclamations des clients est une opportunit dapprentissage, car
elle pointe soit sur un lment que lquipe na pas compris, soit sur une faille
dans son fonctionnement.
En pratique, le travail sur les rclamations se traduit par la recherche de la cause
racine du problme qui a amen le client se plaindre. Ceci conduit lquipe :
mieux comprendre le contexte de son client,
7. Attention toutefois sur ce dernier point : lquipe doit rester vigilante ne pas asservir
lhumain la machine. La vision lean considre la technologie comme un outil mis au service
de lintelligence humaine.
21
revoir ses convictions sur son analyse.
trouver des solutions pour liminer la cause racine et viter que cela se
reproduise,
Cette activit danalyse des rclamations repose galement sur la dmarche de
rsolution de problmes. Lexemple La catgorie mystre du projet Condor
prsente une quipe qui choisit de traiter chaque signalisation utilisateur comme
un problme de qualit.
Valeur et gaspillages
Tout ce travail dinvestigation et danalyse a pour objectif de trouver la valeur
pour le client. Cest seulement une fois quelle est clarie quapparaissent
clairement les obstacles : les gaspillages qui occasionnent des pertes de temps
pour les utilisateurs ou ceux qui construisent le logiciel.
Les gaspillages sobservent de nombreux niveaux :
dans lactivit de lutilisateur il faut alors comprendre comment les liminer
en amliorant le logiciel ou le support
dans lactivit de traitement du logiciel installation, exploitation, sauvegarde,
etc.
dans lactivit de dveloppement du logiciel.
Les pratiques lean ont pour objet dimpliquer lensemble des collaborateurs de
lentreprise dans la recherche permanente de cration de valeur pour les clients,
en utilisant llimination des gaspillages comme autant dopportunits de librer
le temps prcieux de ces collaborateurs. Deux de ces pratiques principales sont
prsentes dans les chapitres suivants.
Premiers pas
Pour renforcer votre comprhension des attentes de vos clients, nous proposons
ces exercices :
Allez observer le client sur le terrain
Pour votre projet actuel, allez voir trois utilisateurs distincts sur leurs lieux de
travail
1. Pour chacun des utilisateurs, observez pour comprendre :
Que cherche-t-il faire ?
En quoi la structure actuelle pose un problme ?
2. Quapprenez-vous de nouveau sur leur contexte ?
La solution qui est prvue rsout-elle vraiment leur problme ?
22
Clariez le problme et mesurez le succs
Pour votre projet actuel, menez linvestigation pour rpondre ces questions :
Quel est le bnce attendu du logiciel ? Est-ce quil permet de rsoudre
compltement le problme du client ?
Exprimez-le en termes de dlais, qualit et cot pour lutilisateur et pour le
commanditaire.
Exprimentez pour valider les prfrences du client
Prenez les stories livres de votre dernire itration et posez-vous ces questions :
Quel est le bnce attendu de ces stories ?
Quelles observations devez-vous faire sur le terrain pour vrier quelles ont
port leurs fruits ?
Allez mener lobservation. Quavez-vous appris ? Quels sont les impacts ?
Regardez les rclamations
Prenez les trois dernires rclamations client. Pour chacune, menez ces investiga-
tions :
Quelle est la cause racine du problme ?
Quapprenez-vous sur le contexte et les attentes de votre client/utilisateur ?
Comment pouvez-vous vous assurer que ce problme ne survienne nouveau ?
Aller plus loin
Le lean au service du client
Jim WOMACK et Dan JONES Edition Vuibert
23
Figure 4.8 livre lean au service du client
24
Chapitre 5
De Management visuel
Visualiser le challenge et les
problmes
Les pratiques agiles
Favoriser le travail en quipe
Dans le bureau dune quipe de dveloppeurs agiles, personne ne stonne de
voir les murs couverts de post-its et de posters dessins la main.
Le principe est simple : lutilisation de lespace visuel permet damliorer la
qualit et la quantit dinformation change au sein de lquipe et avec ceux
qui lentourent.
Un projet de dveloppement logiciel en quipe se confronte la fois un besoin
de communication intense et aux limites de la communication verbale, quelle soit
formelle ou informelle. Les mthodes classiques ont recours des outils de gestion
de projet informatiss ou des chiers sur des rpertoires partags. Solutions
trop lourdes ou dshumanises pour le manifeste agile qui invite privilgier les
individus et leurs interactions plus que les processus et les outils . Lachage
mural est alors la rponse adapte pour la communication interne et externe.
Encourager lauto-organisation
En interne, ces lments visuels sont des outils avec lesquels les dveloppeurs
interagissent et laide desquels ils se coordonnent entre eux. Par exemple, sur
un taskboard, on fait avancer le post-it reprsentant une tche au fur et mesure
de sa progression. Cela facilite aussi lintgration dun nouvel arrivant.
Cette clart sur ce quil y a faire et sur les objectifs contribue lmergence de
lauto-organisation. Ce nest plus le chef de projet qui aecte les tches, mais
lquipe elle-mme.
25
Figure 5.1 Un achage mural (radiateur dinformation) dans un bureau de
dveloppeurs
26
Vis--vis de lextrieur, les indicateurs, volontairement simples, donnent une
vision synthtique de ltat du projet et vitent le reporting coteux et inecace
car non partag.
Quelques exemples
La culture agile regorge dexemples que les quipes de dveloppement peuvent
reprendre leur propre compte, comme le montrent les spcimens suivants.
Figure 5.2 Tableau kanban
Les quipes plus avances commencent crer des aches sur mesure pour
rpondre leurs problmatiques spciques.
Puisque la technologie utilise (papier, feutres et traits main leve) est rudi-
mentaire, il est facile et rapide dadapter les achages aux besoins qui mergent,
et dexprimenter de nouvelles approches.
Les rtrospectives sont des moments privilgis pour faire voluer les achages,
pour en crer et en supprimer. Tous les formats sont bons tant que les lments
achs restent utiles et utiliss.
Une pratique quotidienne
Tous les jours, lquipe se runit devant le tableau davancement des tches pour
une courte runion dinspection et dadaptation. Le support visuel matrialise les
informations orales fournies rituellement par chacun des membres de lquipe :
depuis hier, jai termin. . .
dici demain, je pense terminer. . .
voici ce qui pourrait constituer un obstacle au fait de terminer. . .
27
Figure 5.3 Niko niko
Figure 5.4 Burndonw chart
28
Figure 5.5 Un poster sur-mesure
29
Figure 5.6 Exemples dachage dune quipe crative
Une pratique ecace et volutive
Les quipes agiles en posture damlioration continue sont en exprimentation
permanente sur leur management visuel. Aujourdhui, pour aller plus loin elles
ont recours de plus en plus lapproche kanban : matrialisation des limites sur
le travail en cours, dnition de classes de service, etc.
Les sections qui suivent prsentent les exprimentations dquipes agiles qui ont
souhait faire voluer leur management visuel en lobservant sous un angle lean.
Scne de crime : trouvez lindic !
Le contexte
Une enseigne de la grande distribution sadresse lagence web que je dirige
pour mettre en ligne son ore Traiteurs de n danne. Le site doit orir la
possibilit aux clients de construire une liste de courses quils pourront utiliser
ensuite en magasin pour commander leurs produits. Le site ne sera accessible
que cinq semaines par an loccasion des ftes.
Lanne suivante, suite au succs de lopration et une demande de plus en
plus importante, lenseigne dcide dajouter le paiement en ligne. Le niveau de
performance demand est trs lev : une abilit sur la commande de 100% et
un taux contractuel de disponibilit au-del de 95%. Je dois donc orir mon
client un service de maintenance, cependant mes quipes agiles actuelles nont
aucun cadre de travail pour assurer ce nouveau type de prestation.
30
Figure 5.7 Radiateur dinformations existant pour grer les projets web
Pendant les 3 annes suivantes, nous russissons au prix de gros eorts tenir nos
engagements. En eet, nous devons dvelopper de nouveaux projets pour dautres
clients tout en assurant la maintenance de ce site. Chaque anne lhistoire se
rpte, lquipe semble toujours confronte aux mmes problmes. Les sprints
sont perturbs par les actions de maintenance et les problmes de fonctionnement
de lapplication. Nous ne capitalisons pas sur ce que nous avons appris les annes
prcdentes.
Les pnalits en cas de non-respect des engagements peuvent mettre lentreprise
en danger. La pression est donc trs importante, dautant que je suis incapable
de savoir tout moment si la situation est sous contrle ou pas.
La dmarche
La question qui se pose est de savoir comment tre certains que nous sommes en
train de russir, cest--dire assurer un service de maintenance de qualit tout
en rduisant limpact de cette activit sur le dveloppement des autres projets.
La premire tape consiste comprendre ce qui est vraiment important pour le
client pendant la dure de vie du site de-commerce. Je veux savoir sur quoi je
dois porter une attention particulire an de satisfaire totalement mon client.
Je dcide de ne pas dcider sa place et de lui poser la question. Pour cela, je
mappuie sur loutil Voix Du Client
1
1. Cf. Section Principes Lean du chapitre Attentes du Client
31
Trois points clefs ressortent de ce questionnement :
Les dates douverture et de fermeture du service. Le site doit tre
accessible seulement entre le 19 novembre et le 26 dcembre, priode dou-
verture annonce par lenseigne. Le client investit dans une campagne de
communication (TV, radio, publicit sur le lieu de vente, etc.). Il communique
fortement sur la date douverture du service qui doit tre oprationnel au
moment x. Pour la fermeture, il est trs important darrter le service pour
chaque magasin aux heures dnies par le client. Dans le cas contraire, un
magasin pourrait tre dans lincapacit dhonorer les commandes passes. La
rputation de lenseigne est donc en jeu.
Lengagement sur la prise de commande du client du magasin. 100%
des commandes prises doivent tre honores.
La disponibilit du site. Le site doit tre accessible 100% du temps sur
la priode douverture. Mme si contractuellement le site doit avoir une
disponibilit de 95%, le client attend une disponibilit totale du service.
A partir de ce constat, je construis avec lquipe un ensemble dindicateurs
clefs, an de nous concentrer sur le vritable challenge permettant de satisfaire
pleinement notre client. Assist par ces indicateurs, je veux connatre chaque
jour ltat de la situation pour maider dcider.
Les dates douverture et de fermeture du service :
Un indicateur quotidien OK/NOK sur louverture et la fermeture du site
par magasin.
Lengagement sur la prise de commande du client du magasin :
Un indicateur quotidien OK/NOK sur la conformit des commandes en-
voyes.
La disponibilit du site :
Un indicateur quotidien OK/NOK sur laccessibilit au catalogue de produit
et la commande proprement dite.
Un indicateur quotidien OK/NOK sur le fonctionnement des fonctionnalits
du site (nuage de tags, envoi un ami,. . . )
Les indicateurs se prsentent comme suit :
Nous achons et faisons vivre ces indicateurs dans notre Open Space. La situation
est rendue visible. Chaque fois quil y a un problme
2
exemple : plainte client car
le service est lent, avec 8 secondes pour passer commande au lieu de 2 secondes),
les indicateurs sont mis jour. Tous les matins, nous faisons un point sur la
situation. Si un problme est survenu la veille, cest loccasion pour nous de
partager et dapprendre sur les actions menes.
Notre management visuel est organis de la manire suivante :
Lexploitation de ces informations me permet aujourdhui de juger avec lquipe
de limportance des problmes. Lquipe travaille plus sereinement. Elle est
capable de rpondre aux exigences du client le plus rapidement possible. Les
projets sont moins perturbs et lquipe dlivre plus de fonctionnalits par sprint.
Dautre part, cette dmarche qui amliore la qualit du service nous permet de
renforcer la relation de conance avec notre client qui reconduit chaque anne
notre partenariat.
2. Cf. Section Principes Lean du chapitre Leviers de lamlioration
32
Figure 5.8 Structure de nos indicateurs de performance*
Figure 5.9 Structure de notre management visuel
33
Figure 5.10 Management visuel pour une activit de maintenance
Quavons-nous fait
- Comprendre ensemble :
- Interroger les clients sur ce qui est vraiment important pour eux avec loutil
Voix du client
- Traduire le besoin du client en indicateurs de performance
- Voir ensemble :
- Rendre visible le challenge et les problmes
- Agir ensemble :
- Prendre les bonnes dcisions immdiatement ds que le problme est connu
- Prparer la rsolution de problme dnitive via le PDCA
3
Le rsultat
- Un site e-commerce avec un haut niveau de abilit
- Des projets livrs plus vite, car moins de perturbations extrieures
Ce que jai appris
En qualiant ensemble la nature des problmes, nous utilisons au mieux les
comptences de chacun pour rsoudre plus rapidement les problmes. Peu
importe la forme des premiers indicateurs construits tant quils montrent la
cible et les problmes, ils saneront dans le temps pour mieux correspondre
lattente du client.
34
Scne de crime : tous coupables
Contexte
Suite la fusion de plusieurs organismes, une grande socit de services se voit
coner la ralisation dun nouveau systme uni de gestion des dossiers des
cotisants. Les enjeux de mise en service de ce nouveau systme sont critiques :
Le suivi comptable a mis jour un cart considrable entre les cotisations, les
remboursements et lencours. Il faut trs rapidement clarier la situation, puis
la corriger.
De nombreux cotisants font face de trs longs dlais de traitement de leurs
dossiers.
Aprs une premire phase de six mois, le premier lot sest sold par un chec :
lquipe a livr avec un retard de plusieurs semaines, hors budget, un produit
non conforme aux attentes du client.
Cette situation se traduit par une crise dans lquipe de ralisation : le directeur
de projet et le chef de projet sont remplacs, la moiti de lquipe demande
changer dactivit.
Jinterviens comme coach agile auprs de lquipe, qui comporte une vingtaine
de personnes.
Visualiser le challenge
Lquipe doit se mettre en capacit de produire le prochain lot dans un dlai de
trois mois, sans retard, en assurant une qualit acceptable du point de vue du
client nal. Elle doit galement parvenir livrer des lots intermdiaires toutes
les deux semaines pour rassurer le client.
Ce challenge
4
se traduit tout dabord par lachage dun objectif de production
pour la premire itration :
Lquipe analyse les principales tapes de son ux de production
5
, puis reprsente
son activit sous la forme dun tableau visuel.
Lenjeu de litration en cours consiste sortir toutes les pices prsentes sur le
tableau
6
.
3. Cf. Section Principes Lean du chapitre Leviers de lamlioration
4. Cf. Section Principes Lean du chapitre Attentes du Client
5. Cf. Section Principes Lean du chapitre Management visuel
6. Une amlioration possible consisterait clarier lobjectif de la journe, pour mettre
en place un systme complet de ux tir. Cependant ce stade, linformation permet dj
lquipe de commencer identier ses principaux problmes.
35
Figure 5.11 Objectif de production
Figure 5.12 Tableau reprsentant le ux de production
36
Rvler les problmes
Problme principal : les tches narrivent pas jusqu la dernire colonne.
Depuis plusieurs semaines, lquipe bute sur une somme croissante dobstacles
bloquants sans arriver sorganiser pour les surmonter. La frustration qui en
rsulte se transforme progressivement en antagonisme envers la cellule danalyse
fonctionnelle. Celle-ci, dlocalise auprs du client nal, est rendue responsable du
blocage. Lquipe de ralisation lui reproche de laisser saccumuler les demandes
dinformations, sans les traiter dans un temps acceptable.
Les premires runions quotidiennes conrment que la majorit des dveloppeurs
sont en attente de clarication sur des questions dordre fonctionnel. Ces deman-
des sont transmises par lintermdiaire dun outil lectronique, mais la plupart
restent indniment sans rponse. Lquipe ralise que loutil ne lui permet pas
dapprhender la situation.
Pour y voir plus clair, elle dcide de rendre visibles ces obstacles sur son manage-
ment visuel. Au cours de ce travail danalyse, elle fait une dcouverte surprenante :
l o lquipe technique voit questions en cours, lquipe fonctionnelle nen voit
de son ct que 2.
La cause racine
7
du problme se trouve dans la variabilit individuelle dinter-
prtation du processus. Chacun saisit la demande sa manire, puis, dlguant
la responsabilit au systme, ne se proccupe plus du suivi du processus de
rsolution. En particulier, les tickets sur lesquels le service destinataire est mal
renseign, ne sont pas traits correctement. Ils demeurent en ltat dans le
systme.
Tout dabord, lquipe enrichit son management visuel
8
, en rendant visibles,
pour chaque tche, les obstacles (questions bloquantes en cours) sous la forme
de post-its rouges :
Figure 5.13 Achage des obstacles sur les tches
Ensuite, lquipe met au point un standard de rdaction dune che de demande.
Je passe voir chaque collaborateur pour le former la bonne faon de faire. De
plus, lmetteur de la demande devient responsable des actions de suivi.
Les obstacles sont matrialiss et suivis sur un tableau ddi :
7. Cf. Section Principes Lean du chapitre Leviers de lamlioration
8. Cf. Section Principes Lean du chapitre Management visuel
37
Figure 5.14 Standard de dnition dune demande
Figure 5.15 Tableau de suivi des obstacles
38
Les runions quotidiennes, qui taient auparavant centres sur les tches, font
maintenant une large place au traitement des obstacles en cours. Chaque jour,
un point est eectu sur les obstacles non levs. Les ches des obstacles non
rsolus sont dplaces en fonction de leur niveau durgence (voir tableau de suivi
des obstacles).
Ds quun obstacle est lev, sa che est dplace vers un espace spcique
o il demeure jusquau lendemain. Cela permet un autre quipier, dont une
tche serait en attente de la mme demande, de savoir quil peut reprendre son
traitement.
Figure 5.16 Panneau des obstacles rsolus
Deux semaines aprs cette dcouverte, les questions en attente de rponse de la
part de la cellule danalyse fonctionnelle ont toutes t traites. Lquipe peut
vrier visuellement au quotidien que cette quipe nest pas source de blocage
de leur processus, les tensions sont apaises, les relations uidies.
Lquipe a appris grer les obstacles, ce qui lui a permis de retrouver sa capacit
produire. Une bonne partie des tches en attente ont pu avancer dans les
tapes suivantes du processus.
Quavons-nous fait
Comprendre ensemble :
Dnir le challenge : prochain lot dans trois mois sans retard et avec zro
dfaut
Traduire le besoin du client en indicateurs de performance
Voir ensemble :
Rendre visible les problmes qui mempchent davancer sur mes tches par
lintermdiaire des bacs rouges
9
Rendre visible le ux de dveloppement
9. Cf. Section Principes Lean du chapitre Management visuel
39
Agir ensemble :
Comprendre les typologies de problmes, les rendre visible et sorganiser
tous les jours pour les attaquer un par un
Le rsultat
Les obstacles ont t levs ce qui permis lquipe de sortir ses tches lheure.
Ce que jai appris
Lquipe communique et travaille plus ecacement avec les analystes fonctionnels.
Scne de crime : le burdown tait rouge
Contexte
Comme dans beaucoup dquipes agiles nous avons un burndown chart ditra-
tion :
Figure 5.17 Burndown chart ditration
Nous rencontrons un problme
10
de tenue des dlais qui se matrialise sprint
aprs sprint par un reste faire de 10 20% en n de sprint :
Recherche de cause
Peut-tre ne consacrons-nous pas le temps prvu initialement raliser nos
sprints ? Certains membres de lquipe interviennent en eet sur plusieurs ac-
10. Cf. Section Principes Lean du chapitre Leviers de lamlioration
40
Figure 5.18 Evolution du reste faire au l des sprints
tivits (management, runions transverses. . . ). En tant que Team Leader, je
nchappe pas cet parpillement.
Enrichissement du management visuel
Pour clarier la situation, nous enrichissons notre management visuel en ajoutant
un graphique des jours consomms, copie quasi-conforme de notre burndown
chart ditration.
Figure 5.19 Burndown chart des jours consomms
Notre hypothse se conrme : une partie de lquipe na pas consacr litration
autant de jours quelle le pensait. Lquipe croyait disposer dune capacit de
100 jours avant litration, mais na pu en fournir rellement que 80.
41
Action : suivi des carts
Il faut maintenant agir. Je trace, sprint aprs sprint, la dirence entre les jours
consomms et les jours planis.
Figure 5.20 Suivi de la dirence entre les jours consomms et les jours
planis
Sur les 24 derniers sprints, jobserve une forte variabilit. Je pense que les
membres de lquipe nont aucun moyen de dtecter un cart en cours de sprint.
Consomm individuel
Jen discute avec lquipe et nous dcidons de tracer jour aprs jour le temps
consomm de chaque personne.
En dbut de sprint, nous imprimons un graphique qui montre pour chaque
personne le nombre de jours quelle a annonc en sprint planning. Durant chaque
daily scrum meeting, un dveloppeur remplit les lignes. Quand Romain dit je
suis intervenu sur telle tche toute la journe, le dveloppeur surligne en uo
une journe supplmentaire consomme sur la ligne de Romain.
Ce suivi permet dalerter Romain : Attention, il ne reste que 2 jours et il te
reste 1,5 jours consacrer au sprint.
Linformation ache est exploite
Chaque membre de lquipe est maintenant en mesure de suivre au jour le
jour un ventuel cart de son implication dans le sprint. Par exemple, si une
runion transverse imprvue mest propose, je choisis dy participer ou pas en
connaissant pleinement son impact sur le sprint.
Le reste faire en n ditration, qui tait totalement imprdictible et chaotique
devient dune exceptionnelle stabilit. Plus exceptionnel encore, les jours-homme
non consomms se stabilisent au mme moment, ce qui conrme lhypothse
dune corrlation entre les deux phnomnes (voir les courbes du Suivi des
carts en n ditration).
Par contre, nous narrivons pas encore tenir 100% de nos engagements du sprint.
En eet les tches de dveloppement saccumulent dans la case A valider ,
dernire tape de notre kanban et lquipe des spcications ne les valide pas
toutes avant la n du sprint.
42
Figure 5.21 Suivi du nombre de jours consacr au sprint
Figure 5.22 Suivi des carts en n ditration
43
Suite de lhistoire
Et les deux quipes se marirent et eurent beaucoup de stories nies en n de
sprint.
Les quipes de spcication et de dveloppement dcident de fusionner leur
management visuel et leur daily meeting. Les dbuts sont diciles, mais partir
du sprint .1, elles russissent samliorer drastiquement en se focalisant sur les
stories valider plutt que sur de nouvelles spcications :
Figure 5.23 Evolution du reste faire la suite dune action damlioration
Quavons-nous fait
Comprendre ensemble :
Rajouter un indicateur de performance mesurant le temps consomm par
lquipe pour pouvoir le confronter au burndown
Voir ensemble :
Mesurer les jours consomms pour faire apparatre un delta par rapport
lestimation faite en dbut de sprint
Un visuel permettant chacun de savoir, tout moment, combien de jours
il lui reste pour terminer les tches sur lesquelles il sest engag
Agir ensemble :
Se poser la question est-ce quil me reste assez de temps pour tenir mes
engagements du sprint
Planier sa journe en fonction (ex : privilgier le dveloppement plutt que
des tches moindre valeur ajoute telle quune runion)
Le rsultat
Nous livrons le mme volume de fonctionnalits ditration en itration (environ
90%), ce qui permet chaque membre de lquipe de mieux planier son
prochain sprint.
Nos indicateurs nous ont permis de valider ensemble la russite dune action
collective.
Ce que jai appris
Laisser lquipe trouver delle-mme les solutions ses problmes paie.
44
Principes lean
Quest-ce que le management visuel lean apporte une
quipe agile ?
Le management visuel est une pratique de base du lean qui poursuit deux buts
complmentaires :
Aligner lensemble des acteurs du projet sur un mme objectif : la satisfaction
des clients.
Partager les dicults et les pistes damlioration de manire objective an
que chacun comprenne comment il peut contribuer lamlioration.
Lapproche lean du management visuel permet de franchir un palier sur trois
sujets :
Identier de manire trs prcise o se situent les problmes que lquipe doit
attaquer pour amliorer aussi bien le produit que ses conditions de travail.
Ceci se retrouve dans lexemple Trouver lindic . Le management visuel
renvoie lquipe plusieurs signaux qui permettent dagir sur les bons sujets :
volume important des demandes de maintenance et retards de livraison des
projets. Ceci encourage lquipe aller la rencontre de ses clients pour mieux
comprendre les dicults rencontres.
Collaborer avec les autres quipes de manire ecace. Dans lexemple Tous
coupables , lquipe technique blme les analystes et inversement, et les choses
navancent pas. Ils visualisent le problme ensemble, et en trs peu de temps,
ils arrivent se mettre daccord sur une solution simple pour dbloquer la
situation.
Communiquer avec ses managers sur des faits clairs et ainsi mieux se faire
entendre.
Les objectifs
Le management visuel fournit en temps rel linformation et le feedback objectif
ncessaires la comprhension de lactivit de lquipe. Il lui donne les moyens
de rpondre chaque instant la question :
Sommes-nous en train de russir notre journe ? .
Comme chaque outil lean, le management visuel est un outil dapprentissage.
Il permet aux collaborateurs de devenir des experts dans leur mtier par la
rsolution des problmes qui mergent.
Il est bas sur trois axes :
45
Figure 5.24 Le triangle du management visuel lean
Comprendre ensemble
La construction et lutilisation du management visuel amnent lquipe dvelop-
per une comprhension commune de :
lattente de ses clients ;
son challenge et sa propre performance ;
son processus de dveloppement ;
les rles et les comptences de chacun;
les rles et les comptences de chacun.
Le client
Dans un premier temps, lquipe commence par identier clairement ses clients
11
.
Ensuite, elle dnit leurs besoins et leurs critres de satisfaction : o est la valeur
pour eux dans ce quelle leur dlivre ? Dans quelles conditions faut-il leur dlivrer
(qualit, dlais, cots) ?
Dans lexemple Trouvez lindic ! , les dveloppeurs sont alls la rencontre de
leurs clients (service marketing et DSI de leur commanditaire). Ils ont ralis
que leur contrat ne retait pas leurs relles attentes. Sils respectaient les 95%
de disponibilit du site, pas de pnalit pour lquipe, mais une image dgrade
du point de vue du client.
Le challenge et la performance
Lquipe dnit sa condition cible et la traduit sous la forme dindicateurs de
performance. Ces derniers montrent la qualit de ce que lquipe produit, dans
quels dlais et avec quelle productivit le tout du point de vue du rsultat
nal, cest--dire du point de vue du client. Les indicateurs dnis doivent donc
couvrir les sujets suivants :
Qualit du service ou produit livr : lquipe a-t-elle russi livrer la bonne
fonctionnalit du premier coup?
11. Cf. Section Principes Lean du chapitre Attentes du Client
46
Respect des dlais de livraison attendus par le client (et pas uniquement
ceux ngocis avec lui) ou le stock (le volume des demandes client dans le
backlog que lquipe na pas encore pu traiter). Charge lquipe de samliorer
pour sapprocher de lattente client. Dans lexemple le burndowntait rouge ,
les dveloppeurs se battent pour respecter leur engagement de dlais sur le
sprint (90% livr au lieu de 100%) et vont jusqu mesurer leur propre temps
consomm pour y arriver.
Productivit : indicateur cl pour suivre lamlioration de la capacit de
lquipe.
Satisfaction client :lquipe peut avoir limpression que tout va bien alors
que le client nest pas entirement satisfait.
Des indicateurs spciques aux objectifs du projet peuvent tre ajouts, no-
tamment des indicateurs de succs du produit lui-mme : disponibilit, taux
dutilisation, taux de rtention des utilisateurs, etc.
Le processus
Lquipe dnit clairement les activits valeur ajoute pour le client et les
tapes par lesquelles elle doit passer pour livrer le service ou le produit requis.
Lobjectif est de saligner et de rester focalis sur ce qui est important pour le
client, tout en facilitant le travail de chaque collaborateur.
Lquipe
Chaque personne doit tre capable dexprimer clairement son rle et sa place
dans lquipe. Ceci lui permet dinteragir avec les autres sans ambigut.
Lquipe ache aussi une matrice de comptences de tous ses membres, ainsi
quun programme de formation, lobjectif de dveloppement des comptences
tant clair pour chacun.
Voir ensemble
Ds que lquipe est claire sur la direction prendre et quelle est prte mesurer
sa performance au jour le jour, elle doit rendre visible ce quelle est en train de
produire. Le but est de voir les direntes units de production (ex : des tches,
des tickets, des fonctionnalits) avancer dans le processus.
Pour cela, lquipe met en place un systme lui permettant de visualiser le ux
de ses activits comprenant lobjectif du jour et la distribution des tches, ainsi
que la performance. Lobjectif est dtre alert immdiatement en cas danomalie
an de ragir rapidement.
Flux dactivit
Typiquement, les quipes agiles utilisent des taskboards pour organiser leurs
sprints et visualiser le ux des tches.
47
Figure 5.25 Matrice des comptences de lquipe
Le lean apporte un lment supplmentaire en invitant trouver des moyens
de rendre visibles tous les obstacles que rencontre lquipe pour atteindre ses
objectifs. Lexemple Tous coupables illustre ce principe : les dveloppeurs
ajoutent des tiquettes rouges sur leurs tches lorsquil leur manque une informa-
tion pour avancer. Ils se donnent des objectifs quotidiens pour lever ces obstacles
et partagent la solution avec leurs quipiers pour en tirer des leons.
Pour rendre les problmes visibles, une premire pratique lean consiste intro-
duire des bacs rouges - une manire visuelle de reprsenter les obstacles de
qualit :
Soit des problmes de qualit en entre (par exemple une user story insusam-
ment claire ou incohrente avec lapproche du produit, ou bien une user story
qui est en soi une retouche parce quelle avait t mal cadre ou ralise lors
dun prcdent sprint)
Soit des problmes de qualit rencontrs au cours dune tche (par exemple un
dveloppeur trouve un endroit du code qui recle des dfauts)
Chaque problme de qualit est imprim ou crit sur une feuille, puis plac dans
une bannette rouge proximit du taskboard :
Les bacs rouges
Rgulirement, lquipe se livre lanalyse du contenu de ses bacs rouges pour
comprendre la cause de ces problmes de qualit et y trouver une solution.
Au-del des problmes de qualit, dautres natures de problmes peuvent tre
rendues visibles sur le management visuel, par exemple :
48
des demandes client restes trop longtemps en attente,
des problmes de surcharge de certains membres de lquipe par rapport
dautres.
Il ny a pas de rgle explicite prcisant quelles natures de problmes doivent tre
rendus visibles, et comment. Chaque quipe fait voluer son management visuel
au gr de ses besoins et de son niveau de maturit.
Dans certains contextes spciques, il peut tre utile de mettre en place un visuel
un peu dirent. Ci-dessous, deux possibilits :
1. Un visuel gros volumes , utilis dans des phases de projet qui comportent
des tches rptitives par exemple une migration de donnes manuelles.
Lquipe se donne des objectifs chirs et vrie plusieurs fois par jour si
elle les atteint ou pas (exemple : cration et excution de tests fonctionnels).
Figure 5.26 tableau_de_suivi_de_production
2. Un visuel physique , lorsquil est ncessaire de voir ce qui est produit
sur papier. Ce visuel peut tre utilis, par exemple, dans le cadre dun
projet de conception de documentation technique.
49
Limage ci-dessous reprsente trois bannettes :
1. une bannette contenant des pages rdiges par Julie qui demande une
relecture Germain ( traiter ),
2. une deuxime bannette contenant les pages pour lesquelles Julie attend
des renseignements ou un feu-vert ( suspendu )
3. une troisime bannette ( les bacs rouges ) contenant les pages qui
comportent des problmes rsoudre immdiatement pour dbloquer Julie.
Le mur de la performance
Lquipe construit ses indicateurs de performance pour savoir tout moment
si elle rpond bien aux attentes de ses clients. Elle les met jour la main
quotidiennement et y annote les pics et les valles pour expliquer les
hausses et les baisses inattendues. Un bon indicateur montre la tendance dans le
temps et une cible an de faire merger les carts de performance, ce qui forme
la dnition dun problme
Figure 5.27 Le mur de la performance
Les indicateurs de type burndown peuvent parfaitement tre utiliss. Ils
deviennent un outil dapprentissage lorsquon y annote les causes des retards, et
les expriences damlioration mises en uvre.
50
Dautres indicateurs ne se prtent pas une reprsentation en burndown chart.
Le modle gnrique ci-dessous reprsente une bonne faon de reprsenter un
indicateur :
Figure 5.28 Structure dindicateur type pour le suivi dune valeur unique qui
volue dans le temps
Suivi des problmes
Lquipe note les problmes quelle rencontre sur une main courante, qui prsente
plusieurs intrts :
Partager les problmes rencontrs et se mettre daccord sur leur dnition
Penser vrier le rsultat des actions mises en uvre
Agir ensemble
Le management visuel favorise lauto-organisation de lquipe an quelle puisse
ragir rapidement aux problmes et adapter son fonctionnement pour faire de
la rsolution de problmes. Il permet ainsi lquipe de prendre ses propres
dcisions sur lobjectif oprationnel du jour, son organisation et les solutions
mettre en place pour travailler plus sereinement.
Dans lexemple Tous coupables , la runion dquipe quotidienne nest plus
seulement une opportunit de parler de ses tches, mais ore loccasion de
partager ses problmes. Lquipe se rorganise pour donner lquipe lopportu-
nit de rsoudre les problmes bloquants sans perturber le bon droulement du
sprint et surcharger les dveloppeurs.
Lquipe rsout dirents types de problmes mis en vidence par son manage-
ment visuel. Du plus simple, qui ncessite une action rapide de type just do
it au plus complexe ncessitant une rexion plus profonde. Dans lexemple
51
Figure 5.29 Tableau de suivi des problmes
le burndown tait rouge , lquipe ne se dcourage pas et continue de chercher
la cause racine de son problme li au non-respect des dlais.
Lquipe consigne les problmes au fur et mesure quils apparaissent sur le
mur et les traite les uns aprs les autres. Suivant la nature du problme, lquipe
peut se recongurer et aecter certains de ses membres spciquement son
analyse et sa rsolution.
La dmarche lean de rsolution de problmes est dtaille dans le prochain
chapitre : Les leviers de lamlioration .
Premiers pas
Comprendre ensemble
Allez voir votre client, votre manager et votre quipe pour comprendre leurs
critres de succs :
Que cherchez vous russir ?
Projetons-nous en n danne. A quoi verrez-vous que vous avez bien russi
lanne ?
Aprs avoir rencontr, interrog, observ vos clients, crivez sur papier la liste
de ces critres. Ils dnissent votre challenge.
Voir ensemble
Mettez-vous devant votre management visuel et voyez avec lensemble de lquipe :
52
O est le client ? Le challenge est-il bien reprsent ?
Prenez un des critres de succs de la liste que vous avez tablie. Comment
est-elle traduite concrtement dans le management visuel ? Lobjectif est-il clair
pour chacun?
Prenez chacun des indicateurs au mur. Chacun sait-il ce quil doit faire pour
contribuer latteinte de lobjectif ?
Les pices produire sont-elles visibles ?
Agir ensemble
Tous les jours, posez-vous ces questions :
En ce moment, en sappuyant uniquement sur ce que montre le management
visuel, lquipe est-elle en train de russir sa journe ?
Les obstacles sont-ils visibles ?
Les problmes que lquipe est en train de rsoudre sont-ils visibles ? Lamliora-
tion est-elle visible ?
Quelle est la dernire chose que vous avez apprise grce votre management
visuel ?
Aller plus loin
The Visual Factory
Michel GREIF Edition Productivity Press
Version franaise disponible en ebook
Aller lessentiel :
Chapitre 5 The Visual Production Control pour des exemples de manage-
ment visuel
Chapitre 6 Process Indicators pour comprendre les indicateurs de perfor-
mance ( ne pas confondre avec des indicateurs dactivit)
Creating a Lean Culture
David MANN Edition CRC Press
Shingo Prize : la plus haute distinction des livres lean
Aller lessentiel :
Chapitre 4 Visual Controls pour retrouver des exemples de management
visuel
53
54
Chapitre 6
De Lamlioration continue
Trouver les leviers de
lamlioration
Les pratiques agiles
Au plus profond de la culture agile
Des principes favorisant lidentication des actions damlioration sont intgrs
au plus profond de la culture agile.
Par exemple :
Le dveloppement itratif : Rpter les mmes activits permet damliorer
sa pratique.
La livraison frquente : En sassurant que les fonctionnalits dveloppes sont
remises rapidement entre les mains du client, lagilit cre les conditions pour
quune conversation ait lieu avec lui. Sil nest pas satisfait, lquipe cherche un
moyen damliorer la situation.
Les temps rtrospectifs : En rservant du temps pour rchir, lquipe cre
lespace ncessaire pour le choix dactions damliorations.
Les domaines privilgis damlioration
Au l des annes, la communaut agile sest constitue un riche catalogue de
pratiques favorisant lamlioration.
Le mouvement agile a t initi par des dveloppeurs qui voulaient rompre avec
des mthodes de projet contraignantes, des environnements de collaboration
peu propices lpanouissement, et des pratiques dingnierie inecientes. Cest
la raison pour laquelle on peut trouver des pratiques agiles dans ces dirents
domaines. En voici quelques exemples signicatifs.
55
Lorganisation du travail
Comme le mcanicien qui sait reprer les anomalies dans le bruit rptitif du
moteur, lquipe identie les eets des changements introduits par leurs dcisions
dune itration lautre. Elle sait reconnaitre des motifs rcurrents, sait ragir
et grer le stress par le rythme du travail. Cette ide est reproduite de manire
fractale jusquaux gestes du dveloppement : la construction dun programme
est aussi une rsolution successive de micro-problmes.
Figure 6.1 XP feedback loops
Les trucs de geeks
Le refactoring, les tests automatiques sont des leviers techniques damlioration
du produit logiciel. Le dveloppement pilot par les tests est un bon moyen de
construire un design mergeant, garant de lvolutivit du code. Cela a pour eet
de crer des degrs de libert (fonctionnelles, techniques) et assure la facult de
lquipe de dlivrer des volutions un rythme constant. Le refactoring est aussi
une manire pour lquipe de polir son code, de se lapproprier, le rendre plus
habitable (Cf Software Craftmanship).
Le binmage constitue galement un levier damlioration. Par exemple, en
associant un dveloppeur dune grande exprience mtier avec un dveloppeur
nouveau dans lquipe : le dveloppeur nouveau avec son il neuf peut apporter de
la hauteur dans les solutions conues, ainsi que son expertise technique. Lexpert
mtier peut apporter au novice ses explications des concepts et techniques du
projet.
56
La communication interpersonnelle
La qualit de la communication reprsente un axe majeur damlioration. Pour
exploiter les bnces de la communication orale, il est conseill de regrouper
les postes de dveloppement dans le mme bureau. Quand la situation lexige,
lquipe peut galement augmenter la bande passante auprs de son client, par
exemple en linvitant plus frquemment des runions de travail.
La construction dquipe apparat galement comme un domaine daction priv-
ilgi. Les coaches agiles puisent dans plusieurs domaines des sciences humaines
et du coaching dquipe (Virginia Satir, Ecole de Palo Alto, Core protocols, psy-
chologie sociale) an de guider les quipes dans lamlioration de leur ecacit.
Trouver des leviers sur mesure
Le travail en quipe auto-organise constitue un des principes fondamentaux de
la culture agile (The best architectures, requirements, and designs emerge from
self-organizing teams). Aussi, la source privilgie de leviers damlioration
rside dans lquipe mme.
La rtrospective, quelle ait pour objet une itration ou un projet entier, est le
moment privilgi pour analyser la situation et choisir un levier damlioration.
Chaque levier consiste introduire ou ajuster une pratique issue du catalogue
cit prcdemment, ou une action concocte sur mesure.
La diversit des points de vue de chaque individu est le gage du potentiel
damlioration de lquipe. Celle-ci doit seorcer dexploiter au mieux cette
57
richesse en partageant les informations pertinentes dont chacun peut disposer
individuellement. Une fois ces informations partages, nombre de techniques
facilitent lidentication des problmes rsoudre et la mise au point dactions
de rsolution, mais toujours en sappuyant sur le collectif.
Quelle quen soit la source dinspiration et la mthode daccouchement, une
bonne action damlioration runit les caractristiques suivantes :
elle est prometteuse : Le bnce attendu important. Ce bnce est valu
selon les critres propres aux participants.
la porte des participants : Ceux-ci sont en mesure de la mettre en
uvre avec les moyens leur disposition ; ceci exclut les actions trop coteuse
ou en dehors du champ daction.
elle remporte ladhsion : Cest laction qui fait consensus parmi les par-
ticipants qui est choisie.
Les sections suivantes illustrent les retours dexprience de praticiens agiles
qui ont essay des pratiques lean sur leurs projets pour aller plus loin dans
lamlioration.
Scne de crime : la mise en production qui ne
devait pas chouer
Lodeur du napalm au petit matin
Un oprateur majeur propose un service grand public de tlvision et vido
la demande. Il sert 40 millions daccs par mois grce 250 000 lignes de
code Java, une plateforme Linux/Apache/Tomcat/Mysql et un bus de donnes
erlang RabbitMQ. Ce service est dvelopp par mon quipe de 8 dveloppeurs
et exploit par 3 ingnieurs systme. Cette quipe de dveloppement pratique
scrum et XP depuis 4 ans.
Un matin, je retrouve lquipe systme avec des cernes, en intervention depuis 5
h du matin. Le service web grand public est techniquement oprationnel, mais
inaccessible. Malgr un rol lback eectu sans problme, le monitoring du bus de
donnes et des consommateurs des messages de statistiques est toujours rouge,
signalant un incident. Cest pourquoi lquipe systme nose pas rouvrir le service
au public.
Je vais voir lingnieur systme pour laider rtablir le service au plus tt.
Nous essayons de relancer les consommateurs, sans succs. Je tente de lancer un
consommateur la main sans passer par le script dexploitation. Je dcouvre
une erreur (NullPointerException). Elle indique que lexcutable na pas trouv
son chier de conguration. Le lien symbolique vers le rpertoire des chiers
spciques lenvironnement de production nexiste pas. Lingnieur systme le
recre immdiatement la main. Il redmarre les consommateurs et une minute
plus tard le monitoring repasse au vert. Le service est r-ouvert et le trac
reprend.
58
Figure 6.2 Dpassement du seuil prconis de la le
Une situation client dramatique
O en sommes-nous ? La version cible nest toujours pas en production. Le ple
exploitation client est pass en incident majeur (plus de 2h dinterruption de
service + retour arrire). Il veut passer en niveau de vigilance maximale sur la
prochaine mise en production. Cest dire au minimum avec 19 jours de pravis,
avec prsentation des changements, solutions de retour-arrire.
De son ct, le ple marketing-fonctionnel veut publier dans deux semaines une
volution dune importance ingale depuis 7 ans. Pour assurer cette grosse
volution, il faut eectuer 4 mises en production. En comptant 19 jours de
pravis pour chacune, il faudrait 3 mois au lieu des 2 semaines voulues par le
marketing.
Les 5 pourquoi
Une fois le service rtabli, je pars mener une enqute minutieuse, dans lesprit
des 5 pourquoi du lean
1
pour viter la rapparition de lincident.
Pourquoi le lien symbolique na-t-il pas t cr ? Le script shell dinstallation
maintenu par lquipe systme na pas cr ce lien symbolique.
Pourquoi ? Ce script est compos de deux instructions : une vrication de
monitoring et la cration du lien symbolique. Linstruction de vrication choue
et interrompt toute lexcution.
Pourquoi ? Cette instruction se rfre un chemin inexistant.
1. Les 5 pourquoi du lean : Cf. la section Principes Lean du chapitre Leviers de
lamlioration
59
Pourquoi ? Ce script a t mal modi lors dune mise jour du systme de
monitoring.
Une cause profonde
2
a t identie : une maladresse lors dun changement
technique.
Lchec des procdures qualit
Pourtant, dans mon entreprise, il existe un standard pour se prmunir de ce
genre de maladresse, savoir la rptition systmatique en environnement de
pr-production.
Pourquoi la rptition en pr-production na-t-elle pas rvl ce dysfonction-
nement ? Les scripts shell dinstallation qui sy trouvent sont dirents de ceux
en production : ils nont pas t modis.
Une autre cause profonde a t identie : un cart entre les environnements.
Comment fatiguer son ingnieur systme ?
Une autre question subsiste : pourquoi un ingnieur systme, pourtant talentueux,
a-t-il d attendre larrive dun dveloppeur pour recrer un lien symbolique ?
Rponse : lors de lincident, aucune trace napparaissait, ni dans les logs systme,
ni dans la console.
Pourquoi ? Les logs de lapplication partaient vers la sortie standard ( cause du
lien symbolique manquant) et le script dexploitation ignorait la sortie standard.
Figure 6.3 Perte de la sortie standard
Prvenir plutt que gurir
Larbre de causalit
3
indique trois causes racines, en dehors de notre champ
daction.
Nous modions notre code pour quil adresse lingnieur systme un message
explicite en cas de dysfonctionnement. En terme lean, nous ajoutons un andon
4
.
2. Cause profonde en lean : Cf. la section Principes Lean du chapitre Leviers de
lamlioration
3. larbre de cause : lenchanement cause et consquence est reprsent sous forme arbores-
cente. Cf : la section Principes Lean du chapitre Leviers de lamlioration
4. Le andon dsigne une alerte lumineuse pour signaler tout dysfonctionnement au plus
tt et saccompagne dun arrt immdiat. Dans le cas des machines et des outils, lal-
60
Figure 6.4 arbre causal dun incident de production
Figure 6.5 Introduction dun andon dans le script
61
Comme nous avons la main sur le script dexploitation, nous le modions pour
rediriger la sortie standard, jusque-l ignore, vers les logs systmes. Nous
ajoutons galement la capture de lexception NullPointerException de manire
informer lexploitant du problme sur la sortie standard. Pour ne rien laisser au
hasard, nous testons ce message auprs de lingnieur systme pour sassurer de
sa comprhensibilit.
Prochaines investigations mener :
comprendre do vient la dirence entre la pr-production et la production;
comprendre pourquoi lingnieur systme a produit un script dfectueux.
Je suis content davoir compris ce qui stait vraiment pass et davoir trouv
une contre-mesure conome qui empchera le mme dsastre de se reproduire.
Jai la satisfaction davoir pos la premire pierre du long chemin vers le rtab-
lissement de la conance avec notre client.
Quavons-nous fait
Protger immdiatement le client, avant dentamer le cycle Plan-Do-Check-
Act ;
Trouver les causes racines, avec le 5-pourquoi ;
Ajouter un andon dans la chane de dploiement applicative pour que lincident
ne se reproduise pas.
Le rsultat
Notre application est devenue plus exploitable. Elle met un peu plus notre quipe
systme en situation de russir.
Nous avons identi des sources de variabilit prcises, qui vont permettre une
investigation plus pousse.
Ce que jai appris
Je croyais tre impuissant face un incident qui relevait compltement dune
autre quipe, alors quen fait, jai pu apporter une contribution qui, elle seule,
vitera de nouveaux incidents.
En tant que dveloppeur, jai appris quil faut que janticipe aussi le cas o le
systme de log narrive pas sinitialiser.
lumage du andon est automatique en cas danomalie. En informatique, cela voque le con-
cept du Fail-Fast (cf [http ://martinfowler.com/ieeeSoftware/failFast.pdf] (http ://martin-
fowler.com/ieeeSoftware/failFast.pdf)).
62
Scne de crime : du ri dans mes sprints
Chaque anne, mon quipe agile doit assurer la maintenance dun site web
marchand en plus de son activit de dveloppement. Cette activit ponctuelle
perturbe les sprints en cours.
5
Lquipe met tout dabord en place un management visuel pour :
comprendre la situation : les besoins du client et ce quoi elle doit faire
attention lors de la maintenance ;
voir la nature des dysfonctionnements ;
tre capable de ragir en fonction de la criticit des problmes.
Figure 6.6 Suivi des problmes
Du management visuel au Plan-Do-Check-Act (PDCA)
Mme si la situation semble samliorer, des problmes dj corrigs reviennent
danne en anne (espace disque insusant, abilit des statistiques, magasins
qui ne prsentent pas lore. . . ). Lquipe apprend ragir rapidement aux bons
problmes en protgeant le client par des actions immdiates. Malheureusement,
celles-ci ne sont pas prennes.
Comment sy prendre pour que la situation samliore et que les problmes
identis soient corrigs dnitivement ?
5. Cette situation est galement dcrite dans la section Trouvez lindic ! du chapitre
Management Visuel
63
Je dcide de mettre en uvre la technique du Plan-Do-Check-Act (PDCA).
Sur le management visuel, chaque problme gure sous forme dun post-it.
Un membre de lquipe est charg danalyser le problme en profondeur en
utilisant la technique des 5 pourquoi
6
. Cette technique simple permet de
trouver la cause racine du problme.
Ensuite, lquipier propose une contre-mesure pour supprimer cette cause. Il
dtermine galement un indicateur appropri la vrication de lecacit de la
contre-mesure. Suivant le rsultat de la vrication, les procdures sont adaptes
pour intgrer la nouvelle pratique.
Le service de prise de commande ne rpond pas dans les
temps.
Le service de prise de commande rpond en 8 secondes au lieu de 2 secondes.
Le systme de monitoring remonte une alerte sur la console de supervision. Une
premire investigation identie la cause principale : un des serveurs ddis la
prise de commande na plus susamment despace disque.
Lquipe recherche sur le disque la partition incrimine. Elle dcouvre que le
rpertoire /tmp est plein.
Action immdiate : Un dveloppeur vide le rpertoire et tout revient dans
lordre.
Action dnitive : Nous cherchons resoudre le problme en suivant les tapes
du PDCA :
Plan
Impact du problme sur le client nal :
le temps de la prise de commande est rallong de 6 secondes.
il y a un risque que le problme se produise aussi sur les autres machines,
empchant compltement la prise de commande.
Lquipe applique la technique des 5 pourquoi :
Le serveur ne rpond pas.
Pourquoi ? le rpertoire /tmp est plein.
Pourquoi ? les log binaires prennent toute la place. Ce nest pas normal que
les logs binaires soient prsents sur cette machine.
Pourquoi ? la conguration du serveur nest pas correcte
Pourquoi ? la procdure dinstallation ne prcise pas quil ne faut pas activer
les logs binaires sur les serveurs en question
6. Les 5 pourquoi du lean : Cf. la section Principes Lean du chapitre Leviers de
lamlioration
64
Do
Action 1 : supprimer tous les logs binaires de tous les serveurs ddis la prise
de commande.
Lanalyse de la cause racine a permis didentier une seconde action qui devrait
permettre dviter la rapparition du problme.
Action 2 : dsactiver les logs binaires sur tous les serveurs ddis la prise de
commande.
Check
Il ny a plus de log binaires dans le rpertoire /tmp et lespace disque demeure
susant pour que lapplication fonctionne correctement.
Act / Adjust
Aprs vrication du rsultat des actions, la procdure dinstallation des serveurs
de prise de commande est mise jour.
Rsultats
La pratique du PLAN-DO-CHECK-ACT est applique de manire systmatique
tous les problmes rencontrs. Elle a permis damliorer les performances
danne en anne. Le nombre de rclamations client a diminu de 37% en
deux ans pendant que le trac augmentait de 40% et que le nombre de
fonctionnalits augmentait dune dizaine chaque anne.
La diminution du nombre de problmes a permis de limiter limpact de la
maintenance sur la vlocit de lquipe de dveloppement tout en garantissant
la satisfaction de notre client.
Au-del des bnces pour ce projet prcis, jobserve que lenchanement des
cycles Plan-Do-Check-Act fait monter en comptence mon quipe et que les
autres projets se passent mieux.
Quavons-nous fait
Protger immdiatement le client, avant dentamer le cycle Plan-Do-Check-
Act ;
Trouver les causes racines, avec le 5-pourquoi ;
Eectuer une action corrective la racine ;
Prenniser une action damlioration en modiant un standard.
Le rsultat
Nous avons diminu signicativement le volume dincidents.
65
Nous avons un standard corrig qui nous protge de la rcurrence.
Ce que jai appris
Mon quipe a acquis des comptences en administration systme.
Jai dsormais une exprience personnelle de lalignement de lentreprise sur la
satisfaction client par le dveloppement des comptences.
Scne de crime : joue-la courte et prcise
Notre client est mcontent car lquipe de dveloppement dont je fais partie met
deux fois plus de temps quil ne souhaite sur les gros projets.
Figure 6.7 Dpassements de dlais sur nos trois derniers grands projets
Premire hypothse
Pour comprendre o gagner du temps, le Scrum Master propose de visualiser le
problme. Il met une feuille au mur, puis chaque dveloppeur qui constate un
frein ou un blocage le mentionne sur cet emplacement avec une estimation du
temps perdu. Avec beaucoup de discipline, tous les dveloppeurs jouent le jeu.
Au moment o nous compilons les donnes, nous tombons de haut : nous tions
convaincus de trouver un gisement damlioration, mais la mesure rvle moins
de 2h perdues par semaine. Ce nest presque rien compar aux 60 jours hommes
de chaque sprint.
Je ralise que ce nest pas surprenant. Les gens sont sensibles ce qui sort de
lordinaire, mais ne remarquent pas les freins dont ils ont lhabitude.
Deuxime hypothse
Mon Scrum Master a une nouvelle intuition : lquipe passe trop de temps
faire du refactoring. Je trouve pour ma part que lcriture des tests dacceptance
automatiss est chronophage. Qui a raison?
66
Cela mrite une deuxime exprimentation.
Pour claircir ce mystre, pendant plusieurs sprints, je note chaque daily scrum
meeting, sur quoi nous travaillons :
Figure 6.8 Activits et freins en dveloppement
Figure 6.9 Rpartition des activits de dveloppement
Astuce : prparer un modle vierge pour assurer une meilleure pertinence des
observations rcoltes
Constats : les tests dacceptance automatiss ne reprsentent que 5,5% de notre
temps de travail et le refactoring peine 2%. Lhypothse du Scrum Master et
la mienne taient donc toutes les deux fausses.
Llment qui prend le plus de temps est la programmation, avec 40%. Le
contraire aurait t tonnant dans une quipe de dveloppement. Mais cela ne
fait que dplacer le problme : o passe notre temps quand nous programmons ?
Troisime exprimentation
Je lance une troisime exprimentation : linvestigation pendant le pair-
programming.
67
Figure 6.10 Statistiques de rpartition des activits de dveloppement
Pendant 20 demi-journes, le copilote note le temps pass la minute prs.
Figure 6.11 Liste des frottements de lactivit de dveloppement
Avant de faire cette exprimentation, nous pensions passer beaucoup de temps
dans la rdaction des tests unitaires. Dailleurs, des confrres agilistes nous disent
souvent quils passent entre un tiers et la moiti du temps crire des tests. Or,
nous constatons que nous y passons moins de 20% :
Nous imaginions galement perdre beaucoup de temps comprendre et clarier
des spcications, mais cela ne reprsente nalement que 4%.
Champagne ! Nous avons vit de continuer consacrer des mois et des mois
damlioration continue quatre faux problmes, mais ce nest pas tout. Jai vu
que notre gaspillage le plus consquent est de comprendre lexistant. Dsormais,
quand jignore o intervenir pour raliser ma tche, je demande systmatiquement
par quelle classe rentrer dans le code existant et cela me permet daller deux fois
plus vite.
68
Figure 6.12 Synthse de la rpatition des activits de dveloppement
Quavons-nous fait
Convertir une plainte client en un cart quanti.
Formuler des hypothses.
Prparer des formulaires de collecte de donnes.
Tester nos hypothses avec des mesures.
Le rsultat
Jai obtenu des donnes factuelles sur o passe le temps de lquipe.
Mon quipe a conomis une nergie colossale en vitant dinvestir sur des fausses
pistes.
Ce que jai appris
Jai appris un geste qui acclre ma vitesse de dveloppement.
Jai appris une mthode pour identier un potentiel dacclration.
Principes lean
Aux origines
Le pre du lean est convaincu que chacun est rempli dimpressions, de prjugs,
dopinions, qui sont autant dides fausses. Ces ides fausses conduisent des
pertes de temps normes, mais aussi des conits puisque chaque problme
rencontr est loccasion de mettre en opposition les prjugs de chacun.
Il utilise une mthode dapprentissage venue des Etats-Unis pour liminer ces
ides fausses une sorte de TDD (Test-Driven Development) pour lutter contre
les bugs qui limitent nos raisonnements : le Plan-Do-Check-Act ou PDCA.
Le cycle PDCA
69
Figure 6.13 Plan Do Check Act
70
Comme le systme mental de chacun est dirent, lapprentissage ne peut tre
quindividuel. Un cycle Plan-Do-Check-Act est donc port par une personne et
une seule. Le collectif est quand mme prsent, mais dune manire dirente
de lagilit : le porteur va voir une par une les personnes impliques sur leur
terrain pour mieux comprendre ce qui se passe. Il prsente ses raisonnements
pour obtenir des feedbacks. Dans lexemple La mise en production qui ne
devait pas chouer , cest un seul dveloppeur qui claircit le problme en allant
voir les gens. Lexercice est donc individuel mais pas solitaire.
Plutt que de senliser dans un dbat strile qui nait dopinions comme Jean
est un trs bon ingnieur systme, il naurait pas modi ce script sans le tester
ou de gnralits comme le client nest jamais clair dans sa tte , le praticien
du lean est avide de faits : Combien de fois le client na-t-il pas t clair ?
Allons voir lingnieur systme pour savoir ce qui sest eectivement pass.
Quest-ce que le Plan-Do-Check-Act apporte une quipe
agile ?
Le lean fournit donc une mthode pour aronter des problmes complexes
comme :
Ceux qui reviennent nous hanter et que nous narrivons pas vraiment rsoudre
dnitivement. Dans lexemple Du ri dans mes sprints , les dveloppeurs
dpassent la correction rustine et font disparatre toute une classe de problmes
avant mme quils ne surviennent.
Des problmes qui sortent de la zone de contrle de lquipe. Dans lexemple
La mise en production qui ne devait pas chouer , le dveloppeur trouve la
force de traverser les barrires entre production et dveloppement pour creuser
jusquau coeur de lincident.
Le problme est prsent au manager dune manire tellement factuelle quaucune
trace de rancur ny subsiste.
Un dveloppeur peut remettre en cause une pratique de dveloppement contre-
productive sans heurter ses coquipiers.
Toute lquipe a le cur net sur ce qui se passe vraiment sur le terrain comme
dans La mise en production qui ne devait pas chouer o elle se rend compte
que les modications des scripts de monitoring ne sont pas testes.
Enn, le Plan-Do-Check-Act vite dinvestir sur des fausses pistes.
Comment faire en pratique ?
A chaque pas dun Plan-Do-Check-Act, la mthode prconise que le porteur
prsente ce quil a compris un expert du sujet et des acteurs du problme,
pour dtecter dventuelles ides fausses.
71
Plan
Dnir le problme Dans lexemple Joue-la courte et prcise , le client se
plaint dune drive des dlais. Le membre de lquipe pense quil surestime cette
drive. Le lean transforme cette armation en un problme en le visualisant
sous la forme dun cart quanti entre une attente et un constat. Le porteur se
rend compte que les dlais sont gnralement deux fois plus longs que le client
ne le souhaiterait dans le cas des grosses piques
7
:
Figure 6.14 Dpassement des dlais
Qualier limpact Comment juger si le problme mrite lnergie que le
porteur va lui consacrer ? Un bon problme aura un impact signicatif pour le
client ou lentreprise (nancirement ou en terme de stratgie).
Comprendre la situation Pour contrer les croyances errones, le porteur
observe, compte, examine des instances du problme. Cette pratique sappelle
le Go&See ou aller sur le gemba
8
. Elle rpond aux questions A quelle
tape, quel endroit, le problme survient-il ? et Quel est le potentiel
damlioration? .
Pour aider voir le potentiel damlioration, le lean met disposition des outils,
qui sont autant de grilles de lecture pour auter le regard. Le plus connu de ces
outils conceptuels est la notion des 7 gaspillages
9
, cest--dire 7 faons direntes
de gaspiller le temps prcieux dune personne. Le tableau ci-dessous donne
quelques exemples de ces familles dans le contexte du projet de dveloppement
agile.
7. Une pique est un ensemble fonctionnel cohrent de User Stories.
8. Le chapitre De Satisfaire le client Comprendre son attente prsente aussi cette
pratique, mais restreint au primtre du client.
9. Le chapitre De Satisfaire le client Comprendre son attente introduit la notion de
gaspillage par opposition la cration de valeur. La notion prsente ici est plus restreinte, en
lappliquant spciquement au temps de ceux qui crent de la valeur.
72
| Type de gaspillage | Exemples | |- |Surproduction | Ecrire du code qui
nest jamais utilis.
Raliser une User Story plus tt que ncessaire. | Corrections & retouches |
Investigation et correction dun dfaut.
Refactoring exactement inverse celui fait par un autre binme. | Attente |
Attente de la disponibilit de lenvironnement de test.
Attente du rsultat du build.
Lenteur du poste de travail.
Attente dune information ou dune dcision dordre fonctionnel lors de la ral-
isation dune tche. | Stock | Maintenance dun backlog de User Stories non
dveloppes.
Revoir rgulirement les post-it sur un poster Ides damlioration sans
jamais mettre ces ides en uvre. | Gestes inutiles | Navigation dans le code.
Redmarrage de lenvironnement de dveloppement (IDE). | Etapes inutiles |
Deux binmes qui ralisent des tches qui se chevauchent.
| Raliser une tche inutile. | Transport | Reporter des modications entre dif-
frentes branches au sein dun systme de gestion de conguration.
Transmettre des informations dun dveloppeur lautre.
Trouver les causes racines Le porteur va jusqu la cause racine. Dans lex-
emple Du ri dans mes sprints , poser plusieurs fois la question pourquoi
amne dcouvrir une erreur dans la procdure dinstallation de tous les serveurs.
Dans le folklore lean, cette pratique est dsigne par le terme 5 pourquoi .
La consigne littrale est de se poser cinq fois dale la question pourquoi .
Cependant, le chire 5 est une invitation creuser plus que dhabitude, et non
pas une rgle. Il faut aussi se mer de rponses qui scarteraient des faits pour
tendre vers des accusations.
Les enchanements cause-consquence peuvent tre reprsents sous forme dar-
bre.
Figure 6.15 Arbre de causalit
Des hypothses sont ainsi formules et testes. Dans lexemple Joue-la courte
73
et prcise , la croyance une quipe extreme programming passe la moiti de
son temps crire des tests est invalide.
Formuler puis choisir des contre-mesures Une fois les causes bien com-
prises, le porteur fait un exercice de pense divergente : il imagine un maximum
de contre-mesures pour adresser les direntes causes. Le lean privilgie les
contre-mesures ingnieuses, conomes et dont leet peut tre vri rapidement.
Lexemple La mise en production qui ne devait pas chouer illustre cet
tat desprit de lamlioration continue. Le dveloppeur aurait pu dire cest
inadmissible ce que fait lquipe systme, eux de samliorer en ralignant
pr-production et production, en testant les scripts dinstallation . Pourtant,
il choisit cote que cote dapporter une petite contribution. Il russit ainsi sa
journe double titre : en rtablissant le systme le matin et en amliorant le
feedback de lapplication le soir.
Formuler la mthode de Check Le porteur explique comment il va vrier
factuellement si sa contre-mesure fonctionne.
Do
La phase Do correspond la mise en uvre de la contre-mesure choisie.
Check
Le Check est la vrication factuelle de limpact de la contre-mesure, comme
prvu durant le Plan. Un Check peut tre soit OK, si les objectifs viss sont
atteints. Sinon il est NOK.
Dans lexemple Du ri dans mes sprints , lquipe mesure une diminution
de 37% des incidents. Son Check est OK.
Act
Durant la phase Act, le porteur prennise les enseignements quil tire de ses
exprimentations. Dans lexemple prcdent, lquipe corrige la procdure din-
stallation de ses serveurs.
Que le Check soit OK ou NOK, il y a toujours quelque chose apprendre dune
exprimentation bien mene. Le plus beau succs est de pouvoir se dire Jtais
persuad de X, en fait, javais tort ! .
Premiers pas
La rsolution de problme est une technique puissante mais manier avec
prcaution. Cest pourquoi nous vous invitons suivre scrupuleusement les 7
tapes qui suivent.
74
Choisir un sujet
Choisissez un sujet qui est important pour vous. Posez-vous la question de la
dernire dicult majeure que vous avez rencontre ou du problme qui revient
le plus souvent.
Formuler le problme
Formulez-le sous forme dcart entre :
ce que vous constatez
ce que vous voudriez la place.
Identier limpact
Rpondez la question : Pourquoi est-ce important ?
Vriez quil y a un impact signicatif pour le client ou pour lentreprise.
(cf. chapitre De Satisfaire le client Comprendre le client ).
Dnir lcart au standard
Quand ce problme se manifeste, quobservez-vous ?
Chercher les causes racines
Quest-ce qui provoque ce problme ? numrez toutes les hypothses qui vous
semblent plausibles.
Limportant est de trouver des hypothses testables.
Vrier les hypothses
Trouvez le moyen le plus simple et rapide de conrmer vos hypothses.
Dnir le rsultat attendu
Avant dentreprendre les actions correctives, dnissez o, quand et comment
vous pourrez vrier quelles auront port leurs fruits.
Aller plus loin
Toyota Kata
Mike Rother Edition McGraw-Hill
75
Figure 6.16 Toyota Kata
Managing to learn
John Shook Edition Lean Enterprise Institute, Inc.
Figure 6.17 Managing to learn
Understanding A3 thinking
Durward K. Sobek II., Art Smalley Edition Productivity Press
76
Figure 6.18 Understanding A3 thinking
77
Chapitre 7
Conclusion
Le lean est une pratique. La valeur de ce guide rside dans les premiers pas ,
les exercices que nous avons slectionns pour vous. Commencez les mettre
en uvre ds maintenant, pas aprs pas, et venez partager vos dclics et vos
questions avec les autres praticiens pour que nous progressions tous ensemble.
Nous posterons sur le site ci-dessous les informations ncessaires pour nous
retrouver :
http://www.leanagilecamp.fr
78
Chapitre 8
Livres de rfrence
Le management lean
Michael Ball, Godefroy Beauvallet Edition Pearson
La pratique du lean management dans lIT
Marie-Pia Ignace, Christian Ignace, Rgis Medina et Antoine Contal Edition
Pearson
79
Figure 8.1 livre la pratique du lean IT
80
Chapitre 9
Ressources de rfrence
Glossaire lean
http://www.lean.enst.fr/wiki/bin/view/Lean/GlossaireLean
Blog Lean et SI
http://leansi.wp.mines-telecom.fr/
81