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

Lire la suite

Publicités

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

Lire la suite

Carnet de route : Agile France 2014 (3/4)

Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.

De bon matin…

De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.

image

Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…

image

Assez plaisanté ! La journée va commencer, place à la keynote !

Coaching Teams Through Change

Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.

Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !

image

Le début d’un changement

Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.

Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.

Lone rangers et development owners

Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.

L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé.
Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !

Gold card

A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.

Ce que j’en ai pensé

Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :

  • Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
  • Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !

Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !

Le mythe du framework agile

Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !

Le framework maison

Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !

image

Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain !
Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !

Citons dans le désordre :

  • Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
  • Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
  • pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…

Qu’en est-il des « full stack » reconnus ?

Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !

Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.

Ce biais a des conséquences, on va le voir bientôt.

D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.

Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.

En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !

Bref nous obtenons :

  • Des architectures monolithiques.
  • Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
  • Des couplages forts avec la représentation et la base de données.
  • De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
  • Une testabilité rarement au rendez-vous.

Mais alors, c’est quoi un framework agile ?

Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.

  • Elle doit nous permettre de retarder les décisions
  • Elle minimise les couplages.
  • Elle est facile à changer.Elle est testable (via TDD et ATDD)

Une proposition et des inspirations

Pour Jean-Baptiste Dusseault, une telle architecture c’est :

  • Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
  • Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
  • Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.

Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…

La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.

Ce que j’en ai pensé

Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !

Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses

Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !

Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !

image

Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :

Les gens se foutent de la manière dont nous résolvons les problèmes.

Au hasard des améliorations, on va trouver :

  • « t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
  • Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
  • Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
  • Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
  • Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !

Les conclusions de Cyrille

  • Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
  • Il n’y a pas de choses simples : l’amélioration continue est une quête !
  • Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
  • Mesurer l’impact d’un problème, c’est déjà 50% de la résolution

Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !

Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !

Ce que j’en ai pensé

Une très bonne session : amusante et instructive. Bravo !

Refactorer du Legacy

Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».

image

Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :

  • On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
  • On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
  • On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
  • On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
  • Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
image

Ce que j’en ai pensé

Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.

J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.

Pause déjeuner

Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.

  • Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
  • Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
  • Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
  • Ils ont beaucoup d’autonomie et sont entreprenant.
  • Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.

Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !

Carnet de route : Agile France 2014 (1/4)

Agile France, c’est un rendez-vous incontournable. Enfin disons : sauf cas de force majeure. Le lieu reste le même et surtout fidèle à lui-même : le chalet de la porte jaune !

En arrivant, on est certain d’y trouver du café, mais surtout des connaissances et des amis. Ca commence bien !

image

L’organisation se fait aussi un point d’honneur d’être dans le timing. Et ça, ce n’est guère évident ! C’est Damien Thouvenin qui officie comme que maître de cérémonie cette année.

image

Avant de laisser place à la Keynote de Régis Médina, je voudrais souligner la formidable présence de Romain Couturier pour animer un scribing en continu lors de cet Agile France. Il a également initié plusieurs groupes à son art, qui se sont aussi jeté à l’eau pour capturer les sessions de l’open-space !

image

Le produit, prochaine frontière de l’agilité

Le Product Management, c’est un sujet plutôt « trendy » en ce moment. Régis va l’évoquer pour nous avec sa sensibilité Lean.

Le bon vieux temps

Autrefois, avant l’agile, on produisait les logiciels en phase. Arrivait la phase de tests. En fait, le moment où commençait vraiment le projet. Parfois, tout était purement et simplement jeté à la poubelle. mais on sait maîtriser cela désormais. Hélas, la récompense pour un problème résolu, c’est un nouveau problème !

Le nouveau problème, c’est que nos utilisateurs veulent plus et plus vite : ils ont des services en ligne accessibles depuis partout, des applications mobiles … Ils ne sont plus dupes ! Le niveau monte, il n’y a plus le choix : il faut produire un SUPER logiciel !

Obtenir le whaou effect !

Et déjà, deux trucs pour ne pas l’obtenir:

  • « design par comitee ». Ici les Product Owner ne servent que d’aiguillage entre des besoins plus ou moins divergents.
  • Fonctionner en flux à l’extrême. Le revers du flux, ce de ne porter son attention sue sur des petits bouts.

Alors quelle solution ?

image

Le Lean Startup offre une partie de la solution, mais il n’offre pas de réponse aux points de vue antagonistes, ni à la résolution des contraintes. Régis préfère orienter son regard vers le Lean Engineering, où un chef d’orchestre (et un seul) porte la vision du client (vous avez dit « product owner » ?). Bien. Mais quels caractéristiques, quelles aptitudes doit posséder ce chef d’orchestre.

Si l’on regarde les grands chief engineers, on voit que l’une de leur caractéristique commune est leur capacité à dire « non ». Mais comme on s’en doute, cela ne suffit pas. L’orateur évoque pour nous trois compétences clé.

Trois compétences

Positionner le challenge : c’est le chief engineer qui donne la direction et place la barre. S’il ne le fait pas, les personnes de l’équipe se trouveront individuellement leur propres challenges ! Positionner le challenge, c’est aussi identifier les paramètres clé, ceux que l’on aura déterminés en allant voir sur le terrain.

Cultiver le désaccord : Lister les options s’offrant à nous de manière crédibles et les attaquer de front (set based design).

Dénicher les erreurs : En ayant un niveau d’exigence élevé, obligeant à voir et revoir sans cesse les solutions adoptées. La voie empruntée ici est celle de la résolution des problèmes.

image

Ce que j’en ai pensé

C’est toujours un plaisir d’écouter Régis. Et ses interventions sont toujours d’excellente qualité. Je ne peux qu’abonder dans le sens qu’il évoque, même si je trouverais certains autres points à appuyer, comme l’importance du feedback (bien couvert par le Lean Startup dans ce cas).

Cela ne révolutionne pas non plus mon image du product management, j’y trouve les éléments que j’avais déjà, à l’exception sans doute du « cultiver le désaccord » qui donne un peu à réfléchir. Curieusement ce point sera aussi abordé dans une autre session ! Mais c’est aussi un aspect que l’on retrouve aussi dans le design thinking…

Le mot de l’organisation

Avant d’aborder la suite du programmes, nous avons droit aux pitches de la première journée : 30 secondes par orateur, c’est vraiment court ! On a aussi le mot de l’association, par la voix de son président, Emmanuel Gaillot.

image

L’an dernier, Emmanuel nous avait gratifié d’une tirade pour le moins asez sèche, assis sur une chaise. Pas terrible. Je ne sais s’il a lu mon compte-rendu, mais cette année c’est débout qu’il s’est exprimé, avec un verbe moins acerbe et nettement teinté d’humour, et avec le même message. Ca change tout ! Kudo, Emmanuel !

Il est temps de rejoindre la session suivante. Moi, je ne change pas de salle car Pascal Van Cauwenberghe fait son talk avec Jacques Couvreur dans celle-ci.

La simplicité : Pas facile !

Je ne savais pas à quoi m’attendre pour cette session (dont je n’avais même pas pris la peine de lire le résumé). La simplicité, ce n’est effectivement pas facile, car elle nécessite avant tout de définir ce qu’est la simplicité !

Pour nous aider dans notre quête, Pascal et Jacques vont plonger dans la substance proposée dans deux ouvrages.

The Laws of simplicity

Le livre de John Maeda nous propose 10 lois que nous passons revue.

1 – La réduction : Ne laisser apparents que la fonction et le message.C’est donner une apparence de simplicité.

2 – Organisation : Ranger les éléments pour donner une impression de simplicité.

3 – Lutter contre les temps d’attente : l’attente donne une impression de complexité. Exhiber un élément dynamique comme une barre de progression atténue cela.

4 – L’apprentissage : Elle couvre deux niveaux :

  • L’apprentissage immédiat : c’est permettre la découverte.
  • La maîtrise, qui intègre une notion de dynamique.
image

5 – La différence (Jacques est resté sec là dessus)

6 – Le contexte : un concept difficile à saisir, mais qui tempère d’un « ni trop, ni trop peu » cette notion de simplicité.

7 – L’émotion : La simplicité est aussi un facteur non rationnel.

8 – La confiance : C’est offrir un contexte sécurisé, permettant de faire et défaire sans crainte.

9 – L’Echec : Parfois, on ne peut pas tout simplifier. Mais essayer permet d’apprendre.

10 – La loi cardinale : Moins d’évidence et plus de sens.

Bon, je reste un peu sur a fin avec cet énoncé de concepts. Certains éléments de la liste me parlent un peu, mais cela manque de substance. Passons au second opus.

The Laws of Substraction

Le livre de Matthew E. May livre à son tour 6 règles.

1 – Ce qui n’est pas là est parfois plus important que ce qui est là. Pascal rapproche ce point de la loi de Conway. Améliorer l’environnement (en éliminant des barrière) peut améliorer le produit.

2 – Les règles simples produisent les expériences les plus productives. Pascal nous propose deux choses à essayer en ce sens :

  • Quelles règles (qui protègent) peut-on supprimer ?
  • « abandonner » l’application aux utilisateurs.

4 – Ajouter des contraintes. Pour déclencher de nouveaux comportements, on peut par exemple : réduire la durée des itérations, réduire la durée entre 2 commits, etc..

5 – Parfois, il faut casser pour percer. Ne pas avoir peur des crises…

6 – Parfois, ne rien faire c’est mieux !

Je sais, il me manque l’item numéro 3 : désolé !

Ce que j’en ai pensé

Je suis un fan des présentations de Pascal. Cette fois, je suis resté sur ma faim. Mais néanmoins, je serais bien là aux prochaines présentations de Jacques et Pascal !

Le prochain créneau nous propose des lightning talks. Mon choix est fait depuis longtemps !

Tim Gallwey ou comment le coaching a commencé

Christophe Keromen nous a proposé une session une session de 20 minutes passionnante commençant par un échec : celui de Tim Gallwey, alors champion de tennis, ratant la balle de match d’une demi-finale de championnat (et le match par la même occasion). Ainsi commence le constat : nous sommes tous nos propres saboteurs ! Nous avons du potentiel, mais nous faisons moins que ce que nous sommes capables de réellement faire. D’où l’équation :

Performance = potentiel – interférences

Quand « self 1 » gêne « self 2 »

Nous interférons avec nous-même.

image

Notre « self 1 » représente l’égo, le moi rationnel, tandis que « self 2 » représente le corps et l’inconscient. Lorsque nous laissons « self 1 » interagir, nous provoquons un ralentissement, une diminution de notre probabilité de réussir. Ce point est appuyé par les neuroscience qui affirment que la quasi-totalité des informations dont nous disposons est inconsciente.

A quoi cela peut-il me servir ?

Christophe nous propose deux axes.

L’apprentissage. Les images sont supérieures aux mots. On apprend mieux par mimétisme sans chercher à décrire ou à rationaliser ce que nous faisons (sinon nous rappelons « self 1 »).

Les habitudes. Nous créons des habitudes pour répondre à un contexte qui est souvent la marque du passé, bien que répondant à une intension positive. Il faut remplacer ces habitudes par de nouvelles, répondant aux mêmes intentions, mais adaptées au contexte présent.

Ce que j’en ai pense

Christophe a superbement abordé le sujet. Me voici avec encore un sujet à potasser. Je retiens dans l’immédiat la prédominance de l’exemple sur la formulation littéraire.

Pas la peine de bouger de place pour la prochaine présentation qui se déroulera dans la même salle. Tant mieux pour moi, car ça se bouscule !

La rétrospective continue

C’est en duo et dans une salle comble que Régis Médina et Antoine Contal nous ont proposé leur session. Toutes les places sont prises et une partie du public est debout !

image

Evidemment, comme on peu s’y attendre, Antoine et Regis nous parleront de Lean. La clé des retrospectives réussies, celles qui progressent au lieu de s’enliser se situe hors des rétrospectives : c’est créer un environnement où l’équipe progresse. Continuellement.

Dans ce cadre, le rôle du coach devient celui du coach sportif : il aide à poser le challenge.

Le challenge !

Forcément, sur un projet, le challenge est un concept plus flou que pour un sportif. Mais c’est posible en prenant en compte ce qui est important pour le projet. Il n’y a pas de recette miracle.

  • Le sourire du client
  • Le lien avec l’argent. Le flouze, quoi !
  • La stratégie
image

Pour un manager, les dimensions à prendre en compte pourront être :

  • Qualité du code.
  • Délai de livraison.
  • Productivité (même si ce facteur est à prendre avec prudence).

Finalement, il faut trouver le moyen de rendre ce challenge visuel (indicateur, progression…).

Un apprentissage individuel

Une fois posé le challenge, il faut le décliner en petits exercices d’amélioration individuel : chaque action d’amélioration doit avoir son porteur. Ce porteur devient expert du sujet, et il profite ensuite des rétrospectives pour partager son savoir !

Chaque action d’amélioration se décline en expérimentations suivant le cycle PDCA : ce sont des Katas.

image

Finalement une bonne nouvelle, mais…

La bonne nouvelle, c’est que l’on peut garder les rétrospectives. Elles deviennent un lieu d’échange des nouvelles pratiques.
Il y a aussi un prix à payer :

  • Ecouter les managers
  • Ecouter la réalité plutôt que ses envies
  • Persévérer

Les bénéfices en contrepartie :

  • On peut avoir un impact
  • Quand ça marche, le comportement des personnes change.

Enfin, Antoine et Régis nous proposes des exercices à faire en rentrant

  • Aller voir et écouter le client
  • Construire le modèle économique du produit
  • Questionner un directeur sur les objectifs stratégiques
  • Mettre en place un indicateur
  • Commencer avec un problème dont nous (en tant que coach) connaissons la réponse.

Ce que j’en ai pensé

Comme d’habitude, avec Antoine et Régis, c’est du lourd comme disent les jeunes. On prend cher au passage aussi : leur sessions sont aussi intéressantes que déprimantes. Mais ça tombe bien, les actions d’amélioration sont au centre de ce que j’ai à faire en ce moment !

Pause déjeuner

Je ne reviens pas sur la qualité de la la restauration d’Agile France, j’en ai déjà longuement parlé l’an dernier !

Le déjeuner, c’est surtout l’occasion d’échanger avec les personnes que l’on apprécie (il y en a beaucoup !). Ce midi, ce sera avec Nathaliel Richand et Jean-Luc Lambert. Bien sûr, nous évoquons un peu le Printemps Agile, mais nous parlons surtout enseignement : Nathaniel voudrait développer des MOOCs agile, ce qui est dans les tendances du moment, mais peu compatible avec un enseignement de plus en plus par le jeux et « from the back of the room »…

image

Sans doute il y a-t-il complémentarité entre les deux modes, en utilisant les MOOCs pour des sujets plus étroits, pour lesquels il serait difficile d’organiser des sessions, donc plus avancés.

Voilà, ce sera tout pour aujourd’hui. Je vous donne rendez-vous très bientôt pour le déroulement de l’après-midi.

Open Space Agile de Mai

Yannick Ameur nous avait déjà convié à un open-space en Février dernier, sous la houlette de l’association Agile France. C’est en comité plus restreint que nous nous sommes retrouvés cette fois-ci. Réunis sous de bonnes auspices je dois dire : le buffet a été monté un peu au dernier moment en mode auto-organisé … et a remarquablement bien marché !

Au départ prévu sur 3 slots et 3 salles, nous nous sommes finalement restreints à 2 slots et 2 salles, avec un agile game pour terminer.

image

Transition vers la gestion de projet agile

Je me suis décidé vers ce sujet type « grand classique » pour ce premier slot. Avec des questions il faut bien le dire, assez récurrentes :

  • Par quoi commencer ?
  • Que faire si l’on rencontre de la résistance ?
image

Ici nous avons concrètement le cas d’un chef de projet faisant de la résistance active… mais aussi sur le départ. Oui, une transition réussie passe assez souvent par le changement d’un certain nombre de têtes. Comme l’évoque le Host Leadership (http://hostleadership.com/) : le passage à l’agilité est une invitation ; ne vous y rendez pas si vous n’avez pas l’intention d’en respecter les règles.

Le passage d’un projet à l’agilité pose aussi la question du fond et de le forme: il est assez tentant de se focaliser sur le décorum agile (les cérémonies, les post-it, etc…), mais plus difficile et pourtant plus important de porter l’attention sur le « mind set » agile: auto-organisation, amélioration continue, etc.

Lean vs Agile

Yannick nous a proposé ce sujet, suite à la discussion que j’avais eu la veille à la ScrumBeer avec David et Margerie !

image
  • Lean est-il complémentaire d’Agile et vice-versa ?
  • Qu’est-ce qui caractérise chacune des approche, ou les rend convergente ?

Tout d’abord il semble difficile à tout le monde de définir le Lean. C’est probablement l’une des raisons qui permet à de grands cabinets de déployer ce qu’ils prétendent être du Lean et s’avère extrêmement destructif sur le plan humain !

Nous avons demandé à Christophe Keromen, l’un des co-auteur du Petit guide de management Lean à l’usage des équipes agiles ce qu’il en pensait. Le point le plus important est pour lui :

  • L’emphase, dans le lean, sur l’amélioration continue, via le cycle PDCA et bien sûr certains outils (Kaisen, Kata, A3, etc.)
  • L’accent mis dans l’agile sur le facteur humain.

Enfin, quand on parle de Lean, il ne faut pas confondre celui-ci avec le Lean Software Development ou même avec le Lean Startup … des choses bien différentes !

Et quand on parle de convergences, on parle souvent d’emprunts de techniques Lean, comme le Kaban. Yannick lui, remarque l’utilité de s’inspirer de l’approche scientifique du Lean : mesurer la réalité et focaliser la résolution de problème par rapport à ses mesures.

Christophe nous affirme que « le lean n’a pas besoin de l’agile ». Il est certain que les deux courants vivent leur vie, bien que l’agile n’hésites pas à emprunter des pratqiues à droite et à gauche. Mais cette petite phrase me conforte sur ma perception un peu snob des praticiens du Lean, qui se voient parfois comme l’aristocratie de l’agilité…

Débrief et fin

Nous étions un peu pris au dépourvu par ces 10 minutes de débrief, mais les animateurs des sessions se sont quand même prêtés au jeu.

image

J’ai peu prétexter de ma foulure au poignet pour échapper au « SOS Titanic ». Je l’avais par ailleurs expérimenté à Agile Games France. Les joueurs n’ont pas été courronés de succès ici, en partie à cause de la pression du temps lors de cette animation. La limite de temps est peut-être nécessaire, mais si elle est trop forte, on perd l’intérêt du jeu !

image

Par ailleurs Dov a tranquilement viré la moitié des occupants du canot pour « sauver » quelques uns de ses occupants. Une manière inédite d’arriver à ses fins…

Enfin, ami lecteur, si tu te décides à animer ce jeu penses au moins à deux choses :

  • On ne brave pas l’eau froide et les requins en même temps. En tout cas, les requins eux ne bravent pas l’eau froide.
  • On ne peut pas mourir de froid et de faim. Il faut choisir…

Prochaines étapes: la soirée du FKUG et Agile France !

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 !