Note de lecture : The Lean Mindset, par Mary Poppendieck & Tom Poppendieck avec Henrik Kniberg

Note : 7 ; La pensée Lean, ou comment se focaliser sur les choses importantes, au-delà du « Lean Software Development ».

« Nous avons écrit 3 livres à propos du développement logiciel, mais nous ne pouvions en écrire un 4ème, car l’ile du développement logiciel a largement disparu. », c’est ainsi que se termine ce volume. Un texte qui ne s’inscrit dans pas dans la continuité des autres ouvrages des Poppendieck. Il est de loin mon préféré, il dirige résolument vers une pensée « produit ».

Le texte est court, il est expédié en un peu plus de 160 pages sur 5 chapitres et une épilogue. Après une introduction pour camper les notions de « lean mindset », de « fast pace thinking » (représenté par Oto) et de « slow pace thinking » (il s’agit d’Anna) qui nous viennent tout droit de kahneman, on attaque les 38 pages du chapitre 1 « the purpose of business ». Les questions qui y sont adressés sont d’ordre organisationnelles : quelle est la finalité de l’organisation ? Penser qu’il s’agit de maximiser la valeur de l’action est un leurre ou un effet de second degrés, alors que ce qui compte est ce qui mobilise les forces vives de l’entreprise.

Le second chapitre est consacré justement aux facteurs mobilisant les forces vives de l’entreprise. Le sujet couvre 30 pages et introduit également le Lean Product Development. Il ne s’agit pas seulement de motivation intrinsèque, mais d’aider les personnes à grandir, favoriser l’apprentissage. Ce sont des aspects que le Lean revendique mais qui sont rarement bien développés. Il y est aussi question d’intuition et de biais cognitifs, ce qui nous ramène encore à Khaneman.

Lire la suite

Note de lecture : The Principles of Product Development Flow, par Donald G. Reinertsen

Note : 8 ; Passionnant et passionnément austère !

Don Reinertsen n’est pas là pour s’amuser. Déjà vers la page 17, l’auteur nous explique que la manière d’appréhender les dimensions économiques d’un produit sont aujourd’hui bien naïve, que la théorie des contraintes de Goldratt est certes un progrès mais qu’elle ne représente qu’une étape intermédiaire, et que nous allons passer en revue tout cela au long de 150 principes que couvre le reste du livre. Oui : 150 ! A ce stade, on pressent que la lecture des 266 pages de l’ouvrage découpé en 9 chapitres va être bien plus longue que prévue. Une impression qui se vérifiera.

Le premier chapitre compte 26 pages. Il sert d’introduction aux 8 autres chapitres, ce n’est donc pas le plus difficile à lire. Et pourtant il fourmille déjà de concepts et d’une description très affutée des problèmes auxquels nous devons faire face lorsque l’on développe un produit. Bref, il campe le décors et for bien !

On a guère pitié du lecteur : le second chapitre sur la « vue économique » est déjà un des chapitres difficiles de l’ouvrage. Mais c’est aussi la clé de voute de ce qui suit, à savoir le coût du délai ! On y parle d’objectifs économiques clés et déjà de la perception économique de la taille des lots intégrant le facteur « coût de transaction ».

Lire la suite

Note de lecture : Managing to Learn, par John Shook

Note : 4 ; Storytelling peu convainquant

Cet ouvrage au format inhabituel m’a été chaudement recommandé pour m’initier au A3 problem solving. Le format est inhabituel pour trois raisons :

  • Du fait de son format physique tout d’abord. Il est pratiquement carré et dépasse donc allègrement mes autres livres une fois rangé dans la bibliothèque.
  • Par son approche éditoriale : il s’agit d’un double storytelling, permettant une lecture à double niveau. Mais ceci complexifie aussi considérablement la manière d’aborder le texte. J’y reviendrais.
  • Par ses annexes : en fait des exemples de A3 (qui du coup ne sont pas au format A3), livrés pliés et insérés dans un rabat de la couverture arrière. Une bonne surprise de l’ouvrage.

Mais revenons-en au texte. Sous le format inhabituel dont j’ai parlé tout à l’heure, l’ouvrage compte 127 pages présentées en deux colonnes de largeurs inégales. La plus large, imprimée en noire, raconte l’histoire de Porter qui s’initie au A3 (mais bon, il connaît quand même un peu en fait). Cette histoire doit nous permettre de nous initier par l’exemple au concept du A3, le fameux « problem solving » spirit ! La seconde colonne est imprimée en bleue, c’est une histoire dans l’histoire, celle de Sanderson le manager de Porter. Sanderson est en posture de coach par rapport à Porter, c’est donc un deuxième niveau de lecture qui nous est proposé ici.

Lire la suite

ScrumDay 2015 : Scaling Dilemna, par Mary Poppendieck

Quand nous étions petits, nous étions fantastiques ! Maintenant que nous sommes plus gros … nous avons cessé d’être fantastiques. En fait, on ne communique plus aussi bien.

Quels sont les problèmes ?

  • La coopération
  • La complexité
  • L’état d’esprit
  • Le focus

Ce sont ces 4 points que Mary Poppendieck va développer dans sa keynote de ce second jour du ScrumDay.

Coopération

Quand l’entreprise grandit, on tend à l’organiser en silo. Et ça ne marche pas si bien que ça ! On peut prendre le problème dans l’autre sens, et mettre les fonctions (ou les fonctionnalités) en silo. Ce n’est guère mieux.

Lire la suite

Petit Printemps est devenu grand !

Connaissez-vous Leanette ?

image

Leanette est la mascotte du Club Agile Caennais. Un club qui est né sous l’impulsion de Jean-Luc Lambert entouré de quelques passionnés. De rencontres en meetups, il ont organisé une rencontre en 2012. Le club n’était alors pas dans mon radar. Cette rencontre de 30 personnes s’est transformée en un petit évènement de 70 personnes l’année suivante. Celui-ci avait attiré mon attention par la présence exceptionnelle de Jurgen Appelo et j’avais relaté l’évènement ici et ici.

De 70, la rencontre est passée à 150 inscrits l’année suivante. Une édition où je figurais cette fois comme speaker et que vous retrouverez ici et ici, et bien entendu ici pour ma propre session.

Bienvenue à l’édition 2015 !

C’est de nouveau comme speaker que je suis venu cette année. Cette fois, il a fallu quitter les locaux de l’université pour accueillir les 300 inscrits. Un beau succès !

image

Lire la suite

Focus

Chap 1 : Où l’on parle de flux

Le focus, au niveau de l’entreprise, qu’est-ce que cela signifie ? En premier lieu, de se concentrer sur la chaine de valeur. Et sur le flux, plutôt que l’utilisation des ressources. Le Value Stream Mapping est un des outils permettant de mettre en évidence les possibilités d’amélioration de ce flux.

Le corollaire est de se concentrer sur un petit nombre de features plutôt que sur des gros batches qui mettent du temps à passer dans le rétroviseur. Donc du Focus !

Chap 2 : Se faciliter la vie

Nous avons vu le problème du « trop de choses à faire ». Et le temps pour le faire est limité. Bien entendu, nous avons moins de temps disponible que de choses à faire. Mais en réalité celles qui sont indispensables n’en sont qu’une fraction. On pourrait appeler le reste des « options » ! Nous sommes maitres de nos choix, n’en devenons pas les esclaves.

Chap 3 : Tel un hamster dans sa roue

Les sollicitations nous viennent de toute part ! Elles créent un bruit qui nous empêche de faire ce qui est important. S’isoler de ces perturbations et se concentrer sur une seule chose jusqu’à ce qu’elle soit terminée, il n’y a rien de nouveau là. Quelques techniques peuvent nous aider comme le « zéro inbox » ou le Pomodoro.

Lire la suite

Formons-nous à Kanban avec le FKUG

Zenika accueillait cette nouvelle réunion mensuelle dans le zLocalHost. Une foule très nombreuse s’y était donné rendez-vous pour cet opus dédié à la formation au Kanban et aux techniques associées.

image

Un programme très chargé. Peut-être un peu trop, c’est vraiment tout ce que l’on pourrait reprocher à cette remarquable soirée !

Après le mot d’accueil du Sponsor soirée, Couthaier nous donne quelques nouvelles de l’association. Elle est très active il faut bien le dire. D’ailleurs la soirée suivante aura déjà eu lieu quand vous lirez ces lignes. Mais place à l’action.

Et l’action pour commencer, c’est avec Pascal Poussard et les essentiels de Kanban !

Initiation au Kanban avec Pascal Poussard

C’est toujours un plaisir pour moi d’entendre Pascal. Cette fois encore, il nous gratifie d’une session d’initation au Kanban clair et énergique, se concentrant sur les aspect importants de l’approche. On pourra juste lui reprocher de faire des infidélités au Scrum User Group (dont il est l’un des membres éminents du bureau) pour faire une pige au FKUG !

image

4 objectifs et 2 notions clé

La Kanban, c’est surtout 4 objectifs :

  • La qualité
  • Equilibrer le rapport demande / débit
  • Livrer souvent
  • Réduire la variabilité

Deux notions clé font de Kanban une approche radicalement différente.

  • La chaine de valeur : Ici, elle part de l’aval. C’est la demande qui contrôle la mise à disposition, d’où la fameuse notion de « flux tiré ».
  • Le temps de cycle : On ne parle plus de vélocité ou de capacité. Kanban se focalise sur le délai entre la demande et la mise à disposition au-delà de toute chose. Si cette notion n’est pas importante pour vous, sans doute n’êtes-vous pas un bon candidat au Kanban. Mais réfléchissez bien…

6 principes

Visualiser la chaine de valeur. C’est la première pierre du Kanban. Car visualiser cette chaine de valeur, c’est rendre compte de manière claire de ce qui se passe, créer une adhésion autour de celle-ci et permettre de « casser les silos ».

Limiter le travail encours (WIP limit). Ce principe est à la fois le moteur du flux tiré et de la réduction du temps de cycle.

Gérer le flux. Dans un système, le flux est limité par son goulot d’étranglement (théorie des contraintes). Cette dernière nous dit aussi qu’il y a nécessairement un goulot d’étranglement dans le système, qu’il faut décider (et non subir) où celle-ci se positionne et subordonner le système à cette contrainte.

Rendre les processus explicites. Comme les approches agiles, Kanaban est une école de rigueur : les règles de passages sont clairement définies, ainsi que les procédures exceptionnelles.

Amélioration continue. L’observation et la mesure de ce qui se passe nous permettent de déterminer ce qui peut faire l’objet d’amélioration.

Feedback : Celui-ci vient des mesures et de la voix du client.

Pour quel contexte ?

  • Si notre flux de travail n’est pas équilibré.
  • Si notre chaine de travail est surchargée.

Comment commencer ? Avec ce que l’on a, simplement en rendant notre processus explicite. Puis en enclenchant des cycles d’amélioration.

Retrouvez ici la prestation de Pascal.

Ainsi que le support de sa présentation.

Le management visuel et l’Obeya, par Christophe Keromen

Au commencement

On commence fort avec Christophe en se posant la question suivante : pourquoi faire un management visuel ? Pour nous pousser à l’action ! Si celui-ci n’atteint pas ce but, il faut le jeter !

Pourquoi doit-il être visuel ? La Programmation Neuro-Linguistique nous dit que des 5 sens, le VAKOG de la PNL, c’est le sens visuel qui est dominant, car notre cerveau est efficace pour reconnaitre les motifs.

La question suivante sera donc : qu’en fait-on ? On va s’en servir pour rendre visible les problèmes, et rendre aussi visible le lien entre le problème (que l’on refuse souvent de voir) et l’action.

image

Commençons avec un tableau Scrum…

Celui-ci nous permet de rendre visible la progression. Mais rend-t-il visible le challenge ? Permet-il de voir les « impediments », les boulets qui nous freinent ?

Christophe nous résume ainsi ce que le management visuel rend possible :

  • Voir ensemble
  • Agir ensemble
  • Apprendre ensemble

Pour permettre cela, il faut non seulement faire attention à l’information que l’on montre (et qui conditionnera tout le reste), mais faire en sorte que l’information représentée sur ce tableau soit :

  • Univoque
  • Visible
  • Interactive

Un tableau soigné

Cela commence en soignant ce tableau au niveau du contenu. Ce sont les « 3 U » :

  • Utile (ce qui n’est pas utile constitue une pollution)
  • Utilisable
  • Utilisé (quelle est la dernière chose que vous avez apprise avec le tableau ?)

Cela signifie aussi un tableau soigné du point de vue esthétique. Eh oui je confirme : personne ne va aller voir un tableau moche !

Du manangement visuel à l’Obeya

Que doit montrer d’autre notre management visuel ?

  • Les objectifs (le challenge)
  • Les règles
  • La vision

C’est de tout cela dont on parle quand on évoque l’Obeya. Mais l’Obeya, c’est aussi un espace, l’Obeya Room, à l’agencement très spécifique. Le but ? Se mettre en position de faire du Kaizen !

Retrouvez ici la présentation de Christophe Keromen en vidéo.

Ainsi que les slides de sa présentation.

La résolution de problèmes avec le A3, par Laurene Vol

Le A3, c’était probablement la présentation que j’attendais avec le plus d’impatience. Mais ce fut aussi probablement la présentation la plus faible, hélas. Non pas qu’elle fut mauvaise, mais elle est restée très « by the book ».

Un A3 pour traiter des problèmes

Et ces problèmes, comment sont-ils identifiés ?

  • De manière spontanée, durant l’itération, quand on tombe dessus !
  • En rétrospective
  • Via des indicateurs

Ces problèmes, Laurene nous propose de les collecter au sein d’un tableau, plus précisément dans une matrice de Merill-Covey. Vous connaissez déjà certainement.

image

A partir de là, des règles nous permettront de déterminer la manière dont nous traiterons ces problèmes. Pour certains d’entre-eux, ce sera le A3 !

Du contexte à l’analyse

Le A3 débute avec une partie « contexte ». Elle répond à la question : Pourquoi en est-on là ?

Vient ensuite le « current state » : un état initial quantifié et si possible illustré avec un schéma. Si des contournements sont déjà mis en oeuvre, ils sont exposés.

image

L’objectif, c’est l’état final désiré. Il est lui-même quantifié.

La partie délicate, c’est bien l’analyse. On privilégie l’analyse causale à l’aide de différentes techniques : les 5 pourquoi, les diagrammes de cause-effets ou les diagrammes en arêtes de poissons.

Vous avez trouvé mon compte-rendu trop succinct ? Regardez la vidéo de l’intervention de Laurene.

Son support de présentation est également disponible.

Kaizen & PDCA avec Julien Karoubi

Je dois avouer que Julien affronte des challenges que je n’oserai pas, même dans mes jours les plus téméraires.

Ainsi, pour illustrer le principe de l’amélioration continue, Julien a proposé un jeu !

image

Ce jeu, Julien l’a imaginé spécialement pour cette soirée. Il s’agit d’effectuer des itérations et de consacrer un peu de temps pour trouver des améliorations de fonctionnement, à l’image du Ball Point. Ici, Julien s’évertue également de perturber le système en intervenant au milieu des itérations, histoire de casser de rythme et voir comment l’équipe réagit !

image

Résultat moyennement concluant. On arrive à la même productivité avec ou sans temps consacré à l’amélioration. Mais on doit pendre en compte que du temps de travail est alors consacré aux rétrospectives. Il faut dire que les tranches de temps sont réellement très courtes, surtout pour les rétrospectives. Voyons en video ce que cela donne.

Il était aussi audacieux de la part de Julien de faire ce jeu dans une configuration de soirée « plénière » : Il y avait 80 personnes dans le showroom Zenika, probablement moins de 10 pouvaient voir et suivre réellement ce qui se passait.

Quoi qu’il en soit, cette cassure était bienvenue dans ce marathon de présentations !

Key Performance Indicators pour Kanban, par Yannick Quennec’hdu

Yannick est très, très affuté (et expérimenté) sur les mises en place de Kanban et les mesures associées dans des contextes multi-équipes. On pouvait s’attendre à une présentation de haute qualité, nous l’avons eu !

Parlons pré-requis

Toutes nos présentations s’articulent bien ensemble, car pour Yannick, un pré-requis important est … la mise en place d’un management visuel ! Bon, il n’y a pas que cela. Il faut aussi que notre Kanban soit « stabilisé » également. Nous ne devons pas non plus perdre de vue notre objectif : rendre factuel notre Kanban !

image

Les indicateurs

Ils sont classiques, mais ça ne fait pas de mal de les reprendre :

Le Lead Time : combien de temps entre une « commande » et un client servi.

Le temps de cycle : Le temps séparant deux évènements identiques. C’est donc l’inverse de la fréquence et vice-versa.

Le débit : Le nombre d’items livrés dans un laps de temps donné. Là on ne parle plus d’étape du processus, mais de ce qui sort du Kanban !

Le travail en cours : combien d’éléments sont en élaboration aux différentes étapes du processus !

Le diagramme de flux cumulé est l’outil de prédilection permettant de mesurer et voir évaluer la plupart de ces indicateurs. Ca, c’étaient les bases. Et maintenant, voici…

Le grand Mix

Ces indicateurs se combinent pour voir les corrélations entre ces indicateurs.

La loi de Little : Elle indique que le temps pour terminer est inversement proportionnel à l’en cours. Donc réduire l’en-cours augmente le débit !

La prédictibilité : Un indicateur compliqué, basé sur le débit et la taille des tickets.

L’efficience : Pour mesurer dans notre processus, le temps qui ajoute de la valeur au produit. En pratique, on isole les zones tampon et l’on mesure le temps que le ticket y passe.

La qualité : C’est le coût de la non-qualité qui est mesurée, via des « tâches rework », par exemple. Yannick utilise cela pour mesurer la valeur économique de l’accroissement d’une équipe de tests !

Variabilité : Ces variabilités peuvent être locales ou globales.
Je vous recommande la vidéo de l’intervention très riche de Yannick

Et aussi, bien sûr, le support de sa présentation.

Mesure de la maturité par Nicolas Lochet

La soirée n’est pas encore tout à fait finie ! Nicolas nous expose à la vitesse de la lumière une grille d’audit de maturité Kanban, basée sur les éléments du livre de Laurent Morrisseau.

image

Il n’y a pas de support de présentation, car Nicolas nous présentait directement sa feuille Excel (que je n’ai pas non plus). Hélas, nous n’avons pas également de captation vidéo de cette intervention.

Enfin, un petit « preview » ne fera de mal à personne : voilà !

image

On a soif !

Il est plus que temps d’aller au ravitaillement. Vider le frigo rempli de bières et les petits fours et autres provisions de bouche laissées à disposition, telle était notre dernière tâche !

image

Ce que j’en ai pensé

Ce Meetup était vraiment très riche. La mission était d’initier le plus grand nombre aux éléments de base de Kanban. Les diverses présentations ont réellement rempli ce rôle. En fait l’agenda était même trop ambitieux. Nous aurions eu de la matière pour deux soirées ici.

Second point, bien que mineur : je n’ai pas compris la nécessité de rendre cette soirée payante. D’autant qu’étant hébergée chez Zenika, tous les coûts étaient assurés par l’hôte ! Cela n’a pas freiné les ardeurs (et la contribution demandée était minime) et cela a certinement alimentée la caisse de l’association.

Le FKUG montre une fois de plus son dynamisme, non seulement à organiser une soirée par mois, mais à varier les formules de ces soirées. Un rythme et une variété que j’avais escomptée pour le Scrum User Group il n’y a pas si longtemps que cela, et qui reste à retrouver.

L’association organisait aussi en décembre une soirée jeux, je n’ai malheureusement pas pu y participer. J’attends avec impatience l’année prochaine !

Le FKUG offre un tour de chauffe à Lean Kanban France !

Beau programme pour cette rentrée du FKUG ! En effet, cette soirée hébergée par Wemanity proposait pas moins de 4 sessions sur 2 tracks. Nous serons donc hélas frustrés de 2 sessions !

image

Un petit mot sur le FKUG tout d’abord :

  • Les choses avancent, avec maintenant un site pour l’association.
  • La taille de la communauté augmente aussi progressivement : elle compte 330 inscrits sur meetup ! La j’en suis sûr, nous étions moins nombreux chez notre hôte…
  • On est rentré et bien rentrés : le prochain meetup se profile déjà pour le mois de novembre…

Assez bavardé, place aux présentations !

Apprendre à apprendre pour le 21ème siècle, par Yannick Grenzinger

Cette session, seul Yannick pouvait nous en gratifier ! Sur la dernière année, Yannick a suivi 30 cours en ligne, les fameux MOOCs, il est en quelque sorte un « boulimique du savoir » !

Cette présentation, que Yannick propose par ailleurs au format Brown Bag Lunch s’articule sur 3 niveaux : l’individu, le produit, l’organisation.

image

Apprendre pour les individus

Ici, Yannick nous propose quelques « hacks » :

  • Déconstruire pour mieux reconstruire : faire des tranches d’une dizaine de minutes. Cette déconstruction est déjà une étape de l’acquisition de la connaissance !
  • Des répétitions fréquentes, mais espacées (!)
  • S’appuyer sur l’utilisation de modèles mentaux et de métaphores. Tiens ? Cela ne vous rappelle-t-il pas XP ?
  • Eliminer les bloquants.
  • Utiliser une boucle de feedback rapide. Nous autres agilistes sommes en terrain connu…

Bien sûr, pour faire bonne mesure, Yannick sait aussi nous proposer quelques bonnes lectures :

L’un des points majeurs est qu’il n’est pas besoin d’avoir une « connaissance parfaite ». Les fameux 80% sont largement suffisants et s’acquièrent comparativement rapidement !

Apprendre sur les produits

Et déjà, sur la construction de produits, quel est l’inverse de l’apprentissage ? Le « cycle en V » bien sûr ! Et bien entendu, notre objectif est bien d’apprendre en permanence. Notre attirail d’agiliste possède ce qu’il faut à ce égard : Rétro, A3, Kaizen, etc…

Apprendre, c’est aussi utiliser le pouvoir de la collaboration et les techniques de co-création.

Enfin, apprendre c’est aussi accepter l’échec et penser à « aller plus vite sur l’échec ». C’est ce que nous enseigne le Lean Startup.

Apprendre en tant qu’organisation

De nouveau la même question : quel est l’inverse de l’apprentissage ? C’est le Taylorisme : un travail codifié devant être exécuté sans reflexion par des executant dont réfléchir n’est pas le rôle !

image

Apprendre au sein d’organisation, c’est d’abord savoir organiser pour la complexité, plutôt que chercher à la maîtriser ou le réduire à tout prix. Le Stoos Network a pour but de faire progresser ce mode de pensée, bien que force soit de constater qu’il peine à prendre de l’ampleur.
Le rôle du management est à repenser dans une organisation apprenante. C’est ce que nous enseigne le Management 3.0, mais aussi les militaires dans le manuel Warfighting !

Ce que j’en ai pensé

Je sors un peu frustré par cette session. De l’aveu même de Yannick, la partie « organisation » nécessite d’être renforcée. Mais c’est surtout sur la partie « individu » que l’on attendait l’orateur, et malheureusement il ne développe pas assez ses « hacks ». Nous aurions aussi aimé une reflexion sur la nature (et l’objectif) différent de l’apprentissage au 21ème siècle, à l’ère de l’information à haute valeur disponible au bout des doigts !
Toutefois, je sors aussi avec quelques pointeurs de lecture (encore). Connaissant Yannick, ils valent sans aucun doute le détour !

Continuous Delivery : A Plug-in for Kanban, par Samuel Retière

Il s’agit en fait d’une présentation qui serait fait à 3 voix au LKF, ici il n’y avait que celle de Samuel. Je ne vais pas paraphraser la présentation de Samuel, car vous pouvez y accéder ici.

Ce que Samuel nous présente ici, ce sont les « patterns de transformation » appliqués à la SGIB et organisé en 3 niveaux. Les thèmes s’articulent beaucoup autour du Kanban Thinking de Karl Scotland : valeur, flux et potentiel

image

Le niveau 1 n’a peut-être l’air de rien, mais on y parle déjà cycle TDD et flux !

Le second niveau correspond déjà à une maturité acquise par bien peu d’équipe. On y trouve pèle mêle une pensée produit épaulée par du Lean Canvas, du BDD, du Flux « end to end », donc avec du devops à la clé !

Au niveau 3, on trouve des choses bien plus rares telles que la maximisation de la valeur « infrastructure as code ».Et le seul élément que j’ignorais de la présentation : le Black Swan Coaching ! Plus curieusement, on y trouve le DDD que j’aurais mis personnellement au niveau 2 au maximum. Peut-être même au niveau 1 !

Le programme inclut un cocktail de cours, de workshops et de katas. Le tout épaulé par 3 coaches qui permettent de couvrir le spectre de compétences évoqué. Impressionnant !

<

Fin

Hélas, il n’était pas possible de tout voir. J’aurais par exemple aimé assister au retour d’expérience sur SAFE chez JC Decaux. Il s’agit d’un buzzword qui monte et il faut que j’en sache plus sur le sujet. Celui-ci au demeurant me semble complexe, trop pour être honnêtement agile et j’y perçois des reminiscences d’Unified Process… Qu’importe, il me faudra bien appréhender correctement ce dont il s’agit.

Lean Agile Camp, saison 2

Le premier opus du Lean Agile Camp s’était déroulé en novembre dernier, une période peu propice pour moi et j’avais abdiqué. Pas question de rater celle-ci par, contre : programmée début Juillet, il n’y avait guère de conflit de dates à l’horizon.

Quand on veut parler de Lean sérieusement, on a de bonne chance que Régis Médina ou Antoine Contal ne soient pas loin. Nous avons eu la chance de bénéficier de l’expertise des deux !

image

Au programme de cette journée, des dojo pour aborder 3 sujets :

  • La compréhension du client
  • Le management visuel
  • La résolution de problème

1er atelier : le « job to be done »

Cet atelier est destiné à confronter nos hypothèses à la réalité. Pour ce faire, nous avons choisi une application (l’application Meetup mobile dans notre cas) et avons cherché à en établir les cas d’utilisation, structuré de la manière suivante :

  • Contexte d’utilisation
  • Job
  • Attributs

Dis comme ça, c’est un peu abstrait. Voyons plutôt le résultat que nous avons obtenu.

image

Dans une seconde étape, nous avons consolidé le travail fait avec nos hypothèses en allant rechercher des feedbacks utilisateurs. On le craignait, mais bien sûr hélas, la réalité du terrain nous donne un tout autre son de cloche : les propriétés que nous avions jugées importantes ne semblent pas les bonnes. Par exemple, la question de la confiance dans les groupes ou les membres semble récurrente (nous avons croisé plusieurs sites et forums utilisateurs).

Bref, on découvre de nouveaux « job to be done », de nouvelles propriétés et en éliminons certaines qui ne sont pas recoupées par nos sources d’information.

A la fin de l’exercice, nous partageaons nos trouvailles entre groupes.

image

Le « misfit » entre nos hypothèses et la réalité est un point commun entre nos deux groupes !

Le FIAP Jean Monnet qui nous hébergeait propose des facilités pour déjeuner. Grâce à cela nous pouvons limiter nous pause déjeuner à 1 heure. D’autant que la zone restauration est carrément vide en ce premier week-end de Juillet !

image

Retour aux choses sérieuses avec notre second kata !

2nd atelier : le management visuel

Cette fois, nous allons partir d’une situation existante, un cas existant dans l’un de nos contexte et proposer des visualisations adaptées. Il pourra s’agir d’une visualisation ex-nihilo ou l’amélioration d’une visualisation existante. Les clés que nous proposent nos deux coaches Lean sont :

  • S’inspirer des jeux video : être clair sur les scores !
  • Donner un contexte stratégique, mais un focus opérationnel !
  • Visualiser le challenge !

Attention, le challenge peut être anxiogène, le mieux est d’être capable de montrer les progrès au jour le jour, car la motivation vient du succès !
Nous avons choisi deux contextes issus de notre groupe :

  • Un centre de service, qui cherche encore quel est son objectif de succès !
  • Un grand projet qui a un objectif de périmètre pour une date donnée et doit motiver celles-cis afin d’atteindre ce but alors que les mesures montrent un état courant en-dessous de ce qui est escompté.
image

Certes, le management visuel n’était nouveau pour aucun de nous. Et pourtant ! Pourtant, grâce à ces quelques lignes directrices et aux interactions du groupe, nous avons abouti à des résultats inespérés !

3ème atelier : la résolution de problème avec le PISCAR

La résolution de problème, c’est un peu l’épicentre du Lean (avec l’amélioration continue). Et qui dit amélioration continue, dit PDCA, n’est-ce pas ?

image

Nous allons nous concentrer sur la partie « problème » du PDCA et utiliser une heuristique proposée par Régis Médina : le PISCAR que nous allons donc expérimenter sur nos études de cas :

  • P : Le Problème ; il doit être énoncé sans essayer de camper un contexte ! On définit un problème comme un écart quantifié.
  • I : L’impact ; Il doit être chiffré. Il nous permet de répondre à la question : Est-ce le bon problème.
  • S : Standard ; la partie la moins évidente de l’exercice. L’idée est de comparer la situation à problème au cas normal.
  • C : Causes ; que l’on obtient par exemple avec les « 5 pourquoi ». Mais surtout on cherche les racines. Les 5 pourquoi, ça fait un peu tarte à la crème…
  • A : Action ; une action qui doit être le plus rapide et le plus simple (donc la moins coûteuse) possible. Donc, une expérimentation.
  • R : Résultats attendus ; ils sont à mettre en rapport avec l’impact.
image

Nous effectuons l’exercice de manière itérative, car c’est probablement le plus difficile de la journée. Corina s’est proposée pour exposer le sien pour clore ce 3ème volet.

image

Ce que j’en ai pensé

C’est ce que j’appelle une journée bien investie, même prise sur mon week-end ! Une journée pour comprendre, pratiquer et échanger sur 3 pratiques: j’ai hâte de remettre ça !