Petit guide de management lean lusage des quipes agiles

crit par un collectif de dix auteurs sous la houlette bienveillante de Rgis Medina Version 1.04 4 septembre 2013

Table des matires

1 Avant-propos 2 Inauguration du pont 3 Structure du livre 4 De Satisfaire le client Comprendre son attente Pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scne de crime : apparition mystrieuse au cabinet dentaire . . . . . . Scne de crime : vie et mort dune ide gniale . . . . . . . . . . . . . Scne de crime : la catgorie mystre du projet Condor . . . . . . . . . Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 6 7 7 10 13 15 18 22 23

5 De Management visuel Visualiser le challenge et les problmes 24 Les pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scne de crime : trouvez lindic ! . . . . . . . . . . . . . . . . . . . . . Scne de crime : tous coupables . . . . . . . . . . . . . . . . . . . . . . Scne de crime : le burdown tait rouge . . . . . . . . . . . . . . . . . Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 29 34 39 44 51 52

6 De Lamlioration continue Trouver les leviers de lamlioration 54 Les pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scne de crime : la mise en production qui ne devait pas chouer . . . Scne de crime : du ri dans mes sprints . . . . . . . . . . . . . . . . Scne de crime : joue-la courte et prcise . . . . . . . . . . . . . . . . . Principes lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aller plus loin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Conclusion 8 Livres de rfrence Le management lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . La pratique du lean management dans lIT . . . . . . . . . . . . . . . 9 Ressources de rfrence 54 57 62 65 68 73 74 77 78 78 78 80

Cette uvre est mise disposition selon les termes de la Licence Creative Commons Attribution - Pas dUtilisation Commerciale - Pas de Modication 3.0 non transpos.

Les auteurs Philippe Blayo Antoine Contal Dominique De Premorel Pierre Jannez Christophe Keromen Rgis Medina Sandrine Olivencia Christophe Ordano Raphal Pierquin Bruno Thomas

web www.barreverte.fr

twitter @pblayo @antoine_contal @domidepremorel @pierrejannez

www.ckti.com www.regismedina.com www.leanedge.org

@ckeromen @regis_medina @sandrineolivenc @chrisordano

ut7.fr www.barreverte.fr

@perafoo @bam_thomas

Chapitre 1

Avant-propos
Les pratiques prsentes dans ce guide ouvrent la voie vers une vision dirente de lorganisation. Une vision base sur une conviction : Le changement vers une organisation la fois plus ecace et plus respectueuse des personnes est possible. Ce changement nat de la somme des apprentissages individuels. Lamlioration continue, en dnitive, est celle des comptences de chaque collaborateur. Lapprentissage devient indissociable du travail, et le qui doit faire quoi pour russir devient qui doit apprendre faire quoi pour russir . Cette transformation radicale se construit jour aprs jour, personne par personne, en allant sur le terrain pour aider chaque collaborateur russir sa journe. Cela amne chacun crer plus de valeur pour ses clients, son entreprise et la socit, et trouver ainsi un sens son travail. Le chemin vers cet idal a t trac par nos prdcesseurs pendant plusieurs dcennies, et consign sous la forme de principes et de pratiques qui ont pris le nom de lean . Ce savoir-faire prcieux nous a t transmis par Marie-Pia Ignace et Michael Ball. Nous vous le transmettons notre tour, en esprant quil vous apportera les mmes moments de satisfaction, les incroyables dclics qui vous feront prendre de la hauteur. Rgis Medina

Chapitre 2

Inauguration du pont
Depuis plusieurs annes, lesprit et les pratiques agiles vous ont permis damliorer votre satisfaction professionnelle et la performance de vos quipes. Mais voil : il reste encore des sources de frustrations. Les autres quipes rsistent, les managers ne sponsorisent pas vos initiatives de changement, les clients se plaignent. Il doit bien exister des moyens damliorer les choses, mais comment les trouver ? En vous entranant aux pratiques lean slectionnes dans ce livre, vous apprendrez : trouver les leviers de lamlioration qui amneront vos quipes un autre niveau de performance ; rsoudre les dicults que vous rencontrez dans vos relations avec dautres quipes ou le management ; livrer des logiciels qui amliorent la vie de vos utilisateurs et dont vous pouvez tre ers. Ces nouvelles comptences vous apporteront le savoir-faire ncessaire pour insuer les changements vitaux au sein des organisations. Ce livre se structure autour de trois apprentissages fondamentaux. Pour chacun dentre eux, des praticiens agiles vous racontent comment, en appliquant dautres pratiques, en adoptant dautres postures, en sentranant fonctionner diremment, ils ont trouv des solutions simples des problmes qui paraissaient complexes. Puis des experts dcrivent les principes lean mis en uvre dans les histoires prsentes. Enn, des prconisations de premiers pas vous guident vers la mise en pratique. Ce livre est n de du dsir de praticiens agiles ayant expriment le management lean de partager les richesses surprenantes de ce nouveau continent. Nous souhaitons transmettre ce que nous avons appris lors de notre voyage initiatique. Notre promesse : a en vaut la peine !

Chapitre 3

Structure du livre
Ce guide comprend trois chapitres : Comprendre lattente du client Visualiser le challenge et les problmes Trouver les leviers de lamlioration Chaque chapitre est organis de la faon suivante : Une description des pratiques agiles sur le thme abord. Trois cas rels dquipes agiles ayant intgr le management lean dans leurs pratiques. Ils dcrivent leur contexte, les exercices quils appliquent, et ce quils y gagnent. A la n de chaque cas, nous analysons et dveloppons les principes lean mis en uvre. Une description des pratiques lean sur le thme du chapitre. Les premiers pas que nous proposons de mener pour se lancer. Des rfrences de lecture pour aller plus loin. Bonne lecture et du succs dans vos exprimentations !

Chapitre 4

De Satisfaire le client Comprendre son attente

Pratiques agiles
Linspiration du manifeste
Le Manifeste agile (http://agilemanifesto.org/) met le client au centre des proccupations du dveloppement Agile de logiciels. Les signataires insistent en particulier sur la ncessit de collaborer avec le client pour rpondre son besoin : La collaboration avec les clients plus que la ngociation contractuelle. Dans une approche agile, le primtre du produit nest pas g. Lquipe doit fournir au client toute linformation qui lui permette doptimiser la production de valeur en fonction de leort fourni. En contrepartie, le client est co-responsable de latteinte de lobjectif. Il simplique de manire rgulire dans la rednition du primtre fonctionnel. Scrum prconise ainsi lactivit de Product backlog grooming tout au long du projet. Nous retrouvons plusieurs fois mentionn le client dans les douze principes : Notre plus haute priorit est de satisfaire le client en livrant rapidement et rgulirement des fonctionnalits grande valeur ajoute. Les processus Agiles exploitent le changement pour donner un avantage comptitif au client. Les utilisateurs ou leurs reprsentants et les dveloppeurs doivent travailler ensemble quotidiennement tout au long du projet. Lquipe de ralisation et le client adoptent une posture dapprentissage la fois du processus et du produit. Postulat de lagilit : le besoin nest pas compltement identiable en amont de la ralisation et de nombreux changements ultrieurs imposeront lensemble des acteurs de sadapter en cours de ralisation. Seule une collaboration troite entre tous les intervenants permettra cet apprentissage. En agilit, satisfaire le client suppose dabord de se donner la possibilit dexprimenter, puis de tirer des enseignements du rsultat des expriences an de 7

rednir les prochains lments produire.

Focus produit
La dmarche traditionnelle prsuppose que le besoin du client peut tre captur. Il est clairement identi, nvoluera plus et fait lobjet de spcications dtailles. Adoptant une position trs dirente, les agilistes sont obsds par une question : sommes-nous en train de construire le bon produit ? Le focus est ainsi dplac du projet vers le produit. Scrum ancre encore davantage cette importance de lorientation produit en rpartissant les responsabilits anciennement cones au chef de projet vers un nouveau triumvirat : quipe, Scrum Master et Product Owner.

Figure 4.1 Le Trimvirat Agile

La mise en pratique quotidienne

Le bon produit ? Comme nous lavons rappel, lquipe agile sattle en priorit au d de livrer rapidement et rgulirement des fonctionnalits au client. Cela permet de confronter son attente la ralisation. Ensemble, ils inspectent le travail ralis, puis dcident des adaptations ncessaires pour se rapprocher de la satisfaction du besoin. Itrations et approche empirique Les quipes agiles adoptent ainsi un processus qui sappuie sur des itrations courtes (deux quatre semaines en Scrum). Elles mettent en uvre une ap8

proche empirique reposant sur une succession rapide et rgulire dessais-erreurscorrections. Spcier en favorisant la communication Dans lobjectif de pouvoir livrer rapidement, les exigences fonctionnelles sont dcoupes en petits lments qui permettront une focalisation sur de petits lots porteurs de valeur. Pas de spcication dtaille exhaustive en amont, mais une prcision juste temps (au moment o les fonctions vont tre ralises) sous forme de conversation entre le reprsentant de lquipe et le client. Une pratique courante consiste formaliser ces lments sous la forme de User Stories. Ces histoires utilisateur combinent une concision impose (doit tenir sur une carte) et la dtermination de tests dacceptation par le client (doit tre testable). Comment maximiser la valeur ? Pour dterminer le contenu fonctionnel de la prochaine itration, lquipe agile collabore avec le client en vue de maximiser la valeur ajoute au produit. Ensemble, ils tablissent une liste des prochains lments raliser en prcisant lordre dans lequel ces lments doivent tre produits. Lordre dtermin tient compte en priorit de la valeur dun lment et de leort ncessaire sa ralisation. En agilit, lestimation de leort nest pas laaire dun seul individu. Les personnes devant raliser sont les mieux placs pour estimer. La pratique du Planning Poker permet par exemple dobtenir une estimation collective de leort de ralisation, tout en contribuant diuser la comprhension du produit raliser.

Figure 4.2 User Stories

Le logiciel oprationnel Le manifeste insiste sur limportance de la production dun logiciel oprationnel : Un logiciel oprationnel est la principale mesure davancement. Lobtention de ce logiciel oprationnel en n ditration permet lensemble des acteurs de se runir pour passer en revue les lments compltement termins (conformment la dnition de termin tablie au pralable avec le client). Cette runion permet de vrier ladquation de la production au besoin. Les participants obtiennent des informations qui sont exploites lors de la planication du contenu de la prochaine itration. Le bon produit et le maximum de valeur ? Seule la mise disposition des lments naliss auprs des utilisateurs naux permet de dterminer si lquipe a construit le bon produit porteur de valeur. En consquence, lobjectif ultime de lquipe agile consiste se mettre en mesure de mettre en production immdiatement les lments valids lors de la revue (Continuous delivery ), liminant jusquau besoin de dnir des versions (releases ).

Nous dcouvrons comment mieux dvelopper des logiciels par la pratique

La communaut agile explore de plus en plus le concept du Right Product en exprimentant des pratiques trs diverses (inspiration du Lean Startup, notion de Minimal Viable Product ), souvent fondes sur une reprsentation visuelle des concepts (Persona, Impact Mapping, Story Mapping, Empathy Map. . . ). Elle cherche galement tirer le meilleur parti de la spcication par lexemple en allant jusqu lautomatisation des tests fonctionnels (BDD pour Behaviour Driven Development , etc.) Les sections qui suivent dcrivent les expriences de quelques praticiens agiles qui ont mis en uvre des pratiques lean pour mieux comprendre les attentes de leur client.

Scne de crime : apparition mystrieuse au cabinet dentaire

Un rseau de dentistes cherche sinformatiser pour saisir les donnes de ses patients, aussi bien dans les tablissements daccueil spcialiss que dans les centres de soin en ville ou lhpital. Lors du recueil des besoins, avec mon quipe de dveloppement, nous avons dcouvert que les dentistes sont en fait des geeks qui aiment les Macs . Nous avons identi ce qui est important pour eux : la facilit de prise en main, la convivialit et lutilisation de la souris. 10

Figure 4.3 Exploration du right product

Observation sur le terrain

Nous ralisons un go&see 1 en nous rendant sur le terrain (le gemba 2 , en terme lean) pour voir comment travaille un praticien. Le praticien interroge le patient sur ses antcdents 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 eectuer la saisie. Il russit son challenge grce son assistante qui saisit les donnes au fur et mesure de lexamen. Notre hypothse selon laquelle lutilisateur premier tait le dentiste se rvle errone. Or, pour aller plus vite, cette assistante nutilise que les touches du clavier : pas une minute perdre pour enchaner ces dix vacations.

Vrication de lobservation
Ce que nous avons observ change notre perception de lusage de cette application.
1. go&see est une pratique lean : cf.la section Principe lean de ce chapitre. 2. gemba dsigne lendroit o les choses se passent. Cf. la section Principe lean de ce chapitre.

11

Figure 4.4 Contexte dutilisation du logiciel Une fois rentrs, nous menons une exprimentation en navigant uniquement avec les tabulations du clavier. Cest une catastrophe ! Lutilisateur est balad de haut en bas, le faisant tourner en girouette.

Action corrective
Lquipe change la navigation pour que les tabulations suivent lordre dans lequel lassistante eectue la saisie.

Figure 4.5 Nouveau schma de navigation au clavier

12

Le mot de lassistante : merci Go&See

Sans cette visite au cabinet, l o les choses se passent, nous naurions pas dtect les attentes ergonomiques spciques de lassistante. Le logiciel laide maintenant correctement pour remplir sa mission.

Quavons-nous fait aller voir le client, sur son lieu de travail, pour mieux comprendre son contexte ; confronter nos hypothses avec la ralit du gemba ; adapter loutil lusage dans son contexte puis retourner sur le terrain pour conrmer la valeur apporte ;

Le rsultat Nous avons dcouvert un nouvel utilisateur et ses attentes ergonomiques, ce qui nous a amen adapter le logiciel pour lui en faciliter lusage. Ce que jai appris Toute hypothse sur le client doit tre confronte la ralit du gemba. Cest une excellente pratique pour identier la valeur et les prfrences du client.

Scne de crime : vie et mort dune ide gniale

Une ide gniale
Lors dun atelier regroupant des crateurs de startups, les participants les plus courageux pitchent leur ide. Lun dentre eux a une intuition formidable : crer un guide touristique international, proposant les bons plans des autochtones . Lorsquon visite Venise lt, plutt que de suer dans un bain de foule sur la place Saint Marc, autant aller siroter un Spriss (la boisson locale) au comptoir du bacaro dune petite place ombrage. Les vnitiens le savent bien. Le touriste moyen, lui, ne sait pas o trouver ces bons plans. Trs vite, dautres participants viennent renforcer notre petite quipe naissante et la machine semballe. On se retrousse les manches, et on travaille dj sur les questions fondamentales : Comment rcolte-t-on ces astuces ? Combien peut-on vendre ce guide ? etc. Tout le monde est motiv, prt attaquer le dveloppement du site web et de lapplication mobile correspondante.

13

Aller voir vos clients

Lanimateur intervient en nous demandant daller la rencontre de nos futurs clients. Le lean appelle cette pratique couter la voix du client 3 Notre mission : comprendre comment, aujourdhui, les touristes trouvent leur bons plans. Protons de notre situation, en plein cur de Paris, pour rencontrer des touristes avides dastuces de Parisiens.

Dsillusion
Deux heures plus tard, nous voil de retour, dpits. Que sest-il pass ? Lentrepreneur explique : Je tombe des nues. On en a vu, des touristes. Mais aucune rponse sur leur dicult trouver des bons plans locaux, puisquils nen cherchent pas. Les plans locaux, a ne les intresse pas. Ce qui a de la valeur pour eux, cest de trouver le bon chemin pour aller voir la Tour Eiel.

La leon tirer
Lhistoire de cette ide gniale se termine ici. Mais pas celle de notre quipe dentrepreneurs : quelques minutes leur ont su pour trouver une nouvelle ide gniale. Mais cette fois-ci, en commenant par une visite terrain 4 avant de semballer. Voil une belle n, puisquau cours de cette histoire, aucun dveloppeur na d dvelopper un logiciel inutile. Lentrepreneur a pu consacrer lnergie conomise dautres projets plus prometteurs. Lerreur de lentrepreneur peut sembler vidente, mais elle est pourtant trs rpandue. Son ide, comme toutes les ides, reposait sur des hypothses. Lune de ces hypothses ( les touristes recherchent les bons plans locaux ), quil considrait pourtant comme une vidence, ne correspond pas la ralit. Cette illusion dvidence, renforce par le confort du bureau, retient bien des entrepreneurs, et au moins autant de Product Owners, daller se confronter la ralit. Ils manquent ainsi lopportunit de valider leurs hypothses sur les besoins des utilisateurs et les problmes que ceux-ci rencontrent dans leurs activits. 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 ecace de valider des hypothses sur les attentes du client est daller voir les utilisateurs potentiels Plus vite nous confrontons ces hypothses la ralit du terrain, plus nous gagnons du temps sur la cration de la valeur.

Scne de crime : la catgorie mystre du projet Condor

Un oprateur tlcom vend aux entreprises une solution de centre dappels virtuels. Cette solution est dveloppe par notre quipe agile de sept personnes. Nous avons hrit dun code de mauvaise qualit que nous amliorons progressivement. Cependant, nous sommes confronts environ deux signalisations 5 par jour de nos utilisateurs naux. Cela provoque une tension avec le management, notre commanditaire est furieux, et les relations avec les exploitants sont diciles.

Catgorisation des incidents

Je dcide de prendre le cas au srieux. Pour cela, je commence par lire les tickets dincidents dans loutil de ticketing du SAV. Il y a beaucoup de types de tickets dirents. Je les compte et les catgorise. Cela constitue un bulletin de sant que jache sur le mur lentre de notre War Room.

Figure 4.6 Bulletin de sant du projet Condor

5. Nous appelons signalisation un incident remont par lutilisateur.

15

Analyse du problme
Les trois catgories les plus volumineuses sont : 1. formation utilisateur : les utilisateurs ne comprennent pas comment fonctionne lapplication ; 2. rseau et plateforme : pas directement lie des dfauts logiciel ; 3. mystre : nous ne savons pas identier lorigine de la signalisation. Premire surprise, le grand gagnant est la catgorie mystre . Deuxime surprise, il y a nalement une minorit de signalisations lies la qualit logicielle. Par ailleurs, je me rends compte que de nombreux tickets sont rests sans rponse : ils taient abandonns dans loutil.

Identier lorigine
Dsaronns par le ou de ces tickets mystre, nous dcidons davancer sur notre problme en nous donnant les moyens didentier lorigine des prochaines signalisations. Nous faisons un travail important damlioration des logs de lapplication. Les rcapitulatifs quotidiens qui remontent par mail les erreurs et les warnings contiennent plusieurs centaines de lignes htrognes. Nous donnons un format standard ces logs, en dcrivant les informations devant y gurer (client, identiant dappel, raison de lerreur avec un lment de contexte). Nous nous rendons compte quil est dicile de suivre un appel tlphonique entier car certaines logs sont sur les SVI (Systme Vocal Interactif) et dautres sont sur les serveurs dapplication. Nous dveloppons un script dagrgation pour consolider chronologiquement ces sources direntes. Nous faisons alors diminuer drastiquement la catgorie mystre de 30% 5%.

Gestion du timeout
Maintenant que nous voyons plus clair, un motif important de signalisation semble lie au protocole de communication avec le serveur du rseau tlcom qui est bas sur de lUDP. Rien ne garantit dans ce protocole que linformation ne soit pas perdue. Dans un certain nombre de cas, la perte dun vnement entrane le blocage des appelants sur une le dattente du SVI. Il faut attendre le timeout du SVI qui est de 30 mn. Cest inacceptable pour lquipe. Nous dcidons de mettre en place un mcanisme de gestion de timeout. Cela demande dajouter une couche de simulation du temps pour la compatibilit avec les tests automatiques.

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 trac le plus lev.

Observation chez le client

Accueillis dans une atmosphre tendue, nous allons observer les agents du centre dappel avec leur superviseur. Sous nos yeux, une opratrice double-clique sur le bouton de pause. Cela a pour eet de demander une pause et de sortir de pause immdiatement. Surpris, nous lui demandons pourquoi elle fait cette opration. Elle nous explique quelle repasse ainsi devant ses collgues dans la le dattribution des appels, an de prendre plus dappels. Le superviseur nous explique que les agents sont intresss au nombre dappels traits. Sidrs, nous comprenons alors les incidents de distribution dappels remonts par les autres, tonns que leur collgue leur passe devant. Devant nous, un autre agent prend un appel et souhaite appuyer sur une touche de fonction pour acher une information de leur outil de CRM. Ce faisant, sa main eeure le bouton raccrocher et elle perd lappel sans comprendre pourquoi. Nous venons de rsoudre un autre ticket non reproductible. Mais pas seulement. Le superviseur qui nous accompagne a assist la scne et comprend que le problme ne vient pas de lapplication, mais de lergonomie des postes de travail. Il fait rehausser les postes tlphoniques pour quils soient plus loigns des claviers. Plus tard dans laprs-midi, une opratrice redirige un appel vers lhtel de Roissy. Une personne de lquipe de dveloppement qui nous assiste distance prcise que lappel est perdu. Nous allons voir la conguration de lapplication et ralisons que le numro de lhtel est erron. Voil lexplication des erreurs de type RouteSelectFailure. Nous avions longtemps privilgi la fausse piste des problmes de standard chez le client. Nous partons dans un climat plus dtendu : les agents sont contents davoir t couts et nous sommes soulags davoir supprim trois causes de signalisation.

Quavons-nous fait commenc par visualiser notre problme ; protg le client en coutant et en prenant au srieux ses plaintes ; nous rendre sur le gemba 6 en lisant les tickets de support puis en allant voir lutilisateur en action. 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 dnitive dun grand nombre de problmes qui paraissaient hors de notre porte.

Principes lean
Comprendre le besoin profond du client
La dmarche damlioration du lean commence par la dnition dun objectif clair et partag par tous. Cet objectif est construit en prenant comme premire rfrence la satisfaction complte des clients du projet. Or lexprience montre un cart frquent entre ce quun client exprime et ce qui le satisfait rellement. Cette dicult sexplique de plusieurs manires : Il lui est dicile de formuler les exigences du logiciel sans y ajouter ses propres prfrences ou interprtations. La demande le met en situation de concepteur de logiciels - un mtier pointu auquel il nest souvent pas form. Le lean propose un ensemble de pratiques et principes ecaces pour cibler les besoins rels du client et aner la comprhension de ses prfrences. Tout dabord, dans un contexte de dveloppement logiciel, il faut identier quels sont les vrais clients du projet. Il en existe trois grandes familles : Lutilisateur nal, celui qui va proter directement le logiciel au quotidien. Le commanditaire, qui paie la prestation de dveloppement et en attend un retour conomique. Sa satisfaction dpend de celle de lutilisateur nal, mais aussi dautres paramtres qui svaluent au niveau de lentreprise. Les quipes en aval de lquipe de dveloppement qui vont tester, exploiter, et fournir du support. Dans un contexte agile, il est important de ne pas considrer priori le Product Owner comme tant le client au sens lean du projet. Dans de nombreux cas le Product Owner dsign pour le projet est plutt un reprsentant du commanditaire et des utilisateurs. Dun point de vue lean, il est donc plutt du ct de lquipe, et les clients au sens lean restent principalement les utilisateurs et le commanditaire. Chacun de ces clients a ses propres attentes, quil faut identier et satisfaire. Le lean ore une structure pour guider cette exploration, base sur cinq axes : Les pratiques qui suivent constituent un bon point de dpart pour entamer ce travail de dtective. 18

Figure 4.7 Les cinq attentes du client

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

Le vritable besoin du client ne se dniche pas dans une salle de runion. Il faut aller le trouver sur le terrain, l o laction se passe un lieu que les praticiens du lean appellent le gemba . Dans un contexte agile, il sagit de lendroit o lutilisateur sera amen utiliser le logiciel. Simple dapparence, cette observation recle toutefois un pige : le go&see peut se transformer rapidement en go&talk , bien souvent linitiative de la personne observe. Quelques points doivent tre respects pour viter cet cueil : Expliquer la personne observe lobjectif et les modalits de lobservation, en prcisant quil sagit dune observation et non dune interview. Si ncessaire, il est possible de demander cette personne de penser voix haute pour mieux comprendre ce quelle cherche faire. Observer le plus longtemps possible sans parler. Rpondre poliment ses questions et linviter reprendre son activit. Une bonne observation doit apporter des lments de rponse deux questions : Que cherche faire lutilisateur dans ce contexte prcis ? Quels sont les obstacles quil rencontre pour atteindre son objectif ? Les deux exemples Apparition mystrieuse au cabinet dentaire et Vie et mort dune ide gniale illustrent les prises de conscience importantes que provoquent habituellement des observations russies. En termes lean, ces observations amnent lquipe observer le processus de son client : o se trouve la valeur ses yeux et quels sont les gaspillages liminer. Avec les quipes en aval, lexercice est quasiment identique, mais lattention porte 19

essentiellement sur lidentication des gaspillages que les livraisons de lquipe agile gnrent chez ces autres quipes. Lquipe agile met-elle ces dernires en condition de russir ? Dans le cas du commanditaire, lexercice consiste comprendre comment il mesure le succs et les quelques points qui sont vritablement essentiels pour lui. Comme pour lutilisateur, le go&see nest pas un go&talk . Lobservateur dcouvre par exemple que le commanditaire est sensible telle ligne prcise dans un reporting comportant des centaines de pages.

Dnir le problme rsoudre et la faon de mesurer le succs

Plutt que de dnir lattente du client sous la forme dune solution mettre en uvre (les fonctionnalits dvelopper), le lean pose la question du problme global auquel le projet doit apporter une solution pour satisfaire ses utilisateurs et commanditaires. Une fois le problme pos, il sagit de dnir la faon dont il sera possible de vrier que le projet la bien rsolu. Lquipe se dote dindicateurs objectifs qui retent ce succs. Quelques exemples : Amliorer la qualit : taux derreur commis par les utilisateurs, volume 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 dnir des problmes clairs rsoudre ensemble, de mieux choisir les fonctionnalits et les sujets damlioration, et de vrier que les ides damlioration mises en uvre portent leurs fruits. Il sagit de la fondation de la dmarche damlioration du lean, base sur la technique du Plan-Do-Check-Act (PDCA) prsente plus loin dans ce guide.

Exprimenter pour valider ses prfrences

Chaque fonctionnalit est porteuse dincertitude. Il se peut que : malgr ses observations sur le terrain, lquipe ait mal compris lattente des clients, la fonctionnalit ne rsolve pas le problme dans le contexte de certains utilisateurs, la fonctionnalit cre de nouveaux problmes insouponns. Pour viter cela, il est ncessaire de procder de nouvelles observations terrain aprs les livraisons. Il sagit de la phase de Check de la rsolution de problmes, qui peut tre applique la n de chaque itration.

Prendre trs au srieux chaque rclamation client

Chacune des rclamations des clients est une opportunit dapprentissage, car elle pointe soit sur un lment que lquipe na pas compris, soit sur une faille dans son fonctionnement. En pratique, le travail sur les rclamations se traduit par la recherche de la cause racine du problme qui a amen le client se plaindre. Ceci conduit lquipe : mieux comprendre le contexte de son client, revoir ses convictions sur son analyse. trouver des solutions pour liminer la cause racine et viter que cela se reproduise, Cette activit danalyse des rclamations repose galement sur la dmarche de rsolution de problmes. Lexemple La catgorie mystre du projet Condor prsente une quipe qui choisit de traiter chaque signalisation utilisateur comme un problme de qualit.
7. Attention toutefois sur ce dernier point : lquipe doit rester vigilante ne pas asservir lhumain la machine. La vision lean considre la technologie comme un outil mis au service de lintelligence humaine.

21

Valeur et gaspillages
Tout ce travail dinvestigation et danalyse a pour objectif de trouver la valeur pour le client. Cest seulement une fois quelle est clarie quapparaissent clairement les obstacles : les gaspillages qui occasionnent des pertes de temps pour les utilisateurs ou ceux qui construisent le logiciel. Les gaspillages sobservent de nombreux niveaux : dans lactivit de lutilisateur il faut alors comprendre comment les liminer en amliorant le logiciel ou le support dans lactivit de traitement du logiciel installation, exploitation, sauvegarde, etc. dans lactivit de dveloppement du logiciel. Les pratiques lean ont pour objet dimpliquer lensemble des collaborateurs de lentreprise dans la recherche permanente de cration de valeur pour les clients, en utilisant llimination des gaspillages comme autant dopportunits de librer le temps prcieux de ces collaborateurs. Deux de ces pratiques principales sont prsentes dans les chapitres suivants.

Premiers pas
Pour renforcer votre comprhension des attentes de vos clients, nous proposons ces exercices :

Allez observer le client sur le terrain

Pour votre projet actuel, allez voir trois utilisateurs distincts sur leurs lieux de travail 1. Pour chacun des utilisateurs, observez pour comprendre : Que cherche-t-il faire ? En quoi la structure actuelle pose un problme ? 2. Quapprenez-vous de nouveau sur leur contexte ? La solution qui est prvue rsout-elle vraiment leur problme ?

Clariez le problme et mesurez le succs

Pour votre projet actuel, menez linvestigation pour rpondre ces questions : Quel est le bnce attendu du logiciel ? Est-ce quil permet de rsoudre compltement le problme du client ? Exprimez-le en termes de dlais, qualit et cot pour lutilisateur et pour le commanditaire.

22

Exprimentez pour valider les prfrences du client

Prenez les stories livres de votre dernire itration et posez-vous ces questions : Quel est le bnce attendu de ces stories ? Quelles observations devez-vous faire sur le terrain pour vrier quelles ont port leurs fruits ? Allez mener lobservation. Quavez-vous appris ? Quels sont les impacts ?

Regardez les rclamations

Prenez les trois dernires rclamations client. Pour chacune, menez ces investigations : Quelle est la cause racine du problme ? Quapprenez-vous sur le contexte et les attentes de votre client/utilisateur ? Comment pouvez-vous vous assurer que ce problme ne survienne nouveau ?

Aller plus loin

Le lean au service du client
Jim WOMACK et Dan JONES Edition Vuibert

Figure 4.8 livre lean au service du client

23

Chapitre 5

De Management visuel Visualiser le challenge et les problmes

Les pratiques agiles
Favoriser le travail en quipe
Dans le bureau dune quipe de dveloppeurs agiles, personne ne stonne de voir les murs couverts de post-its et de posters dessins la main. Le principe est simple : lutilisation de lespace visuel permet damliorer la qualit et la quantit dinformation change au sein de lquipe et avec ceux qui lentourent. Un projet de dveloppement logiciel en quipe se confronte la fois un besoin de communication intense et aux limites de la communication verbale, quelle soit formelle ou informelle. Les mthodes classiques ont recours des outils de gestion de projet informatiss ou des chiers sur des rpertoires partags. Solutions trop lourdes ou dshumanises pour le manifeste agile qui invite privilgier les individus et leurs interactions plus que les processus et les outils . Lachage mural est alors la rponse adapte pour la communication interne et externe.

Encourager lauto-organisation
En interne, ces lments visuels sont des outils avec lesquels les dveloppeurs interagissent et laide desquels ils se coordonnent entre eux. Par exemple, sur un taskboard, on fait avancer le post-it reprsentant une tche au fur et mesure de sa progression. Cela facilite aussi lintgration dun nouvel arrivant. Cette clart sur ce quil y a faire et sur les objectifs contribue lmergence de lauto-organisation. Ce nest plus le chef de projet qui aecte les tches, mais lquipe elle-mme. 24

Figure 5.1 Un achage 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 inecace car non partag.

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

Figure 5.2 Tableau kanban Les quipes plus avances commencent crer des aches sur mesure pour rpondre leurs problmatiques spciques. Puisque la technologie utilise (papier, feutres et traits main leve) est rudimentaire, il est facile et rapide dadapter les achages aux besoins qui mergent, et dexprimenter de nouvelles approches. Les rtrospectives sont des moments privilgis pour faire voluer les achages, pour en crer et en supprimer. Tous les formats sont bons tant que les lments achs restent utiles et utiliss.

Une pratique quotidienne

Tous les jours, lquipe se runit devant le tableau davancement des tches pour une courte runion dinspection et dadaptation. Le support visuel matrialise les informations orales fournies rituellement par chacun des membres de lquipe : depuis hier, jai termin. . . dici demain, je pense terminer. . . voici ce qui pourrait constituer un obstacle au fait de terminer. . . 26

Figure 5.3 Niko niko

Figure 5.4 Burndonw chart

27

Figure 5.5 Un poster sur-mesure

28

Figure 5.6 Exemples dachage dune quipe crative

Une pratique ecace et volutive

Les quipes agiles en posture damlioration continue sont en exprimentation permanente sur leur management visuel. Aujourdhui, pour aller plus loin elles ont recours de plus en plus lapproche kanban : matrialisation des limites sur le travail en cours, dnition de classes de service, etc. Les sections qui suivent prsentent les exprimentations dquipes agiles qui ont souhait faire voluer leur management visuel en lobservant sous un angle lean.

Scne de crime : trouvez lindic !

Le contexte
Une enseigne de la grande distribution sadresse lagence web que je dirige pour mettre en ligne son ore Traiteurs de n danne. Le site doit orir la possibilit aux clients de construire une liste de courses quils pourront utiliser ensuite en magasin pour commander leurs produits. Le site ne sera accessible que cinq semaines par an loccasion des ftes. Lanne suivante, suite au succs de lopration et une demande de plus en plus importante, lenseigne dcide dajouter le paiement en ligne. Le niveau de performance demand est trs lev : une abilit sur la commande de 100% et un taux contractuel de disponibilit au-del de 95%. Je dois donc orir mon client un service de maintenance, cependant mes quipes agiles actuelles nont aucun cadre de travail pour assurer ce nouveau type de prestation. 29

Figure 5.7 Radiateur dinformations existant pour grer les projets web Pendant les 3 annes suivantes, nous russissons au prix de gros eorts tenir nos engagements. En eet, nous devons dvelopper de nouveaux projets pour dautres clients tout en assurant la maintenance de ce site. Chaque anne lhistoire se rpte, lquipe semble toujours confronte aux mmes problmes. Les sprints sont perturbs par les actions de maintenance et les problmes de fonctionnement de lapplication. Nous ne capitalisons pas sur ce que nous avons appris les annes prcdentes. Les pnalits en cas de non-respect des engagements peuvent mettre lentreprise en danger. La pression est donc trs importante, dautant que je suis incapable de savoir tout moment si la situation est sous contrle ou pas.

La dmarche
La question qui se pose est de savoir comment tre certains que nous sommes en train de russir, cest--dire assurer un service de maintenance de qualit tout en rduisant limpact de cette activit sur le dveloppement des autres projets. La premire tape consiste comprendre ce qui est vraiment important pour le client pendant la dure de vie du site de-commerce. Je veux savoir sur quoi je dois porter une attention particulire an de satisfaire totalement mon client. Je dcide de ne pas dcider sa place et de lui poser la question. Pour cela, je mappuie sur loutil Voix Du Client 1
1. Cf. Section Principes Lean du chapitre Attentes du Client

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 x. Pour la fermeture, il est trs important darrter le service pour chaque magasin aux heures dnies par le client. Dans le cas contraire, un magasin pourrait tre dans lincapacit dhonorer les commandes passes. La rputation de lenseigne est donc en jeu. Lengagement sur la prise de commande du client du magasin. 100% des commandes prises doivent tre honores. La disponibilit du site. Le site doit tre accessible 100% du temps sur la priode douverture. Mme si contractuellement le site doit avoir une disponibilit de 95%, le client attend une disponibilit totale du service. A partir de ce constat, je construis avec lquipe un ensemble dindicateurs clefs, an de nous concentrer sur le vritable challenge permettant de satisfaire pleinement notre client. Assist par ces indicateurs, je veux connatre chaque jour ltat de la situation pour maider dcider. Les dates douverture et de fermeture du service : Un indicateur quotidien OK/NOK sur louverture et la fermeture du site par magasin. Lengagement sur la prise de commande du client du magasin : Un indicateur quotidien OK/NOK sur la conformit des commandes envoyes. La disponibilit du site : Un indicateur quotidien OK/NOK sur laccessibilit au catalogue de produit et la commande proprement dite. Un indicateur quotidien OK/NOK sur le fonctionnement des fonctionnalits du site (nuage de tags, envoi un ami,. . . ) Les indicateurs se prsentent comme suit : Nous achons et faisons vivre ces indicateurs dans notre Open Space. La situation est rendue visible. Chaque fois quil y a un problme 2 exemple : plainte client car le service est lent, avec 8 secondes pour passer commande au lieu de 2 secondes), les indicateurs sont mis jour. Tous les matins, nous faisons un point sur la situation. Si un problme est survenu la veille, cest loccasion pour nous de partager et dapprendre sur les actions menes. Notre management visuel est organis de la manire suivante : Lexploitation de ces informations me permet aujourdhui de juger avec lquipe de limportance des problmes. Lquipe travaille plus sereinement. Elle est capable de rpondre aux exigences du client le plus rapidement possible. Les projets sont moins perturbs et lquipe dlivre plus de fonctionnalits par sprint. Dautre part, cette dmarche qui amliore la qualit du service nous permet de renforcer la relation de conance avec notre client qui reconduit chaque anne notre partenariat.
2. Cf. Section Principes Lean du chapitre Leviers de lamlioration

31

Figure 5.8 Structure de nos indicateurs de performance*

Figure 5.9 Structure de notre management visuel

32

Figure 5.10 Management visuel pour une activit de maintenance

Quavons-nous fait - Comprendre ensemble : - Interroger les clients sur ce qui est vraiment important pour eux avec loutil Voix du client - Traduire le besoin du client en indicateurs de performance - Voir ensemble : - Rendre visible le challenge et les problmes - Agir ensemble : - Prendre les bonnes dcisions immdiatement ds que le problme est connu - Prparer la rsolution de problme dnitive via le PDCA 3 Le rsultat - Un site e-commerce avec un haut niveau de abilit - Des projets livrs plus vite, car moins de perturbations extrieures Ce que jai appris En qualiant ensemble la nature des problmes, nous utilisons au mieux les comptences de chacun pour rsoudre plus rapidement les problmes. Peu importe la forme des premiers indicateurs construits tant quils montrent la cible et les problmes, ils saneront dans le temps pour mieux correspondre lattente du client. 33

Scne de crime : tous coupables

Contexte
Suite la fusion de plusieurs organismes, une grande socit de services se voit coner la ralisation dun nouveau systme uni de gestion des dossiers des cotisants. Les enjeux de mise en service de ce nouveau systme sont critiques : Le suivi comptable a mis jour un cart considrable entre les cotisations, les remboursements et lencours. Il faut trs rapidement clarier la situation, puis la corriger. De nombreux cotisants font face de trs longs dlais de traitement de leurs dossiers. Aprs une premire phase de six mois, le premier lot sest sold par un chec : lquipe a livr avec un retard de plusieurs semaines, hors budget, un produit non conforme aux attentes du client. Cette situation se traduit par une crise dans lquipe de ralisation : le directeur de projet et le chef de projet sont remplacs, la moiti de lquipe demande changer dactivit. Jinterviens comme coach agile auprs de lquipe, qui comporte une vingtaine de personnes.

Visualiser le challenge
Lquipe doit se mettre en capacit de produire le prochain lot dans un dlai de trois mois, sans retard, en assurant une qualit acceptable du point de vue du client nal. Elle doit galement parvenir livrer des lots intermdiaires toutes les deux semaines pour rassurer le client. Ce challenge 4 se traduit tout dabord par lachage dun objectif de production pour la premire itration : Lquipe analyse les principales tapes de son ux de production 5 , puis reprsente son activit sous la forme dun tableau visuel. Lenjeu de litration en cours consiste sortir toutes les pices prsentes sur le tableau 6 .
3. Cf. Section Principes Lean du chapitre Leviers de lamlioration 4. Cf. Section Principes Lean du chapitre Attentes du Client 5. Cf. Section Principes Lean du chapitre Management visuel 6. Une amlioration possible consisterait clarier lobjectif de la journe, pour mettre en place un systme complet de ux tir. Cependant ce stade, linformation permet dj lquipe de commencer identier ses principaux problmes.

34

Figure 5.11 Objectif de production

Figure 5.12 Tableau reprsentant le ux 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 nal, est rendue responsable du blocage. Lquipe de ralisation lui reproche de laisser saccumuler les demandes dinformations, sans les traiter dans un temps acceptable. Les premires runions quotidiennes conrment que la majorit des dveloppeurs sont en attente de clarication sur des questions dordre fonctionnel. Ces demandes sont transmises par lintermdiaire dun outil lectronique, mais la plupart restent indniment sans rponse. Lquipe ralise que loutil ne lui permet pas dapprhender la situation. Pour y voir plus clair, elle dcide de rendre visibles ces obstacles sur son management 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 dinterprtation du processus. Chacun saisit la demande sa manire, puis, dlguant la responsabilit au systme, ne se proccupe plus du suivi du processus de rsolution. En particulier, les tickets sur lesquels le service destinataire est mal renseign, ne sont pas traits correctement. Ils demeurent en ltat dans le systme. Tout dabord, lquipe enrichit son management visuel 8 , en rendant visibles, pour chaque tche, les obstacles (questions bloquantes en cours) sous la forme de post-its rouges :

Figure 5.13 Achage des obstacles sur les tches Ensuite, lquipe met au point un standard de rdaction dune che de demande. Je passe voir chaque collaborateur pour le former la bonne faon de faire. De plus, lmetteur de la demande devient responsable des actions de suivi. Les obstacles sont matrialiss et suivis sur un tableau ddi :
7. Cf. Section Principes Lean du chapitre Leviers de lamlioration 8. Cf. Section Principes Lean du chapitre Management visuel

36

Figure 5.14 Standard de dnition dune demande

Figure 5.15 Tableau de suivi des obstacles

37

Les runions quotidiennes, qui taient auparavant centres sur les tches, font maintenant une large place au traitement des obstacles en cours. Chaque jour, un point est eectu sur les obstacles non levs. Les ches des obstacles non rsolus sont dplaces en fonction de leur niveau durgence (voir tableau de suivi des obstacles). Ds quun obstacle est lev, sa che est dplace vers un espace spcique o il demeure jusquau lendemain. Cela permet un autre quipier, dont une tche serait en attente de la mme demande, de savoir quil peut reprendre son traitement.

Figure 5.16 Panneau des obstacles rsolus Deux semaines aprs cette dcouverte, les questions en attente de rponse de la part de la cellule danalyse fonctionnelle ont toutes t traites. Lquipe peut vrier visuellement au quotidien que cette quipe nest pas source de blocage de leur processus, les tensions sont apaises, les relations uidies. Lquipe a appris grer les obstacles, ce qui lui a permis de retrouver sa capacit produire. Une bonne partie des tches en attente ont pu avancer dans les tapes suivantes du processus.

Quavons-nous fait Comprendre ensemble : Dnir le challenge : prochain lot dans trois mois sans retard et avec zro dfaut Traduire le besoin du client en indicateurs de performance Voir ensemble : Rendre visible les problmes qui mempchent davancer sur mes tches par lintermdiaire des bacs rouges 9 Rendre visible le ux de dveloppement
9. Cf. Section Principes Lean du chapitre Management visuel

38

 Agir ensemble : Comprendre les typologies de problmes, les rendre visible et sorganiser tous les jours pour les attaquer un par un Le rsultat Les obstacles ont t levs ce qui permis lquipe de sortir ses tches lheure. Ce que jai appris Lquipe communique et travaille plus ecacement avec les analystes fonctionnels.

Scne de crime : le burdown tait rouge

Contexte
Comme dans beaucoup dquipes agiles nous avons un burndown chart ditration :

Figure 5.17 Burndown chart ditration Nous rencontrons un problme 10 de tenue des dlais qui se matrialise sprint aprs sprint par un reste faire de 10 20% en n de sprint :

Recherche de cause
Peut-tre ne consacrons-nous pas le temps prvu initialement raliser nos sprints ? Certains membres de lquipe interviennent en eet sur plusieurs ac10. Cf. Section Principes Lean du chapitre Leviers de lamlioration

39

Figure 5.18 Evolution du reste faire au l des sprints tivits (management, runions transverses. . . ). En tant que Team Leader, je nchappe pas cet parpillement.

Enrichissement du management visuel

Pour clarier la situation, nous enrichissons notre management visuel en ajoutant un graphique des jours consomms, copie quasi-conforme de notre burndown chart ditration.

Figure 5.19 Burndown chart des jours consomms Notre hypothse se conrme : une partie de lquipe na pas consacr litration autant de jours quelle le pensait. Lquipe croyait disposer dune capacit de 100 jours avant litration, mais na pu en fournir rellement que 80. 40

Action : suivi des carts

Il faut maintenant agir. Je trace, sprint aprs sprint, la dirence entre les jours consomms et les jours planis.

Figure 5.20 Suivi de la dirence entre les jours consomms et les jours planis Sur les 24 derniers sprints, jobserve une forte variabilit. Je pense que les membres de lquipe nont aucun moyen de dtecter un cart en cours de sprint.

Consomm individuel
Jen discute avec lquipe et nous dcidons de tracer jour aprs jour le temps consomm de chaque personne. En dbut de sprint, nous imprimons un graphique qui montre pour chaque personne le nombre de jours quelle a annonc en sprint planning. Durant chaque daily scrum meeting, un dveloppeur remplit les lignes. Quand Romain dit je suis intervenu sur telle tche toute la journe, le dveloppeur surligne en uo une journe supplmentaire consomme sur la ligne de Romain. Ce suivi permet dalerter Romain : Attention, il ne reste que 2 jours et il te reste 1,5 jours consacrer au sprint.

Linformation ache est exploite

Chaque membre de lquipe est maintenant en mesure de suivre au jour le jour un ventuel cart de son implication dans le sprint. Par exemple, si une runion transverse imprvue mest propose, je choisis dy participer ou pas en connaissant pleinement son impact sur le sprint. Le reste faire en n ditration, qui tait totalement imprdictible et chaotique devient dune exceptionnelle stabilit. Plus exceptionnel encore, les jours-homme non consomms se stabilisent au mme moment, ce qui conrme lhypothse dune corrlation entre les deux phnomnes (voir les courbes du Suivi des carts en n ditration). Par contre, nous narrivons pas encore tenir 100% de nos engagements du sprint. En eet les tches de dveloppement saccumulent dans la case A valider , dernire tape de notre kanban et lquipe des spcications ne les valide pas toutes avant la n du sprint. 41

Figure 5.21 Suivi du nombre de jours consacr au sprint

Figure 5.22 Suivi des carts en n ditration

42

Suite de lhistoire
Les deux quipes se marirent et eurent beaucoup de stories nies en n de sprint. Les quipes de spcication et de dveloppement dcident de fusionner leur management visuel et leur daily meeting. Les dbuts sont diciles, mais partir du sprint 15.1, elles russissent samliorer drastiquement en se focalisant sur les stories valider plutt que sur de nouvelles spcications :

Figure 5.23 Evolution du reste faire la suite dune action damlioration

Quavons-nous fait Comprendre ensemble : Rajouter un indicateur de performance mesurant le temps consomm par lquipe pour pouvoir le confronter au burndown Voir ensemble : Mesurer les jours consomms pour faire apparatre un delta par rapport lestimation faite en dbut de sprint Un visuel permettant chacun de savoir, tout moment, combien de jours il lui reste pour terminer les tches sur lesquelles il sest engag Agir ensemble : Se poser la question est-ce quil me reste assez de temps pour tenir mes engagements du sprint Planier sa journe en fonction (ex : privilgier le dveloppement plutt que des tches moindre valeur ajoute telle quune runion) Le rsultat Nous livrons le mme volume de fonctionnalits ditration en itration (environ 90%), ce qui permet chaque membre de lquipe de mieux planier son prochain sprint. Nos indicateurs nous ont permis de valider ensemble la russite dune action collective. Ce que jai appris Laisser lquipe trouver delle-mme les solutions ses problmes paie. 43

Principes lean
Quest-ce que le management visuel lean apporte une quipe agile ?
Le management visuel est une pratique de base du lean qui poursuit deux buts complmentaires : Aligner lensemble des acteurs du projet sur un mme objectif : la satisfaction des clients. Partager les dicults et les pistes damlioration de manire objective an que chacun comprenne comment il peut contribuer lamlioration. Lapproche lean du management visuel permet de franchir un palier sur trois sujets : Identier de manire trs prcise o se situent les problmes que lquipe doit attaquer pour amliorer aussi bien le produit que ses conditions de travail. Ceci se retrouve dans lexemple Trouver lindic . Le management visuel renvoie lquipe plusieurs signaux qui permettent dagir sur les bons sujets : volume important des demandes de maintenance et retards de livraison des projets. Ceci encourage lquipe aller la rencontre de ses clients pour mieux comprendre les dicults rencontres. Collaborer avec les autres quipes de manire ecace. Dans lexemple Tous coupables , lquipe technique blme les analystes et inversement, et les choses navancent pas. Ils visualisent le problme ensemble, et en trs peu de temps, ils arrivent se mettre daccord sur une solution simple pour dbloquer la situation. Communiquer avec ses managers sur des faits clairs et ainsi mieux se faire entendre.

Les objectifs
Le management visuel fournit en temps rel linformation et le feedback objectif ncessaires la comprhension de lactivit de lquipe. Il lui donne les moyens de rpondre chaque instant la question : Sommes-nous en train de russir notre journe ? . Comme chaque outil lean, le management visuel est un outil dapprentissage. Il permet aux collaborateurs de devenir des experts dans leur mtier par la rsolution des problmes qui mergent. Il est bas sur trois axes :

44

Figure 5.24 Le triangle du management visuel lean

Comprendre ensemble
La construction et lutilisation du management visuel amnent lquipe dvelopper 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.

Le client Dans un premier temps, lquipe commence par identier clairement ses clients 11 . Ensuite, elle dnit leurs besoins et leurs critres de satisfaction : o est la valeur pour eux dans ce quelle leur dlivre ? Dans quelles conditions faut-il leur dlivrer (qualit, dlais, cots) ? Dans lexemple Trouvez lindic ! , les dveloppeurs sont alls la rencontre de leurs clients (service marketing et DSI de leur commanditaire). Ils ont ralis que leur contrat ne retait pas leurs relles attentes. Sils respectaient les 95% de disponibilit du site, pas de pnalit pour lquipe, mais une image dgrade du point de vue du client. Le challenge et la performance Lquipe dnit sa condition cible et la traduit sous la forme dindicateurs de performance. Ces derniers montrent la qualit de ce que lquipe produit, dans quels dlais et avec quelle productivit le tout du point de vue du rsultat nal, cest--dire du point de vue du client. Les indicateurs dnis doivent donc couvrir les sujets suivants : Qualit du service ou produit livr : lquipe a-t-elle russi livrer la bonne fonctionnalit du premier coup ?
11. Cf. Section Principes Lean du chapitre Attentes du Client

45

 Respect des dlais de livraison attendus par le client (et pas uniquement ceux ngocis avec lui) ou le stock (le volume des demandes client dans le backlog que lquipe na pas encore pu traiter). Charge lquipe de samliorer pour sapprocher de lattente client. Dans lexemple le burndown tait rouge , les dveloppeurs se battent pour respecter leur engagement de dlais sur le sprint (90% livr au lieu de 100%) et vont jusqu mesurer leur propre temps consomm pour y arriver. Productivit : indicateur cl pour suivre lamlioration de la capacit de lquipe. Satisfaction client :lquipe peut avoir limpression que tout va bien alors que le client nest pas entirement satisfait. Des indicateurs spciques aux objectifs du projet peuvent tre ajouts, notamment des indicateurs de succs du produit lui-mme : disponibilit, taux dutilisation, taux de rtention des utilisateurs, etc. Le processus Lquipe dnit clairement les activits valeur ajoute pour le client et les tapes par lesquelles elle doit passer pour livrer le service ou le produit requis. Lobjectif est de saligner et de rester focalis sur ce qui est important pour le client, tout en facilitant le travail de chaque collaborateur. Lquipe Chaque personne doit tre capable dexprimer clairement son rle et sa place dans lquipe. Ceci lui permet dinteragir avec les autres sans ambigut. Lquipe ache aussi une matrice de comptences de tous ses membres, ainsi quun programme de formation, lobjectif de dveloppement des comptences tant clair pour chacun.

Voir ensemble
Ds que lquipe est claire sur la direction prendre et quelle est prte mesurer sa performance au jour le jour, elle doit rendre visible ce quelle est en train de produire. Le but est de voir les direntes units de production (ex : des tches, des tickets, des fonctionnalits) avancer dans le processus. Pour cela, lquipe met en place un systme lui permettant de visualiser le ux de ses activits comprenant lobjectif du jour et la distribution des tches, ainsi que la performance. Lobjectif est dtre alert immdiatement en cas danomalie an de ragir rapidement. Flux dactivit Typiquement, les quipes agiles utilisent des taskboards pour organiser leurs sprints et visualiser le ux des tches. 46

Figure 5.25 Matrice des comptences de lquipe Le lean apporte un lment supplmentaire en invitant trouver des moyens de rendre visibles tous les obstacles que rencontre lquipe pour atteindre ses objectifs. Lexemple Tous coupables illustre ce principe : les dveloppeurs ajoutent des tiquettes rouges sur leurs tches lorsquil leur manque une information 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 introduire des bacs rouges - une manire visuelle de reprsenter les obstacles de qualit : Soit des problmes de qualit en entre (par exemple une user story insuisamment claire ou incohrente avec lapproche du produit, ou bien une user story qui est en soi une retouche parce quelle avait t mal cadre ou ralise lors dun prcdent sprint) Soit des problmes de qualit rencontrs au cours dune tche (par exemple un dveloppeur trouve un endroit du code qui recle des dfauts) Chaque problme de qualit est imprim ou crit sur une feuille, puis plac dans une bannette rouge proximit du taskboard : Les bacs rouges Rgulirement, lquipe se livre lanalyse du contenu de ses bacs rouges pour comprendre la cause de ces problmes de qualit et y trouver une solution. Au-del des problmes de qualit, dautres natures de problmes peuvent tre rendues visibles sur le management visuel, par exemple : 47

 des demandes client restes trop longtemps en attente, des problmes de surcharge de certains membres de lquipe par rapport dautres. Il ny a pas de rgle explicite prcisant quelles natures de problmes doivent tre rendus visibles, et comment. Chaque quipe fait voluer son management visuel au gr de ses besoins et de son niveau de maturit. Dans certains contextes spciques, il peut tre utile de mettre en place un visuel un peu dirent. Ci-dessous, deux possibilits : 1. Un visuel gros volumes , utilis dans des phases de projet qui comportent des tches rptitives par exemple une migration de donnes manuelles. Lquipe se donne des objectifs chirs et vrie plusieurs fois par jour si elle les atteint ou pas (exemple : cration et excution de tests fonctionnels).

Figure 5.26 tableau_de_suivi_de_production 2. Un visuel physique , lorsquil est ncessaire de voir ce qui est produit sur papier. Ce visuel peut tre utilis, par exemple, dans le cadre dun projet de conception de documentation technique.

48

Limage ci-dessous reprsente trois bannettes : 1. une bannette contenant des pages rdiges par Julie qui demande une relecture Germain ( traiter ), 2. une deuxime bannette contenant les pages pour lesquelles Julie attend des renseignements ou un feu-vert ( suspendu ) 3. une troisime bannette ( les bacs rouges ) contenant les pages qui comportent des problmes rsoudre immdiatement pour dbloquer Julie.

Le mur de la performance Lquipe construit ses indicateurs de performance pour savoir tout moment si elle rpond bien aux attentes de ses clients. Elle les met jour la main quotidiennement et y annote les pics et les valles pour expliquer les hausses et les baisses inattendues. Un bon indicateur montre la tendance dans le temps et une cible an de faire merger les carts de performance, ce qui forme la dnition dun problme

Figure 5.27 Le mur de la performance Les indicateurs de type burndown peuvent parfaitement tre utiliss. Ils deviennent un outil dapprentissage lorsquon y annote les causes des retards, et les expriences damlioration mises en uvre. 49

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

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

Suivi des problmes Lquipe note les problmes quelle rencontre sur une main courante, qui prsente plusieurs intrts : Partager les problmes rencontrs et se mettre daccord sur leur dnition Penser vrier le rsultat des actions mises en uvre

Agir ensemble
Le management visuel favorise lauto-organisation de lquipe an quelle puisse ragir rapidement aux problmes et adapter son fonctionnement pour faire de la rsolution de problmes. Il permet ainsi lquipe de prendre ses propres dcisions sur lobjectif oprationnel du jour, son organisation et les solutions mettre en place pour travailler plus sereinement. Dans lexemple Tous coupables , la runion dquipe quotidienne nest plus seulement une opportunit de parler de ses tches, mais ore loccasion de partager ses problmes. Lquipe se rorganise pour donner lquipe lopportunit de rsoudre les problmes bloquants sans perturber le bon droulement du sprint et surcharger les dveloppeurs. Lquipe rsout dirents types de problmes mis en vidence par son management visuel. Du plus simple, qui ncessite une action rapide de type just do it au plus complexe ncessitant une rexion plus profonde. Dans lexemple 50

Figure 5.29 Tableau de suivi des problmes le burndown tait rouge , lquipe ne se dcourage pas et continue de chercher la cause racine de son problme li au non-respect des dlais. Lquipe consigne les problmes au fur et mesure quils apparaissent sur le mur et les traite les uns aprs les autres. Suivant la nature du problme, lquipe peut se recongurer et aecter certains de ses membres spciquement son analyse et sa rsolution. La dmarche lean de rsolution de problmes est dtaille dans le prochain chapitre : Les leviers de lamlioration .

Premiers pas
Comprendre ensemble
Allez voir votre client, votre manager et votre quipe pour comprendre leurs critres de succs : Que cherchez vous russir ? Projetons-nous en n danne. A quoi verrez-vous que vous avez bien russi lanne ? Aprs avoir rencontr, interrog, observ vos clients, crivez sur papier la liste de ces critres. Ils dnissent votre challenge.

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

O est le client ? Le challenge est-il bien reprsent ? Prenez un des critres de succs de la liste que vous avez tablie. Comment est-elle traduite concrtement dans le management visuel ? Lobjectif est-il clair pour chacun ? Prenez chacun des indicateurs au mur. Chacun sait-il ce quil doit faire pour contribuer latteinte de lobjectif ? Les pices produire sont-elles visibles ?

Agir ensemble
Tous les jours, posez-vous ces questions : En ce moment, en sappuyant uniquement sur ce que montre le management visuel, lquipe est-elle en train de russir sa journe ? Les obstacles sont-ils visibles ? Les problmes que lquipe est en train de rsoudre sont-ils visibles ? Lamlioration est-elle visible ? Quelle est la dernire chose que vous avez apprise grce votre management visuel ?

Aller plus loin

The Visual Factory
Michel GREIF Edition Productivity Press Version franaise disponible en ebook Aller lessentiel : Chapitre 5 The Visual Production Control pour des exemples de management visuel Chapitre 6 Process Indicators pour comprendre les indicateurs de performance ( ne pas confondre avec des indicateurs dactivit)

Creating a Lean Culture

David MANN Edition CRC Press Shingo Prize : la plus haute distinction des livres lean Aller lessentiel : Chapitre 4 Visual Controls pour retrouver des exemples de management visuel

52

53

Chapitre 6

De Lamlioration continue Trouver les leviers de lamlioration

Les pratiques agiles
Au plus profond de la culture agile
Des principes favorisant lidentication des actions damlioration sont intgrs au plus profond de la culture agile. Par exemple : Le dveloppement itratif : Rpter les mmes activits permet damliorer sa pratique. La livraison frquente : En sassurant que les fonctionnalits dveloppes sont remises rapidement entre les mains du client, lagilit cre les conditions pour quune conversation ait lieu avec lui. Sil nest pas satisfait, lquipe cherche un moyen damliorer la situation. Les temps rtrospectifs : En rservant du temps pour rchir, lquipe cre lespace ncessaire pour le choix dactions damliorations.

Les domaines privilgis damlioration

Au l des annes, la communaut agile sest constitue un riche catalogue de pratiques favorisant lamlioration. Le mouvement agile a t initi par des dveloppeurs qui voulaient rompre avec des mthodes de projet contraignantes, des environnements de collaboration peu propices lpanouissement, et des pratiques dingnierie inecientes. Cest la raison pour laquelle on peut trouver des pratiques agiles dans ces dirents domaines. En voici quelques exemples signicatifs. 54

Lorganisation du travail Comme le mcanicien qui sait reprer les anomalies dans le bruit rptitif du moteur, lquipe identie les eets des changements introduits par leurs dcisions dune itration lautre. Elle sait reconnaitre des motifs rcurrents, sait ragir et grer le stress par le rythme du travail. Cette ide est reproduite de manire fractale jusquaux gestes du dveloppement : la construction dun programme est aussi une rsolution successive de micro-problmes.

Figure 6.1 XP feedback loops

Les trucs de geeks Le refactoring, les tests automatiques sont des leviers techniques damlioration du produit logiciel. Le dveloppement pilot par les tests est un bon moyen de construire un design mergeant, garant de lvolutivit du code. Cela a pour eet de crer des degrs de libert (fonctionnelles, techniques) et assure la facult de lquipe de dlivrer des volutions un rythme constant. Le refactoring est aussi une manire pour lquipe de polir son code, de se lapproprier, le rendre plus habitable (Cf Software Craftmanship). Le binmage constitue galement un levier damlioration. Par exemple, en associant un dveloppeur dune grande exprience mtier avec un dveloppeur nouveau dans lquipe : le dveloppeur nouveau avec son il neuf peut apporter de la hauteur dans les solutions conues, ainsi que son expertise technique. Lexpert mtier peut apporter au novice ses explications des concepts et techniques du projet. 55

La communication interpersonnelle La qualit de la communication reprsente un axe majeur damlioration. Pour exploiter les bnces de la communication orale, il est conseill de regrouper les postes de dveloppement dans le mme bureau. Quand la situation lexige, lquipe peut galement augmenter la bande passante auprs de son client, par exemple en linvitant plus frquemment des runions de travail. La construction dquipe apparat galement comme un domaine daction privilgi. Les coaches agiles puisent dans plusieurs domaines des sciences humaines et du coaching dquipe (Virginia Satir, Ecole de Palo Alto, Core protocols, psychologie sociale) an de guider les quipes dans lamlioration de leur ecacit.

Trouver des leviers sur mesure

Le travail en quipe auto-organise constitue un des principes fondamentaux de la culture agile (The best architectures, requirements, and designs emerge from self-organizing teams ). Aussi, la source privilgie de leviers damlioration rside dans lquipe mme. La rtrospective, quelle ait pour objet une itration ou un projet entier, est le moment privilgi pour analyser la situation et choisir un levier damlioration. Chaque levier consiste introduire ou ajuster une pratique issue du catalogue cit prcdemment, ou une action concocte sur mesure.

La diversit des points de vue de chaque individu est le gage du potentiel damlioration de lquipe. Celle-ci doit seorcer dexploiter au mieux cette 56

richesse en partageant les informations pertinentes dont chacun peut disposer individuellement. Une fois ces informations partages, nombre de techniques facilitent lidentication des problmes rsoudre et la mise au point dactions de rsolution, mais toujours en sappuyant sur le collectif. Quelle quen soit la source dinspiration et la mthode daccouchement, une bonne action damlioration runit les caractristiques suivantes : elle est prometteuse : Le bnce attendu important. Ce bnce est valu selon les critres propres aux participants. la porte des participants : Ceux-ci sont en mesure de la mettre en uvre avec les moyens leur disposition ; ceci exclut les actions trop coteuse ou en dehors du champ daction. elle remporte ladhsion : Cest laction qui fait consensus parmi les participants qui est choisie. Les sections suivantes illustrent les retours dexprience de praticiens agiles qui ont essay des pratiques lean sur leurs projets pour aller plus loin dans lamlioration.

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

Lodeur du napalm au petit matin
Un oprateur majeur propose un service grand public de tlvision et vido la demande. Il sert 40 millions daccs par mois grce 250 000 lignes de code Java, une plateforme Linux/Apache/Tomcat/Mysql et un bus de donnes erlang RabbitMQ. Ce service est dvelopp par mon quipe de 8 dveloppeurs et exploit par 3 ingnieurs systme. Cette quipe de dveloppement pratique scrum et XP depuis 4 ans. Un matin, je retrouve lquipe systme avec des cernes, en intervention depuis 5 h du matin. Le service web grand public est techniquement oprationnel, mais inaccessible. Malgr un rollback eectu sans problme, le monitoring du bus de donnes et des consommateurs des messages de statistiques est toujours rouge, signalant un incident. Cest pourquoi lquipe systme nose pas rouvrir le service au public. Je vais voir lingnieur systme pour laider rtablir le service au plus tt. Nous essayons de relancer les consommateurs, sans succs. Je tente de lancer un consommateur la main sans passer par le script dexploitation. Je dcouvre une erreur (NullPointerException ). Elle indique que lexcutable na pas trouv son chier de conguration. Le lien symbolique vers le rpertoire des chiers spciques lenvironnement de production nexiste pas. Lingnieur systme le recre immdiatement la main. Il redmarre les consommateurs et une minute plus tard le monitoring repasse au vert. Le service est r-ouvert et le trac reprend.

57

Figure 6.2 Dpassement du seuil prconis de la le

Une situation client dramatique

O en sommes-nous ? La version cible nest toujours pas en production. Le ple exploitation client est pass en incident majeur (plus de 2h dinterruption de service + retour arrire). Il veut passer en niveau de vigilance maximale sur la prochaine mise en production. Cest dire au minimum avec 19 jours de pravis, avec prsentation des changements, solutions de retour-arrire. De son ct, le ple marketing-fonctionnel veut publier dans deux semaines une volution dune importance ingale depuis 7 ans. Pour assurer cette grosse volution, il faut eectuer 4 mises en production. En comptant 19 jours de pravis pour chacune, il faudrait 3 mois au lieu des 2 semaines voulues par le marketing.

Les 5 pourquoi
Une fois le service rtabli, je pars mener une enqute minutieuse, dans lesprit des 5 pourquoi du lean 1 pour viter la rapparition de lincident. Pourquoi le lien symbolique na-t-il pas t cr ? Le script shell dinstallation maintenu par lquipe systme na pas cr ce lien symbolique. Pourquoi ? Ce script est compos de deux instructions : une vrication de monitoring et la cration du lien symbolique. Linstruction de vrication choue et interrompt toute lexcution. Pourquoi ? Cette instruction se rfre un chemin inexistant.
1. Les 5 pourquoi du lean : Cf. la section Principes Lean du chapitre Leviers de lamlioration

58

Pourquoi ? Ce script a t mal modi lors dune mise jour du systme de monitoring. Une cause profonde 2 a t identie : une maladresse lors dun changement technique. Lchec des procdures qualit Pourtant, dans mon entreprise, il existe un standard pour se prmunir de ce genre de maladresse, savoir la rptition systmatique en environnement de pr-production. Pourquoi la rptition en pr-production na-t-elle pas rvl ce dysfonctionnement ? Les scripts shell dinstallation qui sy trouvent sont dirents de ceux en production : ils nont pas t modis. Une autre cause profonde a t identie : un cart entre les environnements. Comment fatiguer son ingnieur systme ? Une autre question subsiste : pourquoi un ingnieur systme, pourtant talentueux, a-t-il d attendre larrive dun dveloppeur pour recrer un lien symbolique ? Rponse : lors de lincident, aucune trace napparaissait, ni dans les logs systme, ni dans la console. Pourquoi ? Les logs de lapplication partaient vers la sortie standard ( cause du lien symbolique manquant) et le script dexploitation ignorait la sortie standard.

Figure 6.3 Perte de la sortie standard

Prvenir plutt que gurir

Larbre de causalit 3 indique trois causes racines, en dehors de notre champ daction. Nous modions notre code pour quil adresse lingnieur systme un message explicite en cas de dysfonctionnement. En terme lean, nous ajoutons un andon 4 .
2. Cause profonde en lean : Cf. la section Principes Lean du chapitre Leviers de lamlioration 3. larbre de cause : lenchanement cause et consquence est reprsent sous forme arborescente. Cf : la section Principes Lean du chapitre Leviers de lamlioration 4. Le andon dsigne une alerte lumineuse pour signaler tout dysfonctionnement au plus tt et saccompagne dun arrt immdiat. Dans le cas des machines et des outils, lal-

59

Figure 6.4 arbre causal dun incident de production

Figure 6.5 Introduction dun andon dans le script

60

Comme nous avons la main sur le script dexploitation, nous le modions pour rediriger la sortie standard, jusque-l ignore, vers les logs systmes. Nous ajoutons galement la capture de lexception NullPointerException de manire informer lexploitant du problme sur la sortie standard. Pour ne rien laisser au hasard, nous testons ce message auprs de lingnieur systme pour sassurer de sa comprhensibilit. Prochaines investigations mener : comprendre do vient la dirence entre la pr-production et la production ; comprendre pourquoi lingnieur systme a produit un script dfectueux. Je suis content davoir compris ce qui stait vraiment pass et davoir trouv une contre-mesure conome qui empchera le mme dsastre de se reproduire. Jai la satisfaction davoir pos la premire pierre du long chemin vers le rtablissement de la conance avec notre client.

Quavons-nous fait Protger immdiatement le client, avant dentamer le cycle Plan-Do-CheckAct ; Trouver les causes racines, avec le 5-pourquoi ; Ajouter un andon dans la chane de dploiement applicative pour que lincident ne se reproduise pas. Le rsultat Notre application est devenue plus exploitable. Elle met un peu plus notre quipe systme en situation de russir. Nous avons identi des sources de variabilit prcises, qui vont permettre une investigation plus pousse. Ce que jai appris Je croyais tre impuissant face un incident qui relevait compltement dune autre quipe, alors quen fait, jai pu apporter une contribution qui, elle seule, vitera de nouveaux incidents. En tant que dveloppeur, jai appris quil faut que janticipe aussi le cas o le systme de log narrive pas sinitialiser.

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

61

Scne de crime : du ri dans mes sprints

Chaque anne, mon quipe agile doit assurer la maintenance dun site web marchand en plus de son activit de dveloppement. Cette activit ponctuelle perturbe les sprints en cours. 5 Lquipe met tout dabord en place un management visuel pour : comprendre la situation : les besoins du client et ce quoi elle doit faire attention lors de la maintenance ; voir la nature des dysfonctionnements ; tre capable de ragir en fonction de la criticit des problmes.

Figure 6.6 Suivi des problmes

Du management visuel au Plan-Do-Check-Act (PDCA)

Mme si la situation semble samliorer, des problmes dj corrigs reviennent danne en anne (espace disque insusant, abilit des statistiques, magasins qui ne prsentent pas lore. . . ). Lquipe apprend ragir rapidement aux bons problmes en protgeant le client par des actions immdiates. Malheureusement, celles-ci ne sont pas prennes. Comment sy prendre pour que la situation samliore et que les problmes identis soient corrigs dnitivement ?
5. Cette situation est galement dcrite dans la section Trouvez lindic ! du chapitre Management Visuel

62

Je dcide de mettre en uvre la technique du Plan-Do-Check-Act (PDCA). Sur le management visuel, chaque problme gure sous forme dun post-it. Un membre de lquipe est charg danalyser le problme en profondeur en utilisant la technique des 5 pourquoi 6 . Cette technique simple permet de trouver la cause racine du problme. Ensuite, lquipier propose une contre-mesure pour supprimer cette cause. Il dtermine galement un indicateur appropri la vrication de lecacit de la contre-mesure. Suivant le rsultat de la vrication, les procdures sont adaptes pour intgrer la nouvelle pratique.

Le service de prise de commande ne rpond pas dans les temps.

Le service de prise de commande rpond en 8 secondes au lieu de 2 secondes. Le systme de monitoring remonte une alerte sur la console de supervision. Une premire investigation identie la cause principale : un des serveurs ddis la prise de commande na plus susamment despace disque. Lquipe recherche sur le disque la partition incrimine. Elle dcouvre que le rpertoire /tmp est plein. Action immdiate : Un dveloppeur vide le rpertoire et tout revient dans lordre. Action dnitive : Nous cherchons resoudre le problme en suivant les tapes du PDCA : Plan Impact du problme sur le client nal : le temps de la prise de commande est rallong de 6 secondes. il y a un risque que le problme se produise aussi sur les autres machines, empchant compltement la prise de commande. Lquipe applique la technique des 5 pourquoi : Le serveur ne rpond pas. Pourquoi ? le rpertoire /tmp est plein. Pourquoi ? les log binaires prennent toute la place. Ce nest pas normal que les logs binaires soient prsents sur cette machine. Pourquoi ? la conguration du serveur nest pas correcte Pourquoi ? la procdure dinstallation ne prcise pas quil ne faut pas activer les logs binaires sur les serveurs en question
6. Les 5 pourquoi du lean : Cf. la section Principes Lean du chapitre Leviers de lamlioration

63

Do Action 1 : supprimer tous les logs binaires de tous les serveurs ddis la prise de commande. Lanalyse de la cause racine a permis didentier une seconde action qui devrait permettre dviter la rapparition du problme. Action 2 : dsactiver les logs binaires sur tous les serveurs ddis la prise de commande. Check Il ny a plus de log binaires dans le rpertoire /tmp et lespace disque demeure susant pour que lapplication fonctionne correctement. Act / Adjust Aprs vrication du rsultat des actions, la procdure dinstallation des serveurs de prise de commande est mise jour.

Rsultats
La pratique du PLAN-DO-CHECK-ACT est applique de manire systmatique tous les problmes rencontrs. Elle a permis damliorer les performances danne en anne. Le nombre de rclamations client a diminu de 37% en deux ans pendant que le trac augmentait de 40% et que le nombre de fonctionnalits augmentait dune dizaine chaque anne. La diminution du nombre de problmes a permis de limiter limpact de la maintenance sur la vlocit de lquipe de dveloppement tout en garantissant la satisfaction de notre client. Au-del des bnces pour ce projet prcis, jobserve que lenchanement des cycles Plan-Do-Check-Act fait monter en comptence mon quipe et que les autres projets se passent mieux.

Quavons-nous fait Protger immdiatement le client, avant dentamer le cycle Plan-Do-CheckAct ; Trouver les causes racines, avec le 5-pourquoi ; Eectuer une action corrective la racine ; Prenniser une action damlioration en modiant un standard. Le rsultat Nous avons diminu signicativement le volume dincidents. 64

Nous avons un standard corrig qui nous protge de la rcurrence. Ce que jai appris Mon quipe a acquis des comptences en administration systme. Jai dsormais une exprience personnelle de lalignement de lentreprise sur la satisfaction client par le dveloppement des comptences.

Scne de crime : joue-la courte et prcise

Notre client est mcontent car lquipe de dveloppement dont je fais partie met deux fois plus de temps quil ne souhaite sur les gros projets.

Figure 6.7 Dpassements de dlais sur nos trois derniers grands projets

Premire hypothse
Pour comprendre o gagner du temps, le Scrum Master propose de visualiser le problme. Il met une feuille au mur, puis chaque dveloppeur qui constate un frein ou un blocage le mentionne sur cet emplacement avec une estimation du temps perdu. Avec beaucoup de discipline, tous les dveloppeurs jouent le jeu. Au moment o nous compilons les donnes, nous tombons de haut : nous tions convaincus de trouver un gisement damlioration, mais la mesure rvle moins de 2h perdues par semaine. Ce nest presque rien compar aux 60 jours hommes de chaque sprint. Je ralise que ce nest pas surprenant. Les gens sont sensibles ce qui sort de lordinaire, mais ne remarquent pas les freins dont ils ont lhabitude.

Deuxime hypothse
Mon Scrum Master a une nouvelle intuition : lquipe passe trop de temps faire du refactoring. Je trouve pour ma part que lcriture des tests dacceptance automatiss est chronophage. Qui a raison ? 65

Cela mrite une deuxime exprimentation. Pour claircir ce mystre, pendant plusieurs sprints, je note chaque daily scrum meeting, sur quoi nous travaillons :

Figure 6.8 Activits et freins en dveloppement

Figure 6.9 Rpartition des activits de dveloppement Astuce : prparer un modle vierge pour assurer une meilleure pertinence des observations rcoltes Constats : les tests dacceptance automatiss ne reprsentent que 5,5% de notre temps de travail et le refactoring peine 2%. Lhypothse du Scrum Master et la mienne taient donc toutes les deux fausses. Llment qui prend le plus de temps est la programmation, avec 40%. Le contraire aurait t tonnant dans une quipe de dveloppement. Mais cela ne fait que dplacer le problme : o passe notre temps quand nous programmons ?

Troisime exprimentation
Je lance une troisime exprimentation : linvestigation pendant le pairprogramming. 66

Figure 6.10 Statistiques de rpartition des activits de dveloppement Pendant 20 demi-journes, le copilote note le temps pass la minute prs.

Figure 6.11 Liste des frottements de lactivit de dveloppement Avant de faire cette exprimentation, nous pensions passer beaucoup de temps dans la rdaction des tests unitaires. Dailleurs, des confrres agilistes nous disent souvent quils passent entre un tiers et la moiti du temps crire des tests. Or, nous constatons que nous y passons moins de 20% : Nous imaginions galement perdre beaucoup de temps comprendre et clarier des spcications, mais cela ne reprsente nalement que 4%. Champagne ! Nous avons vit de continuer consacrer des mois et des mois damlioration continue quatre faux problmes, mais ce nest pas tout. Jai vu que notre gaspillage le plus consquent est de comprendre lexistant. Dsormais, quand jignore o intervenir pour raliser ma tche, je demande systmatiquement par quelle classe rentrer dans le code existant et cela me permet daller deux fois plus vite.

67

Figure 6.12 Synthse de la rpatition des activits de dveloppement

Quavons-nous fait Convertir une plainte client en un cart quanti. Formuler des hypothses. Prparer des formulaires de collecte de donnes. Tester nos hypothses avec des mesures.

Le rsultat Jai obtenu des donnes factuelles sur o passe le temps de lquipe. Mon quipe a conomis une nergie colossale en vitant dinvestir sur des fausses pistes. Ce que jai appris Jai appris un geste qui acclre ma vitesse de dveloppement. Jai appris une mthode pour identier un potentiel dacclration.

Principes lean
Aux origines
Le pre du lean est convaincu que chacun est rempli dimpressions, de prjugs, dopinions, qui sont autant dides fausses. Ces ides fausses conduisent des pertes de temps normes, mais aussi des conits puisque chaque problme rencontr est loccasion de mettre en opposition les prjugs de chacun. Il utilise une mthode dapprentissage venue des Etats-Unis pour liminer ces ides fausses une sorte de TDD (Test-Driven Development ) pour lutter contre les bugs qui limitent nos raisonnements : le Plan-Do-Check-Act ou PDCA. Le cycle PDCA 68

Figure 6.13 Plan Do Check Act

69

Comme le systme mental de chacun est dirent, lapprentissage ne peut tre quindividuel. Un cycle Plan-Do-Check-Act est donc port par une personne et une seule. Le collectif est quand mme prsent, mais dune manire dirente de lagilit : le porteur va voir une par une les personnes impliques sur leur terrain pour mieux comprendre ce qui se passe. Il prsente ses raisonnements pour obtenir des feedbacks. Dans lexemple La mise en production qui ne devait pas chouer , cest un seul dveloppeur qui claircit le problme en allant voir les gens. Lexercice est donc individuel mais pas solitaire. Plutt que de senliser dans un dbat strile qui nait dopinions comme Jean est un trs bon ingnieur systme, il naurait pas modi ce script sans le tester ou de gnralits comme le client nest jamais clair dans sa tte , le praticien du lean est avide de faits : Combien de fois le client na-t-il pas t clair ? Allons voir lingnieur systme pour savoir ce qui sest eectivement pass.

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

Le lean fournit donc une mthode pour aronter des problmes complexes comme : Ceux qui reviennent nous hanter et que nous narrivons pas vraiment rsoudre dnitivement. Dans lexemple Du ri dans mes sprints , les dveloppeurs dpassent la correction rustine et font disparatre toute une classe de problmes avant mme quils ne surviennent. Des problmes qui sortent de la zone de contrle de lquipe. Dans lexemple La mise en production qui ne devait pas chouer , le dveloppeur trouve la force de traverser les barrires entre production et dveloppement pour creuser jusquau coeur de lincident. Le problme est prsent au manager dune manire tellement factuelle quaucune trace de rancur ny subsiste. Un dveloppeur peut remettre en cause une pratique de dveloppement contreproductive sans heurter ses coquipiers. Toute lquipe a le cur net sur ce qui se passe vraiment sur le terrain comme dans La mise en production qui ne devait pas chouer o elle se rend compte que les modications des scripts de monitoring ne sont pas testes. Enn, le Plan-Do-Check-Act vite dinvestir sur des fausses pistes.

Comment faire en pratique ?

A chaque pas dun Plan-Do-Check-Act, la mthode prconise que le porteur prsente ce quil a compris un expert du sujet et des acteurs du problme, pour dtecter dventuelles ides fausses.

70

Plan Dnir le problme Dans lexemple Joue-la courte et prcise , le client se plaint dune drive des dlais. Le membre de lquipe pense quil surestime cette drive. Le lean transforme cette armation en un problme en le visualisant sous la forme dun cart quanti entre une attente et un constat. Le porteur se rend compte que les dlais sont gnralement deux fois plus longs que le client ne le souhaiterait dans le cas des grosses piques 7 :

Figure 6.14 Dpassement des dlais

Qualier limpact Comment juger si le problme mrite lnergie que le porteur va lui consacrer ? Un bon problme aura un impact signicatif pour le client ou lentreprise (nancirement ou en terme de stratgie). Comprendre la situation Pour contrer les croyances errones, le porteur observe, compte, examine des instances du problme. Cette pratique sappelle le Go&See ou aller sur le gemba 8 . Elle rpond aux questions A quelle tape, quel endroit, le problme survient-il ? et Quel est le potentiel damlioration ? .

Pour aider voir le potentiel damlioration, le lean met disposition des outils, qui sont autant de grilles de lecture pour auter le regard. Le plus connu de ces outils conceptuels est la notion des 7 gaspillages 9 , cest--dire 7 faons direntes de gaspiller le temps prcieux dune personne. Le tableau ci-dessous donne quelques exemples de ces familles dans le contexte du projet de dveloppement agile.
7. Une pique est un ensemble fonctionnel cohrent de User Stories. 8. Le chapitre De Satisfaire le client Comprendre son attente prsente aussi cette pratique, mais restreint au primtre du client. 9. Le chapitre De Satisfaire le client Comprendre son attente introduit la notion de gaspillage par opposition la cration de valeur. La notion prsente ici est plus restreinte, en lappliquant spciquement au temps de ceux qui crent de la valeur.

71

| Type de gaspillage | Exemples | |- |Surproduction | Ecrire du code qui nest jamais utilis. Raliser une User Story plus tt que ncessaire. | Corrections & retouches | Investigation et correction dun dfaut. Refactoring exactement inverse celui fait par un autre binme. | Attente | Attente de la disponibilit de lenvironnement de test. Attente du rsultat du build. Lenteur du poste de travail. Attente dune information ou dune dcision dordre fonctionnel lors de la ralisation dune tche. | Stock | Maintenance dun backlog de User Stories non dveloppes. Revoir rgulirement les post-it sur un poster Ides damlioration sans jamais mettre ces ides en uvre. | Gestes inutiles | Navigation dans le code. Redmarrage de lenvironnement de dveloppement (IDE). | Etapes inutiles | Deux binmes qui ralisent des tches qui se chevauchent. | Raliser une tche inutile. | Transport | Reporter des modications entre diffrentes branches au sein dun systme de gestion de conguration. Transmettre des informations dun dveloppeur lautre. Trouver les causes racines Le porteur va jusqu la cause racine. Dans lexemple Du ri dans mes sprints , poser plusieurs fois la question pourquoi amne dcouvrir une erreur dans la procdure dinstallation de tous les serveurs. Dans le folklore lean, cette pratique est dsigne par le terme 5 pourquoi . La consigne littrale est de se poser cinq fois dale la question pourquoi . Cependant, le chire 5 est une invitation creuser plus que dhabitude, et non pas une rgle. Il faut aussi se mer de rponses qui scarteraient des faits pour tendre vers des accusations. Les enchanements cause-consquence peuvent tre reprsents sous forme darbre.

Figure 6.15 Arbre de causalit Des hypothses sont ainsi formules et testes. Dans lexemple Joue-la courte 72

et prcise , la croyance une quipe extreme programming passe la moiti de son temps crire des tests est invalide. Formuler puis choisir des contre-mesures Une fois les causes bien comprises, le porteur fait un exercice de pense divergente : il imagine un maximum de contre-mesures pour adresser les direntes causes. Le lean privilgie les contre-mesures ingnieuses, conomes et dont leet peut tre vri rapidement. Lexemple La mise en production qui ne devait pas chouer illustre cet tat desprit de lamlioration continue. Le dveloppeur aurait pu dire cest inadmissible ce que fait lquipe systme, eux de samliorer en ralignant pr-production et production, en testant les scripts dinstallation . Pourtant, il choisit cote que cote dapporter une petite contribution. Il russit ainsi sa journe double titre : en rtablissant le systme le matin et en amliorant le feedback de lapplication le soir. Formuler la mthode de Check Le porteur explique comment il va vrier factuellement si sa contre-mesure fonctionne. Do La phase Do correspond la mise en uvre de la contre-mesure choisie. Check Le Check est la vrication factuelle de limpact de la contre-mesure, comme prvu durant le Plan. Un Check peut tre soit OK, si les objectifs viss sont atteints. Sinon il est NOK. Dans lexemple Du ri dans mes sprints , lquipe mesure une diminution de 37% des incidents. Son Check est OK. Act Durant la phase Act, le porteur prennise les enseignements quil tire de ses exprimentations. Dans lexemple prcdent, lquipe corrige la procdure dinstallation 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. 73

Choisir un sujet
Choisissez un sujet qui est important pour vous. Posez-vous la question de la dernire dicult majeure que vous avez rencontre ou du problme qui revient le plus souvent.

Formuler le problme
Formulez-le sous forme dcart entre : ce que vous constatez ce que vous voudriez la place.

Identier limpact
Rpondez la question : Pourquoi est-ce important ? Vriez quil y a un impact signicatif pour le client ou pour lentreprise. (cf. chapitre De Satisfaire le client Comprendre le client ).

Dnir lcart au standard

Quand ce problme se manifeste, quobservez-vous ?

Chercher les causes racines

Quest-ce qui provoque ce problme ? numrez toutes les hypothses qui vous semblent plausibles. Limportant est de trouver des hypothses testables.

Vrier les hypothses

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

Dnir le rsultat attendu

Avant dentreprendre les actions correctives, dnissez o, quand et comment vous pourrez vrier quelles auront port leurs fruits.

Aller plus loin

Toyota Kata
Mike Rother Edition McGraw-Hill 74

Figure 6.16 Toyota Kata

Managing to learn
John Shook Edition Lean Enterprise Institute, Inc.

Figure 6.17 Managing to learn

Understanding A3 thinking
Durward K. Sobek II., Art Smalley Edition Productivity Press

75

Figure 6.18 Understanding A3 thinking

76

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

77

Chapitre 8

Livres de rfrence
Le management lean
Michael Ball, Godefroy Beauvallet Edition Pearson

La pratique du lean management dans lIT

Marie-Pia Ignace, Christian Ignace, Rgis Medina et Antoine Contal Edition Pearson

78

Figure 8.1 livre la pratique du lean IT

79

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/

80