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

Le Mai 26, 2014septembre 7, 2016 par addinquydans Compte-rendu1 commentaire

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 !

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.

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 !

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 ?

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.

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.

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.

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.

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 !

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

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.

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 »…

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

Le Mai 22, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

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.

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 ?

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 !

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.

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 !

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 !

ScrumBeer de Mai, la rançon du succès !

Le Mai 18, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

Au fil du temps, nous avons pris quelques habitudes liées à l’organisation. Par exemple, on sait que des inscrits à la ScrumBeer, seuls 25% des inscrits viendront.

Mais le sait-on vraiment ? Car ce soir-là, ce furent près de 20 agilistes de tout poil qui sont venus envahir notre lieu de libation !

Ce lieu de libation, il fallait le mériter pour y arriver. Il se déroulait au même endroit une sorte de « speed dating professionnel » dans le domaine de la finance. Un jeune homme sapé comme l’as de pique tenait absolument à m’épingler un badge. Vainement. Je suis parvenu à y échapper !

Bien sûr, on a un peu parlé du ScrumDay qui s’est déroulé quelques jours avant. juste un peu finalement, moins que ce que j’aurais pensé. Comme souvent on finit par discuter en petits groupes.

S’améliorer avec le Lean

Avec David et Margerie, nous avons beaucoup parlé amélioration continue. David est un fervent praticien du Lean, donc nous avons nécessairement évoqué les pratiques Kaisen. Ca tombe bien, je suis en train de mettre en place des A3 en ce moment même.

Au centre du processus d’amélioration se trouve le cycle DMAIC (ou le PDCA, mais ce sont en gros les mêmes concepts).

En fonction de la situation, on peut utiliser les Toyota Kata pour les petites améliorations quotidiennes, ou le A3 pour les actions plus en profondeur. Le point de départ essentiel est de partir d’une mesure afin de factualiser le problème et bien sûr d’envisager un gain. Contrairement à ce que je pensais (et qui me posais problème), il n’est pas indispensable de fixer un objectif dès le départ. C’était une source de difficulté pur moi…

Bière suivante !

Encore une fois, je quitte ce ScrumBeer avec des reflexions et des sources d’inspiration ! Cette fois, c’est sur le « Toyota Kata » que je vais devrais me pencher (sans compter améliorer ma compréhension du A3…).

Cette fois, cette ScrumBeer exceptionnellement surpeuplée m’a fait expérimenter le mode stand-up .. il marche bien, ma fois. C’est un peu comme si nous avions été à un cocktail (il y avait d’ailleurs des Mojitos en plus des bières). J’espère que nous pourrons encore caler une petite ScrumBeer en Juin pour boucler l’année .. et le Scrum Picnic début Juillet, que nous n’avions pu faire l’an dernier pour cause de mauvais temps !

Carnet de route : Le ScrumDay 2014 (4/4), Bonus track !

Le Mai 8, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

Après avoir couvert mon parcours de ces 2 jours de ScrumDays (ici, ici et ici), une question reste en suspens : et les autres sessions ? J’ai donc été rechercher du mieux que j’ai pu les supports de présentation des sessions auxquelles je n’ai pu assister. Il en manque encore hélas beaucoup, sans compter la mise en ligne des vidéos. Si vous avez des liens vers les supports manquants, faites m’en part, je les rajouteraient.

Pour commencer, voici le livret des sessions, en mode présentation

La transformation numérique de France Télévision

France Télévision fut le premier sponsor « client final » du French SUG ! Ils nous partagent leur retour d’expérience.

Vous retrouverez aussi cette présentation via le blog d’Alain Buzzacaro.

Le Lean Startup au service du Product Owner, par Jérôme Guenver

J’ai entendu dire beaucoup de bien de cet atelier animé par Jérôme. Un atelier que Jérôme a imaginé suite à une discussion que nous avons eu ensemble chez Zenika. Je suis donc plutôt heureux d’avoir eu un petit rôle pour inspirer un collègue !

Des outils du monde de la psychologie… par Bruno Sbille

On ne présente plus Bruno, en tout cas on ne devrait plus ! Bruno est l’un des piliers de l’imposante communauté agile Belge. Il est aussi l’organisateur de l’Agile Tour Bruxelles auquel je participe depuis sa création (et j’espère continuer). Lors de ce ScrumDay, il proposait cet atelier en plus de son rôle dans la « coach clinic » !

Dans cet atelier, Bruno présentait et permettait d’expérimenter divers outils tels que la PNL, le VAK, etc. Je me souviens encore que Bruno avait fait le déplacement depuis Bruxelles pour la soirée de création du French SUG il y a 6 ans de cela. C’était justeent pour nous parler de PNL !

Let’s Sketch together, par Alvin Berthelot

L’atelier d’Alvin était articulé autour de la création visuelle de produits. Je sais qu’il le produit régulièrement, j’aimerais bien avoir l’opportunité d’y participer…

//e.issuu.com/embed.html#4983774/7715270

The big payoff, par Alexandre Boutin

J’avais eu l’occasion de pratiquer ce jeu lors des premiers Agile Game France. Alex remet le couvert pour ce très bon agile game. Vous pouvez en trouver le descriptif en anglais ici. Et mieux encore le descriptif en Français ainsi que le matériel de jeu sur le blog d’Alex.

Faites Revivre vos spécifications

Un autre sujet orienté BDD issu d’une expérience récente de Yannick. Il m’en avais parlé lors d’un déjeuner, plus tôt dans l’année. Une optique de l’acceptance testing qui diffère un peu de la mienne, mais sans être incompatible (si, si !).

Open Agile Adoption, par Pablo Pernot et Oana Juncu

Encore une session à laquelle j’aurais aimé pouvoir assister si j’avais pu me dédoubler. Too many sessions, so little time…

//e.issuu.com/embed.html#4983774/7715802

Ici, Oana et Pablo nous dévoilent (en partie) le framework de Dan Mezik.

Créer le bon produit avec le Lean Canvas, par Romain Couturier

Romain a vécu un ScrumDay mouvementé, avec une panne de sonorisation suivi d’un changement de salle. Ici Romain nous parle du Lean Startup et plus précisément de l’outil de référence développé par Ash Maurya .

Les nouveaux outils du Product Owner

Story Mapping, Impact Mapping, Lean Canvas et Kanban : ce sont les « nouveaux » éléments que nous propose Claude pour le Product Owner.

//e.issuu.com/embed.html#4983774/7715922

Agilité : la fin du middle management ? Par Kevin Maccioni et Fabien Barbaud

Avec le passage à Scrum, le retour d’expérience des deux orateurs les amènent à répondre oui !

Introduction to Visual Management, par Natalie Yadrentseva

Je ne suis pas certain de joindre ici le bon support, je l’avoue…

Certains éléments de cette présentation me rapellent furieusement le Lightning Talk d’Igor Sviridenko à l’Agile France 2013…

Devops Game, par Vincent Daviet

Le troisième atelier Zenika de ce ScrumDay nous était proposé par notre nouveau venu Lyonnais avec ce Devops Game que je n’ai hélas pas pu expérimenter.

Podojo : PO, viens t’améliorer par la pratique avec nous ! Par Guillaume Duquesnay et Nicolas Verdot

A défaut d’un support de présentation, voici une petite vidéo avec une interview de Dominique Lequepeys sur cet atelier

Le Product Owner est-il un Product Manager agile ? Par Sébastien Saccard

Sébastien Saccard n’est pas un inconnu pour moi : tout d’abord il fut à l’initiative du workshop d’Ash Maurya à Paris, ensuite en tant que président de l’association We Do Product Management, il fut à l’instigation de la rencontre avec Gojko Adzic hébergée chez Zenika.

Sébastien cherche à développer le métier de Product Manager en France. Sa présentation va dans ce sens.

Vous pouvez aussi retrouver la présentation de Sébastien sur son Blog.

Agile-Lean-Kanban : Le guide du routard 2014, par Christophe Keromen

Bien rodée, j’avais eu l’occasion d’assister à cette très vivante présentation de Christophe à l’Agile Tour Rennes 2013. Mais était-ce réellement la même ?

My Product is a James Bond Movie – part V, par Pierre Neis

Les présentations de Pierre ne ressemblent à rien de connu ! Elles sont difficile à raconter, et je doute que le support ci-dessous lui rende justice. J’avais assisté à la « part I » de cette série « James Bond Movie » lors de l’Agile Tour Bruxelles 2013 … nous voici rendu au 5ème opus !

Développer en mode Kick-Ass, par Samuel Le Berrigaud

Le Kick-Ass de Samuel, cela me fait penser au « programming motherfucker » ! D’ailleurs en fait, il en parle dans sa présentation. Je vous recommande ce support pas mal du tout … en attendant la vidéo !

De la culture projet à la culture produit, par Céline Stauder et Gregory Alexandre

La présentation de Céline et Grégory est tout à fait dans le thème de ce ScrumDay. Par contre le support ne vous permettra guère de saisir la substance de la présentation !

Le prétotyping, avec Elalami Lafkih

Le prétotyping, c’est du prototypage « low cost », plus tôt donc avec un feedback anticipé. Elalami nous en expose un certain nombre de techniques. J’ai repris le support de l’orateur utilisé durant l’Agile Tour. Je suis parti du principe qu’il s’agissait du même…

Kapla Challenge, avec Dragos Dreptate

Construire un pont par itération (avec des Kapla), c’est le challenge que nous propose Dragos durant cet atelier

Faire Agile, c’est bien…, par Aurélien Morvant et Simon Jallais

Simon et l’homme aux chaussures de couleurs différentes nous proposent de découvrir ce qu’est « vivre agile ». Une session plutôt décalée !

DSL et refactoring pour les tests d’acceptation, par Laurent Py

Laurent nous fait partager son expérience ATDD / Devops chez Smatesting. En fait, la session ressemble terriblement à une promotion de l’outil Zest’ qui est, oh surprise, développé par la société dont Laurent Py est CEO !

Bon, voici quand même cette présentation…

Les reportages du ScrumDay

Une petite séquence « fun », tournée en bonne partie durant la pause déjeuner du second jour.

Et le reportage du ScrumDay, avec quelques interviews et des interventions de Xavier Warzee et Alistair Cockburn

Ils en parlent aussi…

Quelques liens vers des articles de blog que j’ai peu glaner à droite et à gauche. Si vous avez d’autres liens, n’hésitez pas à m’en faire part.

Il y avait une Coach Clinic, mise sur pied par Fabrice Aimetti et Bruno Sbille. Côté Zenika, Géry Derbier y participait ainsi que Laurent Sarrazin pour Rupture 21. Un compte-rendu est disponible sur le site d’Ayeba.

Alex Boutin nous livre sur son Blog la manière dont il a vécu ce ScrumDay.

Un retour de Laurent Sorin sur la table ronde menée par Véronique Messager

Autre retour également en provenance d’Ippon, un feedback sur la session de Rachel Davies par Victoria Pedron.

Dominique Lequepeys nous adresse les points forts des sessions auxquelles il a participé. Youpi, ceci inclut la mienne !

Christophe Deniaud fait aussi son billet de Blog sur les sessions qu’il a vu, ainsi que sur l’open-space. Lui aussi donne son feedback sur mon atelier. Pas sûr que mon message principal sur l’écriture collaborative des tests soit bien passé…

Coactiv nous livre aussi ses retours.

Carnet de route : Le ScrumDay 2014 (3/4)

Le Mai 4, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

Nouvelle journée, nouvelle énergie. Après la journée conférence que je vous ai comté ici et ici, voici la journée consacrée à l’open-space, à l’image de ce qui se fait à Grenoble depuis quelques années déjà.

L’organisation met à notre disposition tout ce qu’il faut pour se remettre dans le rythme : thé, café, jus de fruits, viennoiseries…

Mais on est vite intrigué par le grand cercle matérialisé à même le sol autour duquel nous sommes invités à nous rassembler pour débuter cet open-space.

Ce sont Laurent Bossavit et Raphael Pierquin qui se chargent d’expliquer les règles de fonctionnement de l’Open-space … ou du moins tentent de le faire ! Apparemment, la sonorisation pose quelques problèmes…

Le principes sont en fait assez simples. Une fois établis, il est temps d’utiliser le matériel mis à notre disposition au centre du cercle pour proposer nos sujets.

Ces sujets sont ensuite eux-mêmes affichés sur les différents créneaux horaires en mode auto-organisé. C’est la « place de marché ».

J’ai posté mon propre sujet. Il est temps de faire le tour de ceux qui peuplent le premier créneau horaire. Et je reste un peu perplexe devant le sujet traitant de l’utilisation des points de fonction dans les projets agiles. Quand je vois ce genre de sujet, mon reflexe est de me demander en quoi ces techniques peuvent nous apprendre quelque chose, si la technicité développée ici peut nous aider. Laurent Bossavit semble plus circonspect quand aux motivations. Du coup, nous décidons tous deux de nous joindre à ce débat.

Agilité et point de fonction

La première chose qui me trouble est une certaine confusion entre l’outil et l’usage. Dans l’esprit de beaucoup, il y a une relation directe entre projet au forfait et point de fonction.

En fait, il semble même que nous ayons un pattern d’usage : on se sert des points de fonction comme outil « commercial » pour chiffrer une réponse à appel d’offre. Ensuite, lors de la réalisation, on se servira des story points. Voilà un constat assez troublant pour moi, bien qu’instructif sur la vision que l’on peut avoir des différents outils :

Les points de fonction sont vus comme un outil donnant un chiffre absolu, alors qu’il donne un chiffre relatif (les points) qui se transforment en charge via des facteurs d’ajustements. Comme les story points, en fait, bien que de façon plus complexe.
Quel est l’intérêt de faire un « chiffrage agile » si en amont le projet est de toute manière verrouillé par un chiffrage contractuel ? Je dirais même : quel est l’intérêt de faire le projet en agile, mais c’est sûrement une autre question…

La discussion s’est beaucoup focalisée sur l’usage de l’une ou l’autre approche, alors que je pense que la question n’est pas là : on peut parfaitement utiliser les FP ou les story points dans les mêmes contextes.
Par contre les points de fonctions traitent des « blocs » plus gros, qui sont ensuite décomposés sous l’angle technique (requêtes, entités, I/O, etc…), alors que les story points s’adressent à des blocs plus fins que l’on évalue globalement, en différent les questions sur les choix de conception. Par son approche les points de fonction « vérouillent » les choix techniques dès le chiffrage.

J’ai été assez déçu par le débat qui ne s’est finalement pas dirigé vers la question de la nature de ces différents types d’estimation (ce que j’évoque plus haut). Dommage…

Ressources Humaines et agilité

Ce sont à la fois l’originalité du sujet et son importance qui m’ont attiré vers ce groupe. Une groupe à coloration un peu « grandes gueules » avec Pablo Pernot et Pierre Neis, par exemple !

Tout d’abord, quels sont les problèmes ?

La gestion du parcours professionnel.
La gestion des évaluations.
La dissonance cognitive entre rôle et fiche de poste.

Le constat partagé par tous est qu’aujourd’hui les RH ne sont pas une aide au sein des projets agiles. Dans le meilleur des cas. Dans le pire des cas, elles sont un frein, voir un obstacle. Bref, il n’y a pas grand monde dans le cercle à aimer les RH. On entend même que les RH n’ont pas de raison d’être !

Mais il nous faut aussi admettre que l’on doit mieux comprendre le problème des RH : celui de devoir composer avec la loi, le management, les syndicats, le C.E., etc… En fait, il nous semble que leur effort porte plus sur la composition de ces contraintes que sur une véritable fonction support au sein de l’entreprise (ce serait plutôt un fonction contrainte !). Le mécanisme des entretiens annuels est bien entendu montré du doigt.

Alors, quelle solution pour la RH dans un environnement agile ?

C’est que cette RH devienne elle-même agile, en portant les valeurs agiles au niveau de l’entreprise. Entre autre choses.

Pause déjeuner

Pas de pause déjeuner bien calée dans le temps pour cette journée open-space ! Les session occupent les créneaux horaires sans discontinuer. Aux participants de faire une pause quand ils le désirent !

On est un peu plus en mode picnic que la veille, d’ailleurs les tables ont disparu au profit de quelques « mange debout », mais on s’assoit aussi par terre.

Cela ne veut pas dire que la qualité n’est pas au rendez-vous. Au contraire ! Je n’ai aucune raison de renier mes éloges d’hier. Jugez-en !

De mon côté, j’ai passé cette pause déjeuner avec Pierre Hervouet, Joumana et Pierre Neis. Pierre Neis nous parle (et nous montre des photos) de #play14, un rassemblement autour des agiles games qu’il co-organisait au Luxembourg. Prochaine étape : en faire une sorte d’Agile Tour des agile games !

Le bureau du SUG en mode Happy

Christopher Mann était le photographe de ce ScrumDay (il avait fait un excellent boulot lors d’Agile France, une bonne raison pour moi de le recommander pour cet évènement). J’ai suivi le mouvement, quand lui-même et le bureau se sont dirigé vers l’extérieur pour ce qui semblait une photo de groupe. Le résultat est visible sur le reportage du ScrumDay, mais j’ai aussi pris mes propres clichés…

Backlog, cher boulet…

J’avais aussi soumi mon propre sujet. En quelque sorte une reprise d’un de mes thèmes préférés sur le backlog produit, à la fois vision de ce qu’il y a à faire et frein du changement.

Au final, on trouve deux grand types de situation :

Les projets agiles « classiques » où la vision d’un périmètre complet est plutôt une chose souhaitée. Le backlog Scrum rempli bien son office car il donne une vue partagée à tous les acteurs du « reste à faire ».
Les projets innovants pour lesquels on essaie de limiter le stock par diverses approches (parfois combinées) : approche type « kanban » où l’on limite volontairement et activement le nombre d’items dans le backlog, où backog à granularité différentielle, à deux ou trois niveaux.

Dans le cas d’une approche « kanban » nous nous sommes posé la question d’évacuer, c’est à dire supprimer les items de plus basse priorité dépassant le WIP. Nous en sommes arrivés à la conclusion qu’il n’y a aucun dommage à le faire : si l’item est important, il reviendra !

J’ai aussi évoqué les sujets qui m’interpellent en ce moment : combiner un backlog (limité) avec une approche type impact mapping et/ou Lean Canvas. Mais nos réflexions n’ont pour l’instant pas abouti…

Clôture des ScrumDays

Ce grand open-space s’est terminé par une retrospective type « tour de parole ». Un tour de parole à près de 200 personnes, il faut dire !

Il me manque le courage (ou la motivation) pour en être. Je préfère passer un peu de temps avec Samira Batahouche d’IBM qui représentait Big Blue au bureau l’an dernier et avait accueilli le ScrumDay à Bois Colombe l’an dernier.

Le stand de Cloudbees est juste à côté, j’en profite pour fixer pour la postérité Nicolas De Loof en hôtesse d’accueil…

Scrum.org était aussi partenaire du ScrumDay cette année. Je me suis vu interdire de prendre le stand en photo, une première pour moi. J’ai moi-même étendu cette interdiction à la keynote de clôture faite par son représentant (je ne me souviens même plus de son nom, pourtant il s’est cité lui-même durant sa présentation).

J’avais aussi décidé de ne prendre aucune note de l’intervention pour faire bonne mesure. Grand bien m’en a pris : elle manquait complètement d’intérêt, j’ai failli quitter la salle. Finalement je suis resté et j’ai consulté mon fil Tweeter pendant le reste de la présentation.

Si j’étais parti, je n’aurais pu prendre en photo l’équipe du French SUG, et cela aurait vraiment été dommage. Grand merci à toute l’équipe pour ce bel évènement ! De droite à gauche : Anne, Christopher, David, Arnaud, Valérie, Karine, Laurence et Xavier.

Voilà, il est temps de replier tous le matériel, et de tout remettre dans les cartons … jusqu’à l’an prochain.

Note à moi-même

Pour ce qui est du format tout d’abord : le ScrumDay (ScrumDays, donc comme je l’ai écrit par ailleurs), ça marche ! Les open-spaces dans des « coins de salle » ne sont toutefois pas une configuration idéale. il faudra trouver mieux et surtout moins bruyant !

Cette année, le thème était la « culture produit ». En fait cela ne me paraissait pas si évident au vu du programme. Maintenant, est-il nécessaire d’avoir des thèmes annuels ? Des tracks thématiques feraient assez bien l’affaire.

Concernant le lieu, eh bien il a clairement la taille voulu pour accueillir l’évènement. Le hall central (qui hélas n’était pas central) permettait une bonne circulation. Les stands des sponsors étaient disposés sur le pourtour.

Question sponsors, leur nombre était réellement à l’inflation, et cela fait un peu ressembler le ScrumDay à une expo (sans compter un traitement pas différentiant des platinums) … La raison est bien entendu le coût d’organisation, car le lieu est apparemment très cher, malgré son éloignement de Paris.

J’avais crains que cet éloignement, justement, soit une cause de désaffection, d’autant que la venue en voiture n’est pas vraiment facilitée (pour ne pas dire franchement découragée), mais il semble au final que ce facteur n’ait eu aucune influence.

Bref, un bel évènement, avec deux fois plus de plaisir pour deux fois plus de durée !

Une dernière chose : nous n’en avons pas fini avec ce ScrumDay : je vous ai promis un 4ème volet : ce sera un « bonus track », je n’en dis pas plus. Je ferais aussi un petit post sur mon atelier sur l’acceptance testing.

Carnet de route : Le ScrumDay 2014 (2/4)

Le Mai 2, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

Je vous avais laissé au moment du déjeuner. La pause n’aura pas été si longue. Sur le créneau suivant, j’ai coché la session de Véronique Messager sur mon programme.

En tant que Scrum Master, je veux m’améliorer pour mieux coacher mon équipe

Cette session de Véronique Messager, n’en est pas une : c’est une table ronde à laquelle elle a convié des Scrum Masters allant du néophyte à l’expérimenté, qu’elle-même coach chez Orange. Cet aréopage de Scrum Masters vient partager avec nous leurs points de vue sur leur travail, leurs manières d’aider les équipes et leurs sensibilités qui peuvent varier.

Le contexte

A l’origine, il y a un groupe d’échange de pratiques se réunissant tous les mois. Le produit de ce groupe d’échange est aujourd’hui une check-list de 52 bonnes pratiques. Véronique nous propose de les aborder regroupées en 3 thèmes, avec le panel de Scrum Masters. Hélas, les contraintes de temps nous limiteront à deux de ces thèmes.

Le changement dans la posture du Scrum Master

Un premier constat partagé est la perte de connaissance sur le code ! Le travail de Scrum Master tient ceux-ci de plus en plus éloigné de cette matière première. De cette perte de connaissance nait un certain sentiment de culpabilité : Suis-je toujours légitime dans mon rôle ? Le travail du Scrum Master n’est pas quantifiable, il n’est même pas visible car il n’a pas de raison d’être évoqué en stand-up. Une crainte qui n’est pas nécessairement étayée : il n’y a guère de remarques sur le fait que le Scrum Master développe beaucoup moins.

Malgré tout, le Scrum Master peut-il continuer à développer ? Les avis sont un peu plus partagés, mais des « oui » s’élèvent, toutefois tempérés :

Pas question de prendre des tâches critiques ! A cet égard, binômer ou prendre en charges des corrections d’anomalies s’avèrent de bonnes idées.
En tout état de cause, les tâches de Scrum Master doivent rester prioritaires.
Rester impliquer dans le développement peut induire un travers de partialité lorsque des discussions s’engagent sur l’architecture, les solutions, etc. Il faut y prendre garde.

La maturité de l’équipe allant croissant, peut-on un jour se passer de Scrum Master ? Une question réccurente, que l’on a aussi trouvé sur Quora. Ici la réponse est unanime : non, le Scrum Master reste indispensable !

Par contre la question reste ouverte sur le Scrum Mastering à temps plein ou à temps partiel ! Si certains par ailleurs pensent qu’au final ce rôle peut tourner (ce que j’ai expérimenté), Bruno Margueritat ne suit pas cet avis, par exemple.

Motiver les membres de l’équipe

Comment s’appercevoir que cette motivation baisse ? En regardant la productivité de l’équipe (donc les « retards »). Véronique a une affinité particulière pour la Process Com, il n’est donc pas étonnant que les Scrum Masters présents évoquent cet outil pour comprendre le fonctionnement des membres de l’équipe.

Ils évquent aussi le temps libre : l’importance d’en ménager (par exemple entre les itérations), mais aussi d’observer comment ce temps libre est utilisé.

Donner du sens et visualiser l’avancement : c’est bien entendu un leitmotiv bien connu et pourtant souvent négligé. Mais il s’agit aussi d’impliquer activement les membres de l’équipe. Pour l’un des Scrum Masters cela passe par la délégation d’une partie des tâches … du Scrum Master ! Par exemple lors des rétrospectives. J’aime bien l’idée et l’état d’esprit !

Ce que j’en ai pensé

Nombreux sont les experts prêts à nous expliquer le rôle et la posture du Scrum Master. Tous ces experts ne sont d’ailleurs pas tous d’accord entre-eux (j’en fais partie !). Ici, ce ne sont pas des experts, mais des vrais praticiens de terrain avec différents niveaux d’expérience et une certaine variété de point de vue.

Du coup, je pense que l’échange aurait pu être encore plus riche avec des Scrum Masters venant d’autres horizons. Les débats auraient été plus intense, ce qui ne serait possible qu’avec un format un peu plus long toutefois.

La culture du programmeur, par Jean-Laurent de Morlhon

J’avais une double raison d’assister à cette session : tout d’abord J’aime bien Jean-Laurent qui est aussi un ancien collègue (double ancien collègue, devrais-je dire). Et ensuite le sujet éveille mon intérêt, même si ma propre crédibilité en tant que programmeur s’étiole certainement de jour en jour… Jean-Laurent est certainement la bonne personne pour transmettre cette culture, sans compter l’humour et le dynamisme qu’il met dans ses interventions. Celle-ci ne fera pas exception !

Pourquoi programmeur ?

Jean-Laurent nous explique quel était son plan pour devenir maître du monde et partir à la retraite à 35 ans. Cela n’a pas marché. Pour moi non plus, d’ailleurs. Car sa passion c’est programmeur (qu’il préfère à « développeur » ou « codeur »). Donc c’est « programmeur ». Et ça veut dire quoi ? Le Larousse dit qu’il s’agit « d’une personne de la préparation, de l’écriture et de la mise au point d’un programme pour ordinateur ». Pour les personnes en-dehors de notre domaine, ils sont souvent perçus comme des personnes aptes à faire des choses mystiques (t’es dans l’informatique ? Tu peux m’aider à brancher mon imprimante ?).

Mais hélas, dans notre milieu professionnel, nous sommes confrontés à un problème de jeunisme. Programmeur n’est pas considéré comme un métier au-delà d’une certaine tranche d’âge. Pour de nombreuses entreprises et écoles, l’évolution normale du programmeur est de devenir chef de projet !

Une culture

La culture, c’est ce qui lie les gens entre eux. Quels sont donc les éléments de cette culture ? L’une d’entre-elle est le « craftmanship ».
C’est avant tout une attitude de pragmatisme, un rééquilibre entre processus et technique. C’est aussi un état d’esprit d’amélioration qui passe par l’entrainement (les dojo, les code retreat, les kata). C’est évidemment utiliser les ressources en ligne : les MOOC sont partout, sur tous les sujets. La culture du programmeur, c’est aussi :

Disposer des meilleurs outils que l’on puisse acheter : aujourd’hui, c’est disposer de grands écrans, de CPU puissants, ne pas être limité par la mémoire, booster les I/O avec des disques SSD, des environnements d’intégration, les bons IDEs, etc..
Vivre en permanence avec de la frustration : nous passons un temps considérable à essayer de faire marcher des trucs … ou à essayer de comprendre pourquoi ils ne marchent pas !

Ce que j’en pense

Une session de « J-Lau », ça vaut toujours le déplacement. Certes, je n’y ai pas appris grand chose, mais je n’étais pas non plus le public visé. Mais la présentation fait un très bon boulot à faire toucher du doigt cette culture du développeur. A voir absolument pour les PO / MOA / Managers à qui sont étranger ces aspects.

Acceptance Tests Workshop

Voilà, c’est mon tour ! J’avais préparé cet atelier avec Benoit Nouyrigat afin de transmettre par la pratique un aspect du développement agile qui nous semble avoir un impact crucial : l’écriture de tests d’acceptance collaborativement entre les différents intervenants d’un projet. Nous avions donc structuré notre atelier en petites équipes, l’atelier lui-même nous conduisant depuis l’écriture de user stories sur notre étude de cas jusqu’à l’implémentation des acceptance tests en BDD avec Cucumber JVM !

Je ne vais pas détailler l’atelier ici, je réserve cela pour un futur post !

Ils ont aimé

Clarifier les specifications en les « instanciant » avec des cas de test.
Découvrir les cas aux limites qui font émerger des règles métier.
Travailler collaborativement autour des cas de test.

Ils pensent que l’on peut améliorer

La phase initiale, avec l’écriture des user stories par les équipe qui apporte peu.
L’absence de temps pour s’approprier les persona.
La brièveté du temps consacré à la partie « outils ».

Ce que j’en pense

Nous devons ajuster certaines parties, c’est tout à fait normal, compte tenu qu’il s’agissait d’une première. Je pense toutefois que les conditions ne nous ont pas permis de juger de l’atelier de manière adéquate : nous avions été programmé en toute fin d’après-midi (avec en plus un démarrage en retard), ce qui équivaut pratiquement à une garantie d’échec pour un atelier très intense comme celui-ci.

La première heure s’est très bien passé, mais la fatigue a rattrapé le groupe dans la seconde. En fait, je suis plutôt satisfait d’avoir eu une bonne moitié d’atelier, car je m’attendais à un échec complet. Les participants se sont même déclarés très satisfaits !

J’aimerais toutefois pouvoir jouer cet atelier dans de bonnes conditions pour avoir un meilleur aperçu de son impact.

Nous avons joué l’écriture des acceptance tests en deux temps, avec ou sans le style « given when then », mais nous n’avons pas donné d’indications suffisantes pour marquer la différence. A retravailler.

Une certaine déception de Benoit et moi-même sur la demande d’avoir plus sur la partie outil ! Notre expérience commune est que la différence se fait dans l’écriture collaborative (d’ailleurs la collaboration est à gauche et les outils à droite, si vous voyez ce que je veux dire…). Soit nous ne sommes pas parvenus à être assez marquants sur l’importance de cet aspects, soit notre public est incorrigible sur l’idée que les outils sont ce qui importe le plus. Nous avons là un sujet de reflexion pour la version 2.0 de notre atelier…

Le diner

J’ai fait l’éloge du lunch du midi, je dois les mêmes au diner auquel j’étais convié n tant qu’orateur. C’est bien sûr une belle occasion d’échanger avec les membres de la communauté…

… Ainsi qu’avec les joyeux membres du bureau.

J’ai aussi passé un très agréable moment avec Alex Boutin, à échanger sur ce que l’un et l’autre nous aimons faire, les questions que nous nous posons… Alex est l’une des personnalités de la communauté agile que j’apprécie le plus, pour son sens du partage et de l’invitation. Je n’en apprécie que plus ce genre d’opportunités.

Il est maintenant temps de retourner dans mes pénates. Rendez-vous bientôt pour la seconde journée de ces Scrum Days !

Carnet de route : Le ScrumDay 2014 (1/4)

Le avril 27, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

Bienvenue au ScrumDay 2014 !

Cette édition sera particulière pour moi : c’est la première où je ne fais pas partie du comité d’organisation ! Certes, j’y aurais ma session, mais je vais faire mon possible pour profiter pleinement de ces deux jours, et vous en faire bénéficier maintenant !

Pour tout dire, ça commence par un peu de galère : Xavier Warzee voulait depuis longtemps organiser l’évènement chez Disney. C’est loin et cher (le prix de la conférence triple donc au passage), mais mon statut de conférencier me donne accès à la conférence « full package », celui qui vaut 290 € ! Reste l’accès. Venir en voiture s’avère plus galère que si nous avions été en plein Paris, j’opte pour le RER.

L’accès est un rien compliqué, mais le SUG a tout prévu : Pascal est là pour nous accueillir dès la sortie de la gare !

N’oublions pas que chez Mickey on est presque aux états-unis, le délit de sale gueule existe encore. Pour moi, c’est fouille minutieuse à chaque contrôle de sécurité. Même avec une certaine habitude de la chose, ça ne me met pas spécialement de bonne humeur. C’est dommage d’autant que le French SUG n’y est pour rien. Mais si c’est au même endroit l’an prochain, ce sera probablement sans moi.

Je découvre le centre de conférence en arrivant : vraiment très spacieux (et même un chouia labyrinthique), quand au hall principal…

Le temps de prendre un café et d’échanger avec les amis, nouveaux ou anciens, l’heure est vite passée et nous sommes attendus dans la salle où se dérouleront discours d’ouverture et keynote.

Ouverture du Scrum Day

Rameuter Presque 500 personnes, ça prend du temps, on va donc débuter avec un peu de retard. Que du classique pourrait-on dire.

Comme il est de coutume, le président du SUG ouvre ce ScrumDay ou ScrumDays, devrai-je plutôt dire.

On retrace un peu d’histoire, quelques chiffres et surtout on présente le déroulement de ces deux jours, le maître de cérémonie de la seconde journée sera Laurent Bossavit, épaulé de Raphael Pierquin pour un grand open-space, à l’image de ce qui se fait à Grenoble.

On termine cette ouverture par le mot des sponsors. Les sponsors ! Il y en a 17 ! C’est certainement un record, en tout cas c’est un marathon de les écouter tour à tour.

Laurent Delvaux ouvre le tir pour Zenika, et j’ai vite perdu le compte. Mention spéciale pour le représentant de HP France qui nous a gratifié d’une introduction au style humoristique bien enlevé !
Heureusement, on va maintenant enchainer sur la keynote.

Alistair Cockburn : What’s new with agile ?

J’étais curieux de voir ce dont Alistair allait parler. Après tout, j’ai l’habitude de l’entendre parler d’agilité, ou comme dirait Géry Derbier de jeu de coopération et collaboration. En fait, il commence par évoquer les personnes … et les difficultés que nous avons face aux problèmes et à nos décisions. C’est un préambule au manifeste agile dont il est l’un des signataires.

Mais pour parler de Scrum, Alistair évoque le Shu Ha Ri ! Curieusement, c’était le sujet de ma présentation à Caen il y a 3 semaines, je suis tout ouï. Si vous l’ignorez, il s’agit des 3 niveaux de maturité en agile, emprunté par Alistair aux arts martiaux, à l’Aikido pour être plus précis.

Le Shu est le niveau initiatique. Le Shu c’est copier la technique sans en dévier. Hélas, nombre de personnes tombent amoureux du Shu et ne le quitte jamais…
Le Ha est le perfectionnement, il signifie « cassure ». Dans le Ha, on collectera nombre de techniques utiles.
Le Ri est le niveau de la maîtrise, c’est littéralement l’abandon. On invente, mixte ses propres techniques.

Core Scrum

Scrum n’est pas fondamentalement du niveau Shu, il est du niveau Ri. Et au niveau Ri, le « core Scrum » se définit ainsi :

Délivrer à chaque Sprint (plutôt que démontrer)
Laisser l’équipe décider (en assignant une tâche)
Inspecter et adapter à chaque Sprint

Ca c’est l’esprit du Scrum. Autour de cela, gravitent des rumeurs ou des freins (Alistair parle de balanes).

Les « balanes » sont tous ces éléments de Scrum, des éléments « Shu » sur lesquels on se focalise alors qu’ils n’ont qu’une importance secondaire :

Le burndown chart : il n’est pas essentiel, faites-le si vous en avez envie, d’ailleurs il ne fait plus même plus partie des éléments « obligatoires du Scrum Guide !
Le Scrum Board : Doit-on en faire un ? A quoi doit-il ressembler ? L’équipe décidera.
Le Scrum Master est-il un chef de projet ? Un tech Lead ? Cela dépendra du contexte.
Le Product Owner doit-il assister au stand-up ? Laissez l’équipe décider !
Les 3 questions du stand-up : ce peut être une aide, mais pas un dogme !

Rumeurs et ouïe dire, ou les « lutins » comme dirait Laurent Bossavit:

Les User Stories : Elles ne font pas partie de Scrum, elles ont été créées avec XP. Scrum n’oblige pas à utiliser les stories.
Le Planning Poker : Cette pratique vient également d’XP ; si elle convient, alors utilisez-la !
La suite de Fibonacci / les story points : Ce ne sont pas non plus des pratiques spécifiquement liées à Scrum. Tirez-en parti si vous aimez.

Le « big agile »

Alistair évoque pour commencer le framework SAFe. J’avoue y avoir porté peu d’intérêt, bien que ce soit un sujet dont on parle en ce moment. Je m’attendais à voir Alistair le démonter, mais non ?!?

Quand on parle d’agile en grand en ce moment, on évoque souvent Spotify autour duquel Henrik Kniberg communique beaucoup en ce moment. Ce qu’il appelle l’organisation 3D semble aussi une référence pour Alistair. Et qui dit grande organisation dit dépendances : l’architecture du système doit prendre en compte cet aspect afin de rendre le déploiement asynchrone.

Disciplined learning

Le dernier point évoquer par notre keynote speaker est l’un de ceux qui lui tiennent beaucoup à coeur : l’apprentissage. Alistair oppose le « big bang » synonyme d’apprentissage tardif d’un apprentissage au plus tôt (ou réduction des risques, mais l’emphase sur l’apprentissage n’est-il pas préférable ?). Cette courbe n’est d’ailleurs pas une courbe, mais une espèce d’escalier, car tous les progrès ne se valent pas et certaines expérimentations d’avèrent stériles. Géry Derbier évoque souvent la chose quand il anime le Carpaccio Game : il y a 4 dimensions d’apprentissage sur un projet :

Business (ce volet pouvant lui-même avoir différents axes, et pas seulement le ROI).
Social (la formation de l’équipe).
Technique
Coût / délais (découverte de la vélocité, par exemple).

Cette façon d’appréhender le projet permet de le borner (trim the tail), soit par la date, soit par la valeur.

Ce que j’en ai pensé

Peut-être Alistair Cockburn n’était pas aussi percutant qu’il nous en a donné l’habitude, mais s’agissant du Scrum Day il nous a livré une keynote s’articulant autour du Scrum, du vrai Scrum ! Je ne peux qu’apprécier le propos faisant écho à ma propre présentation du Printemps Agile, bien sûr, mais surtout je trouve important de mettre en exergue les aspects importants de Scrum (le Scrum Core), par rapport aux choses secondaires qui sont celles sur lesquelles se focalisent souvent les détracteurs de Scrum !

//e.issuu.com/embed.html#4983774/7625512

Romain couturier nous a aussi gratifié d’un « scribing » de la session d’Alistair. Il a bien voulu le partager avec nous, et je m’incline devant son talent !

Nous avons déjà pris un peu de retard sur le timing, le changement de salle est un tout petit peu serré. Pour moi, le choix de la session suivante était déjà fait.

Coaching Teams Through Change, par Rachel Davies

Rachel Davis est l’auteur d’un des quelques ouvrages disponibles en rayonage sur le coaching agile. Un ouvrage que j’avais trouvé correct sans être fantastique. Le sujet de cette session lui, me fait plutôt penser au Fearless Change !

D’abord, quel est le plus grand obstacle au changement ? Bien entendu : la résistance ! Alors certes, on voit beaucoup de choses à faire … tellement à faire et si peu de temps ! Mais la première précaution est justement de ne pas se précipiter !

Communiquer

Choisir ses mots avec soin (en fonction du canal de votre interlocuteur, comme dirait Véronique Messager). N’oublions pas de nous mettre à la place de notre interlocuteur : ce que nous voulons dire correspond rarement à ce que nos interlocuteurs veulent entendre !

La communication, c’est aussi un processus bidirectionnel. N’oublions pas l’écoute, en fait, commençons par cela. Une bonne écoute c’est :

Absorber de l’information
Rester calme et attendre.
Encourager l’interlocuteur.

Voilà qui me rappelle la session de Florence Chabanois à l’Agile France 2013.

Leadership

Et ceci me rappelle à nouveau le Fearless Change. On y trouve plusieurs idées:

Aller parler aux sceptiques : comprendre ce qui les retiens est le premier pas vers la compréhension des faiblesses de notre message. De plus les sceptiques ne sont pas des opposants, du moins pas nécessairement. Ils peuvent même s’avérer être à terme vos plus ardents défenseurs.

Plusieurs facteurs peuvent influencer le refus de suivre :

La difficulté
La permission
Le (mauvais) timing
Ce n’est de toute manière pas mon idée !

L’exemplarité: Pour inciter les autres à suivre, commencer par faire vous-même. Vous voulez mettre en place un Kanban ? Utilisez déjà un « personal Kanban ».

Traiter les problèmes

Les rétrospective sont là pour les mettre en évidence et dresser des plans d’action. Mais plus encore, rendons les problèmes visibles tous les jours en les affichant !

Ce que j’en ai pensé

Pour être franc, j’ai eu du mal à m’enthousiasmer pour cette session un peu fourre-tout, avec un fil conducteur un peu difficile à saisir ! Bref, un peu déçu, je l’avoue…

Sébastien Ferron a publié un excellent post sur cette session sur le blog de SOAT.

Pollénisation croisée avec la communauté des designers ?

Pierre Hervouet et Joumana Mattar nous proposaient cette session. Si l’audience était nettement plus réduite qu’avec Rachel Davies, le contenu… eh bien j’ai préféré cette session, voilà !

Pourtant je suis venu sans trop savoir à quoi m’attendre. Mais j’avais aimé la session que Pierre avait animé avec Pascal Van Cauwenberghe à Agile France 2013. Je l’ai donc suivi ici.

Pierre vient ici avec une étiquette « Agile Lebanon », et il venait nous parler du Global Service JAM !

Le Global Service JAM, c’est une sorte de Startup Week-end pour les designers : une unité de lieu et d’action pour 48 heures, et pour sortir avec un produit ! Le JAM s’organise sur 3 jours.

1ère journée : Open minder

Au programme : ice-breaker, brainstorming et agile games !
On explore l’espace, on répartit des idées sur une table (cela offre une meilleure circulation qu’un mur) et on met l’utilisateur au centre en utilisant des personas.

A ce stade, on ne sait pas encore ce que l’on va construire !
Une première journée jugée très positive par Pierre et Joumana. Avec un outil atypique : l’unstuck jarre, remplie de questions perturbantes quand on est en panne…

2nd journée

Beaucoup de choses dans cette seconde journée ! En fait tellement d’outils que Pierre et Joumana nous ont distribué un jeu de cartes les rassemblant tous ! Voilà, vous n’aviez qu’à être à cette session !

On va donc y trouver pêle-mêle :

Get out of the building : à l’image du Lean Startup Machine, pour aller valider son concept dans la rue !
Des energizers
Le bottleneck game de Pascal Van Cauwenberghe et Portia Tung, pour introduire l’amélioration continue
5 focus steps !
La carte d’empathie pour explorer les personas. A l’image de ce que l’on fait en Lean Startup.
Le User Journey map pour explorer l’expérience utilisateur via du story telling.
Le PoP (prototyping on paper).

3ème journée : stress et deadline

A la fin de cette journée, il faut livrer !

Ce que j’en ai pensé

Beaucoup de choses dans cette session, j’ai la sensation d’en avoir raté la moitié. Au moins ! Cela m’a permis d’explorer un concept que je ne connaissais pas et je repars donc avec pas mal de pointeurs à investiguer !

Si l’aventure du Global Service JAM Libanais vous a intéressé ou intrigué, vous pouvez les retrouver sur leur Blog Tumblr.

Il est bientôt l’heure du déjeuner. En passant, je vois Romain qui termine sa session.

Déjeuner

Disons-le tout net : ce ScrumDay est de loin celui qui m’aura laissé la meilleure impression sur cet aspect : on a de la place et plusieurs buffet sont disposés de manière à ce que l’on ait jamais besoin d’attendre très longtemps. Les plats sont diversifiés et de qualité, et l’on peut s’assoir pour converser en même temps que l’on se restaure. Bravo !

Profiter de la pause déjeuner pour converser avec les nombreuses brillantes personnes que je peux croiser ici est un luxe que je n’ai jamais eu jusqu’à présent au ScrumDay ! C’est avec Jean-Laurent de Morlhon que je passerais la plus grande partie de cette pause. Le développement (le vrai) est la passion de Jean-Laurent. Aujourd’hui il partage son temps entre les missions de dev orientées « craftmanship », Serpodile la société créé par sa femme et le partage au sein des communautés qui lui tiennent à coeur. Nous retrouverons Jean-Laurent au cours de l’après-midi pour sa session.

Je clos ici le premier volet de mon retour sur ce ScrumDay, il ne faudrait pas risquer l’indigestion !

Carnet de route : le Printemps Agile 2014 à Caen (1/2)

Le avril 13, 2014septembre 7, 2016 par addinquydans Compte-rendu1 commentaire

J’avais participé à l’édition précédente (vous trouverez mes comptes-rendu ici et ici). Cette année je suis de retour, mais comme je l’avais annoncé, cette fois comme orateur !

Ce Printemps Agile a d’ailleurs pris pas mal d’ampleur. C’étaient 70 personnes qui s’y étaient inscrites l’an dernier. Nous voici rendus à plus de 200 ! Même avec un peu moins de présents (un peu plus de 150, semble-t-il), car l’évènements étant gratuit, nous subissons le phénomène du désistement, cela reste un sacré succès. Par rapport à l’an dernier, l’équipe d’organisation s’est aussi bien étoffée. Je pense à Emilie Sulmont et Myriam Boure, mais aussi aux étudiants de Jean-Luc !

Un Marshmallow pour commencer ?

Passé le traditionnel accueil, non nous n’avons pas droit à l’habituelle keynote. Désolé mais le créneau dévolu à entretenir l’égo d’un quelconque gourou, ce n’est pas le genre du Printemps Agile !

Au programme, on nous a prévu un agile game, un classique, avant tout, avant même le petit mot d’introduction. Franchement j’étais perplexe sur la faisabilité de cette idée : des gens qui arrivent, doivent se mettre dans le rythme, ont envie de boire leur petit café…

Eh bien non, j’ai eu tord. L’idée est franchement géniale ! On s’est rapidement mis en mouvement sur une quinzaine de tables.

Comme c’est souvent le cas, les essais et réussites sont très diverses. Depuis la tentative, disons modeste…

… Jusqu’aux plus ambitieuses (ça ne marchera pas).

Le team gagnat aura plutôt fait dans le simple, avec une oeuvre tout bonnement achevée au bout de 3 minutes !

Bravo à Eve et Alfred (entre autre), il ne faut pas non plus oublier le 4ème membre de l’équipe : celui qui est derrière l’appareil photo !

Je déclare ouvert…

Cette année encore, c’est Jean-Luc qui introduit cette nouvelle édition du printemps agile. Si la communauté agile Caennaise est restreinte, elle est très active comme le démontre l’agenda annuel. De plus, cela fait plaisir de voir l’enseignement supérieur s’y intéresser sérieusement, aussi bien du côté étudiant que du côté enseignant !

Scrum Shu Ha Ri

Sur ces bonnes paroles, je dois vous abandonner : ma présentation “Scrum Shu Ha Ri” figure sur le premier créneau horaire. Ne vous en faites pas : je partagerais bientôt mon support de présentation pour faire suite à mon teaser. Avec un peu de chance, je pourrais aussi vous partager une vidéo et l’article correspondant si j’ai le courrage !
C’est d’ailleurs toute une matinée Zenika qui se partageait la salle ce matin là : Géry Derbier prenait ma suite pour un Carpaccio !

Carpaccio Game

Le Carpaccio, c’est ce jeu agile créé par Alistair Cockburn pour appréhender le découpage des fonctionnalités en tranches fines. Géry en est littéralement devenu le spécialiste et l’a pratiqué de nombreuse fois.

Moi-même, j’ai eu l’occasion de l’animer une demi-douzaine de fois, car il fait partie de mon “package immersion agile” chez mon client actuel.

J’assistais Géry durant cet atelier, car nous avions un nombre de participants tout à fait conséquent. La premi§re partie se fait sans machine : nous cherchons à découper le problème en tranches.

La seconde produit un peu plus de sueur: il faut développer et démontrer le produit toute les huit minutes !

L’animation de Géry diffère un peu de la mienne. Celle de Géry est certaine plus orthodoxe : il enchaine directement les itération de 8 mainutes (8 minutes !) … démo comprises. Pour ma part, je demande à ceux qui assistent à la démo de faire des vérifications approfondies… du coup je neutralise le chrono au bout de 45 secondes. Cela me permet aussi de tracer les courbes d’évolution des différentes équipes.

Du coup, le stress selon l’animation de Géry est beaucoup plus élevé. On termine l’atelier par une petite rétrospective: qu’avez-vous appris de ce jeu ? Qu’y avez-vous observé ?

Ceci termine notre matinée du printemps agile… et la première partie de ce retour. A très bientôt pour la seconde partie !

Agile France 2014 : J’y serais, et vous ?

Le avril 5, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

On est encore un peu loin de la date fatidique, mais c’est bien maintenant que le programme se construit pour les 22 et 23 Mai au traditionnel rendez-vous du Chalet de la Porte Jaune !

Je cours en seconde division cette année : je présenterais une version “Lightning Talk” de ma session de Grenoble : User Stories, what else ?

La version 45 minutes était déjà pas mal dense, il va me falloir être pas mal créatif pour en faire une version 15 minutes sans assasiner l’auditoire tout en n’abdiquant pas sur le contenu : beau challenge !

Moi qui voulait ralentir un peu le rythme en faisant (comme mes confrères) un peu de réutilisation de mes présentations, il semble que cela devra attendre un peu ! Il faudra que je fasse quelques statistiques sur le sujet, la ratio de mes “présentations exclusives”, donc celles que je ne donne qu’une seule fois, dépasse largement les 50%. Et je n’ai jamais servi aucune d’entre-elle plus de deux fois.

Et le teasing, alors ?

Bien sûr, vous n’y échapperez pas ! Le voici.

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.

Au cours de ce Lightning Talk, nous allons passer en revue plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles, afin d’évaluer comment elles peuvent renforcer nos pratiques actuelles.

Je vous rappelle le lien vers le site de la conférence Agile France.

A très bientôt !

Agile France 2014 : J’y serais, et vous ?

Gojko Adzic : Making impact !

Le mars 26, 2014septembre 7, 2016 par addinquydans Compte-renduLaisser un commentaire

L’association We Do Product Management nous proposait ce 11 Mars une soirée exceptionnelle avec 2 orateurs. Gojko Adzic himself nous proposera une présentation sur le thème “making impact” tandis que Nicolas Gouy nous gratifiera d’un développement autour de l’Agile with GUTS !

Zenika accueillait cette soirée : un grand merci à Sébastien Sacard et Lisa Marçais du côté du WDPM, et aussi à Al chez Zenika pour son aide avant, pendant et après la soirée !

On commence d’ailleurs par une petite présentation du WDPM avant d’attaquer les choses sérieuses.

Making Impact par Gojko Adzic

La définition amont d’un produit se heurte à des facteurs d’imprédictabilité. Facteurs que l’on connait par ailleurs depuis plus de 100 ans :

Le facteur local
Le facteur temps
Le facteur Humain

Ces facteurs ont été identifiés par Peter Palchinsky. Dans The Ghost of the Executed Engineer, les auteurs reviennent sur certains désastres de l’Union Soviétique illustrant les facteurs de Palchinsky. Intéressons-nous spécifiquement à l’un d’entre-eux: le canal de la Baltique à la Mer Blanche.

Ce canal peut être considéré comme un succès, car il a bel et bien vu le jour, comme prévu. Cependant, il échoue aux 3 critères da Palchinsky et malgré son existence c’est effectivement un échec cuisant :

Le facteur temps : la construction du canal n’a pas anticipé l’évolution des cargos. En définitive, le canal s’est avéré rapidement trop peu profond pour les nouveaux navires !
Le facteur local : Sa situation septentrionale le rend gelé, donc impraticable 6 mois par an !
Le facteur humain : creusé à main d’hommes par des prisonniers dans des conditions extrêmes, il aura coûté le vie à 200000 d’entre-eux !

Autre exemple d’échec : le PC Junior d’IBM. Cette aventure coûta à IBM pas moins de 2 milliards de dollars ! Et pourtant, le géant de l’informatique ne fit jamais que délivrer exactement ce que l’utilisateur voulait ! Mais il échoua sur l’imprédictabilité du facteur humain.

D’un point de vue du Product Manager, on tend à planifier comme si tout était sous notre contrôle. Il faut au contraire créer des plans à même d’exploiter cette imprédictabilité au lieu de la combattre vainement.

Rechercher de nouvelles idées, essayer de nouvelles choses.

Cette approche trouve une incarnation dans le Set Based Design, l’aptitude à essayer différentes solutions en éliminant progressivement les moins valables.

En 2002 (ou était-ce en 2003 ?) Ducati se lance dans l’aventure Moto GP. Plutôt que d’essayer de construire d’emblée la meilleure moto, les ingénieurs conçoivent un engin sur lequel ils peuvent essayer multitude d’options. Après des débuts laborieux, celle-ci devient redoutable en seconde moitié de saison et l’écurie finit 2nd au championat constructeur !

Vous courrez après le déploiement continu ? Mais qu’en est-il de votre capacité à multiplier les versions, les comparer, créer des variations ? Cette approche permet d’expérimenter et d’apprendre. Bref essayer de nouvelles idées pour comprendre dans quelle direction il convient de se diriger !

La survivabilité

Le principe est simple : si votre expérimentation échoue, que les dommages en soit minimes … en tout cas que cela ne fasse pas couler l’entreprise !

Les connaissances et les pratiques d’ingénierie sont là … mais pas l’état d’esprit du product management !

Selection

Il faut faire le nettoyage sur ce qui ne sert à rien ou ce qui a échoué. En développement logiciel on ne supprime jamais rien (on garde, on ne sait jamais…). Et ce code ou ces composants morts deviennent un passif qui nous empêche d’avancer.

Non aux roadmaps, oui aux map of roads"

Mauvaise nouvelle pour les agilistes : le Product Manager n’est pas intéressé par les User Stories ! Ou plutôt, il est intéressé par leur faible granularité et leur côté “survivable” !

C’est le boulot du Product Manager de se créer des options, et les User Stories sont un bon outil pour cela : explorer des directions, sélectionner, changer d’option … bref tout sauf un plan linéaire ! Quelque chose qui ressemblerait à un plan avec un GPS pour s’y diriger. Ce GPS, c’est l’impact Mapping !

L’alignement rapide avec l’impact Mapping

L’impact mapping, c’est avant tout 4 questions pour arriver à une meilleure solution :

Pourquoi ?
Qui ?
Comment ?
Quoi ?

Ce framework nous aide, car il nous évite de nous enfermer dans une logique unidirectionnelle, il nous permet d’explorer des variations : cette hypothèse contribue-t-elle au pourquoi ? Dois changer le “quoi” … ou m’intéresser à un autre acteur… S’il est parfois difficile de déterminer le pourquoi, les clients ont souvent moins de mal à dire ce qu’ils ne veulent pas. C’est un autre moyen d’arriver à nos fins !

On peut rapprocher l’approche Impact Mapping du Design Thinking : se générer des options, les explorer et les éliminer ! On a changé le mode dialogue au niveau du product management : on est passé du sacro-saint périmètre aux options et à leur contribution à un objectif…

Nicolas Gouy : Agile with GUTS

Nicolas est l’auteur d’un ebook portant ce titre et publié par infoQ.

Désolé pour la piètre qualité de la photo, vraiment l’éclairage (ou son absence, plutôt) m’a rendu la tâche difficile…

Parlons de valeur

Tout d’abord, c’est une notion subjective ! Et comme l’a indiqué précédemment Gojko Adzic, elle est subordonnée aux facteurs d’imprédicatabilité. Histoire de bien commencer, et de commencer fort (je dois dire), Nicolas nous parle des Shreddies. Les voici en image, pour illustrer le propos.

En passant d’un modèle à l’autre (sic !), Schreddies a vu son chiffre d’affaire s’envoler : la valeur n’est pas une question de sens commun ! Mais cela se travaille. Pourtant, sur nos projets agile, nous arrêtons notre horizon au backlog, comme si ce qu’il y avait avant était tabou !

Dans GUTS, il y a “G”, et ce “G”, c’est le Goals ! Notre but, c’est d’avoir un impact en étant en empathie avec notre client.

Le “U” quand à lui, c’est “Uncertainty”, et nous retrouvons les éléments que nous a partagé Gojko juste avant : il nous faut être à l’aise avec cela, et même en tirer parti. Comment ? En “crash testant” nos idées, en les validant au plus tôt.

Le “T” est plus original, car il s’agit du “Trade Off”. La solution parfaite est rarement un but désiré et raisonnable : il faut faire des compromis intelligents. Sur ce point, je ne suis pas sûr d’avoir compris ce que Nicolas voulait dire (exprimé plus simplement : je n’ai en fait rien compris). Bon, je verrais cela plus tard…

Le “S” signifie lui “Speed”. Une notion qui devrait remplacer celle de vélocité. Si la seconde notion couvre l’idée d’abattre plus de travail en moins de temps, la seconde consiste plutôt à atteindre un but plus rapidement … donc à être intelligent sur la manière d’y arriver ! C’est donc en fait remplacer la notion de périmètre par celle d’objectifs !

Quand on met l’acronyme ensemble, eh bien on parle bien entendu de “courage”. Et avoir du courage, c’est savoir être pertinent : toujours chercher à faire plus avec moins !

	addinquy dans Note de lecture : The Lean Sta…
	Benoit Adamski dans Note de lecture : The Lean Sta…
	Les 21 vous allez co… dans Note de lecture : Vous allez c…
	Mes conférences sur… dans Carnet de route : Agile France…
	Lee dans Parlons outils pour Kanban…