Professional Documents
Culture Documents
quipes agiles
1 Avant-propos 4
2 Inauguration du pont 5
3 Structure du livre 6
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
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 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
6
Chapitre 4
De Satisfaire le client
Comprendre son attente
Pratiques agiles
Linspiration du manifeste
7
redfinir les prochains lments produire.
Focus produit
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.
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.
9
Le logiciel oprationnel
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).
10
Figure 4.3 Exploration du right product
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.
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.
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
Dsillusion
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.
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.
15
Analyse du problme
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
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.
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
18
Figure 4.7 Les cinq attentes du client
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.
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.
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
Premiers pas
Pour renforcer votre comprhension des attentes de vos clients, nous proposons
ces exercices :
Pour votre projet actuel, allez voir trois utilisateurs distincts sur leurs lieux de
travail
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 ?
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 ?
23
Chapitre 5
De Management visuel
Visualiser le challenge et les
problmes
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
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.
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
27
Figure 5.5 Un poster sur-mesure
28
Figure 5.6 Exemples daffichage dune quipe crative
Le contexte
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*
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
Visualiser le challenge
34
Figure 5.11 Objectif 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 :
36
Figure 5.14 Standard de dfinition dune demande
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.
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.
Contexte
Comme dans beaucoup dquipes agiles nous avons un burndown chart ditra-
tion :
39
Figure 5.18 Evolution du reste faire au fil des sprints
Recherche de cause
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.
42
dune corrlation entre les deux phnomnes (voir les courbes du 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
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
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
Comprendre ensemble
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
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.
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 :
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).
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
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.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
Agir ensemble
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
Agir ensemble
52
Aller plus loin
53
54
Chapitre 6
De lamlioration continue
Trouver les leviers de
lamlioration
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.
56
La communication interpersonnelle
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.
58
Figure 6.2 Dpassement du seuil prconis de la file
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.
60
Figure 6.4 Arbre causal dun incident de production
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.
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.
Plan
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
Act / Adjust
Rsultats
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.
Figure 6.7 Dpassements de dlais sur nos trois derniers grands projets
Premire hypothse
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 :
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
67
Figure 6.10 Statistiques de rpartition des activits de dveloppement
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.
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.
71
Plan
Dfinir le problme
Qualifier limpact
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.
73
Figure 6.15 Arbre de causalit
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.
Do
Check
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
Formuler le problme
Identifier limpact
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.
Toyota Kata
Managing to learn
Understanding A3 thinking
76
Figure 6.17 Managing to learn
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
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