User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

Note de lecture : La pratique du Lean Management dans l’IT, par Marie-Pia & Christian Ignace, Régis Medina & Antoine Contal

Note : 8 ; Comprendre l’application du Lean à l’informatique. Vraiment.

Il ne faut pas se leurrer : comprendre le Lean, c’est difficile. On nous parle de la maison Toyota, d’un certain nombre de pratiques, le tout cimenté avec des mots Japonais … Très bien. Mais ça reste très flou. Et comme de plus, le Lean passe pour être un peu l’aristocratie de l’agilité, ça ne fait pas très bien de dire qu’on a pas pigé ! Ce que l’on appelle parfois le « Lean Software Development » n’aide pas non plus tant que ça. Difficile de comprendre en quoi cela est différent de nos pratiques actuelles.

Il y a peu de textes qui m’ont permis de prendre conscience de la nature du Lean. En fait, il n’y en a que deux. Le premier est le « système Lean » de Womack et Jones, mais il portait sur l’application du Lean à la production. Le second est celui-ci !

On dit que l’on apprends mieux quand on nous raconte des histoires. C’est ce que font les auteurs ici. Au long des 11 chapitres complétant les 240 pages de cet ouvrages, ils nous enseignent par l’exemple les pratiques Lean au service de l’IT.

En Lean, tout part de la valeur et c’est ce que les auteurs abordent au premier chapitre. S’il ne s’appuie pas sur des exemple il expose efficacement les deux facettes de la valeur (on oublie souvent que pour le Lean il y en a deux) et les sources de gaspillage.

Le chapitre 2 « un idéal de fonctionnement » poursuit sur cette description du Lean qui reste ici encore un peu théorique en décrivant la « maison Toyota ». Un grand classique, serait-on tenté de dire, mais présenté avec une grande clarté. Même si je vois le sujet abordé pour la 3 ou 4ème fois, j’ai eu l’impression de voir la lumière s’allumer…

Le chapitre 3 « la pratique du Lean » est à lire et à relire, tel un kata que l’on répète afin de s’imprégner du message sans qu’il ne soit plus besoin d’y réfléchir. On n’y évoque pas seulement les différentes pratiques, mais aussi de la façon dont elles s’articulent, par où on commence… Une vingtaine de pages de pur enseignement.

Notre premier cas pratique arrive au chapitre 4, avec la gestion d’incidents. On y part d’une situation à laquelle on applique une démarche Lean. On expose celle-ci, notre plan d’action. Puis on déroule celui-ci avec ses découvertes ses progrès etc.… Le tout abondamment illustré est parfaitement limpide.

L’amélioration venant de la répétition, nous abordons un nouveau cas client au chapitre 5, une équipe support plus précisément. Si le chapitre 4 avait mis en pratique certains concepts comme le lead time ou le bac rouge, le chapitre 5 permet de voir plus précisément le PDCA.

De la réparation de la valeur, on passe à la création de valeur au chapitre 6 qui aborde la question du projet. D’autres outils sont illustrés ici comme l’Obeya room, la voix du client ou encore la résolution de problèmes (bien que le A3 soit mis de côté) ou encore le takt time. On le voit, un chapitre bien rempli !

C’est à la mise en flux que se consacre le chapitre 7. Parmi les thèmes qui y sont abordés, on trouve la restauration de la confiance avec le client et le management visuel.

Le chapitre 8 est entièrement consacré à l’un des piliers du Lean : le Kaisen, c’est à dire l’amélioration continue. C’est dans le cadre de l’amélioration de l’expérience utilisateur que le sujet est abordé. On y croise chemin faisant le modèle des 5 attentes client du Lean. Aspect déjà largement abordé dans les autres chapitres, le « go & see », prends une large part ici. Les concepts de « get out of the building » et d’expérimentation nous sont plus familiers dans la littérature Lean Startup mais ils figurent aussi au programme.

Il aurait été difficile de traiter pour cet ouvrage d’éluder le sujet de l’agilité. D’autant qu’Antoine et Régis sont parmi les plus anciens praticiens de l’agilité de l’hexagone car ils ont débuté avec XP dans les années 90 ! Lean y est présenté comme une approche permettant de doper la mise en œuvre de l’agilité avec XP et Scrum.

Le chapitre 10 est une occasion de reprendre de la hauteur. On y passe en revue les pratiques essentielles du Lean et ce qu’elles apportent.

Déployer le Lean ne se fait pas d’un coup de baguette magique. C’est au contraire un chemin difficile. Les auteurs évoquent leur expérience de la chose et les différents biais par lesquels cela peut être fait.

La pratique du Lean Management dans l’IT est un texte qui se lit très bien. Ne soyez pas surpris de le boucler dans la semaine. La plupart des chapitres racontent une histoire, une introduction du Lean dans un contexte particulier avec les actions menées par les coaches. Mais lecture aisée ne signifie pas texte creux ou chemin facile. De nombreuses pratiques sont mises en œuvre, beaucoup de concepts sont expliqués et nécessitent de revenir sur le contenu.

J’ai coutume d’aller écouter Régis et Antoine quand j’en ai l’occasion. Les sujets qu’ils présentent sont riches et intéressants. Mais comme disent les jeunes : on prends cher ! Les coaches Lean qui ont écrit cet ouvrage ont un très haut niveau de maturité, ils nous montrent le chemin et nous laissent comprendre que nous avons encore beaucoup à progresser en plaçant la barre très haut. Cela aussi nous vient du Lean. Et cela peut nous aider à progresser mais aussi nous décourager. C’est probablement le prix à payer.

La discrétion avec laquelle ce livre est sorti ne doit pas en occulter la valeur. Il a raté de peu mon classement du “book of the year”. C’est un texte de haut niveau dont la matière est illustrée avec talent par des cas réels et le déroulement d’une véritable transformation. Ne le ratez pas !

pratique-lean-IT

Référence complète : La pratique du Lean Management dans l’IT, agilité et amélioration continue – Marie-Pia Ignace, Christian Ignace, Régis Medina & Antoine Contal – Pearson France 2012 – ISBN : 978-2-7440-6544-6

La pratique du Lean Management dans l'IT


http://www.goodreads.com/book/add_to_books_widget_frame/17911905?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Retours sur Agile France 2013, 4ème partie (en images)

Avant-dernière ligne droite pour mes retours sur Agile France 2013. Pour ceux qui débarquent, sachez que vous trouverez :

  • Un premier post couvrant le début de matinée
  • Un second terminant la matinée et couvrant le début d’après-midi
  • Un troisième terminant la journée du vendredi.

Welcome !

On commence tranquilement la journée par un café, une viennoiserie et des conversation avec des têtes connues.

agileFrance2013-12CafeVendredi01

Personnellement, j’aime bien arriver tôt et prendre mon temps avant de me ruer dans les sessions.

agileFrance2013-12CafeVendredi07

D’ailleurs en fait, on ne va pas commencer par une session, mais par le mot du bureau Agile France (à ne pas confondre avec l’organisation de la conférence Agile France).

Le mot du bureau Agile France

C’est Emmanuel Gaillot qui s’y colle. Je dirais que cela n’a pas été mon moment préféré de la conférence. Le style déjà est étrange : Emmanuel assis (comme il n’est pas un géant, on ne le voyait pas) lit une déclaration. Curieux, mais bon. La déclaration surtout en elle-même ne m’a pas fait forte impression, en tout cas dans le sens positif.

Je me méprends peut-être sur le teneur du message, mais il m’a semblé qu’on y opposait cet évènement non-sponsorisé et fier de l’être aux autres “vendus” à des partenaires, un Agile France “première manifestation agile en France” aux autres qui viennent saturer le paysage…

En tant que membre du Scrum User Group et donc organisateur du Scrum Day, j’ai un peu de mal à ne pas prendre cela comme une attaque ! Et franchement si nous avons des sponsors qui nous permettent de rendre l’évènement abordable, je n’ai pas pour autant l’impression de vendre mon âme. Mais j’ai peut-être mal interprêté le propos du bureau…

Alors que dois-je penser ?

A bien y réfléchir, rien de différent par rapport à ce que je pensais jusqu’à présent : Agile France est un magnifique évènement (le ScrumDay aussi et j’en suis fier), j’étais heureux d’y être et je reviendrais ! Il faudrait bien plus que cela pour gâcher mon plaisir !

D’ailleurs, c’est reparti !

Florence Chabanois : Mais pourquoi y m’écoute pas ?

C’est hélas assez souvent plus qu’une impression : c’est une réalité malheureuse de la communication sur nos projets ! Mais où donc se situe le problème ? Sommes-nous mauvais à faire entendre notre voix ou est-ce notre aptitude à écouter qui est prise en défaut ? Les deux mon capitaine ! Et Florence Chabannois va nous l’expliquer dans cette session.

agileFrance2013-13Chabanois03

Ecouter ou prétendre écouter ?

Mauvaise nouvelle : Le premier facteur de défaillance d’écoute, c’est nous même.

D’abord nous parlons trop (ce doit être vrai, ma mère me disait la même chose…) !

  • Difficile d’écouter quand on parle. Du coup nous nous écoutons nous-même plus que nous écoutons notre interlocuteur.
  • Le “moi je” qui rammène la discussion à soi, les rappels sont autant d’interruptions qui font obstacle à la communication.

Bref, quand on écoute et que l’on veut aussi parler, il faut attendre le bon moment pour le faire !

Par exemple, là ça marche bien : toute monde écoute Florence…

agileFrance2013-13Chabanois04

Ceci nous conduit à la première recette de Florence Chabanois

Recette n°1 : quand on écoute, il faut se taire

Quand florence parle de se taire, ce n’est pas seulement à propos de ce que l’on dit à haute voix. C’éest aussi faire taire notre petite voix intérieure (tiens ça me fait penser à Magnum, pour ceux qui ont vu la série…). Là, j’avoue que c’est plus challengeant, car je ne sais pas pour vous, mais pour moi la “petite voix intérieure”, c’est un peu tout le temps !

Ca ne s’arrête pas là, il faut aussi se concentrer sur ce que nous dit notre interlocuteur.

Et aussi montrer cela par notre attitude corporelle, en regardant notre vis-à-vis.

C’est un bon début. Mais ce n’est pas fini. Car à différents interlocuteurs, différentes attitudes d’écoute. Nous en arrivons à la seconde règle.

Recette n°2 : savoir s’adapter à son interlocuteur

Pour s’adapter, il faut reconnaitre des profils de personnalité. Et pour cela Florence nous propose … le modèle DISC !

On ne peut pas vraiment dire que ce soit d’une grande originalité, sans compter qu’il faut toujours un peu se méfier des modèles. Mais si ça aide à faire le boulot… Florence nous propose quelques exemples connus. Je vous laisse les découvrir dans la présentation, ils valent le coup !

Passons en revue ces différents types et comment s’adapter :

Le dominant

C’est un “problem solver”, il est pressé, voir brutal.

Avec lui, inutile de prendre des gants ou de longues introductions. Il faut faire des phrases courtes et aller droit au but.

L’influent

C’est l’archétype du commercial. Il est centré sur les personnes, les réseaux. Par contre, il manque d’organisation et le focus sur les délais n’est pas son point fort.

Quand on communique avec lui, il faut mettre l’emphase sur l’énergie et la passion. Il sera aussi sensible à ce qui touche à la réputation.

Le stable

Il est empathique, timide et orienté sur les personnes. Une sorte d’antithèse du dominant. Il est aussi indécis et torturé (dans les cas extrêmes quand même, j’imagine…). L’équipe est plus importante que lui-même.

Il faut lui parler doucement (n’oubliez pas qu’il est torturé, faut pas en rajouter) et être à 100% avec lui.

Le consciencieux

Il est orienté tâches et introverti. Les règles sont importantes pour lui. C’est un perfectionniste qui veut tous les éléments avant de se décider car il a peur de se rater. Les détails seront donc aussi très importants.

Recette n°3 : Reformuler

Pourquoi ?

  • Déjà pour montrer que l’on écoute et que cela se voit !
  • Pour tester notre bonne compréhension du message.
  • Pour provoquer l’empathie. On teste le moment où l’on est en phase lorsque notre interlocuteur nous dit “ouais, c’est ça !”.

Ce que j’en ai pensé

Une présentation certes agréable, mais où l’on apprends pas grand chose de nouveau.

Cela étant dit, je pense qu’il ne faut pas négliger les vertus de ce type de présentations, focalisées sur un aspect comportemental, même s’il est connu ou devrait l’être. C’est un retour aux fondamentaux, une sorte de “kata du coaching”. Il n’y a pas que le truc nouveau qui déchire qui compte. Les gestes élémentaires et quotidiens, nous les faisons bien plus souvent et nous devons ne pas oublier de les faire correctement.

Merci Florence !

Lectures recommandées

Régis Medina : Plus d’agilité avec le Lean

Nous étions resté hier avec la première paire de mon carré d’as. Transformons maintenant cela en brelan. Jamais je n’ai d’hésitation à aller écouter Régis et jamais je n’ai été déçu. Il en va de même aujourd’hui.

agileFrance2013-14Medina01

Alors voilà, on fait de l’agile. A-t-on amélioré les choses ? Oui, ça ne fait aucun doute ! Doit-on en rester là ? Régis est un vieux baroudeur de l’agilité. En fait le plus ancien ancien que je connaisse. S’il y a bien une personne capable d’évoquer cela, c’est lui !

La réponse est : oui. Nous allons voir pourquoi.

Il reste des challenges…

On parle bien au pluriel !

Avoir des gens “super forts”. On ne parle plus de faire des projets avec de grosses équipes, mais au contraire avec de petites capables d’abattre un gros travail ! On n’a pas le choix, sinon c’est le passage par la case “offshore” !

Faire des bon produits ! Des produits adaptés à nos clients, qui emportent l’adhésion. Ces dernières années, les services sur le Web ont terriblement monté le niveau de jeu !

Tenir le rythme du client. Grâce à l’agilité, nous avons drastiquement augmenté nos cadences de livraison et notre réactivité au changement. Las de son côté, le client a vu aussi ses rythmes s’accélérer. En fait, ses rythmes ont plus accéléré que les nôtres ! A notre grand désarrois, le fossé s’est donc encore creusé !

Quid d’une meilleure méthode ?

Oui, quelle est la bonne méthode pour passer le cap ?

Encore faux : ce n’est pas la bonne question !

Mettre les choses en perspective ne fait pas de mal. A mon grand plaisir, Régis l’a très bien fait en prenant le contre-pied d’idées à la mode.

La taylorisme.

On oppose souvent l’agilité au taylorisme, ce qui est juste. Mais on le fait sans discernement en se contentant d’asséner que “le taylorisme c’est mal”. Pourtant c’est bien lui qui a permi l’essort de l’ère industriel, il a permis un énorme pas en avant ! Mais l’organisation scientifique du travail montre des limites :

  • Le processus n’est pas toujours adapté au quotidien
  • L’équipe doit souvent adapter le processus au terrain.

Pour Régis Médina, il s’agit de garder les bénéfices de l’OST en adressant ses lacunes. Comment ? En gardant les personnes au centre du dispositif.

Attention, garder les bénéfices ne signifie pas conserver le principe du taylorisme qui divise le monde entre ceux qui pensent et ceux qui exécutent. En fait, c’est même le travers de nombreux déploiements “Lean” : on cherche à utiliser les outils du Lean dans le cadre de l’OST.

Nous avons hélas quelques mises en oeuvres catastrophiques estampillées Lean qui opèrent ainsi et sont très visibles. A mon avis, ces grand projets sont plutôt du Business Process Reengineering. On pourrait presqu’en dire que c’est l’ennemi juré du Lean … Mais je m’égare, revenons au propos de Régis.

Nous allions parler du Lean.

Le Lean à la rescousse

Pour éclairer le terrain du Lean, Régis nous dresse une image de la “maison Lean” :

  • Voir l’entreprise comme un terrain d’amélioration, donc d’expérimentation. L’opportunité de mener des “dojo”.
  • Le respect des personnes. Le succès est un droit ! Le rôle du manager est d’aider les équipes à relever des challenges.
  • Développer les compétences, non par “l’expérience” où les gens sont laissés à eux-même ou en usant nos pantalons sur les chaises des salles de formation, mais par la pratique délibérée.

Sur le développement des compétences, Régis nous entraine vers le terrain biologique et le développement et le renforcement des réseaux synaptiques par leurs usages. J’aime bien l’exercice intellectuel de ce rapprochement, mais je ne suis pas sûr de suivre l’orateur sur ce terrain. Pas en l’absence de sérieuses références dans le domaine des savoirs évolués (par opposition aux connaissances de base comme le langage, l’écriture, etc…). Disons que c’est au moins une perspective intéressante.

Pour débuter sur cette voie, l’orateur nous propose de commencer par…

3 pratiques

Management visuel

Le management visuel ce n’est pas mettre sur les murs n’importe quoi ! En Lean, c’est rendre visible l’exercice que l’on essaie de faire.

Le point principal est de visualiser le challenge à atteindre, ce qu’on veut réussir. C’est un focus différent de celui des “tâches à faire”.

Cet objectif macro à moyen terme doit se décliner en objectifs à la journée. Régis nous parlait du “droit au succès” au début de sa présentation : le droit au succès, c’est aussi pouvoir rentrer chez soi en étant fier d’avoir atteint le but que l’on s’était fixé en début de journée.

Le management visuel, c’est aussi rendre visible les problèmes et leur résolution. On rejoint ici la notion de Kaisen, c’est à dire d’amélioration continue. Pourquoi rendre visible les problèmes ? Pour avoir le nez dessus et être en position de devoir les résoudre plutôt que de les remettre au lendemain.

Votre exercice : Sur votre support de management visuel, mettez en évidence :

  • Qu’est-ce qui nous permet d’apprendre quelque chose
  • Qu’est-ce que le succès ?
  • Voit-on les points à travailler ?

La résolution de problèmes

L’outil de base, c’est le cycle PDCA, une approche rigide mais un passage indispensable en Lean. Nous cherchons à répondre à la question : quelle action précise va payer ?

Votre exercice : Une action de la dernière rétrospective dont vous êtes content :

  • Quel était le problème ? Etait-on en mesure de le chiffrer ? Quels en étaient les impacts pour l’entreprise ?
  • Quel était l’objectif de l’action ? Qu’est-ce qui nous permet de voir que l’action marche ?

L’observation de terrain

C’est voir où l’on peut grater de l’efficacité en allant là où l’action se passe.

Par exemple, en regardant l’utilisateur travailler avec l’outil informatique : noter les actions qui apportent de la valeur et celles qui sont du “gaspillage” au sens Lean. dans un cas l’outil aide, dans l’autre il est un frein.

Votre exercice :

  • Sur chaque item de backlog, quel est la valeur associée.

Conclusions

On fait avancer les choses, non pas en faisant de grand plans et en concevant des “ultrasolutions”, mais par la pratique quotidienne et répétée.

Changer notre façon de voir : les processus ne sont pas important. Scrum, XP, Kanban … quelle est la bonne méthode ? Ce n’est pas la bonne question. La bonne question est : comment développer les personnes.

Ce que j’en ai pensé

Voilà encore une session dont ma restitution va être bien fade. Difficile de rendre justice à la présentation de Régis. C’est bien fait pour vous, fallait être là ! La compréhension du Lean passe par la pratique et l’infusion des concepts. C’est ce qu’a fait Régis, il nous a infusé le savoirs de base. Il ne s’est pas arrêté là, il nous propose de commencer quelque part !

L’histoire ne s’achève pas ici. En fait ce n’est qu’un préambule. Régis travaille avec des collègues à un “starter kit” qui fait suite à cette introduction afin de nous aider à démarrer la mise en ouvre. Franchement, j’ai hâte de voir cela. Pour patienter un peu, voici le support de présentation.

http://fr.slideshare.net/slideshow/embed_code/22424062

Lectures recommandées

Dernière ligne droite

Nous allons souffler un peu avant les dernières sessions de cet Agile France 2013. Nous nous retrouvons très bientôt !

Retours sur Agile France 2013, 3ème partie (en images)

Après avoir couvert le début de matinée et le milieu de journée, il est temps de nous intéresser à la fin de cette première journée de conférence.

On commence par un Lightning Talk. Ou ce qui aurait dû être un lightning talk, car il est joyeusement passé de 15 minutes à 25 ! Mais c’est sans importance. C’était intéressant.

Egor Sviridenko – Je vois !

Ou comment la visualisation non conventionnelle contribue à des projets agiles

Une bonne visualisation fait la différence et permet de mettre en évidence une information importante qui sinon resterait cachée.

La visualisation par l’exemple

Pour illustrer cela, Egor nous parle de l’épidémie de choléra à Londres en 1854. En quelques semaines cette épidémie fit des centaines de victimes. Le mode de transmission de cette maladie n’était pas encore connu à cette époque (on pensait à tord qu’il s’agissait d’une transmission aérienne).

Les autorités se sont révélées incapables d’endiguer l’épidémie, jusqu’à ce qu’un médecin, John Snow, ait l’idée de reporter le nombre de personnes atteintes sur une carte. Cela permit d’abord de délimiter l’extension de l’épidémie, puis d’en localiser l’épicentre. Et enfin d’en déterminer la cause probable : une pompe à eau dont John Snow obtiendra le démontage de la poignée, mettant ainsi un terme à l’épidémie !

cholera_map_john_snow

La visualisation permet de rendre mieux interprêtable des informations. Encore faut-il utiliser la représentation adaptée !

D’autres visualisations

Egor a regroupé les principes de visualisation en 4 familles. Nous venons d’en voir la première : les cartes.

Si l’utilité de la carte dréssée par John Snow est indéniable, les données y sont superposées de manière plutôt classique. Mr Minard a utilisé une représentation bien plus originale afin de stigmatiser le désastre de la campagne de Russie de Napoléon 1er.

Les réseaux permettent de représenter des informations corrélées entre elles. McLaren utilise un backlog converti en mindmap afin de déterminer les évolutions à réaliser sur ses logiciels embarqués. Comme vous pourrez le voir sur le support de présentation, c’est assez impressionnant. A mon grand étonnement, ils paraissent être capables de s’en servir !

Les timelines permettent de construire des histoires où l’on voir l’évolution d’un ou plusieurs facteurs au fil du temps. La timeline du “seigneur des anneaux” nous permet d’appréhender les tribulations des personnages, leurs séparations et leurs rencontres. Celle de Jurassic Park nous montre que les différents personnages se font bouffer au fur et à mesure de l’intrigue. Mais ça on le savait déjà.

La représentation à plusieurs variables permet de représenter des facteurs non corrélés sur une même représentation. Un exercice dans lequel il est préférable de se restreindre afin de ne pas rendre cette visualisation illisible. Le Kanban que nous utilisons de plus en plus sur nos projets agiles rentre dans cette catégorie.

Je ne saurais trop vous recommander le support de présentation d’Egor : il regorge littéralement d’exemples de ces visualisations. Rien ne saurait être plus parlant !

Conclusions et conseil de lecture

Quel est la qualité principale d’une bonne représentation ? Elle doit raconter une histoire !

Un conseil de lecture principal :

Antoine Contal – Coacher des managers

Sur mon premier compte-rendu, j’avais évoqué 4 orateurs que je vais systématiquement écouter. Mon carré d’as en quelque sorte. Le premier était Pascal Van Cauwenberghe, Antoine est le suivant. Vous découvrirez les deux autres lors de la seconde journée.

agileFrance2013-09Contal01

L’heure est grave ! De nombreuses équipes améliorent leur façon de faire et leur productivité, et ce qui les handicapent, c’est parfois le management intermédiaire, celui qui devrait au contraire les aider à être plus efficaces ! Comment changer cela ?

Le management au quotidien

En Lean, on commence toujours par aller observer. Donc, il faut aller voir la bête dans son habitat naturel. Celui-ci se trouve en deux endroits principaux :

  • Son bureau
  • La salle de réunion

Quelle sont ses activités principales ?

  • Avaler et produire des rapports
  • Assigner des tâches
  • Eteindre des incendies

Ah ! Nous allions oublier son péché mignon : entamer des projets pharaoniques. Ce qu’en Lean on appelle des “ultrasolutions”.

L’idéal du management

En Lean, celui-ci se construit autour d’un certain nombre de valeurs et de principes.

  • L’amélioration continue : Le Kaisen. C’est progresser à petits pas en construisant des expérimentations.
  • Le Genchi Gembutsu : retourner sur le terrain, pour se baser sur des faits, plutôt que sur des opinions (ce qui est souvent le cas du travail fait en salle de réunion).
  • Construire des challenges : oser rêver l’idéal. Motiver par rapport à l’excellence. Le but est de créer l’adhésion, mais aussi de placer la barre haut afin de faire progresser.
  • Respect des personnes : croire dans le potentiel des personnes. Comprendre que les problèmes sont personnalisés et doivent donner lieu à un apprentissage.
  • Teamwork : savoir travailler et collaborer au-delà des frontières organisationnelles.

Pour Antoine Contal, le manager Lean est à la fois un chercheur et un entraineur sportif !

Comment réussir en sachant ce qui rate

  • Les critères de réussite : ils doivent être clairs. On peut coacher une équipe de développement sans définir clairement ce qu’est le succès et s’en tirer. Ce n’est pas possible avec des managers !
  • Etre sur un mauvais sujet. Par exemple : améliorer le délai de production des rapports d’activité !
  • Etre purement dans l’humain.

C’est bien d’avoir une idée de comment rater, mais c’est mieux si l’on a une idée de comment contrer ces travers.

  • Il faut définir le succès proprement. Il n’y a pas de raccourcis par rapport à cette étape. Le faire c’est déjà du coaching !
  • Choisir les bon sujets. Comment ? Ce sont ceux qui sont bon pour le manager et pour les équipes !

Le coaching fonctionne si la performance et les conditions de travail des équipes s’améliorent.

Petits exercices

Antoine Contal nous en propose 3.

Exercice 1 : Ecouter l’utilisateur

On en revient à la question de la valeur.

L’orateur illustre cela avec un manager confronté à un usager d’une application pour laquelle un lourd projet vient de se terminer. A la question “que pensez-vous des nouvelles fonctionnalités ?” ce dernier répond … “oh ! Elles ne me gênent pas…”.

Las, l’histoire se termine mal : le manager ne fera rien par rapport à cela et finira par être remplacé !

Exercice 2 : Définir la performance

Cela passe par la mise en place d’indicateurs (lead time, en cours, stock), d’enquêtes de satisfaction.

Le rôle du management intermédiaire est aussi de reconnecter l’opérationnel avec la stratégie. Antoine évoque pour nous l’histoire de cet urbaniste SI qui découvre que ses indicateurs d’urbanisation ne sont pas ce qu’il croit simplement parce que les cellules opérationnelles en charge d’arrêter les systèmes remplacées (et qui ne dépendent pas de lui) ne l’ont pas fait !

Exercice 3 : Aller voir

Encore et toujours aller sur le terrain. Pas seulement celui des utilisateurs, mais aussi celui des équipes de développement pour identifier ce qui nuit à leur travail.

“Comment je fais…”

Pour l’orateur, le rôle de coach de managers est un rôle de coach sportif !

Le manager est passé d’une situation où il accomplit son travail dans son bureau ou dans les salles de réunion à une situation où il est présent sur le terrain, pour voir ce qui se passe.

Le coach fait s’enchainer les exercices d’entrainements faits sur mesure, afin d’adresser les points où il s’y prend mal, ce qu’il doit apprendre.

Une session de coaching typique se découpe ainsi :

  • 30 minute : préparation ; où allons-nous, que voulons-nous tester.
  • 1h30 : Aller sur le terrain ; le manager doit apprendre à voir. Le coach reste silencieux, observe et prend des notes (pour le débrief). Il se permet une et une seule question !
  • 1h : Debrief ; Qu’avons-nous vu ou pas ? Que doit améliorer le manager. Que doit-il répéter avant la prochaine session.

Typiquement, le rythme est d’une ou deux sessions par mois.

L’ingrédient secret duu coach Lean, ce sont les “3 R” :

  • Relate : c’est la relation interpersonnellle que le coach doit construire avec le manager. Celui-ci doit apprendre à faire confiance à son coach.
  • Repeat : Faire répéter le même geste, encore et encore.
  • Reframe : Le coach donne “une autre lecture” de ce que le coaché a vu.

A vous de jouer

Pour synthétiser, quel doit être le rôle du manager ?

  • C’est “l’étoile du nord” des équipes de développement.
  • On fait progresser le manager en lui donnant de “petits exercices”.
  • La manager doit devenir un développeur de talents.

Une dernière chose : Il est rare que la demande de coaching de manager soit formalisée ou même demandée. Si la nécessité apparait, Antoine utilise le mode “stealth” et intègre cela au coaching de l’équipe !

Ce que j’en ai pensé

Difficile de rendre justice à la présentation d’Antoine par un simple compte rendu. Disons que, malgré le nombre appréciable de présentations de bonne qualité auxquelles j’ai assisté, c’est pour moi le point fort de cet Agile France 2013 !

Antoine Contal ne garde rien pour lui dans ses présentations. Son niveau de maturité fait qu’il est assez à l’aise pour procéder ainsi. On repart avec pas mal d’éléments à mettre en oeuvre, des éléments de reflexion pour nous faire progresser. En fait, comme disent les jeunes j’ai toujours un peu l’impression de “prendre cher” avec les présentations d’Antoine et de son comparse. Pourtant j’y retourne. Comme il l’a si bien dit, il place la barre haut et c’est grâce à cela que l’on progresse. C’est un peu déprimant pour moi de voir la marge de progression qu’il me reste, j’ai l’impression d’avoir si peu progressé, de rater tellement de choses … Mais nul doute que nous avons besoin de personnes du niveau d’excellence et de maturité d’Antoine pour nous y aider.

Lectures recommandées

Autres resources :

Pascal Van Cauwenberghe et Pierre Hervouet – Vous pouvez ignorer les contrôleurs de gestion, les contrôleurs de gestion eux ne vous ignoreront pas !

L’agilité, c’est l’adaptation au besoin, l’émergence du changement ! Mais bon, une entreprise a quand même besoin de savoir où aller et surtout de savoir où va son argent. Alors, on peut dire que l’on se focalise sur la valeur, des gens ont besoin de se focaliser sur les dépenses. Ces gens sont le contrôleurs de gestion. On les connait à peine, on les ignore (peut-être même les méprisent-on) le plus souvent. Ce n’est pas raisonnable.

Pascal et Pierre viennent nous faire prendre conscience de cette dure réalité. Nous allons suivre pour cela les pas de Dora l’exploratrice (en plus de ceux de Pascal et Pierre) !

agileFrance2013-10BeyondBudget02

Cost accounting

Puisque l’on est en atelier, on va se mettre aux travaux pratiques. Des travaux pratiques bien sympathiques, car on va préparer des cocktails ! On mélange des ingrédients, on a 2 tailles de cocktails et il faut calculer le coût de chacun.

agileFrance2013-10BeyondBudget01

Le cost accounting, c’est comme faire des cockatils (mais on a pas le droit de l’avouer). On a des ingrédients (des centres de coûts) et il faut les saupoudrer sur des lignes budgétaires !

C’est une approche analytique détaillée qui est très précise … mais précise ne veut pas dire exacte. En fait la ventilation de coûts comme les frais généraux peut montrer les faits sous des jours différents selon la façon dont on l’opère.

Attention ! On ne peut échaper complètement à cette approche, car c’est celle qui est de toute façon demandée règlementairement par les services publics.

Dernier travers du “cost accounting” : les stratégies budgétaires tendent à emmener ce type de gestion vers une sorte de “cycle en V” de la gestion budgétaire. C’est comme ça que l’on se retrouve à préparer le budget de l’année suivant dès le mois de Juillet !

Throughput Accounting

Ce mode de gestion prend un angle différent : celui de gérer l’investissement en fonction des goulots d’étranglement ! C’est une sorte de vue systémique de l’investissement.

agileFrance2013-10BeyondBudget04

L’un des avantages par rapport au cost accounting : c’est de sortir du cycle en V ! Mais ce n’est pas encore parfait, car l’investissement n’est pas rapproché de la valeur du flux auquel il est subordonné.

Lean Accounting

Le Lean Accounting adresse ce dernier reproche. Ici, le point de départ est la valeur client, ce qui va déterminer un prix au produit. En fonction de celui-ci on décide de la marge, donc du coût ! C’est le “target costing”. Pierre et Pascal semblent confiants sur l’approche, mais j’ai quand même l’impression que ça peut vite tourner à la quadrature du cercle…

Un autre point différenciateur important, c’est que le contrôleur de gestion lean fait partie de l’équipe !

Beyond Budgeting

Cette approche est plus difficile à appréhender, plus proche de l’agilité tel que nous l’entendons (donc plus intéressante, il faut donc que j’y travaille). Elle s’appuie sur 12 principes qu je ne vais pas répéter ici, car ils figurent dans le “hands out” ci-dessous.

L’idée est de sortir des comportements biaisés introduits par le contrôle de gestion.

Ce que j’en ai pensé

Nous avons tout un univers à explorer ici.

Les références bibliographiques du hands-out lèvent un coin du voile. Hélas cette session est un peu courte pour vraiment nous permettre de saisir les 4 approches. Elles montrent, dans leur progression, une “agilification” croissante des concepts. C’est excellent ! J’ai un peu l’impression cependant que ces concepts m’ont filé entre les doigts. Il faudrait que je révise.

L’idée de faire un atelier est excellente. Et le cocktail pour le “cost accounting” a bien marché. Hélas le côté atelier s’est arrêté ici. Il faudrait imaginer la suite des exercices pour chacune des 4 étapes…

Comme je l’ai dit : c’est relativement nouveau pour moi … mais aussi important. Je ne regrette pas d’avoir choisi cet atelier.

A demain !

Une journée bien remplie, comme vous avez pu le voir. Il est temps de cloturer celle-ci

agileFrance2013-11FinJeudi02

A très bientôt pour la journée de Vendredi !

Jim Coplien à propos de l’architecture DCI et de son rôle au sein d’une approche agile

Cette intervention enregistrée en 2009. Elle reprend le propos développé par Jim Coplien et Gertrud Bjornvig dans leur livre : Lean Architecture.

Sans être révolutionnaire, il y a quelques idées intéressantes. Mais qualifier cette architecture de “lean” est un peu source de confusion pour moi. Bref, en ce qui me concerne, je ne suis pas encore convaincu…

Note de lecture : Implementing Lean Software Development, par Mary et Tom Poppendieck

Note : 7 ; Suite de l’opus précédant…

Le précédant ouvrage des Poppendieck nous avait accoutumé aux pratiques Lean, celui-ci passe en quelque sortes, une seconde couche. Les principes sont à nouveau passés en revue, mais ici on consacre un chapitre par élément (et non par principe) important. Leur mise en valeur s’effectuant essentiellement à l’aide de cas d’exemples, non seulement pour introduire chaque chapitre, mais aussi pour illustrer celui-ci tout au long.

  • Value : La valeur est au centre des principes Lean, non seulement pour délivrer les fonctionnalités apportant le plus de valeur et ce régulièrement (itérativement), mais en délivrant celle-ci le plus rapidement possible en optimisant la chaine de valeur et en focalisant les équipes sur les activités qui délivrent cette valeur.
  • Waste : C’est aussi en focalisant les équipes sur les activités liées au produit final que l’on élimine le gâchis, mais aussi en éliminant les produits semi-finis ou en éradiquant le « hands-off » ou passage de relais formels entre deux équipes. Parmi les 7 origines du gâchis on trouvera également les fonctionnalités inutiles, les défauts, les délais, le réapprentissage et le « task switching », tous symptômes qui peuvent être éliminés à la racine.
  • Speed : La théorie des files d’attente est au centre des préoccupations de rapidité. Ici l’attention est portée sur les temps de cycle, et le moyen le plus efficace pour les raccourcir : l’élimination des temps d’attente
  • People : Le moyen de rendre plus efficace une équipe est de lui confier sa propre destinée! C’est aller plus loin que la simple “responsabilisation”. L’équipe ainsi autodirigée trouve son accomplissement dans son propre travail. Fini la motivation par les bonus et autres salaries variables…
  • Knowledge : Créer de la connaissance, apprendre en faisant. C’est résumer un peu rapidement l’esprit de la chose, mais ici il est question de “set based design” et de refactoring, au final de différer les décision jusqu’au moment où l’on a appris suffisamment d’éléments pour opérer une décision judicieuse et non à priori.
  • Quality: Ce point est abordé de manière peu convaincante dans l’ouvrage, sauf peut-être quand sont évoqués les 5 “S”: Sort, Systematize, Shine, Standardize et Sustain. Bien entendu y sont aussi évoqués les tests. La catégorisation des tests qui est proposée est à mon avis très pertinente.
  • Partners : Cette partie traité des partenariats, des contrats et de l’externalisation. Lean approche cette question par le “win win” et les contrats à long terme.

La grande qualité de cet livre sont les histories qui servent d’exemples aux différentes questions abordées. Beaucoup de points restent hélas un peu abstraits, et malgré la qualité du texte, on en est toujours à se demander à la fin: “mais comment implémenter Lean dans le monde du développement logiciel ?”.

implementing-lean-soft-dev

Référence complète : Implementing Lean Software Development, From concept to cash – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series 2006 – ISBN : 0-321-43738-1

Implementing Lean Software Development: From Concept to Cash


http://www.goodreads.com/book/add_to_books_widget_frame/0321437381?atmb_widget%5Bbutton%5D=atmb_widget_1.png

1ère conférence Lean Kanban France

Cette première édition se déroulera les 18 et 19 Octobres dans les locaux de Valtech au 103 rue de Grenelle.

Cette conférence associera des sessions en Anglais proposées par des grands noms du domaine, à côté de sessions en Français proposant cas d’utilisation et retours d’expérience. Le positionnement de cette conférence, ainsi probablement que la capacité d’accueil limitée des locaux met le ticket d’entrée à un tarif assez élevé : de 450 € (early bird) à 800 € (last minute).

Je n’y serais pas, ayant déjà un agenda chargé et aussi, je dois l’avouer, du fait du tarif du ticket d’entrée. Mais une personne de mon équipe y sera. J’espère luis soutirer quelques informations.

1ère conférence Lean Kanban France