Ce n’est pas le rôle du client de savoir ce qu’il veut.

Steve Jobs

Note de lecture : Alfresco Developer Guide, par Jeff Potts

Note : 5 ; Très complet, mais un poil indigeste.

Avec ses 500 pages, cet ouvrage ne cache pas ses ambitions de couvrir le sujet en profondeur. Il n’est découpé qu’en neuf chapitres, mais complétés d’annexes assez volumineuses couvrant les API sous forme de manuel de référence sur 70 pages.

Le chapitre 1 nous fait le tour du propriétaire sous l’angle de l’architecture. C’est ma fois fort réussie.

Au chapitre 2, on s’attaque au développement d’une extension d’Alfresco en utilisant Eclipse. Le but essentiel semble être de prendre de l’aisance sur l’environnement de travail. Toutefois j’ai trouvé la démarche un peu confuse.

Le chapitre 3 est particulièrement consistent, mais aussi très complet. Il aborde une facette différente d’Alfresco mais plus importante encore : la programmation de définition de contenus : création de nouveaux types, de propriétés, relations et facettes. Puis viennent les aspects qui viennent s’y greffer : programmation avec Java, les Web Services et PHP, customisation de l’IHM et des recherches, etc… Bref c’est particulièrement complet, mais le style rend tout cela hélas pas très facile à appréhender.

Le chapitre 4 fait suite assez logiquement, car il trait de tous les automatismes de traitement qui peuvent se greffer sur les contenus : actions, transformateurs, extracteurs, etc… Cela n’est en fait utile que si l’on a bien sûr l’intention de basculer de l’intelligence métier sur la gestion de contenu…

Le chapitre 5, moins utile de mon point de vue évoque la customisation de l’IHM d’Alfresco, donc utile seulement si l’on veut donner un accès à l’IHM du progiciel aux utilisateurs. J’avoue que je finis par être un peu noyé par ces fragments de code ou de XML que j’ai du mal à rattacher à quelque chose. C’était déjà un peu vrai dans les chapitres précédents, mais ça l’est plus encore ici.

Le chapitre 6 est particulièrement important, du moins à mes yeux : il évoque l’API Rest d’Alfresco. Hélas, le texte part du postulat de l’utilisation de cette API depuis des pages HTML, depuis du code JavaScript. De mon point de vue cela réduit nettement l’intérêt et la portée du chapitre.

Un large chapitre, le chapitre 7, est consacré aux « worflows avancés », donc ceux s’adossant à jBPM. Si les aspects en contact avec Alfresco présentent un peu d’intérêt (mais je cherche toujours comment lier un document à une instance de workflow, comme je le fais pour Documentum…), la description en profondeur de jBPM sort un peu du cadre de cet ouvrage à mon avis. D’ailleurs il y a des livres sur jBPM, même chez PACKT publishing !

Le chapitre 8 est assurément le plus volumineux de l’ouvrage, car ses 80 couvrent le Web Content Management. Le lien entre WCM et ECM (alors que c’est sans aucun doute l’un des intérêts d’Alfresco) ne m’apparaît pas clairement montré. Mais il faudrait que je mette mon nez de plus près dans ce chapitre pour m’en assurer.

Le dernier chapitre aborde la sécurité, aspect souvent complexe sur les systèmes d’ECM. Mais on fait bel et bien le tour de la question : authentification (essentiellement avec LDAP), SSO et permissions.

De manière générale, je dirais que l’ouvrage semble faire le tour de la question. Ou plus exactement, il aborde tous les sujets, même s’il nous laisse aller vers la documentation pour couvrir complètement en largeur tous les sujets. Si l’on avait voulu le faire, le livre aurait probablement fait 2000 pages ! Donc le parti pris était surement le bon. Il n’en reste pas moins que le traitement du sujet est assez aride, et comme je dis plus haut, un peu indigeste.

Enfin bon, le livre fait le boulot. Si vous développez avec Alfresco, ce sera sans aucun doute un plus de l’avoir près de vous.

alfresco-dev-guide

Référence complète : Alfresco Developer Guide, Customizing Alfresco with actions, web scripts, web forms, workflows and more – Jeff Potts – Packt Publishing 2008 – ISBN : 978 1 847193 11 7

Alfresco Developer Guide

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

Note de lecture : Cloud Application Architectures, par George Reese

Note : 3 ; Ou plus exactement : Aborder Amazon EC2 pour l’ingénieur système

Aborder le Cloud quand on a pas grande idée de la chose est un exercice difficile. Le livre de George Reese a pour but de nous mettre le pied à l’étrier. En vérité, avec ses 160 pages, ce n’est pas un bien gros ouvrage. Aussi n’est-il pas surprenant de constater qu’il se focalise sur un cas particulier : le déploiement d’applications en IAAS sur Amazon EC2. Même les autres offres Amazon sont mises de côté (j pense bien sûr à S3). C’est en fait principalement les aspects système liés au déploiement sur EC2 qui sont développés ici.

Le premier chapitre se focalise sur les cas d’usage du cloud computing et les aspects économiques qui lui sont attaché.

Le second chapitre détaille l’offre Amazon, les concepts qu’il faut connaître lorsque l’on pénètre dans cet écosystème : EC2, S3 ; elastic IP, Région, EBS, etc… On y manipule déjà ces objets via les commandes permettant de créer et gérer ces différents objets. De quoi donner une dimension plus concrète au propos.

Le troisième chapitre « avant la transition » revisite le modèle économique afin de nous aider à faire un choix sur le modèle de déploiement. Les différents aspects à considérer (sauvegarde, sécurité, disponibilité, scalabilité, aspects légaux) sont abordés. J’ai bien aimé ce chapitre qui oblige à se poser de nombreuses questions préalablement à l’établissement d’une « architecture cloud ».

Le chapitre 4 est une partie assurément importante du livre car elle présente des cas d’architecture d’applications cloud. Hélas les 30 pages de ce chapitre sont plus une introduction qu’un traitement en profondeur.

Les chapitres 5 et 6 sont dédiés à la sécurité d’une part et au « disaster recovery planning » d’autre part. Ce sont deux éléments très importants d’une architecture cloud. Si la partie dédiée à la sécurité s’avère plutôt traitée en profondeur, donnant pas mal d’éléments de réflexion, le chapitre 6 donne plutôt quelques éléments sur le DRP, mais guère plus.

Qui dit « cloud » dit « scaling » et « élasticité ». Le chapitre 7 est dédié à cette question, mais là encore le point est traité assez légèrement.

Au-delà des 7 chapitres de ce livre, on notera 2 annexes dédiées à Rackspace et GoGrid. Ecrits par les CTO de ces deux entreprises, il s’agit hélas plutôt de brochures publicitaires pour ces deux offres.

En conclusion, ce livre apparaît pour moi plutôt comme une introduction au Cloud et plus particulièrement à IAAS avec EC2. Il a clairement le mérité d’amorcer les pistes de réflexions (au demeurant pas si évidentes) liées au déploiement de solutions Cloud. Il est loin d’être une référence exhaustive sur le sujet. Peut-être n’est-ce pas plus mal, car le sujet évolue vite, tout comme les différentes offres, et cela permet d’avoir un certain état de l’art en 160 pages ! L’inconvénient est l’obsolescence très rapide de ce livre.

L’offre Cloud avance et évolue à la vitesse de la lumière. Je crains qu’un texte accusant déjà 3 ans ne puisse être toujours être considéré comme pertinent.

cloud-computing-architectures

Référence complète : Cloud Application Architectures, Building applications and infrastructure in the cloud – George Reese – O’Reilly 2009 – ISBN : 978 0 596 15636 7

Cloud Application Architectures: Building Applications and Infrastructure in the Cloud

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

Retours sur Agile France 2013, dernière partie (en images)

Dernière ligne droite pour cet Agile France 2013 !

Pour ceux qui n’auraient pas suivi les épisodes précédents, nous avons :

Les épisodes du Jeudi :

Pour le vendredi :

Projetons-nous directement au début d’après-midi où nous avons rendez-vous avec …

Laurent Bossavit : L’art d’avoir tort

Il manquait à notre main la quatrième carte de mon carré d’as. La voici. Il ne devrait pas être la peine de présenter Laurent Bossavit qui fut non seulement un des membres fondateurs de cette conférence, mais aussi une des figures marquantes de l’agilité en France depuis 12 ans ! Evangéliste, auteur, infatigable chercheur et bien d’autres choses encore, il est aussi à l’origine de l’institut Agile qui est aujourd’hui, selon ses propres mots, plus un hobby qu’un travail.

agileFrance2013-15Bossavit01

Laurent nous promet pour cet atelier :

  • 3 exercices interactifs (en fait, nous n’en ferons que deux, pour des questions de temps).
  • 1 super-pouvoir
  • 2 sites Web
  • 1 page de pub

Commençons par une question: pourquoi la question des estimations donne-t-elle lieu à tant de discussions enflammées (pour ne pas dire plus) ? Parce que l’on voir le monde en noir et blanc !

Le but de cet atelier est de sortir de ce mode de pensée binaire pour rentrer dans une logique probabiliste. C’est aussi grâce à ce mode de pensée que l’on va pouvoir se diriger vers une logique d’amélioration en travaillant sur nos intervals de confiance.

Assez pour l’introduction. Au boulot !

1er exercice

Ce premier exercice est largement inspiré d’un exercice de Steve McConnel extrait de cet ouvrage. L’objectif est de donner des réponses aux questions posées avec un interval de confiance de 90%. Allons-y !

agileFrance2013-15Bossavit02

En tant qu’informaticiens aguerris, nous savons que nous avons tendance à être optimistes. Plus amusant : en sachant cela et sachant même que l’exercice veut montrer cela, nous donnons dans le panneau. En relevant les copies, l’interval que nous avons voulu de 90% se révèle plutôt être de 50%. Votre serviteur n’a pas échappé à la chose : je n’ai réussi qu’un médiocre 5/10 !

Quel est notre problème ? C’est ce que Laurent appelle un “problème de calibration du hardware” !

Connais-toi toi-même

Voilà donc où il faut travailler : apprendre à connaitre notre propre cerveau : MON incertitude m’intéresse plus que les faits !

Dans son ouvrage “Expert Political Judgment”, Philip Tetlock présente des tests de pronostiques politiques auprès d’experts mondiaux reconnus. Les résultats parlent d’eux-mêmes:

  • 15% des évènements qualifiés “d’impossibles” par ces experts ont effectivement eu lieu.
  • 27% des évènement jugés par ces mêmes experts “d’absolument certains” ne se sont pas produits.

Le problème est un problème de calibration de l’écart de confiance. Dans le principe, il est facile à adresser: il suffit d’élargir l’interval de confiance !

Calibration = %confiance – %fausses réponses

Second exercice

Dans ce second exercice, Laurent nous propose une série d’affirmations. Nous devons nous prononcer sur celles-ci avec un pourcentage de confiance. On jauge nos réponses en utilisant le “score de Brier” originellement utilisé en météorologie. On obtient le moins de points en donnant réponse juste avec un pourcentage de confiance élevé, mais un maximum de points dans le cas contraire.

image

Le but est d’obtenir le minimum de points. On peut connaitre notre capacité de résolution à partir de là :

Résolution = %réponse vrais / %réponses fausses

En fait, ces deux exercices nous guident vers des directions qui peuvent paraître divergentes :

  • Je suis bien calibré : je ne me mouille pas dans mes estimations
  • Je veux m’améliorer en résolution : je dois me mouiller.

En travaillant sur ces deux fronts, nous allons acquérir notre super-pouvoir : SuperGeek !

super-geek2

Conclusions et références recommandée

Pour aller plus loin, il faut travailler, comme toujours ! Laurent nous propose de le faire via deux sites :

  • Pour enregistrer et suivre nos prédictions : predictionbook ; ça, c’est pour l’approche “fun”.
  • Philip Tetlock mène des études très sérieuses à l’aide de groupe de travail. On peut s’y joindre sur goodjudgement mais c’est visiblement assez prenant.

L’un des effets de bord positif de cet approche, de l’expérience même de Laurent, est qu’elle permet de prendre de la distance par rapport à un évènement à venir. Dans le cas de Laurent, un jugement au tribunal !

Quelques références bibliographiques :

C’est vrai, Laurent nous avait aussi promis une page de pub ! Elle concerne son livre paru sur LeanPub

Pour finir, qualques posts sur la même présentation, faite cettefois-ci lors du ScrumDay :

Alfred Almendra : Un peu d’UX pour innover efficacement

Alfred nous propose un atelier pour imaginer un MVP à la Lean Startup, en utilisant un peu d’UX !

Cet atelier est inspiré d’un atelier réalisé par Ariadna Font. Nous allons avoir un temps très limité pour réaliser une première ébauche de notre MVP. Plutôt qua de rentrer dans de longues explications, jetons-nous dans le bain ! 6 étapes en tout et pour tout. Et ça rigole pas ! Enfin si, quand même un peu…

Etape 1 : La carte d’empathie

On avait le choix entre deux sujets. Je suis très fier d’avoir convaincu les personnes de mon groupe d’avoir choisi un autre sujet : nous allons réaliser Funky Shirt, un service permettant de réaliser des chemises uniques et custosmisées … et bien sûr, Funky !

agileFrance2013-16Almendra04

La carte d’empathie nous permet de parler aux émotions : ce qu’on pense et ressent, ce que l’on entend, ce que l’on voit, ainsi que les problèmes et les besoins. Nous avons 10 minutes pour cela. C’est un peu court et c’est un peu le rush.

Etape 2 : Le pitch

En utilisant le fameux “elevator statement. Il pouvait servir de base à notre pitch … ou nous pouvions utiliser autre chose. C’est ce que nous avons fait. La clé étant de mettre en avant la proposition de valeur essentielle et l’aspect différenciant.

agileFrance2013-16Almendra03

Les 10 minutes étaient aussi un peu serrées, mais c’était déjà moins la panique qu’à l’étape précédente.

Etape 3 : Prototypage

C’est une application mobile ! Donc à nous de réaliser la "landing page” de cette application, plus une ou deux autres. Mais si possible une seule autre. 15 minutes pour ça !

Etape 4 : Test utilisateur

Une personne de chaque groupe va tester l’application d’un autre groupe. Elle se tient à bonne distance, le groupe reste silencieux et observe le testeur. Celui-ci décrit à haute voix ce qu’il observe et la façon dont il réagit.

Etape 5 : Prototypage

Sur la base de ce feedback, nous avions le droit de faire 1 modifications. En fait, on en a bien fait 2 ou trois. Hum… 5 minutes de modifications et nouveau cycle de feedback !

Etape 6 : Test utilisateur

Cette fois, c’est moi qui fait le beta testeur sur un autre MVP. Une ergonomie meilleure que chez nous, je dois dire …

Ce que j’en ai pensé

J’aime bien l’idée de ces ateliers en cycle court. Cet atelier-ci était probablement un peu surpeuplé pour qu’Alfred puisse en faire une facilitation efficace. J’ai bien aimé que nous ayons essayé de développer une idée originale ! Je retiens toutefois que :

  • On pouvait essayer de travailler sur une idée existante, pas nécessairement super-originale et faire quelque chose de potable dans le timing.
  • Ou l’on pouvait essayer d’être beaucoup plus original et alors le timing devenait un peu plus contraignant.

Bien sûr, la seconde idée me semble plus porteuse, mais il aurait fallu 1,5 ou 2 fois plus de temps…

En prime, voici le support d’ariadna Font dont Alfred s’est inspiré.

Remy-Christophe Schermesser : Tester autrement, le guide du testeur intergalactique

Ca sent la fin de cet Agile France : j’ai eu du mal à me décider sur la dernière session. Et en plus j’arrive en retard, largement en retard. L’orateur a commencé depuis un bon moment.

agileFrance2013-17Tests01

Remy-Christophe nous propose de nous détacher un moment de nos problématiques de langage “tel langage se teste mieux que tel autre…” et de reflechir à l’expressivité de nos tests.

JUnit, c’est bien mais on en atteint rapidement les limites, surtout en terme de lisibilité. Et surtout en terme d’expressivité quand on veut tester un comportement.

Il y a-t-il un espoir de ce côté ? Oui, il s’appelle RSpec ! Le DSL de RSpec permet de décrire ce qui est attendu !

Autre problème : le test des combinatoires. Nécessiare à une bonne couverture, il l’est aussi au traitement des différents cas sur les tests fonctionnels. La réponse s’apelle ici : mutations ! Ecrire un test et le faire muter, cela peut se faire avec Javalanche. La création de ces mutants peut toutefois conduire à des explosions combinatoires allongeant de manière exagérée la durée d’execution des tests. Il faut tuer sans pitié les combinaisons inutiles ou redondantes.

3ème volet : le property testing. ScalaCheck permet la génération automatique de cas de tests en se basnt sur la description des propriétés au sens mathématique du terme ! A n’utiliser que pour les sections de code critique, car là aussi l’inflation des temps d’execution des tests nous guette au tournant !

This is the end

Ici s’achève pour moi l’édition 2013 d’Agile France où j’étais présent cette année en touriste. J’aimerais l’être moins l’an prochain, nous verrons ce que l’édition 2014 nous réservera !

agile-france-4-1691

Agile Playground #8 (en images) !

Pour changer un peu, l’Agile Playground de ce mois ne déroulait pas chez Valtech, mais dans les locaux de CLT Services. Un espace un peu plus réduit, donc une contrainte de places plus importante. Elle avait été fixée à une trentaine de personnes. Je m’étais dépêché de m’inscrire. Youpi, tant pis pour les autres …

3 jeux étaient en lice. J’avais fixé mon choix sur celui de Yannick Ameur

Atelier RH Team

Comment recruter agile ? Peut-on recruter agile ?

Yannick était ce soir-là le maitre de cérémonie pour ce défi !

apg8-yannick

Votre mission, si vous l’acceptez consiste à créer la fiche poste de votre job que l’on va afficher et trier.

apg8-rh2

S’en suivent les entretiens avec les candidats. Tout d’abord en mode “old school”. Avec vôtre serviteur pour être honnête… Puis en mode “agile” en faisant participer toute l’équipe.

apg8-rh4

Après, c’est le débriefing et les leçons tirées de l’exercice.

apg8-rh3

Yannick nous fait le plaisir de mettre à notre disposition le support servant de trame à l’atelier. Le voici donc.

Cocktail

On termine comme à l’acoutumée autour d’un verre et de longues discussions qui nous font toujours rentrer bien tard dans nos penates !

apg8-cocktail1

Nos discussions ont pas mal tourné autour du coaching : qu’est-ce qu’un coach agile ? Est-ce un coach sportif, un coach miroir “posture basse”, un expert, un mentor, etc… ou un mixte de ces différents rôles ? Le question est trop large pour que je m’étende dessus aujourd’hui. Un autre jour peut-être dans ces colonnes …

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 !