Petit guide de management lean lusage desquipes agiles

crit par un collectif de dix auteurssous la houlette bienveillante de Rgis Medina

Version 1.04 4 septembre 2013

Table des matires

1 Avant-propos 4

2 Inauguration du pont 5

3 Structure du livre 6

4 De Satisfaire le client Comprendre son attente 7

Pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Scne de crime : apparition mystrieuse au cabinet dentaire . . . . . . 10

Scne de crime : vie et mort dune ide gniale . . . . . . . . . . . . . 13

Scne de crime : la catgorie mystre du projet Condor . . . . . . . . . 15

Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 De Management visuel Visualiser le challenge et les prob-lmes 25

Les pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Scne de crime : trouvez lindic ! . . . . . . . . . . . . . . . . . . . . . 30

Scne de crime : tous coupables . . . . . . . . . . . . . . . . . . . . . . 35

Scne de crime : le burdown tait rouge . . . . . . . . . . . . . . . . . 40

Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

1

6 De Lamlioration continue Trouver les leviers de lamliora-tion 55

Les pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Scne de crime : la mise en production qui ne devait pas chouer . . . 58

Scne de crime : du rififi dans mes sprints . . . . . . . . . . . . . . . . 63

Scne de crime : joue-la courte et prcise . . . . . . . . . . . . . . . . . 66

Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7 Conclusion 78

8 Livres de rfrence 79

Le management lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

La pratique du lean management dans lIT . . . . . . . . . . . . . . . 79

9 Ressources de rfrence 81

Cette uvre est mise disposition selon les termes de la Licence CreativeCommons Attribution - Pas dUtilisation Commerciale - Pas de Modification 3.0non 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 diffrentede lorganisation. Une vision base sur une conviction :

Le changement vers une organisation la fois plus efficace et plusrespectueuse des personnes est possible. Ce changement nat de lasomme des apprentissages individuels.Lamlioration continue, en dfinitive, est celle des comptences dechaque 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, personnepar personne, en allant sur le terrain pour aider chaque collaborateur russir sa journe. Cela amne chacun crer plus de valeur pourses clients, son entreprise et la socit, et trouver ainsi un sens sontravail.

Le chemin vers cet idal a t trac par nos prdcesseurs pendant plusieursdcennies, et consign sous la forme de principes et de pratiques qui ont pris lenom de lean .

Ce savoir-faire prcieux nous a t transmis par Marie-Pia Ignace et MichaelBall. Nous vous le transmettons notre tour, en esprant quil vous apporterales mmes moments de satisfaction, les incroyables dclics qui vous feront prendrede la hauteur.

Rgis Medina

4

Chapitre 2

Inauguration du pont

Depuis plusieurs annes, lesprit et les pratiques agiles vous ont permis damliorervotre satisfaction professionnelle et la performance de vos quipes.

Mais voil : il reste encore des sources de frustrations. Les autres quipes rsistent,les managers ne sponsorisent pas vos initiatives de changement, les clients seplaignent. Il doit bien exister des moyens damliorer les choses, mais commentles trouver ?

En vous entranant aux pratiques lean slectionnes dans ce livre, vous apprendrez :

trouver les leviers de lamlioration qui amneront vos quipes un autreniveau de performance ;

- rsoudre les difficults que vous rencontrez dans vos relations avec dautresquipes ou le management ;

livrer des logiciels qui amliorent la vie de vos utilisateurs et dont vous pouveztre fiers.

Ces nouvelles comptences vous apporteront le savoir-faire ncessaire pourinsuer les changements vitaux au sein des organisations.

Ce livre se structure autour de trois apprentissages fondamentaux. Pour cha-cun dentre eux, des praticiens agiles vous racontent comment, en appliquantdautres pratiques, en adoptant dautres postures, en sentranant fonctionnerdiffremment, ils ont trouv des solutions simples des problmes qui paraissaientcomplexes.

Puis des experts dcrivent les principes lean mis en uvre dans les histoiresprsentes.

Enfin, des prconisations de premiers pas vous guident vers la mise en pratique.

Ce livre est n de du dsir de praticiens agiles ayant expriment le managementlean de partager les richesses surprenantes de ce nouveau continent.

Nous souhaitons transmettre ce que nous avons appris lors de notre voyageinitiatique. 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 leurspratiques. Ils dcrivent leur contexte, les exercices quils appliquent, et cequils y gagnent. A la fin de chaque cas, nous analysons et dveloppons lesprincipes 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 desproccupations du dveloppement Agile de logiciels. Les signataires insistenten particulier sur la ncessit de collaborer avec le client pour rpondre sonbesoin : La collaboration avec les clients plus que la ngociation contractuelle.Dans une approche agile, le primtre du produit nest pas fig. Lquipe doitfournir au client toute linformation qui lui permette doptimiser la production devaleur en fonction de leffort fourni. En contrepartie, le client est co-responsablede latteinte de lobjectif. Il simplique de manire rgulire dans la redfinitiondu primtre fonctionnel. Scrum prconise ainsi lactivit de Product backloggrooming 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 etrgulirement des fonctionnalits grande valeur ajoute.

Les processus Agiles exploitent le changement pour donner un avantagecomptitif au client.

Les utilisateurs ou leurs reprsentants et les dveloppeurs doivent travaillerensemble quotidiennement tout au long du projet.

Lquipe de ralisation et le client adoptent une posture dapprentissage la foisdu processus et du produit. Postulat de lagilit : le besoin nest pas compltementidentifiable en amont de la ralisation et de nombreux changements ultrieursimposeront lensemble des acteurs de sadapter en cours de ralisation. Seuleune 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 davantagecette importance de lorientation produit en rpartissant les responsabilitsanciennement confies au chef de projet vers un nouveau triumvirat : quipe,Scrum Master et Product Owner.

Figure 4.1 Le Trimvirat Agile

La mise en pratique quotidienne

Le bon produit ?

Comme nous lavons rappel, lquipe agile sattle en priorit au dfi de livrerrapidement et rgulirement des fonctionnalits au client. Cela permet de con-fronter son attente la ralisation. Ensemble, ils inspectent le travail ralis,puis dcident des adaptations ncessaires pour se rapprocher de la satisfactiondu besoin.

Itrations et approche empirique

Les quipes agiles adoptent ainsi un processus qui sappuie sur des itrationscourtes (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 sontdcoupes en petits lments qui permettront une focalisation sur de petits lotsporteurs 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 conversationentre le reprsentant de lquipe et le client.

Une pratique courante consiste formaliser ces lments sous la forme de UserStories. Ces histoires utilisateur combinent une concision impose (doit tenirsur une carte) et la dtermination de tests dacceptation par le client (doit tretestable).

Comment maximiser la valeur ?

Pour dterminer le contenu fonctionnel de la prochaine itration, lquipe agilecollabore avec le client en vue de maximiser la valeur ajoute au produit. Ensem-ble, ils tablissent une liste des prochains lments raliser en prcisant lordredans lequel ces lments doivent tre produits. Lordre dtermin tient compteen priorit de la valeur dun lment et de leffort ncessaire sa ralisation.

En agilit, lestimation de leffort nest pas laffaire dun seul individu. Lespersonnes devant raliser sont les mieux placs pour estimer. La pratique duPlanning Poker permet par exemple dobtenir une estimation collective de leffortde 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 desacteurs 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. Lesparticipants obtiennent des informations qui sont exploites lors de la planificationdu contenu de la prochaine itration.

Le bon produit et le maximum de valeur ?

Seule la mise disposition des lments finaliss auprs des utilisateurs finauxpermet de dterminer si lquipe a construit le bon produit porteur de valeur.

En consquence, lobjectif ultime de lquipe agile consiste se mettre en mesurede 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 logicielspar la pratique

La communaut agile explore de plus en plus le concept du Right Product enexprimentant des pratiques trs diverses (inspiration du Lean Startup, notionde Minimal Viable Product), souvent fondes sur une reprsentation visuelle desconcepts (Persona, Impact Mapping, Story Mapping, Empathy Map. . . ).

Elle cherche galement tirer le meilleur parti de la spcification par lexempleen allant jusqu lautomatisation des tests fonctionnels (BDD pour BehaviourDriven Development , etc.)

Les sections qui suivent dcrivent les expriences de quelques praticiens agilesqui ont mis en uvre des pratiques lean pour mieux comprendre les attentes deleur client.

Scne de crime : apparition mystrieuse au cabi-net dentaire

Un rseau de dentistes cherche sinformatiser pour saisir les donnes de sespatients, aussi bien dans les tablissements daccueil spcialiss que dans lescentres de soin en ville ou lhpital.

Lors du recueil des besoins, avec mon quipe de dveloppement, nous avonsdcouvert que les dentistes sont en fait des geeks qui aiment les Macs . Nousavons identifi ce qui est important pour eux : la facilit de prise en main, laconvivialit 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 termelean) pour voir comment travaille un praticien.

Le praticien interroge le patient sur ses antcdents, ses allergies puis, examiner sadentition, pendant quune autre personne saisit au fur et mesure les informationsdonnes par le praticien : Soin conservateur en 21 !.

Cest sur le gemba que se produit le dclic. Lobjectif du dentiste est de fairedix vacations par jour. Occup soigner le patient, il na pas les mains librespour effectuer la saisie. Il russit son challenge grce son assistante qui saisitles donnes au fur et mesure de lexamen. Notre hypothse selon laquellelutilisateur premier tait le dentiste se rvle errone.

Or, pour aller plus vite, cette assistante nutilise que les touches du clavier : pasune 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 avecles tabulations du clavier. Cest une catastrophe ! Lutilisateur est balad de hauten bas, le faisant tourner en girouette.

Action corrective

Lquipe change la navigation pour que les tabulations suivent lordre dans lequellassistante 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 pasdtect les attentes ergonomiques spcifiques de lassistante. Le logiciel laidemaintenant 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 quinous 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. Cestune 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 pluscourageux pitchent leur ide. Lun dentre eux a une intuition formidable :crer un guide touristique international, proposant les bons plans des au-tochtones . Lorsquon visite Venise lt, plutt que de suer dans un bain defoule sur la place Saint Marc, autant aller siroter un Spriss (la boisson locale)au comptoir du bacaro dune petite place ombrage. Les vnitiens le savent bien.Le touriste moyen, lui, ne sait pas o trouver ces bons plans.

Trs vite, dautres participants viennent renforcer notre petite quipe naissanteet la machine semballe. On se retrousse les manches, et on travaille dj sur lesquestions fondamentales : Comment rcolte-t-on ces astuces ? Combien peut-onvendre ce guide ? etc.

Tout le monde est motiv, prt attaquer le dveloppement du site web et delapplication mobile correspondante.

13

Aller voir vos clients

Lanimateur intervient en nous demandant daller la rencontre de nos futursclients. Le lean appelle cette pratique couter la voix du client 3 Notremission : comprendre comment, aujourdhui, les touristes trouvent leur bonsplans.

Profitons de notre situation, en plein cur de Paris, pour rencontrer des touristesavides 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 planslocaux, 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 laTour Eiffel.

La leon tirer

Lhistoire de cette ide gniale se termine ici. Mais pas celle de notre quipedentrepreneurs : quelques minutes leur ont suffi pour trouver une nouvelle idegniale. Mais cette fois-ci, en commenant par une visite terrain 4 avant desemballer.

Voil une belle fin, puisquau cours de cette histoire, aucun dveloppeur na ddvelopper un logiciel inutile. Lentrepreneur a pu consacrer lnergie conomise dautres projets plus prometteurs.

Lerreur de lentrepreneur peut sembler vidente, mais elle est pourtant trsrpandue. Son ide, comme toutes les ides, reposait sur des hypothses. Lune deces hypothses ( les touristes recherchent les bons plans locaux ), quil consid-rait pourtant comme une vidence, ne correspond pas la ralit. Cette illusiondvidence, renforce par le confort du bureau, retient bien des entrepreneurs,et au moins autant de Product Owners, daller se confronter la ralit. Ilsmanquent ainsi lopportunit de valider leurs hypothses sur les besoins desutilisateurs et les problmes que ceux-ci rencontrent dans leurs activits.

Pourtant, aller la rencontre de ses utilisateurs, actuels ou futurs,

Quavons-nous fait

aller voir plusieurs touristes, les utilisateurs potentiels ; confronter ses hypothses avec la ralit du terrain.

3. La voix du client est une pratique lean qui permet de capturer les attentes du client. Cf.la section Principe lean de ce chapitre

4. visite terrain se rfre une pratique lean le go & see pour se forger ses propres opinionssur le contexte et les attentes du client. Cf. la section Principe lean de ce chapitre.

14

Le rsultat

Nous avons compris que la valeur pour cette cible est ailleurs, ce qui a vit deperdre du temps dvelopper une application qui ne rencontre pas son march.

Ce que jai appris

La manire la plus efficace de valider des hypothses sur les attentes du clientest daller voir les utilisateurs potentiels

Plus vite nous confrontons ces hypothses la ralit du terrain, plus nousgagnons du temps sur la cration de la valeur.

Scne de crime : la catgorie mystre du projetCondor

Un oprateur tlcom vend aux entreprises une solution de centre dappels virtuels.Cette solution est dveloppe par notre quipe agile de sept personnes. Nousavons hrit dun code de mauvaise qualit que nous amliorons progressivement.Cependant, nous sommes confronts environ deux signalisations 5 par jour denos utilisateurs finaux. Cela provoque une tension avec le management, notrecommanditaire 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 ticketsdincidents dans loutil de ticketing du SAV. Il y a beaucoup de types de ticketsdiffrents. Je les compte et les catgorise. Cela constitue un bulletin de santque jaffiche sur le mur lentre de notre War Room.

Analyse du problme

Les trois catgories les plus volumineuses sont :

1. formation utilisateur : les utilisateurs ne comprennent pas comment fonc-tionne lapplication ;

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

Premire surprise, le grand gagnant est la catgorie mystre . Deuximesurprise, 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.

5. Nous appelons signalisation un incident remont par lutilisateur.

15

Figure 4.6 Bulletin de sant du projet Condor

Identifier lorigine

Dsaronns par le flou de ces tickets mystre, nous dcidons davancer surnotre problme en nous donnant les moyens didentifier lorigine des prochainessignalisations. Nous faisons un travail important damlioration des logs delapplication. Les rcapitulatifs quotidiens qui remontent par mail les erreurs etles warnings contiennent plusieurs centaines de lignes htrognes. Nous donnonsun 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 tlphoniqueentier car certaines logs sont sur les SVI (Systme Vocal Interactif) et dautressont sur les serveurs dapplication. Nous dveloppons un script dagrgation pourconsolider 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 signalisationsemble lie au protocole de communication avec le serveur du rseau tlcomqui est bas sur de lUDP. Rien ne garantit dans ce protocole que linformationne soit pas perdue. Dans un certain nombre de cas, la perte dun vnemententrane le blocage des appelants sur une file dattente du SVI. Il faut attendrele timeout du SVI qui est de 30 mn. Cest inacceptable pour lquipe. Nousdcidons de mettre en place un mcanisme de gestion de timeout. Cela demandedajouter une couche de simulation du temps pour la compatibilit avec les testsautomatiques.

16

Point dtape

Lquipe est satisfaite car elle a fait diminuer les signalisations lies la pertedappel. Elle vite des personnes de payer 30 minutes avant de se faire raccrocherau nez.Comme certains tickets sont toujours inexpliqus, nous dcidons denvoyer unbinme 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 centredappel avec leur superviseur.Sous nos yeux, une opratrice double-clique sur le bouton de pause. Cela apour effet de demander une pause et de sortir de pause immdiatement. Surpris,nous lui demandons pourquoi elle fait cette opration. Elle nous explique quellerepasse ainsi devant ses collgues dans la file dattribution des appels, afin deprendre plus dappels. Le superviseur nous explique que les agents sont intresssau nombre dappels traits. Sidrs, nous comprenons alors les incidents dedistribution dappels remonts par les autres, tonns que leur collgue leur passedevant.Devant nous, un autre agent prend un appel et souhaite appuyer sur une touchede fonction pour afficher une information de leur outil de CRM. Ce faisant,sa main eeure le bouton raccrocher et elle perd lappel sans comprendrepourquoi. Nous venons de rsoudre un autre ticket non reproductible. Mais passeulement. Le superviseur qui nous accompagne a assist la scne et comprendque le problme ne vient pas de lapplication, mais de lergonomie des postes detravail. Il fait rehausser les postes tlphoniques pour quils soient plus loignsdes claviers.Plus tard dans laprs-midi, une opratrice redirige un appel vers lhtel deRoissy. Une personne de lquipe de dveloppement qui nous assiste distanceprcise que lappel est perdu. Nous allons voir la configuration de lapplicationet ralisons que le numro de lhtel est erron. Voil lexplication des erreursde type RouteSelectFailure. Nous avions longtemps privilgi la fausse piste desproblmes de standard chez le client.Nous partons dans un climat plus dtendu : les agents sont contents davoir tcouts 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 voirlutilisateur en action.6. gemba dsigne lendroit o les choses se passent. Cf. la section Principe lean de ce

chapitre.

17

Le rsultatCela sest traduit par une baisse drastique de signalisations en passant de deux parjour une par semaine. Nous avons galement ajout une couche de simulationdu temps qui nous a servi ultrieurement.Ce que jai apprisAller sur le gemba est inconfortable, notamment chez un client insatisfait, maisdune grande richesse dapprentissage. Paradoxalement, cest aussi un gain demotivation.En sortant du primtre de lquipe pour aller voir le client, nous avons puaboutir la rsolution dfinitive dun grand nombre de problmes qui paraissaienthors de notre porte.

Principes lean

Comprendre le besoin profond du client

La dmarche damlioration du lean commence par la dfinition dun objectifclair et partag par tous. Cet objectif est construit en prenant comme premirerfrence la satisfaction complte des clients du projet.Or lexprience montre un cart frquent entre ce quun client exprime et ce quile satisfait rellement. Cette difficult sexplique de plusieurs manires :Il lui est difficile de formuler les exigences du logiciel sans y ajouter ses propresprfrences ou interprtations.La demande le met en situation de concepteur de logiciels - un mtier pointuauquel il nest souvent pas form.Le lean propose un ensemble de pratiques et principes efficaces pour cibler lesbesoins rels du client et affiner la comprhension de ses prfrences.Tout dabord, dans un contexte de dveloppement logiciel, il faut identifier quelssont les vrais clients du projet. Il en existe trois grandes familles : Lutilisateur final, celui qui va profiter directement le logiciel au quotidien. Le commanditaire, qui paie la prestation de dveloppement et en attend un

retour conomique. Sa satisfaction dpend de celle de lutilisateur final, maisaussi dautres paramtres qui svaluent au niveau de lentreprise.

Les quipes en aval de lquipe de dveloppement qui vont tester, exploiter, etfournir du support.

Dans un contexte agile, il est important de ne pas considrer priori le ProductOwner comme tant le client au sens lean du projet. Dans de nombreuxcas le Product Owner dsign pour le projet est plutt un reprsentant ducommanditaire et des utilisateurs. Dun point de vue lean, il est donc pluttdu ct de lquipe, et les clients au sens lean restent principalement lesutilisateurs et le commanditaire.

18

Chacun de ces clients a ses propres attentes, quil faut identifier et satisfaire. Lelean offre une structure pour guider cette exploration, base sur cinq axes :

Figure 4.7 Les cinq attentes du client

Les pratiques qui suivent constituent un bon point de dpart pour entamer cetravail de dtective.

Se faire sa propre opinion en allant observer le client sur leterrain

Le vritable besoin du client ne se dniche pas dans une salle de runion. Il fautaller le trouver sur le terrain, l o laction se passe un lieu que les praticiensdu lean appellent le gemba . Dans un contexte agile, il sagit de lendroit olutilisateur 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 lapersonne observe. Quelques points doivent tre respects pour viter cet cueil :

Expliquer la personne observe lobjectif et les modalits de lobservation, enprcisant quil sagit dune observation et non dune interview. Si ncessaire, ilest possible de demander cette personne de penser voix haute pour mieuxcomprendre ce quelle cherche faire.

Observer le plus longtemps possible sans parler.

Rpondre poliment ses questions et linviter reprendre son activit.

Une bonne observation doit apporter des lments de rponse deux questions :

Que cherche faire lutilisateur dans ce contexte prcis ?

Quels sont les obstacles quil rencontre pour atteindre son objectif ?

19

Les deux exemples Apparition mystrieuse au cabinet dentaire et Vie etmort dune ide gniale illustrent les prises de conscience importantes queprovoquent habituellement des observations russies.

En termes lean, ces observations amnent lquipe observer le processus de sonclient : o se trouve la valeur ses yeux et quels sont les gaspillages liminer.

Avec les quipes en aval, lexercice est quasiment identique, mais lattention porteessentiellement sur lidentification des gaspillages que les livraisons de lquipeagile gnrent chez ces autres quipes. Lquipe agile met-elle ces dernires encondition de russir ?

Dans le cas du commanditaire, lexercice consiste comprendre comment ilmesure le succs et les quelques points qui sont vritablement essentiels pour lui.Comme pour lutilisateur, le go&see nest pas un go&talk . Lobservateurdcouvre par exemple que le commanditaire est sensible telle ligne prcise dansun reporting comportant des centaines de pages.

Dfinir le problme rsoudre et la faon de mesurer lesuccs

Plutt que de dfinir lattente du client sous la forme dune solution mettre enuvre (les fonctionnalits dvelopper), le lean pose la question du problmeglobal auquel le projet doit apporter une solution pour satisfaire ses utilisateurset commanditaires.

Une fois le problme pos, il sagit de dfinir la faon dont il sera possible de

20

vrifier que le projet la bien rsolu. Lquipe se dote dindicateurs objectifs quirefltent ce succs.

Quelques exemples :

Amliorer la qualit : taux derreur commis par les utilisateurs, volume dinci-dents.

Augmenter les ventes : taux dajout darticles dans un panier dun site dee-commerce.

Augmenter la notorit : nombre de Jaime sur Facebook, nombre detweets.

Rduire les dlais : le temps pour acheter un billet de train, le temps pourapprouver 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 projetsur un objectif clair, objectif et indiscutable. Des conditions de succs clairespermettent de dfinir des problmes clairs rsoudre ensemble, de mieux choisirles fonctionnalits et les sujets damlioration, et de vrifier que les ides damlio-ration mises en uvre portent leurs fruits. Il sagit de la fondation de la dmarchedamlioration du lean, base sur la technique du Plan-Do-Check-Act (PDCA)prsente plus loin dans ce guide. [principeslevier]

Exprimenter pour valider ses prfrences

Chaque fonctionnalit est porteuse dincertitude. Il se peut que :

malgr ses observations sur le terrain, lquipe ait mal compris lattente desclients,

la fonctionnalit ne rsolve pas le problme dans le contexte de certainsutilisateurs,

la fonctionnalit cre de nouveaux problmes insouponns.

Pour viter cela, il est ncessaire de procder de nouvelles observations terrainaprs les livraisons. Il sagit de la phase de Check de la rsolution deproblmes, 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, carelle pointe soit sur un lment que lquipe na pas compris, soit sur une failledans son fonctionnement.

En pratique, le travail sur les rclamations se traduit par la recherche de la causeracine du problme qui a amen le client se plaindre. Ceci conduit lquipe :

mieux comprendre le contexte de son client,7. Attention toutefois sur ce dernier point : lquipe doit rester vigilante ne pas asservir

lhumain la machine. La vision lean considre la technologie comme un outil mis au servicede lintelligence humaine.

21

revoir ses convictions sur son analyse. trouver des solutions pour liminer la cause racine et viter que cela sereproduise,

Cette activit danalyse des rclamations repose galement sur la dmarche dersolution de problmes. Lexemple La catgorie mystre du projet Condor prsente une quipe qui choisit de traiter chaque signalisation utilisateur commeun problme de qualit.

Valeur et gaspillages

Tout ce travail dinvestigation et danalyse a pour objectif de trouver la valeurpour le client. Cest seulement une fois quelle est clarifie quapparaissentclairement les obstacles : les gaspillages qui occasionnent des pertes de tempspour les utilisateurs ou ceux qui construisent le logiciel.

Les gaspillages sobservent de nombreux niveaux :

dans lactivit de lutilisateur il faut alors comprendre comment les limineren amliorant le logiciel ou le support

dans lactivit de traitement du logiciel installation, exploitation, sauvegarde,etc.

dans lactivit de dveloppement du logiciel.

Les pratiques lean ont pour objet dimpliquer lensemble des collaborateurs delentreprise dans la recherche permanente de cration de valeur pour les clients,en utilisant llimination des gaspillages comme autant dopportunits de librerle temps prcieux de ces collaborateurs. Deux de ces pratiques principales sontprsentes dans les chapitres suivants.

Premiers pas

Pour renforcer votre comprhension des attentes de vos clients, nous proposonsces exercices :

Allez observer le client sur le terrain

Pour votre projet actuel, allez voir trois utilisateurs distincts sur leurs lieux detravail

1. Pour chacun des utilisateurs, observez pour comprendre : Que cherche-t-il faire ? En quoi la structure actuelle pose un problme ?

2. Quapprenez-vous de nouveau sur leur contexte ? La solution qui est prvue rsout-elle vraiment leur problme ?

22

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 rsoudrecompltement le problme du client ?

Exprimez-le en termes de dlais, qualit et cot pour lutilisateur et pour lecommanditaire.

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 ontport leurs fruits ?

Allez mener lobservation. Quavez-vous appris ? Quels sont les impacts ?

Regardez les rclamations

Prenez les trois dernires rclamations client. Pour chacune, menez ces investiga-tions :

Quelle est la cause racine du problme ? Quapprenez-vous sur le contexte et les attentes de votre client/utilisateur ? Comment pouvez-vous vous assurer que ce problme ne survienne nouveau ?

Aller plus loin

Le lean au service du client

Jim WOMACK et Dan JONES Edition Vuibert

23

Figure 4.8 livre lean au service du client

24

Chapitre 5

De Management visuel Visualiser le challenge et lesproblmes

Les pratiques agiles

Favoriser le travail en quipe

Dans le bureau dune quipe de dveloppeurs agiles, personne ne stonne devoir les murs couverts de post-its et de posters dessins la main.Le principe est simple : lutilisation de lespace visuel permet damliorer laqualit et la quantit dinformation change au sein de lquipe et avec ceuxqui lentourent.Un projet de dveloppement logiciel en quipe se confronte la fois un besoinde communication intense et aux limites de la communication verbale, quelle soitformelle ou informelle. Les mthodes classiques ont recours des outils de gestionde projet informatiss ou des fichiers sur des rpertoires partags. Solutionstrop lourdes ou dshumanises pour le manifeste agile qui invite privilgier lesindividus et leurs interactions plus que les processus et les outils . Laffichagemural 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 dveloppeursinteragissent et laide desquels ils se coordonnent entre eux. Par exemple, surun taskboard, on fait avancer le post-it reprsentant une tche au fur et mesurede sa progression. Cela facilite aussi lintgration dun nouvel arrivant.Cette clart sur ce quil y a faire et sur les objectifs contribue lmergence delauto-organisation. Ce nest plus le chef de projet qui affecte les tches, maislquipe elle-mme.

25

Figure 5.1 Un affichage mural (radiateur dinformation) dans un bureau dedveloppeurs

26

Vis--vis de lextrieur, les indicateurs, volontairement simples, donnent unevision synthtique de ltat du projet et vitent le reporting coteux et inefficacecar non partag.

Quelques exemples

La culture agile regorge dexemples que les quipes de dveloppement peuventreprendre leur propre compte, comme le montrent les spcimens suivants.

Figure 5.2 Tableau kanban

Les quipes plus avances commencent crer des affiches sur mesure pourrpondre 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 lmentsaffichs restent utiles et utiliss.

Une pratique quotidienne

Tous les jours, lquipe se runit devant le tableau davancement des tches pourune courte runion dinspection et dadaptation. Le support visuel matrialise lesinformations orales fournies rituellement par chacun des membres de lquipe :

depuis hier, jai termin. . .

dici demain, je pense terminer. . .

voici ce qui pourrait constituer un obstacle au fait de terminer. . .

27

Figure 5.3 Niko niko

Figure 5.4 Burndonw chart

28

Figure 5.5 Un poster sur-mesure

29

Figure 5.6 Exemples daffichage dune quipe crative

Une pratique efficace et volutive

Les quipes agiles en posture damlioration continue sont en exprimentationpermanente sur leur management visuel. Aujourdhui, pour aller plus loin ellesont recours de plus en plus lapproche kanban : matrialisation des limites surle travail en cours, dfinition de classes de service, etc.Les sections qui suivent prsentent les exprimentations dquipes agiles qui ontsouhait 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 dirigepour mettre en ligne son offre Traiteurs de fin danne. Le site doit offrir lapossibilit aux clients de construire une liste de courses quils pourront utiliserensuite en magasin pour commander leurs produits. Le site ne sera accessibleque cinq semaines par an loccasion des ftes.Lanne suivante, suite au succs de lopration et une demande de plus enplus importante, lenseigne dcide dajouter le paiement en ligne. Le niveau deperformance demand est trs lev : une fiabilit sur la commande de 100% etun taux contractuel de disponibilit au-del de 95%. Je dois donc offrir monclient un service de maintenance, cependant mes quipes agiles actuelles nontaucun cadre de travail pour assurer ce nouveau type de prestation.

30

Figure 5.7 Radiateur dinformations existant pour grer les projets web

Pendant les 3 annes suivantes, nous russissons au prix de gros efforts tenir nosengagements. En effet, nous devons dvelopper de nouveaux projets pour dautresclients tout en assurant la maintenance de ce site. Chaque anne lhistoire serpte, lquipe semble toujours confronte aux mmes problmes. Les sprintssont perturbs par les actions de maintenance et les problmes de fonctionnementde lapplication. Nous ne capitalisons pas sur ce que nous avons appris les annesprcdentes.

Les pnalits en cas de non-respect des engagements peuvent mettre lentrepriseen danger. La pression est donc trs importante, dautant que je suis incapablede 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 entrain de russir, cest--dire assurer un service de maintenance de qualit touten rduisant limpact de cette activit sur le dveloppement des autres projets.

La premire tape consiste comprendre ce qui est vraiment important pour leclient pendant la dure de vie du site de-commerce. Je veux savoir sur quoi jedois 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, jemappuie sur loutil Voix Du Client 1

1. Cf. Section Principes Lean du chapitre Attentes du Client

31

Trois points clefs ressortent de ce questionnement :

Les dates douverture et de fermeture du service. Le site doit treaccessible seulement entre le 19 novembre et le 26 dcembre, priode dou-verture annonce par lenseigne. Le client investit dans une campagne decommunication (TV, radio, publicit sur le lieu de vente, etc.). Il communiquefortement sur la date douverture du service qui doit tre oprationnel aumoment fix. Pour la fermeture, il est trs important darrter le service pourchaque magasin aux heures dfinies par le client. Dans le cas contraire, unmagasin pourrait tre dans lincapacit dhonorer les commandes passes. Larputation 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 surla priode douverture. Mme si contractuellement le site doit avoir unedisponibilit de 95%, le client attend une disponibilit totale du service.

A partir de ce constat, je construis avec lquipe un ensemble dindicateursclefs, afin de nous concentrer sur le vritable challenge permettant de satisfairepleinement notre client. Assist par ces indicateurs, je veux connatre chaquejour 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 sitepar magasin.

Lengagement sur la prise de commande du client du magasin : Un indicateur quotidien OK/NOK sur la conformit des commandes en-voyes.

La disponibilit du site : Un indicateur quotidien OK/NOK sur laccessibilit au catalogue de produitet la commande proprement dite.

Un indicateur quotidien OK/NOK sur le fonctionnement des fonctionnalitsdu 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 situationest rendue visible. Chaque fois quil y a un problme 2 exemple : plainte client carle 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 lasituation. Si un problme est survenu la veille, cest loccasion pour nous departager 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 lquipede limportance des problmes. Lquipe travaille plus sereinement. Elle estcapable de rpondre aux exigences du client le plus rapidement possible. Lesprojets sont moins perturbs et lquipe dlivre plus de fonctionnalits par sprint.Dautre part, cette dmarche qui amliore la qualit du service nous permet derenforcer la relation de confiance avec notre client qui reconduit chaque annenotre partenariat.

2. Cf. Section Principes Lean du chapitre Leviers de lamlioration

32

Figure 5.8 Structure de nos indicateurs de performance*

Figure 5.9 Structure de notre management visuel

33

Figure 5.10 Management visuel pour une activit de maintenance

Quavons-nous fait

- Comprendre ensemble :

- Interroger les clients sur ce qui est vraiment important pour eux avec loutil Voix du client - Traduire le besoin du client en indicateurs de performance

- Voir ensemble :

- Rendre visible le challenge et les problmes

- Agir ensemble :

- Prendre les bonnes dcisions immdiatement ds que le problme est connu

- Prparer la rsolution de problme 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 lescomptences de chacun pour rsoudre plus rapidement les problmes. Peuimporte la forme des premiers indicateurs construits tant quils montrent lacible et les problmes, ils saffineront dans le temps pour mieux correspondre lattente du client. 34

Scne de crime : tous coupables

Contexte

Suite la fusion de plusieurs organismes, une grande socit de services se voitconfier la ralisation dun nouveau systme unifi de gestion des dossiers descotisants. Les enjeux de mise en service de ce nouveau systme sont critiques :

Le suivi comptable a mis jour un cart considrable entre les cotisations, lesremboursements et lencours. Il faut trs rapidement clarifier la situation, puisla corriger.

De nombreux cotisants font face de trs longs dlais de traitement de leursdossiers.

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 produitnon conforme aux attentes du client.

Cette situation se traduit par une crise dans lquipe de ralisation : le directeurde 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 vingtainede personnes.

Visualiser le challenge

Lquipe doit se mettre en capacit de produire le prochain lot dans un dlai detrois mois, sans retard, en assurant une qualit acceptable du point de vue duclient final. Elle doit galement parvenir livrer des lots intermdiaires toutesles deux semaines pour rassurer le client.

Ce challenge 4 se traduit tout dabord par laffichage dun objectif de productionpour la premire itration :

Lquipe analyse les principales tapes de son flux de production 5, puis reprsenteson activit sous la forme dun tableau visuel.

Lenjeu de litration en cours consiste sortir toutes les pices prsentes sur letableau 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.

35

Figure 5.11 Objectif de production

Figure 5.12 Tableau reprsentant le flux de production

36

Rvler les problmes

Problme principal : les tches narrivent pas jusqu la dernire colonne.Depuis plusieurs semaines, lquipe bute sur une somme croissante dobstaclesbloquants sans arriver sorganiser pour les surmonter. La frustration qui enrsulte se transforme progressivement en antagonisme envers la cellule danalysefonctionnelle. Celle-ci, dlocalise auprs du client final, est rendue responsable dublocage. Lquipe de ralisation lui reproche de laisser saccumuler les demandesdinformations, sans les traiter dans un temps acceptable.Les premires runions quotidiennes confirment que la majorit des dveloppeurssont en attente de clarification sur des questions dordre fonctionnel. Ces deman-des sont transmises par lintermdiaire dun outil lectronique, mais la plupartrestent indfiniment sans rponse. Lquipe ralise que loutil ne lui permet pasdapprhender la situation.Pour y voir plus clair, elle dcide de rendre visibles ces obstacles sur son manage-ment visuel. Au cours de ce travail danalyse, elle fait une dcouverte surprenante :l o lquipe technique voit questions en cours, lquipe fonctionnelle nen voitde 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, dlguantla responsabilit au systme, ne se proccupe plus du suivi du processus dersolution. En particulier, les tickets sur lesquels le service destinataire est malrenseign, ne sont pas traits correctement. Ils demeurent en ltat dans lesystme.Tout dabord, lquipe enrichit son management visuel 8, en rendant visibles,pour chaque tche, les obstacles (questions bloquantes en cours) sous la formede 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. Deplus, lmetteur de la demande devient responsable des actions de suivi.Les obstacles sont matrialiss et suivis sur un tableau ddi :

7. Cf. Section Principes Lean du chapitre Leviers de lamlioration 8. Cf. Section Principes Lean du chapitre Management visuel

37

Figure 5.14 Standard de dfinition dune demande

Figure 5.15 Tableau de suivi des obstacles

38

Les runions quotidiennes, qui taient auparavant centres sur les tches, fontmaintenant une large place au traitement des obstacles en cours. Chaque jour,un point est effectu sur les obstacles non levs. Les fiches des obstacles nonrsolus sont dplaces en fonction de leur niveau durgence (voir tableau de suivides obstacles).

Ds quun obstacle est lev, sa fiche est dplace vers un espace spcifiqueo il demeure jusquau lendemain. Cela permet un autre quipier, dont unetche serait en attente de la mme demande, de savoir quil peut reprendre sontraitement.

Figure 5.16 Panneau des obstacles rsolus

Deux semaines aprs cette dcouverte, les questions en attente de rponse de lapart de la cellule danalyse fonctionnelle ont toutes t traites. Lquipe peutvrifier visuellement au quotidien que cette quipe nest pas source de blocagede 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 lestapes suivantes du processus.

Quavons-nous fait

Comprendre ensemble : Dfinir le challenge : prochain lot dans trois mois sans retard et avec zrodfaut

Traduire le besoin du client en indicateurs de performance Voir ensemble : Rendre visible les problmes qui mempchent davancer sur mes tches parlintermdiaire des bacs rouges 9

Rendre visible le flux de dveloppement9. Cf. Section Principes Lean du chapitre Management visuel

39

Agir ensemble : Comprendre les typologies de problmes, les rendre visible et sorganisertous les jours pour les attaquer un par un

Le rsultatLes obstacles ont t levs ce qui permis lquipe de sortir ses tches lheure.Ce que jai apprisLquipe 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 sprintaprs sprint par un reste faire de 10 20% en fin de sprint :

Recherche de cause

Peut-tre ne consacrons-nous pas le temps prvu initialement raliser nossprints ? Certains membres de lquipe interviennent en effet sur plusieurs ac-10. Cf. Section Principes Lean du chapitre Leviers de lamlioration

40

Figure 5.18 Evolution du reste faire au fil des sprints

tivits (management, runions transverses. . . ). En tant que Team Leader, jenchappe pas cet parpillement.

Enrichissement du management visuel

Pour clarifier la situation, nous enrichissons notre management visuel en ajoutantun graphique des jours consomms, copie quasi-conforme de notre burndownchart ditration.

Figure 5.19 Burndown chart des jours consomms

Notre hypothse se confirme : une partie de lquipe na pas consacr litrationautant de jours quelle le pensait. Lquipe croyait disposer dune capacit de100 jours avant litration, mais na pu en fournir rellement que 80.

41

Action : suivi des carts

Il faut maintenant agir. Je trace, sprint aprs sprint, la diffrence entre les joursconsomms et les jours planifis.

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

Sur les 24 derniers sprints, jobserve une forte variabilit. Je pense que lesmembres 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 tempsconsomm de chaque personne.

En dbut de sprint, nous imprimons un graphique qui montre pour chaquepersonne le nombre de jours quelle a annonc en sprint planning. Durant chaquedaily scrum meeting, un dveloppeur remplit les lignes. Quand Romain dit jesuis intervenu sur telle tche toute la journe, le dveloppeur surligne en fluoune journe supplmentaire consomme sur la ligne de Romain.

Ce suivi permet dalerter Romain : Attention, il ne reste que 2 jours et il tereste 1,5 jours consacrer au sprint.

Linformation affiche est exploite

Chaque membre de lquipe est maintenant en mesure de suivre au jour lejour un ventuel cart de son implication dans le sprint. Par exemple, si unerunion transverse imprvue mest propose, je choisis dy participer ou pas enconnaissant pleinement son impact sur le sprint.

Le reste faire en fin ditration, qui tait totalement imprdictible et chaotiquedevient dune exceptionnelle stabilit. Plus exceptionnel encore, les jours-hommenon consomms se stabilisent au mme moment, ce qui confirme lhypothsedune corrlation entre les deux phnomnes (voir les courbes du Suivi descarts 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 pastoutes avant la fin du sprint.

42

Figure 5.21 Suivi du nombre de jours consacr au sprint

Figure 5.22 Suivi des carts en fin ditration

43

Suite de lhistoire

Et les deux quipes se marirent et eurent beaucoup de stories finies en fin desprint.

Les quipes de spcification et de dveloppement dcident de fusionner leurmanagement visuel et leur daily meeting. Les dbuts sont difficiles, mais partirdu sprint .1, elles russissent samliorer drastiquement en se focalisant sur lesstories valider plutt que sur de nouvelles spcifications :

Figure 5.23 Evolution du reste faire la suite dune action damlioration

Quavons-nous fait

Comprendre ensemble : Rajouter un indicateur de performance mesurant le temps consomm parlquipe 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 joursil 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 mesengagements du sprint

Planifier sa journe en fonction (ex : privilgier le dveloppement plutt quedes tches moindre valeur ajoute telle quune runion)

Le rsultat

Nous livrons le mme volume de fonctionnalits ditration en itration (environ90%), ce qui permet chaque membre de lquipe de mieux planifier sonprochain sprint.

Nos indicateurs nous ont permis de valider ensemble la russite dune actioncollective.

Ce que jai appris

Laisser lquipe trouver delle-mme les solutions ses problmes paie.

44

Principes lean

Quest-ce que le management visuel lean apporte unequipe agile ?

Le management visuel est une pratique de base du lean qui poursuit deux butscomplmentaires :

Aligner lensemble des acteurs du projet sur un mme objectif : la satisfactiondes clients.

Partager les difficults et les pistes damlioration de manire objective afinque chacun comprenne comment il peut contribuer lamlioration.

Lapproche lean du management visuel permet de franchir un palier sur troissujets :

Identifier de manire trs prcise o se situent les problmes que lquipe doitattaquer pour amliorer aussi bien le produit que ses conditions de travail.Ceci se retrouve dans lexemple Trouver lindic . Le management visuelrenvoie lquipe plusieurs signaux qui permettent dagir sur les bons sujets :volume important des demandes de maintenance et retards de livraison desprojets. Ceci encourage lquipe aller la rencontre de ses clients pour mieuxcomprendre les difficults rencontres.

Collaborer avec les autres quipes de manire efficace. Dans lexemple Touscoupables , lquipe technique blme les analystes et inversement, et les chosesnavancent pas. Ils visualisent le problme ensemble, et en trs peu de temps,ils arrivent se mettre daccord sur une solution simple pour dbloquer lasituation.

Communiquer avec ses managers sur des faits clairs et ainsi mieux se faireentendre.

Les objectifs

Le management visuel fournit en temps rel linformation et le feedback objectifncessaires la comprhension de lactivit de lquipe. Il lui donne les moyensde 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 larsolution des problmes qui mergent.

Il est bas sur trois axes :

45

Figure 5.24 Le triangle du management visuel lean

Comprendre ensemble

La construction et lutilisation du management visuel amnent lquipe dvelop-per une comprhension commune de :

lattente de ses clients ; son challenge et sa propre performance ; son processus de dveloppement ; les rles et les comptences de chacun ; les rles et les comptences de chacun.

Le client

Dans un premier temps, lquipe commence par identifier clairement ses clients 11.Ensuite, elle dfinit leurs besoins et leurs critres de satisfaction : o est la valeurpour 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 deleurs clients (service marketing et DSI de leur commanditaire). Ils ont ralisque leur contrat ne refltait pas leurs relles attentes. Sils respectaient les 95%de disponibilit du site, pas de pnalit pour lquipe, mais une image dgradedu point de vue du client.

Le challenge et la performance

Lquipe dfinit sa condition cible et la traduit sous la forme dindicateurs deperformance. Ces derniers montrent la qualit de ce que lquipe produit, dansquels dlais et avec quelle productivit le tout du point de vue du rsultatfinal, cest--dire du point de vue du client. Les indicateurs dfinis doivent donccouvrir les sujets suivants :

Qualit du service ou produit livr : lquipe a-t-elle russi livrer la bonnefonctionnalit du premier coup ?11. Cf. Section Principes Lean du chapitre Attentes du Client

46

Respect des dlais de livraison attendus par le client (et pas uniquementceux ngocis avec lui) ou le stock (le volume des demandes client dans lebacklog que lquipe na pas encore pu traiter). Charge lquipe de samliorerpour sapprocher de lattente client. Dans lexemple le burndowntait rouge ,les dveloppeurs se battent pour respecter leur engagement de dlais sur lesprint (90% livr au lieu de 100%) et vont jusqu mesurer leur propre tempsconsomm pour y arriver.

Productivit : indicateur cl pour suivre lamlioration de la capacit delquipe.

Satisfaction client :lquipe peut avoir limpression que tout va bien alorsque 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, tauxdutilisation, taux de rtention des utilisateurs, etc.

Le processus

Lquipe dfinit clairement les activits valeur ajoute pour le client et lestapes 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 leclient, tout en facilitant le travail de chaque collaborateur.

Lquipe

Chaque personne doit tre capable dexprimer clairement son rle et sa placedans lquipe. Ceci lui permet dinteragir avec les autres sans ambigut.

Lquipe affiche aussi une matrice de comptences de tous ses membres, ainsiquun programme de formation, lobjectif de dveloppement des comptencestant clair pour chacun.

Voir ensemble

Ds que lquipe est claire sur la direction prendre et quelle est prte mesurersa performance au jour le jour, elle doit rendre visible ce quelle est en train deproduire. 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 fluxde ses activits comprenant lobjectif du jour et la distribution des tches, ainsique la performance. Lobjectif est dtre alert immdiatement en cas danomalieafin de ragir rapidement.

Flux dactivit

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

47

Figure 5.25 Matrice des comptences de lquipe

Le lean apporte un lment supplmentaire en invitant trouver des moyensde rendre visibles tous les obstacles que rencontre lquipe pour atteindre sesobjectifs. Lexemple Tous coupables illustre ce principe : les dveloppeursajoutent des tiquettes rouges sur leurs tches lorsquil leur manque une informa-tion pour avancer. Ils se donnent des objectifs quotidiens pour lever ces obstacleset 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 dequalit :Soit des problmes de qualit en entre (par exemple une user story insuffisam-ment claire ou incohrente avec lapproche du produit, ou bien une user storyqui est en soi une retouche parce quelle avait t mal cadre ou ralise lorsdun prcdent sprint)Soit des problmes de qualit rencontrs au cours dune tche (par exemple undveloppeur trouve un endroit du code qui recle des dfauts)Chaque problme de qualit est imprim ou crit sur une feuille, puis plac dansune bannette rouge proximit du taskboard :Les bacs rougesRgulirement, lquipe se livre lanalyse du contenu de ses bacs rouges pourcomprendre la cause de ces problmes de qualit et y trouver une solution.Au-del des problmes de qualit, dautres natures de problmes peuvent trerendues visibles sur le management visuel, par exemple :

48

des demandes client restes trop longtemps en attente,

des problmes de surcharge de certains membres de lquipe par rapport dautres.

Il ny a pas de rgle explicite prcisant quelles natures de problmes doivent trerendus visibles, et comment. Chaque quipe fait voluer son management visuelau gr de ses besoins et de son niveau de maturit.

Dans certains contextes spcifiques, il peut tre utile de mettre en place un visuelun peu diffrent. Ci-dessous, deux possibilits :

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

Figure 5.26 tableau_de_suivi_de_production

2. Un visuel physique , lorsquil est ncessaire de voir ce qui est produitsur papier. Ce visuel peut tre utilis, par exemple, dans le cadre dunprojet de conception de documentation technique.

49

Limage ci-dessous reprsente trois bannettes :

1. une bannette contenant des pages rdiges par Julie qui demande unerelecture Germain ( traiter ),

2. une deuxime bannette contenant les pages pour lesquelles Julie attenddes renseignements ou un feu-vert ( suspendu )

3. une troisime bannette ( les bacs rouges ) contenant les pages quicomportent des problmes rsoudre immdiatement pour dbloquer Julie.

Le mur de la performance

Lquipe construit ses indicateurs de performance pour savoir tout momentsi elle rpond bien aux attentes de ses clients. Elle les met jour la mainquotidiennement et y annote les pics et les valles pour expliquer leshausses et les baisses inattendues. Un bon indicateur montre la tendance dans letemps et une cible afin de faire merger les carts de performance, ce qui formela dfinition dun problme

Figure 5.27 Le mur de la performance

Les indicateurs de type burndown peuvent parfaitement tre utiliss. Ilsdeviennent un outil dapprentissage lorsquon y annote les causes des retards, etles expriences damlioration mises en uvre.

50

Dautres indicateurs ne se prtent pas une reprsentation en burndown chart.Le modle gnrique ci-dessous reprsente une bonne faon de reprsenter unindicateur :

Figure 5.28 Structure dindicateur type pour le suivi dune valeur unique quivolue dans le temps

Suivi des problmes

Lquipe note les problmes quelle rencontre sur une main courante, qui prsenteplusieurs intrts :

Partager les problmes rencontrs et se mettre daccord sur leur dfinition

Penser vrifier le rsultat des actions mises en uvre

Agir ensemble

Le management visuel favorise lauto-organisation de lquipe afin quelle puisseragir rapidement aux problmes et adapter son fonctionnement pour faire dela rsolution de problmes. Il permet ainsi lquipe de prendre ses propresdcisions 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 plusseulement une opportunit de parler de ses tches, mais offre loccasion departager ses problmes. Lquipe se rorganise pour donner lquipe lopportu-nit de rsoudre les problmes bloquants sans perturber le bon droulement dusprint et surcharger les dveloppeurs.

Lquipe rsout diffrents types de problmes mis en vidence par son manage-ment visuel. Du plus simple, qui ncessite une action rapide de type just doit au plus complexe ncessitant une rflexion plus profonde. Dans lexemple

51

Figure 5.29 Tableau de suivi des problmes

le burndown tait rouge , lquipe ne se dcourage pas et continue de chercherla cause racine de son problme li au non-respect des dlais.

Lquipe consigne les problmes au fur et mesure quils apparaissent sur lemur et les traite les uns aprs les autres. Suivant la nature du problme, lquipepeut se reconfigurer et affecter certains de ses membres spcifiquement sonanalyse et sa rsolution.

La dmarche lean de rsolution de problmes est dtaille dans le prochainchapitre : Les leviers de lamlioration .

Premiers pas

Comprendre ensemble

Allez voir votre client, votre manager et votre quipe pour comprendre leurscritres de succs :

Que cherchez vous russir ?

Projetons-nous en fin danne. A quoi verrez-vous que vous avez bien russilanne ?

Aprs avoir rencontr, interrog, observ vos clients, crivez sur papier la listede ces critres. Ils dfinissent votre challenge.

Voir ensemble

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

52

O est le client ? Le challenge est-il bien reprsent ?

Prenez un des critres de succs de la liste que vous avez tablie. Commentest-elle traduite concrtement dans le management visuel ? Lobjectif est-il clairpour chacun ?

Prenez chacun des indicateurs au mur. Chacun sait-il ce quil doit faire pourcontribuer 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 managementvisuel, 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 managementvisuel ?

Aller plus loin

The Visual Factory

Michel GREIF Edition Productivity Press

Version franaise disponible en ebook

Aller lessentiel :

Chapitre 5 The Visual Production Control pour des exemples de manage-ment visuel

Chapitre 6 Process Indicators pour comprendre les indicateurs de perfor-mance ( ne pas confondre avec des indicateurs dactivit)

Creating a Lean Culture

David MANN Edition CRC Press

Shingo Prize : la plus haute distinction des livres lean

Aller lessentiel :

Chapitre 4 Visual Controls pour retrouver des exemples de managementvisuel

53

54

Chapitre 6

De Lamlioration continue Trouver les leviers delamlioration

Les pratiques agiles

Au plus profond de la culture agile

Des principes favorisant lidentification des actions damlioration sont intgrsau plus profond de la culture agile.Par exemple :Le dveloppement itratif : Rpter les mmes activits permet damliorersa pratique.La livraison frquente : En sassurant que les fonctionnalits dveloppes sontremises rapidement entre les mains du client, lagilit cre les conditions pourquune conversation ait lieu avec lui. Sil nest pas satisfait, lquipe cherche unmoyen damliorer la situation.Les temps rtrospectifs : En rservant du temps pour rflchir, lquipe crelespace ncessaire pour le choix dactions damliorations.

Les domaines privilgis damlioration

Au fil des annes, la communaut agile sest constitue un riche catalogue depratiques favorisant lamlioration.Le mouvement agile a t initi par des dveloppeurs qui voulaient rompre avecdes mthodes de projet contraignantes, des environnements de collaborationpeu propices lpanouissement, et des pratiques dingnierie inefficientes. Cestla raison pour laquelle on peut trouver des pratiques agiles dans ces diffrentsdomaines. En voici quelques exemples significatifs.

55

Lorganisation du travail

Comme le mcanicien qui sait reprer les anomalies dans le bruit rptitif dumoteur, lquipe identifie les effets des changements introduits par leurs dcisionsdune itration lautre. Elle sait reconnaitre des motifs rcurrents, sait ragiret grer le stress par le rythme du travail. Cette ide est reproduite de manirefractale jusquaux gestes du dveloppement : la construction dun programmeest 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 damliorationdu produit logiciel. Le dveloppement pilot par les tests est un bon moyen deconstruire un design mergeant, garant de lvolutivit du code. Cela a pour effetde crer des degrs de libert (fonctionnelles, techniques) et assure la facult delquipe de dlivrer des volutions un rythme constant. Le refactoring est aussiune manire pour lquipe de polir son code, de se lapproprier, le rendre plushabitable (Cf Software Craftmanship).Le binmage constitue galement un levier damlioration. Par exemple, enassociant un dveloppeur dune grande exprience mtier avec un dveloppeurnouveau dans lquipe : le dveloppeur nouveau avec son il neuf peut apporter dela hauteur dans les solutions conues, ainsi que son expertise technique. Lexpertmtier peut apporter au novice ses explications des concepts et techniques duprojet.

56

La communication interpersonnelle

La qualit de la communication reprsente un axe majeur damlioration. Pourexploiter les bnfices de la communication orale, il est conseill de regrouperles postes de dveloppement dans le mme bureau. Quand la situation lexige,lquipe peut galement augmenter la bande passante auprs de son client, parexemple en linvitant plus frquemment des runions de travail.

La construction dquipe apparat galement comme un domaine daction priv-ilgi. Les coaches agiles puisent dans plusieurs domaines des sciences humaineset 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 dela culture agile (The best architectures, requirements, and designs emerge fromself-organizing teams). Aussi, la source privilgie de leviers damliorationrside dans lquipe mme.

La rtrospective, quelle ait pour objet une itration ou un projet entier, est lemoment privilgi pour analyser la situation et choisir un levier damlioration.Chaque levier consiste introduire ou ajuster une pratique issue du cataloguecit prcdemment, ou une action concocte sur mesure.

La diversit des points de vue de chaque individu est le gage du potentieldamlioration de lquipe. Celle-ci doit sefforcer dexploiter au mieux cette

57

richesse en partageant les informations pertinentes dont chacun peut disposerindividuellement. Une fois ces informations partages, nombre de techniquesfacilitent lidentification des problmes rsoudre et la mise au point dactionsde rsolution, mais toujours en sappuyant sur le collectif.

Quelle quen soit la source dinspiration et la mthode daccouchement, unebonne action damlioration runit les caractristiques suivantes :

elle est prometteuse : Le bnfice attendu important. Ce bnfice est valuselon les critres propres aux participants.

la porte des participants : Ceux-ci sont en mesure de la mettre enuvre avec les moyens leur disposition ; ceci exclut les actions trop coteuseou en dehors du champ daction.

elle remporte ladhsion : Cest laction qui fait consensus parmi les par-ticipants qui est choisie.

Les sections suivantes illustrent les retours dexprience de praticiens agilesqui ont essay des pratiques lean sur leurs projets pour aller plus loin danslamlioration.

Scne de crime : la mise en production qui nedevait 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 decode Java, une plateforme Linux/Apache/Tomcat/Mysql et un bus de donneserlang RabbitMQ. Ce service est dvelopp par mon quipe de 8 dveloppeurset exploit par 3 ingnieurs systme. Cette quipe de dveloppement pratiquescrum et XP depuis 4 ans.

Un matin, je retrouve lquipe systme avec des cernes, en intervention depuis 5h du matin. Le service web grand public est techniquement oprationnel, maisinaccessible. Malgr un rollback effectu sans problme, le monitoring du bus dedonnes et des consommateurs des messages de statistiques est toujours rouge,signalant un incident. Cest pourquoi lquipe systme nose pas rouvrir le serviceau 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 unconsommateur la main sans passer par le script dexploitation. Je dcouvreune erreur (NullPointerException). Elle indique que lexcutable na pas trouvson fichier de configuration. Le lien symbolique vers le rpertoire des fichiersspcifiques lenvironnement de production nexiste pas. Lingnieur systme lerecre immdiatement la main. Il redmarre les consommateurs et une minuteplus tard le monitoring repasse au vert. Le service est r-ouvert et le traficreprend.

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 pleexploitation client est pass en incident majeur (plus de 2h dinterruption deservice + retour arrire). Il veut passer en niveau de vigilance maximale sur laprochaine 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 unevolution dune importance ingale depuis 7 ans. Pour assurer cette grossevolution, il faut effectuer 4 mises en production. En comptant 19 jours depravis pour chacune, il faudrait 3 mois au lieu des 2 semaines voulues par lemarketing.

Les 5 pourquoi

Une fois le service rtabli, je pars mener une enqute minutieuse, dans lespritdes 5 pourquoi du lean 1 pour viter la rapparition de lincident.

Pourquoi le lien symbolique na-t-il pas t cr ? Le script shell dinstallationmaintenu par lquipe systme na pas cr ce lien symbolique.

Pourquoi ? Ce script est compos de deux instructions : une vrification demonitoring et la cration du lien symbolique. Linstruction de vrification choueet 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 demonitoring.

Une cause profonde 2 a t identifie : une maladresse lors dun changementtechnique.

Lchec des procdures qualit

Pourtant, dans mon entreprise, il existe un standard pour se prmunir de cegenre de maladresse, savoir la rptition systmatique en environnement depr-production.

Pourquoi la rptition en pr-production na-t-elle pas rvl ce dysfonction-nement ? Les scripts shell dinstallation qui sy trouvent sont diffrents de ceuxen 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 dulien 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 champdaction.

Nous modifions notre code pour quil adresse lingnieur systme un messageexplicite 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 delamlioration

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 plustt et saccompagne dun arrt immdiat. Dans le cas des machines et des outils, lal-

60

Figure 6.4 arbre causal dun incident de production

Figure 6.5 Introduction dun andon dans le script

61

Comme nous avons la main sur le script dexploitation, nous le modifions pourrediriger la sortie standard, jusque-l ignore, vers les logs systmes. Nousajoutons galement la capture de lexception NullPointerException de manire informer lexploitant du problme sur la sortie standard. Pour ne rien laisser auhasard, nous testons ce message auprs de lingnieur systme pour sassurer desa comprhensibilit.

Prochaines investigations mener :

comprendre do vient la diffrence entre la pr-production et la production ; comprendre pourquoi lingnieur systme a produit un script dfectueux.

Je suis content davoir compris ce qui stait vraiment pass et davoir trouvune contre-mesure conome qui empchera le mme dsastre de se reproduire.

Jai la satisfaction davoir pos la premire pierre du long chemin vers le rtab-lissement de la 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 lincidentne se reproduise pas.

Le rsultat

Notre application est devenue plus exploitable. Elle met un peu plus notre quipesystme en situation de russir.

Nous avons identifi des sources de variabilit prcises, qui vont permettre uneinvestigation plus pousse.

Ce que jai appris

Je croyais tre impuissant face un incident qui relevait compltement duneautre 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 lesystme de log narrive pas sinitialiser.

lumage du andon est automatique en cas danomalie. En informatique, cela voque le con-cept du Fail-Fast (cf [http ://martinfowler.com/ieeeSoftware/failFast.pdf] (http ://martin-fowler.com/ieeeSoftware/failFast.pdf)).

62

Scne de crime : du rififi dans mes sprints

Chaque anne, mon quipe agile doit assurer la maintenance dun site webmarchand en plus de son activit de dveloppement. Cette activit ponctuelleperturbe 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 faireattention 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 reviennentdanne en anne (espace disque insuffisant, fiabilit des statistiques, magasinsqui ne prsentent pas loffre. . . ). Lquipe apprend ragir rapidement aux bonsproblmes 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 problmesidentifis 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 enutilisant la technique des 5 pourquoi 6. Cette technique simple permet detrouver la cause racine du problme.

Ensuite, lquipier propose une contre-mesure pour supprimer cette cause. Ildtermine galement un indicateur appropri la vrification de lefficacit de lacontre-mesure. Suivant le rsultat de la vrification, les procdures sont adaptespour intgrer la nouvelle pratique.

Le service de prise de commande ne rpond pas dans lestemps.

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. Unepremire investigation identifie la cause principale : un des serveurs ddis laprise de commande na plus suffisamment despace disque.

Lquipe recherche sur le disque la partition incrimine. Elle dcouvre que lerpertoire /tmp est plein.

Action immdiate : Un dveloppeur vide le rpertoire et tout revient danslordre.

Action dfinitive : Nous cherchons resoudre le problme en suivant les tapesdu 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 queles 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 activerles logs binaires sur les serveurs en question6. 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 prisede commande.

Lanalyse de la cause racine a permis didentifier une seconde action qui devraitpermettre dviter la rapparition du problme.

Action 2 : dsactiver les logs binaires sur tous les serveurs ddis la prise decommande.

Check

Il ny a plus de log binaires dans le rpertoire /tmp et lespace disque demeuresuffisant pour que lapplication fonctionne correctement.

Act / Adjust

Aprs vrification du rsultat des actions, la procdure dinstallation des serveursde 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 performancesdanne en anne. Le nombre de rclamations client a diminu de 37% endeux ans pendant que le trafic augmentait de 40% et que le nombre defonctionnalits augmentait dune dizaine chaque anne.

La diminution du nombre de problmes a permis de limiter limpact de lamaintenance sur la vlocit de lquipe de dveloppement tout en garantissantla satisfaction de notre client.

Au-del des bnfices pour ce projet prcis, jobserve que lenchanement descycles Plan-Do-Check-Act fait monter en comptence mon quipe et que lesautres 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 lasatisfaction 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 metdeux 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 leproblme. Il met une feuille au mur, puis