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

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 !

image

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).

image

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 !

Publicités

Note de lecture : The Principles of Scientific Management, par Frederick Winslow Taylor

Note : 6 ; Loin d’être aussi stupide qu’on aime à le laisser penser…

Quand on parle « Taylorisme » ou plutôt management scientifique, de son vrai nom, on pense aux temps modernes, à l’abrutissement du travailleur. Mais finalement, ce n’est pas si simple et cette pensée doit être remise dans son contexte. Et surtout il faut lire le texte original de l’auteur qui recèle des informations qui ont ensuite été éludées.

Et pourquoi s’en priver ? L’ebook est disponible gratuitement chez Amazon et le texte n’est guère long, il ne compte que 70 pages ! L’auteur ne rentre pas réellement dans le détail de la mise en œuvre du « scientific management » (qu’il oppose à la gestion par initiative et incitations), en fait il a même tendance à se répéter. Par contre il décrit plusieurs expérimentations sur la mise en place, parfois avec des dialogues cocasses (je recommande la page 19) ! Le style ne l’est cependant généralement pas, le texte accuse plus d’un siècle et cela se voit, surtout quand l’auteur parle de lui-même à la 3ème personne ! L’opuscule ne compte que 2 chapitres.

Le premier chapitre « fundamentals of scientific management » est court, il ne compte que 11 pages. Il pose les postulats de l’application de sa méthode. Il est intéressant de les rappeler, car ils sont souvent éludés et ne s’appliquent de toute manière pas aux « travailleurs du savoir » que nous sommes.

  • Les besoins à satisfaire chez les travailleurs sont les besoins basique de « sécurité », c’est à dire ceux du 1er niveau de la pyramide de Maslow. On ne parle pas d’épanouissement, par exemple. Une meilleure rémunération est tout ce qui est attendu.
  • Le travail considéré est « simple » : il est répétable, mesurable et décomposable. C’est d’ailleurs de l’analyse et de l’optimisation des tâches que proviennent les gains du scientific management.
  • Le travailleur n’a pas l’intelligence nécessaire (« stupide » selon Taylor) pour savoir comment être efficace dans son travail, ni même en fait ce qui est bon pour lui ! D’ailleurs il cherche à tirer au flanc autant que possible…

Les fondamentaux posés, le chapitre 2 s’attaque aux principes. Ils sont mis en perspective par rapport à l’approche « initiative and incentive » et sont illustrés par plusieurs études de cas, y compris une où l’application du scientific management était jugée « impossible ». Les principes sont les suivants :

  • Une étude minutieuse et scientifique des tâche à faire associée à une sélection rigoureuse des travailleurs dont l’aptitude corresponds le mieux. Cette étude est menée par le management, seul apte à réalisé ce travail car ayant la capacité intellectuelle pour cela.
  • Un management qui est en charge d’enseigner et contrôler la bonne application de la réalisation des tâche déterminée. C’est lui aussi qui contrôle le rendement et collecte le feedback quand des améliorations supérieures se font jour.
  • Un partage des gains financiers réalisés entre le management et les travailleurs.

On voit que si cette approche n’a jamais été adaptée aux travailleurs intellectuels, elle ne l’est plus aujourd’hui au monde ouvrier. Il n’en reste pas moins que le management scientifique a été probablement le progrès le plus important du 20ème siècle, celui qui a projeté l’occident vers la révolution industrielle.

L’approche de Taylor est par certains égard dure, parfois inhumaine. L’auteur est aussi vrai capitaliste qui croit dans la croissance illimitée (mais au début du 20ème siècle cela peut avoir du sens). Mais son approche, quand on la considère dans son ensemble n’a pas le goût de stupidité qu’on essaie de lui donner quand on présente cette approche de manière déformé. En fait, l’exemple donné sur l’étude de la coupe du métal est remarquable et s’applique encore largement de nos jours.
Je ne me ferais pas le défenseur du Taylorisme, mais cette lecture me semble à recommander, au moins pour savoir mettre en perspective les approches modernes.

image

Référence complète : The Principles of Scientific Management – Frederick Winslow Taylor – Aeterna 2011 (Kindle edt. ASIN : B0082Y8IWS) – ISBN : 978-1444432312

Harry Potter and the Goblet of Fire (Harry Potter, #4)

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

Functional Programming in Scala sur Coursera

Un an ! J’ai attendu un an pour produire ce post suite au cours « functional programming in Scala » ! Je n’avais pas le temps, pas l’humeur, je changeais de boulot, etc. En fait, je suis peut-être simplement un pro de la procrastination. Enfin voilà!

Ce cours proposé par le créateur de Scala n’avait pas pour but de nous initier au langage, mais de nous faire découvrir la programmation fonctionnelle en nous appuyant sur celui-ci. C’est donc plus particulièrement une facette précise du langage que nous avons découvert, et non le langage dans sa totalité.

Le cours

Le format est plutôt bien choisi, avec des « petits tronçons » de 10 à 15 minutes. Parfois les sujets plus volumineux s’enchainent sur 2 tronçons avec juste un entr’acte entre les deux. Deux mentions spéciales :

  • Aux quizz qui émaillent ces séquences. Ils ne sont pas toujours évidents !
  • A la chevelure de Martin Odersky qui apparait régulièrement en superposition des vidéo !

Certains cours sont présents mais font en fait partie du cursus d’Odersky à l’EPFL. On les reconnait à leur niveau mathématique franchement plus élevé !

Ce n’est pas un cours sur Scala ! Il s’agit d’un cours de programmation fonctionnelle en Scala. Ainsi il y a tout un pan (au moins) du langage qui n’est pas évoqué. De même, le cours n’est pas directement transposable à un autre langage fonctionnel.

Les exos

C’est un peu la partie dure de ce cours. Ils sont de complexité croissante et arrivé vers la 3ème semaine deviennent de vrai casse-tête. Ils sont aussi très consommateurs de temps. Pas question de les laisser pour le dernier moment ! Si les premiers exercices m’ont pris largement moins de temps qu’indiqué, les derniers ont nettement dépassé le temps normalement requis en ce qui me concerne.

Les exercices sont aussi extrêmement cadrés. La plupart du temps, le squelette des méthode est fourni, on s’attend donc à ce que nous écrivions la solution imaginée par l’auteur du cours. C’est probablement bien, mais assez frustrant.

Une dernière chose : les exercices sont très bien instrumentés : il y a une commande SBT qui permet de soumettre l’exercice en ligne, le résultat est noté et argumenté en retours. On peut aussi pratiquement recommencer « ad noseum ». Seul le meilleurs résultat est conservé !

Scala : ce que j’ai aimé

Multi-paradigmes

Même si l’on n’en parle peu durant ce cours, Scala est en fait un langage « multi paradigmes ». En fonction de la sensibilité du développeur, il y a plusieurs voies pour résoudre un problème, en favorisant un paradigme plutôt qu’un autre, en les mixant…

Bien entendu, ceci en fait un langage difficile d’abord. En fait, il me rapelle C++ ! Si pour beaucoup cette comparaison frise l’insulte, ce n’est pas mon cas…

Le support de l’immutabilité

Le nom même du langage vient de « scalable ». Dans les architectures modernes en général et pour Odersky en particulier, être scalable, c’est offrir peu de prise à la concurrence et permettre de clusteriser les traitements. Pour Scala, l’un des secrets consiste à travailler avec des objets immutables. En choisissant d’en faire des val ou des var, on contrôle parfaitement ce que l’on souhaite faire.

Dommage quand même que l’on ait pas de mécanisme pour effectuer cette déclaration au niveau de la classe elle-même, pour interdire son utilisation mutable ! OK, OK, vous allez me dire qu’il me suffit de déclarer tous les champs de ma class « val »…

La surcharge d’opérateurs

Voici une fonctionnalité qui doit hérisser le poil de bien des Javanais ! Je n’ai rien contre la surcharge d’opérateur lorsque sa sémantique est bien inscrite dans celle qui est implicitement attendue par l’utilisateur. C’est d’ailleurs un des pièges en C++ !

Des objets à la place de singletons

Je ne suis pas fan des Singletons, mais le suis encore moins des bricolages à base de méthodes statiques. Donc si l’on veut une instance unique de quelque chose, il suffit de le déclarer en « Object » plutôt qu’en « Class ». Voilà !

D’ailleurs, il n’y a tout simplement plus de membre statique en Scala : bon débarras !

Les Traits

Les interfaces Java me posent un problème depuis le début. Je ne fais que peu de différence entre une interface et un pattern « template method » : refactorer une interface pour en faire un Template Method est pour moi une évolution naturelle. Oui mais voilà en Java, il faut passer d’une interface à une classe abstraite pour faire cela, et ce sont deux choses radicalement différentes ! Il faut repenser le design, ce qui est même souvent impossible « grâce » à l’héritage unique de Java !

Vous allez me dire que que maintenant c’est possible en Java 8 grâce aux « défaut methods ». C’est vrai, même si conceptuellement ce n’est pas ce que j’essaie d’exprimer avec le template method, je peux m’en servir pour cela (en sacrifiant le « final » que j’aurais souhaité utiliser).

Avec les Traits, on peut pratiquement utiliser toutes les fonctionnalités disponibles sur une superclasse ! De notables différence existent cependant (par exemple les traits n’héritent pas d’Object que j’éxecre de toute façon). Et le mécanisme sous-jacent appelé « linéarisation » est très différent.

On peut désormais penser son design de manière très différente : les classes deviennent des « mix in » de fragments de comportements. Et l’importance de l’arbre d’héritage à la papa est grandement diminué.

Des types spéciaux bien utiles…

En lieu et place d’Object, Scala nous propose différents types de base et différents « bottom types ».

image

Any, AnyVal et AnyRef sont les types parents du système de type Java. AnyRef est en fait un déguisement de Object, car il faut quand même tourner sur la JVM…

Plus intéressant : NULL est une vrai classe (à instance unique) et sous-classe tous les descendants de AnyRef. Nothing fait la même chose pour tous les descendants de Any. Il faut un peu apprendre à se servir de tout cela, ce n’est pas évident.

Les case classes

Elles offrent des facilités d’écriture et d’utilisation bien sympathiques, surtout dans le cas de value classes immutables. Par exemple, les paramètres du constructeur sont disponibles en tant qu’attributs “val” sans qu’il n’y ait rien à faire…

for expressions

Pas très facile à appréhender, le for (…) yield {…}, qui est en fait une combinaison de map, flatmap et filter.

Scala : ce que j’aime moins

Le « mode compression »

Je déteste la plupart des raccourcis syntaxiques qui permettent d’économiser un caractère par ci, un caractère par là… Comme par exemple se passer de parenthèses dans certains cas, ou de l’appel de méthode avec la notation à point.

Comme me le faisais remarquer si justement un de mes collègues, la motivation premières de la plupart de ces sucres syntaxiques est de permettre de transformer Scala en syntaxe type DSL ! C’est à mon avis un mauvais calcul, où l’apparente élégance d’écriture se traduit par plus de difficulté pour appréhender la sémantique. Il y a des fois où le côté rustique…

On ne saurait bien entendu passer sous silence le désormais célèbre « _ » ! Là encore, ces apparente économies rappellent les aspects les moins glorieux du Perl !

Bref, Martin aurait mieux fait de se casser une jambe le jour où il a pondu ces trucs là !

La programmation fonctionnelle, ce n’est pas très objet

Je me faisais un plaisir de masquer les listes, d’encapsuler les algorithmes. Avec la programmation fonctionnelle, j’ai l’impression de les exhiber à nouveau. Sans compter bien entendu que cette chère programmation fonctionnelle est le domaine des matheux …ce que je ne suis pas !

Bref, il me faudra pas mal réflechir pour voir si on peut concilier l’élégance de l’objet avec l’efficacité du fonctionnel. Odersky prétend que c’est ce que fait Scala, mais je n’en ai pas d’exemples frappants pour l’instant.

Un syntaxe dense, même sans le mode compression !

Le code Scala, c’est sans aucun doute élégant et efficace. Mais la lecture en demande pas mal de concentration et d’effort. Là encore, je retrouve un aspect un peu C++.

A côté, la syntaxe plus « paysanne » de Java permet plus facilement de débrancher le cerveau (sauf si vous commencez à utiliser les trucs de Java 8…).

La surcharge d’opérateurs

Oui, je sais, je l’avais mis dans les points positifs ! C’est parce qu’hélas Scala ne s’arrête pas à vous permettre de redéfinir les opérateurs prévus dans le langage. Il permet de définir les vôtres (encore cette satané velléité de faire de Scala une machine à DSL). Du coup cela permet de délirer tranquillement à définir des opérateurs en ASCII art sur 4 ou 5 caractères. Et c’est bien parti !!

Next step…

Le cours n’est pas une ballade de santé. C’était une opportunité pour aborder Scala, mais rétrospectivement, ce n’était pas la plus simple ! Commencer par du « better Java » aurait été plus raisonnable à mon âge…

Il y a beaucoup de choses intelligentes que j’aime bien dans Scala. Entre autre son aspect assumé « ulti-paradigmes », qui en fait aussi un langage difficile ! Ce dernier point signifie qu’il faut beaucoup le pratiquer, ce que je ne fais pas. Je me pose donc pas mal de questions sur le fait de persister…

D’autres langages alternatifs sur la JVM proposent des améliorations allant dans le sens de Scala tout en restant centré sur la facilité de lecture. Je pense spécialement à Ceylon. Bien sûr ils n’ont pas non plus le potentiel de Scala. Ils n’ont pas non plus la « traction » de Scala qui est réelle aujourd’hui et qu’on ne saurait ignorer.

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

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…

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…

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.

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)

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…

image

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.

image

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…

image

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.

image

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é ».

image

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.

image

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.

image

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 !

image

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 !

image

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.

image

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 !

image

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.

image

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 !

image

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…

image

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.

image

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…

image

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 !

image

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…

image

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.

image

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

image

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.