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.05 23 octobre 2014

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 pro-

blmes 24
Les pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Scne de crime : trouvez lindic ! . . . . . . . . . . . . . . . . . . . . . 29
Scne de crime : tous coupables . . . . . . . . . . . . . . . . . . . . . . 34
Scne de crime : le burdown tait rouge . . . . . . . . . . . . . . . . . 39
Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
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 rififi dans mes sprints . . . . . . . . . . . . . . . . 63
Scne de crime : joue-la courte et prcise . . . . . . . . . . . . . . . . . 66
Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

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 Modification 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 diffrente
de lorganisation. Une vision base sur une conviction :

Le changement vers une organisation la fois plus efficace et plus

respectueuse des personnes est possible. Ce changement nat de la
somme des apprentissages individuels.
Lamlioration continue, en dfinitive, 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 frustration. 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 difficults 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 fiers.
Ces nouvelles comptences vous apporteront le savoir-faire ncessaire pour
insuffler les changements vitaux au sein des organisations.
Ce livre se structure autour de trois apprentissages fondamentaux. Pour chacun
dentre eux, des praticiens agiles vous racontent comment, en appliquant dautres
pratiques, en adoptant dautres postures, en sentranant fonctionner diff-
remment, 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.
Enfin, des prconisations de premiers pas vous guident vers la mise en pratique.
Ce livre est n 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 fin 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 fig. Lquipe doit
fournir au client toute linformation qui lui permette doptimiser la production de
valeur en fonction de leffort fourni. En contrepartie, le client est co-responsable
de latteinte de lobjectif. Il simplique de manire rgulire dans la redfinition
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 tra-
vailler 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
identifiable 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 afin de

7
redfinir les prochains lments produire.

Focus produit

La dmarche traditionnelle prsuppose que le besoin du client peut tre captur.

Il est clairement identifi, nvoluera plus et fait lobjet de spcifications dtailles.
Adoptant une position trs diffrente, 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 confies au chef de projet vers un nouveau triumvirat : quipe,
Scrum Master et Product Owner.

Figure 4.1 Le Triumvirat Agile

La mise en pratique quotidienne

Le bon produit ?

Comme nous lavons rappel, lquipe agile sattle en priorit au dfi de li-
vrer rapidement et rgulirement des fonctionnalits au client. Cela permet de
confronter 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.

Spcifier 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 spcification 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 col-

labore avec le client en vue de maximiser la valeur ajoute au produit. Ensemble,
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 leffort ncessaire sa ralisation.
En agilit, lestimation de leffort nest pas laffaire dun seul individu. Les
personnes devant raliser sont les mieux places pour estimer. La pratique du
Planning Poker permet par exemple dobtenir une estimation collective de leffort
de ralisation, tout en contribuant diffuser 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 fin ditration permet lensemble des
acteurs de se runir pour passer en revue les lments compltement termins
(conformment la dfinition de termin tablie au pralable avec le client).
Cette runion permet de vrifier ladquation de la production au besoin. Les
participants obtiennent des informations qui sont exploites lors de la planification
du contenu de la prochaine itration.

Le bon produit et le maximum de valeur ?

Seule la mise disposition des lments finaliss auprs des utilisateurs finaux
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 dfinir 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 spcification 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 identifi 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 et ventuelles allergies, puis
examine 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 effectuer 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.

Vrification 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 effectue 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 spcifiques 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 confirmer 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 identifier 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 autoch-
tones . Lorsquon visite Venise lt, plutt que de suer dans un bain de foule
sur la place Saint Marc, autant aller siroter un Spritz (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.
Profitons 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 difficult 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 Eiffel.

La leon tirer

Lhistoire de cette ide gniale se termine ici. Mais pas celle de notre quipe
dentrepreneurs : quelques minutes leur ont suffi pour trouver une nouvelle ide
gniale. Mais cette fois-ci, en commenant par une visite terrain 4 avant de
semballer.
Voil une belle fin, 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
considrait pourtant comme une vidence, ne correspond pas la ralit. Cette
illusion dvidence, renforce par le confort du bureau, retient bien des entrepre-
neurs, 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.
Quavons-nous fait ?
aller voir plusieurs touristes, les utilisateurs potentiels ;
confronter ses hypothses avec la ralit du terrain.
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.
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
Ce que jai appris
La manire la plus efficace 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 finaux. Cela provoque une tension avec le management, notre
commanditaire est furieux, et les relations avec les exploitants sont difficiles.

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
diffrents. Je les compte et les catgorise. Cela constitue un bulletin de sant
que jaffiche sur le mur lentre de notre War Room.

Figure 4.6 Bulletin de sant du projet Condor

5. Nous appelons signalisation un incident remont par lutilisateur.

15
Analyse du problme

Les trois catgories les plus volumineuses sont :

1. formation utilisateur : les utilisateurs ne comprennent pas comment

fonctionne lapplication ;
2. rseau et plateforme : pas directement lie des dfauts logiciel ;
3. mystre : nous ne savons pas identifier lorigine de la signalisation.

Premire surprise, le grand gagnant est la catgorie mystre . Deuxime

surprise, il y a finalement 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.

Identifier lorigine

Dsaronns par le flou de ces tickets mystre, nous dcidons davancer sur
notre problme en nous donnant les moyens didentifier 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 figurer
(client, identifiant dappel, raison de lerreur avec un lment de contexte).
Nous nous rendons compte quil est difficile 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 diffrentes.
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 file 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.

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.

16
Comme certains tickets sont toujours inexpliqus, nous dcidons denvoyer un
binme en observation chez le client ayant le trafic 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 effet 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 file dattribution des appels, afin 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 afficher une information de leur outil de CRM. Ce faisant,
sa main effleure 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 configuration 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.
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.
6. gemba dsigne lendroit o les choses se passent. Cf. la section Principe lean de ce
chapitre.

17
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 dfinitive 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 dfinition 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 difficult sexplique de plusieurs manires :
Il lui est difficile 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 efficaces pour cibler les
besoins rels du client et affiner la comprhension de ses prfrences.
Tout dabord, dans un contexte de dveloppement logiciel, il faut identifier quels
sont les vrais clients du projet. Il en existe trois grandes familles :
Lutilisateur final, celui qui va profiter directement le logiciel au quoti-
dien.
Le commanditaire, qui paie la prestation de dveloppement et en attend
un retour conomique. Sa satisfaction dpend de celle de lutilisateur final,
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.
Chacun de ces clients a ses propres attentes, quil faut identifier et satisfaire. Le
lean offre une structure pour guider cette exploration, base sur cinq axes :
Les pratiques qui suivent constituent un bon point de dpart pour entamer ce
travail de dtective.

18
 Figure 4.7 Les cinq attentes du client

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 ?
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

19
essentiellement sur lidentification 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.

Dfinir le problme rsoudre et la faon de mesurer le

succs

Plutt que de dfinir 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 dfinir la faon dont il sera possible de
vrifier que le projet la bien rsolu. Lquipe se dote dindicateurs objectifs qui
refltent ce succs.
Quelques exemples :
Amliorer la qualit : taux derreur commis par les utilisateurs, volume
dincidents.
Augmenter les ventes : taux dajout darticles dans un panier dun site de
e-commerce.

20
 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 dfinir des problmes clairs rsoudre ensemble, de mieux choi-
sir les fonctionnalits et les sujets damlioration, et de vrifier que les ides
damlioration 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.

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 fin 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,
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.
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
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 clarifie 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, sauve-
garde, 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 ?

Clarifiez le problme et mesurez le succs

Pour votre projet actuel, menez linvestigation pour rpondre ces questions :
Quel est le bnfice 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.

22
Exprimentez pour valider les prfrences du client

Prenez les stories livres de votre dernire itration et posez-vous ces questions :
Quel est le bnfice attendu de ces stories ?
Quelles observations devez-vous faire sur le terrain pour vrifier 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

Figure 4.8 livre lean au service du client

23
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 fichiers 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 . Laffichage
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 affecte les tches, mais
lquipe elle-mme.

24
Figure 5.1 Un affichage mural (radiateur dinformation) dans un bureau de
dveloppeurs

25
Vis--vis de lextrieur, les indicateurs, volontairement simples, donnent une
vision synthtique de ltat du projet et vitent le reporting coteux et inefficace
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 affiches sur mesure pour
rpondre leurs problmatiques spcifiques.
Puisque la technologie utilise (papier, feutres et traits main leve) est rudi-
mentaire, il est facile et rapide dadapter les affichages aux besoins qui mergent,
et dexprimenter de nouvelles approches.
Les rtrospectives sont des moments privilgis pour faire voluer les affichages,
pour en crer et en supprimer. Tous les formats sont bons tant que les lments
affichs 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. . .

26
 Figure 5.3 Niko niko

Figure 5.4 Burndown chart

27
Figure 5.5 Un poster sur-mesure

28
 Figure 5.6 Exemples daffichage dune quipe crative

Une pratique efficace 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, dfinition 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 offre Traiteurs de fin danne. Le site doit offrir 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 fiabilit sur la commande de 100% et
un taux contractuel de disponibilit au-del de 95%. Je dois donc offrir mon
client un service de maintenance, cependant mes quipes agiles actuelles nont
aucun cadre de travail pour assurer ce nouveau type de prestation.

29
 Figure 5.7 Radiateur dinformations existant pour grer les projets web

Pendant les 3 annes suivantes, nous russissons au prix de gros efforts tenir nos
engagements. En effet, 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 afin 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

30
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
douverture 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 fix. Pour la fermeture, il est trs important
darrter le service pour chaque magasin aux heures dfinies 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, afin 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
envoyes.
La disponibilit du site :
Un indicateur quotidien OK/NOK sur laccessibilit au catalogue de
produits et la commande proprement dite.
Un indicateur quotidien OK/NOK sur le fonctionnement des fonction-
nalits du site (nuage de tags, envoi un ami,. . . )
Les indicateurs se prsentent comme suit :
Nous affichons 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 confiance avec notre client qui reconduit chaque anne
notre partenariat.
2. Cf. Section Principes Lean du chapitre Leviers de lamlioration

31
Figure 5.8 Structure de nos indicateurs de performance*

Figure 5.9 Structure de notre management visuel

32
 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 dfinitive via le PDCA 3
Le rsultat
- Un site e-commerce avec un haut niveau de fiabilit
- Des projets livrs plus vite, car moins de perturbations extrieures
Ce que jai appris
En qualifiant 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 saffineront dans le temps pour mieux correspondre
lattente du client.
33
Scne de crime : tous coupables

Contexte

Suite la fusion de plusieurs organismes, une grande socit de services se voit

confier la ralisation dun nouveau systme unifi 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 cotisa-
tions, les remboursements et lencours. Il faut trs rapidement clarifier 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 final. Elle doit galement parvenir livrer des lots intermdiaires toutes
les deux semaines pour rassurer le client.
Ce challenge 4 se traduit tout dabord par laffichage dun objectif de production
pour la premire itration :
Lquipe analyse les principales tapes de son flux 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 clarifier lobjectif de la journe, pour mettre
en place un systme complet de flux tir. Cependant ce stade, linformation permet dj
lquipe de commencer identifier ses principaux problmes.

34
 Figure 5.11 Objectif de production

Figure 5.12 Tableau reprsentant le flux de production

35
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 final, 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 confirment que la majorit des dvelop-
peurs sont en attente de clarification sur des questions dordre fonctionnel. Ces
demandes sont transmises par lintermdiaire dun outil lectronique, mais la
plupart restent indfiniment 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 15 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 Affichage des obstacles sur les tches

Ensuite, lquipe met au point un standard de rdaction dune fiche 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

36
Figure 5.14 Standard de dfinition dune demande

Figure 5.15 Tableau de suivi des obstacles

37
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 effectu sur les obstacles non levs. Les fiches des obstacles non
rsolus sont dplaces en fonction de leur niveau durgence (voir tableau de suivi
des obstacles).
Ds quun obstacle est lev, sa fiche est dplace vers un espace spcifique
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
vrifier visuellement au quotidien que cette quipe nest pas source de blocage
de leur processus, les tensions sont apaises, les relations fluidifies.
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 :
Dfinir 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 flux de dveloppement
9. Cf. Section Principes Lean du chapitre Management visuel

38
 Agir ensemble :
Comprendre les typologies de problmes, les rendre visible et sorgani-
ser tous les jours pour les attaquer un par un
Le rsultat
Les obstacles ont t levs, ce qui a permis lquipe de sortir ses tches
lheure.
Ce que jai appris
Lquipe communique et travaille plus efficacement 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 fin de sprint :
10. Cf. Section Principes Lean du chapitre Leviers de lamlioration

39
 Figure 5.18 Evolution du reste faire au fil des sprints

Recherche de cause

Peut-tre ne consacrons-nous pas le temps prvu initialement raliser nos

sprints ? Certains membres de lquipe interviennent en effet sur plusieurs ac-
tivits (management, runions transverses. . . ). En tant que Team Leader, je
nchappe pas cet parpillement.

Enrichissement du management visuel

Pour clarifier la situation, nous enrichissons notre management visuel en ajoutant

un graphique des jours consomms, copie quasi-conforme de notre burndown
chart ditration.
Notre hypothse se confirme : 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.

Action : suivi des carts

Il faut maintenant agir. Je trace, sprint aprs sprint, la diffrence entre les jours
consomms et les jours planifis.
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

40
 Figure 5.19 Burndown chart des jours consomms

Figure 5.20 Suivi de la diffrence entre les jours consomms et les jours
planifis

41
suis intervenu sur telle tche toute la journe, le dveloppeur surligne en fluo
une journe supplmentaire consomme sur la ligne de Romain.

Figure 5.21 Suivi du nombre de jours consacr au sprint

Chaque couleur reprsente un jour de la semaine : bleu pour le premier Lundi

(Lu 17/6), rouge pour Mardi, vert pour Mercredi,. . .

Figure 5.22 Couleurs associes aux jours de litration

Ce suivi permet dalerter Romain : Attention, il ne reste que 2 jours et il te

reste 1,5 jours consacrer au sprint.

Linformation affiche 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 fin 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 confirme lhypothse

42
dune corrlation entre les deux phnomnes (voir les courbes du Suivi des
carts en fin ditration).

Figure 5.23 Suivi des carts en fin ditration

Par contre, nous narrivons pas encore tenir 100% de nos engagements du sprint.
En effet les tches de dveloppement saccumulent dans la case A valider ,
dernire tape de notre kanban et lquipe des spcifications ne les valide pas
toutes avant la fin du sprint.

Suite de lhistoire

Les deux quipes se marirent et eurent beaucoup de stories finies en fin de

sprint.
Les quipes de spcification et de dveloppement dcident de fusionner leur
management visuel et leur daily meeting. Les dbuts sont difficiles, mais partir
du sprint 15.1, elles russissent samliorer drastiquement en se focalisant sur
les stories valider plutt que sur de nouvelles spcifications :

Figure 5.24 Evolution du reste faire la suite dune action damlioration

Quavons-nous fait ?

43
 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
Planifier sa journe en fonction (ex : privilgier le dveloppement
plutt que des tches moindre valeur ajoute telles 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
planifier 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.

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 satis-
faction des clients.
Partager les difficults et les pistes damlioration de manire objective
afin que chacun comprenne comment il peut contribuer lamlioration.
Lapproche lean du management visuel permet de franchir un palier sur trois
sujets :
Identifier 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 difficults rencontres.

44
 Collaborer avec les autres quipes de manire efficace. 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 :

Comprendre ensemble

Figure 5.25 Le triangle du management visuel lean

La construction et lutilisation du management visuel amnent lquipe dve-

lopper 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.

45
Le client

Dans un premier temps, lquipe commence par identifier clairement ses clients 11 .
Ensuite, elle dfinit 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 refltait 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 dfinit 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
final, cest--dire du point de vue du client. Les indicateurs dfinis doivent donc
couvrir les sujets suivants :
Qualit du service ou produit livr : lquipe a-t-elle russi livrer la
bonne fonctionnalit du premier coup ?
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
burndown tait 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 spcifiques 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 dfinit 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.
11. Cf. Section Principes Lean du chapitre Attentes du Client

46
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 affiche aussi une matrice de comptences de tous ses membres, ainsi
quun programme de formation, lobjectif de dveloppement des comptences
tant clair pour chacun.

Figure 5.26 Matrice des comptences de lquipe

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 diffrentes 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 flux
de ses activits comprenant lobjectif du jour et la distribution des tches, ainsi
que la performance. Lobjectif est dtre alert immdiatement en cas danomalie
afin de ragir rapidement.

Flux dactivit

Typiquement, les quipes agiles utilisent des taskboards pour organiser leurs
sprints et visualiser le flux des tches.

47
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
insuffisamment 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 :
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
rendues visibles, et comment. Chaque quipe fait voluer son management visuel
au gr de ses besoins et de son niveau de maturit.
Dans certains contextes spcifiques, il peut tre utile de mettre en place un visuel
un peu diffrent. Ci-dessous, deux possibilits :

48
 1. Un visuel gros volumes , utilis dans des phases de projet qui com-
portent des tches rptitives par exemple une migration de donnes
manuelles. Lquipe se donne des objectifs chiffrs et vrifie plusieurs fois
par jour si elle les atteint ou pas (exemple : cration et excution de tests
fonctionnels).

Figure 5.27 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.

Limage ci-aprs 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

49
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 afin de faire merger les carts de performance, ce qui forme
la dfinition dun problme .

Figure 5.28 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.
Dautres indicateurs ne se prtent pas une reprsentation en burndown chart.
Le modle gnrique ci-aprs constitue une bonne faon de reprsenter un
indicateur :

Figure 5.29 Structure dindicateur type pour le suivi dune valeur unique qui
volue dans le temps

50
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 dfinition
Penser vrifier le rsultat des actions mises en uvre

Figure 5.30 Tableau de suivi des problmes

Agir ensemble

Le management visuel favorise lauto-organisation de lquipe afin 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 offre loccasion de
partager ses problmes. Le groupe se rorganise pour rsoudre les plus bloquants
sans perturber le bon droulement du sprint ni surcharger les dveloppeurs.
Son management visuel met en vidence diffrents types de problmes. Du plus
simple, qui ncessite une action rapide de type just do it , au plus complexe
ncessitant une rflexion plus profonde. Dans lexemple 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 reconfigurer et affecter certains de ses membres spcifiquement son
analyse et sa rsolution.

51
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 fin 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 dfinissent votre challenge.

Voir ensemble

Mettez-vous devant votre management visuel et voyez avec lensemble de lquipe :

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 ?

52
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
management visuel
Chapitre 6 Process Indicators pour comprendre les indicateurs de
performance ( 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 manage-
ment 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 lidentification 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 rflchir, lquipe cre
lespace ncessaire pour le choix dactions damliorations.

Les domaines privilgis damlioration

Au fil 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 inefficientes. Cest
la raison pour laquelle on peut trouver des pratiques agiles dans ces diffrents
domaines. En voici quelques exemples significatifs.

55
Lorganisation du travail

Comme le mcanicien qui sait reprer les anomalies dans le bruit rptitif du
moteur, lquipe identifie les effets 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 mergent, garant de lvolutivit du code. Cela a pour effet
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 bnfices 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 privi-
lgi. 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) afin de guider les quipes dans lamlioration de leur efficacit.

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 sefforcer 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 lidentification 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 prometteuses : Le bnfice attendu important. Ce bnfice 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
coteuses ou en dehors du champ daction.
elle remporte ladhsion : Cest laction qui fait consensus parmi les
participants 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 rollback effectu 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 fichier de configuration. Le lien symbolique vers le rpertoire des fichiers
spcifiques 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 trafic
reprend.

58
 Figure 6.2 Dpassement du seuil prconis de la file

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 effectuer 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 vrification de
monitoring et la cration du lien symbolique. Linstruction de vrification 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 modifi lors dune mise jour du systme de
monitoring.
Une cause profonde 2 a t identifie : 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 dysfonctionne-
ment ? Les scripts shell dinstallation qui sy trouvent sont diffrents de ceux en
production : ils nont pas t modifis.
Une autre cause profonde a t identifie : 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 modifions 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, lallu-

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 modifions 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
quil est comprhensible.
Prochaines investigations mener :
comprendre do vient la diffrence entre la pr-production et la produc-
tion ;
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 peu coteuse qui empchera le mme dsastre de se reproduire.
Jai la satisfaction davoir pos la premire pierre du long chemin vers le rta-
blissement de la confiance 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 identifi 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.

mage du andon est automatique en cas danomalie. En informatique, cela voque le concept
du Fail-Fast (cf [http ://martinfowler.com/ieeeSoftware/failFast.pdf] (http ://martinfow-
ler.com/ieeeSoftware/failFast.pdf)).

62
Scne de crime : du rififi 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 insuffisant, fiabilit des statistiques, magasins
qui ne prsentent pas loffre. . . ). 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
identifis soient corrigs dfinitivement ?
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 figure 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 vrification de lefficacit de la
contre-mesure. Suivant le rsultat de la vrification, 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 identifie la cause principale : un des serveurs ddis la
prise de commande na plus suffisamment 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 dfinitive : Nous cherchons resoudre le problme en suivant les tapes
du PDCA :

Plan

Impact du problme sur le client final :

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 configuration 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 didentifier 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

suffisant pour que lapplication fonctionne correctement.

Act / Adjust

Aprs vrification 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 trafic 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 bnfices 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 ;
Effectuer une action corrective la racine ;
Prenniser une action damlioration en modifiant un standard.
Le rsultat
Nous avons diminu significativement 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 clarifier
des spcifications, mais cela ne reprsente finalement 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 quantifi.
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 identifier 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 conflits 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 diffrent, 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 diffrente
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 nat dopinions comme Jean
est un trs bon ingnieur systme, il naurait pas modifi 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 effectivement pass.

Quest-ce que le Plan-Do-Check-Act apporte une quipe

agile ?

Le lean fournit donc une mthode pour affronter des problmes complexes
comme :
Ceux qui reviennent nous hanter et que nous narrivons pas vraiment
rsoudre dfinitivement. Dans lexemple Du rififi 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 d-
veloppeur 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 modifications des scripts de monitoring ne sont pas testes.
Enfin, 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

Dfinir 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 affirmation en un problme en le visualisant sous la forme dun
cart quantifi 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

Qualifier limpact

Comment juger si le problme mrite lnergie que le porteur va lui consacrer ?

Un bon problme aura un impact significatif pour le client ou lentreprise
(financirement 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 affuter le regard. Le plus connu de ces
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.

72
outils conceptuels est la notion des 7 gaspillages 9 , cest--dire 7 faons diffrentes
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.

Type de gaspillage

Surproduction
Raliser une User Story plus tt que ncessaire.
Corrections & retouches
Refactoring exactement inverse celui fait par un autre binme.
Attente
Attente du rsultat du build.
Lenteur du poste de travail.
Attente dune information ou dune dcision dordre fonctionnel lors de la ralisation dune tche.
Stock
Revoir rgulirement les post-it sur un poster Ides damlioration sans jamais mettre ces ides en uvr
Gestes inutiles
Redmarrage de lenvironnement de dveloppement (IDE).
Etapes inutiles

Transport
Transmettre des informations dun dveloppeur lautre.

Trouver les causes racines

Le porteur va jusqu la cause racine. Dans lexemple Du rififi 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 daffile la question pourquoi .
Cependant, le chiffre 5 est une invitation creuser plus que dhabitude, et non
pas une rgle. Il faut aussi se mfier de rponses qui scarteraient des faits pour
tendre vers des accusations.
Les enchanements cause-consquence peuvent tre reprsents sous forme
darbre.
Des hypothses sont ainsi formules et testes. Dans lexemple Joue-la courte
et prcise , la croyance une quipe extreme programming passe la moiti de
son temps crire des tests est invalide.
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 spcifiquement au temps de ceux qui crent de la valeur.

73
 Figure 6.15 Arbre de causalit

Formuler puis choisir des contre-mesures

Une fois les causes bien comprises, le porteur fait un exercice de pense divergente :
il imagine un maximum de contre-mesures pour adresser les diffrentes causes.
Le lean privilgie les contre-mesures ingnieuses, conomes et dont leffet peut
tre vrifi 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 vrifier 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 vrification 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.

74
Dans lexemple Du rififi 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 dins-
tallation 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.

Choisir un sujet

Choisissez un sujet qui est important pour vous. Posez-vous la question de la

dernire difficult 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.

Identifier limpact

Rpondez la question : Pourquoi est-ce important ?

Vrifiez quil y a un impact significatif pour le client ou pour lentreprise. (cf. cha-
pitre De Satisfaire le client Comprendre le client ).

Dfinir lcart au standard

Quand ce problme se manifeste, quobservez-vous ?

75
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.

Vrifier les hypothses

Trouvez le moyen le plus simple et rapide de confirmer vos hypothses.

Dfinir le rsultat attendu

Avant dentreprendre les actions correctives, dfinissez o, quand et comment

vous pourrez vrifier quelles auront port leurs fruits.

Aller plus loin

Toyota Kata

Mike Rother Edition McGraw-Hill

Figure 6.16 Toyota Kata

Managing to learn

John Shook Edition Lean Enterprise Institute, Inc.

Understanding A3 thinking

Durward K. Sobek II., Art Smalley Edition Productivity Press

76
 Figure 6.17 Managing to learn

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