Mois : septembre 2014

Améliorer la société au Product Tank

Le par addinquydans Compte-renduLaisser un commentaire

Ce nouveau rendez-vous du Product Tank avait aujourd’hui un focus très clair et très particulier : des produits qui n’en sont pas … et surtout qui sont là pour améliorer la société. Nous étions accueillis à cette occasion au John Paul Lounge, un espace ouvert sur les Champs Elysées !

image

Un petit comité hélas pour un sujet pourtant si particulier et une soirée qui s’avèrera riche d’enseignements.

Open Food Facts

Pour ouvrir la soirée, Stéphane Gigandet nous parle d’Open Food Facts. Et Open Food Facts, c’est avant tout une association loi de 1901, avec uniquement des bénévoles à son bord ! D’ailleurs Stéphane ne se définit pas comme un Product Manager, mais comme un « Product Opener » ! Et ouvert, la base de données d’Open Food Facts l’est, car disponible en open data et sous license Open Database !

Le but, ou la mission devrais-je dire, qu’openfoodfacts.org s’est imposée, c’est d’améliorer la transparence sur la constitution des aliments, donc sur la qualité nutritive de ce que nous achetons, en décryptant les labels ! Et avec plusieurs milliers d’additifs en cours sur le marché, il y a du boulot. Surtout que ceux-cis s’efforcent d’être le moins compréhensibles possibles.

image

Notre orateur du jour est informaticien. Il a d’ailleurs développé les outils que propose Open Food Facts. Notamment, l’application mobile permettant la saisie et la reconnaissance des produits. En fait, il semble bien tenir le projet à bout de bras ! L’inspiration du modèle de fonctionnement vient de Wikipedia : utiliser le crowdsourcing pour aider à décrypter les produits. Aujourd’hui la communauté compte plus de 1000 contributeurs.

Au fait, pourquoi « Product Opener » ? Stéphane nous avoue qu’un tel projet ne peut être dirigé. Subordonné au bénévolat, il ne s’étend pas en fonction des besoin, mais des motivations des contributeurs. L’organisation veut cette base d’intérêt public, elle est donc librement accessible via des API JSON. Mais des projets naissent aussi au sein même d’Open Food Facts :

  • Projet de « science citoyenne ».
  • Repérage de produit contenants du lactose ou du gluten
  • Produits contenant de l’huile de Palme
  • Projet d’archéologie alimentaire, etc.

Bref, Open Food Facts, c’est bien plus que le repérage des ingrédients sur l’étiquette !

image

Aujourd’hui, l’ambition s’étend aux produits de beauté, et aux produits en dehors de la France. De grandes ambitions et un bel état d’esprit !

Open Data Gouv, avec Pierre Pezziardi

Pierre est quelqu’un qu’il est facile de croiser dans différentes communautés, par Exemple, à Agile France. Aujourd’hui, il vient nous parler d’Open Data Gouv, un projet dans lequel il est pleinement impliqué. A la base, il s’agit d’un projet de référencement des données libres. La première question qui s’est posée est : comment évaluer le succès. Par le nombre de réutilisations, par le nombre de personnes réutilisant ces données ! C’est une direction qui a induit la voie suivie par le site qui est passé d’un CMS a un réseau social, et s’est efforcé de suivre les canaux d’engagements.

Cette plateforme s’est voulue résolument en rupture avec les règles établies de l’administration, d’où la nécessité de la créer en dehors d’elle ! Car on ne peut innover dans la structure, on ne peut qu’y reproduire ses codes. Au contraire du principe de méfiance qui prévaut dans l’adminsitration, tout ici est basé sur la bienveillance avec un contrôle à postériori, car les utilisateurs peuvent publier leurs données ! Ils peuvent même reprendre les bases de l’administration pour les rendre plus exploitables ! En pratique, il y a peu de spam.

image

Le co-design est aussi un pilier important de ce travail. Il permet essentiellement deux choses :

  • Engager les personnes dans la création du produit. Celui-ci étant développé selon un cycle Lean Startup.
  • Régler le problème du « démarrage à froid » propre aux réseau sociaux : lors de l’ouverture des portes, il y a déjà beaucoup d’inscrits !

Pour autant, beaucoup d’obstacles se dressent :

  • Ouvrir les portes de l’entreprise pour y mettre l’utilisateur, voilà qui n’est pas naturel !
  • Certaines organisations ont transformé le monopole sur certaines données en rente économique … quand bien même celles-ci sont de mauvaise qualité !

Le but d’opendata.gouv et de libérer les données, inviter tout un chacun à y contribuer, bref faire jouer le crowdsourcing à l’image d’openstreetmap.org ou d’openfoodfacts.org que nous venons de voir. On ne peut avoir des référentiels larges et profonds seuls, il est indispensable de mener ce travail collectivement.

Un point réccurent du raisonnement de Pierre est la recherche des « irritants », il appelle ainsi des problèmes qui se répètent sans arrêt. Ces irritants sont l’occasion de développer de nouvelles possibilités. C’est ainsi qu’est né le Marché Publique Simplifié.

En conclusion

Nous avons eu la chance d’avoir deux interventions non seulement très vivantes, mais aussi très riches. Bien sûr, pour Pierre, on savait déjà. Cela dit ce meetup se distingue surtout par son thème éthique : faire du bien à la société, apporter une destruction créatrice.

Sur ce, je dois me sauver, une Scrumbeer (ou ce qu’il en reste) m’appelle…

Publicités

Agile Playground #16

Le par addinquydans Compte-renduLaisser un commentaire

L’Agile Playground ne se repose jamais … ou si peu ! Après une rencontre organisée mi-Juillet, on reprend nos bonnes habitudes dès mi-Septembre. Pierrick fait office de grand orchestrateur aujourd’hui. Et il nous propose un mode d’organisation inspiré de l’open-space, avec 2 catégories de propositions :

  • Les jeux que l’on souhaite proposer.
  • Les jeux auxquels on souhaiterait participer.

Le formule marche bien, nous recueillons quelques propositions, largement assez pour animer la soirée, pas trop pour ne pas être obligé de rentrer dans une gestion compliquée ! Voilà dejà une formule que l’on pourra rééditer !

image

Pour cette reprise nous étions un peu plus d’une trentaine de personnes, à vue d’oeil. Comme on dit lors des open-space : les personnes qui sont là sont les bonnes personnes !

image

Le « software ball » que propose Pierrick m’intrigue, ne serait-ce que par son nom : allons-y !

Le Software Ball

Le principe de ce jeu est simple et curieux et finalement pas si facile à saisir ! Les participants sont invités à se lancer une balle selon un schéma défini par le maître de jeu (nous ferons 5 itérations en complexifiant ce schéma). Pour exécuter cela, il faut « programmer » chaque participant avec des instructions en français à suivre très précisément. Elles sont inscrites sur des post-it que l’on colle sur soi.

A chaque itération, nous gagnons 10 points, moins le nombre d’instructions nécessaire pour programmer tout le dispositif (les instructions sont les verbes des phrases). C’est là que ça se gâte, n’est-ce pas ? Ce n’est pas fini ! On a droit au copier-coller et c’est gratuit ! Si 2 participants (ou plus) ont les mêmes instructions, on ne décompte que les instructions d’un seul participant. De même, si l’on garde des instructions entre 2 itérations, c’est aussi gratuit !

image

Bref, c’est quand même compliqué, vous pouvez toujours faire un tour sur le site du Software Ball. Pas mal de perte de temps au début : nous essayons un peu vainement de « bien » conceptualiser la chose avant de commencer. En fait, il est plus simple de se lancer et d’expérimenter sur le tas : nous nous lançons donc à deux pour commencer. Rapidement, après une paire d’itération, nous nous rendons compte que notre implémentation initiale génère des coûts exponentiels, car toute la complexité est sur le rôle du « lanceur-dispatcheur » qu’il faut réimplémenter à chaque fois ! Peitit moment de reflexion.

image

Nous galérons un peu pour passer du mode « push » au mode « pull » où les recepteurs appellent la balle et où il n’y a plus d’intelligence sur le dispatcheur. En effet, les règles stipulent de l’on ne peut pas faire de réutilisation partielle d’implémentation. Nous finissons par trouver le contournement !

Ce jeu a pour but de mettre le doigt sur des pratiques de Craftsmanship. En cela il est tout à fait original ! Il nous permet de reflechir à la réutilisation, au moment adéquat pour changer de stratégie et c’est franchement pas mal. Par contre il est frustrant sur le peu de libertés qu’il nous laisse pour faire des choix de cinématiques de circulation de balle. Je pense aussi qu’il devrait permettre la réutilisation partielle. En synthèse, voici le résultat du débrief.

image

Bref, j’ai bien envie de l’essayer, mais en hackant légèrement les règles !

La balle supersonique

Petite originalité de cette édition : un jeu frugal durant le buffet de fin ! Nous avons pu expérimenter une balle supersonique. Enfin, l’ayant déjà joué à Agile Game France, j’ai passé mon tour !

image

Mention spéciale à Julien qui l’a animé en n’ayant expérimenté la chose qu’une seule fois à Agile France. Il a d’ailleurs un peu hacké les règles en permettant de tenir la balle pendant qu’elle circule ! Je pense ne pas le suivre dans cette voie. Mais il bon d’essayer des choses. Voici de que cela donne

See you later

Toutes les bonnes choses ont une fin. Je coupe court à l’un de mes moments préférés : le buffet et la discussion qui terminent la soirée. Rendez-vous le mois prochain !

image

Note de lecture : Specification by Example, par Gojko Adzic

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; La référence sur le développement guidé par les tests. Book of the year 2014 !

Régulièrement, je retarde le moment d’ouvrir un livre que je sais excellent (de réputation) et qui prend la poussière sur une de mes étagères. Ce livre est de ceux-là ! Bien que Manning nous gratifie de temps en temps de titres non-techniques, il est assez étonnant de trouver celui-ci chez cet éditeur, probablement parce que ce n’est pas un livre pour remplir un vide thématique.

Il s’agit bel et bien d’un texte nous proposant un regard novateur sur les tests d’acceptance, même si l’auteur rappelle régulièrement au fil des pages qu’il fait suite à son ouvrage précédent « The Communication Gap ». Ce n’est pas non plus un livre très facile à lire, non qu’il soit volumineux car il ne compte que 250 pages, mais il s’appuie essentiellement sur de nombreux témoignages qui transforment le fil conducteur en une sorte de patchwork. Evidemment, ces nombreux témoignages qui sont autant de cas d’étude font beaucoup pour la crédibilité du texte qui est ainsi à la fois un travail digne d’un universitaire et l’œuvre d’un praticien de terrain. Venons-en au contenu.

L’ouvrage se découpe en 3 parties inégales. La première d’entre-elles ne compte que 60 pages réparties en 4 chapitres. Le premier chapitre nous laisse un peu dans le flou, il s’agit surtout d’un argumentaire étayé de témoignages sur la raison de s’intéresser à la spécification par l’exemple. On rentre dans le dur au chapitre suivant qui aborde la manière dont Gojko Adzic voit s’articuler le besoin depuis les « business goals » jusqu’à la « documentation vivante ». Les aspects amont sont par ailleurs l’objet de son ouvrage suivant « impact mapping ». On y apprend incidemment pourquoi l’auteur préfère « spécification par l’exemple » à « développement guidé par les tests d’acceptance ». Un chapitre à ne rater sous aucun prétexte ! Le chapitre 3 « living documentation » offre pour moi peu d’intérêt, sauf peut-être celui de couvrir le schéma de processus que l’auteur nous a exposé au chapitre 2 ? La spécification par l’exemple ne se veut pas une pratique spécifique aux projets agile, bien que ce soit un terrain de jeu naturel. Au chapitre 4, l’auteur aborde différentes façon de basculer d’un projet classique à l’écriture des tests en amont sous forme de patterns (bien qu’ils n’en empruntent malheureusement pas la forme).

La seconde partie est la plus imposante du livre, avec environ 130 pages et 6 chapitres. C’est le cœur de l’ouvrage. Les 11 pages du chapitre 5 « deriving scope from goal » sont un prélude à « impact mapping » et on y retrouve les mêmes thèmes. Je ne peux qu’en recommander la lecture. Le chapitre 6 est un de mes thèmes préférés car on y évoque la spécification collaborative. Tous les patterns de cette vingtaine de pages valent de l’or. J’applique déjà certains d’entre eux mais trouve ici des éléments pour m’améliorer. Encore un chapitre à ne pas rater.

Les deux chapitres suivants sont au cœur de l’ouvrage. Le chapitre 7 aborde l’écriture même des tests, comment les concevoir, comment les penser pour couvrir une spécification. Là encore ce sont des patterns desquels se dégage une stratégie claire et précise : sur la conception des tests, des cas passants et non passants, des données de test et des exigences « non fonctionnelles » ! Le chapitre 8 est un approfondissement du précédent, avec un accent mis sur les antipatterns.

Il était probablement difficile de parler de ce sujet sans évoquer les questions d’automatisation. C’est ce que font les 2 chapitres suivant. Le chapitre 9 évoque les options techniques d’automatisation y compris l’épineuse question des IHM. Le chapitre 10 se préoccupe surtout de l’intégration de ces tests dans des plateformes d’intégration et des stratégies possibles : isolation des systèmes tiers, plusieurs niveaux de validation, etc. Le chapitre 11 qui clos cette partie reprend le thème de la « documentation vivante ». Les patterns n’y sont pas sans intérêt, mais il reste le chapitre le plus léger de cette partie.

La Troisième partie est consacrée aux études de cas, c’est à dire les projets principaux (pas tous) qui ont donné la matière au livre. Des 7 chapitres qui la compose, 6 sont consacrés à ces études de cas sur 40 pages. J’ai eu du mal à me passionner pour cette partie. Y sont exposés les challenges auxquels ces différents projets ont été exposés à leur passage à le spécification par l’exemple, pourquoi ils l’ont fait et ce qu’il y ont appris.

Le dernier chapitre du livre nous livre les conclusions de l’auteur. L’une des plus importantes me semble être le passage d’une pratique des tests basée sur la défiance (coûteuse et inefficace), à une dynamique basée sur la collaboration et la confiance. Pas étonnant que cette pratique marche mieux en milieu agile.

L’ATDD ou plutôt la spécification par l’exemple est aujourd’hui ce que je considère comme un des plus forts effets de levier pour un projet agile, une fois acquis les pratiques d’ingénierie. L’auteur aborde les différents aspects (collaboration, processus, écriture et conception) avec un regard aiguisé que corrobore des données de terrain. En le lisant, je suis passé du « waouh effect » au « mais bien sûr » jusqu’à « ah oui, c’est ce que je fais et ça marche du tonnerre ». Cet éventail de réactions me rappelle la lecture du Design Patterns. Une autre façon de dire que je pense qu’il s’agit là d’un texte majeur !

image

Référence complète : Specification by Example, How successful teams deliver the right software – Gojko Adzic – Manning 2011 – ISBN : 978 1617290084

Specification by Example

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

Agile at Home, par Henrik Kniberg

Le par addinquydans PresentationLaisser un commentaire

Changement de décors pour cette nouvelle présentation de Henrik Kniber : comment mettre en oeuvre les pratiques agile et Lean à la maison avec 4 enfants !

Kanban

D’abord le Kanban. Il y en a un peu partut chez les Kniberg ! Un Kanban commun pour les tâches partagées, sur le réfrigérateur pour les enfants ou encore pour préparer un barbequeue entre amis.
La famille Kniberg est partie durant 8 mois pour un « familly trip » autour du monde. Il y a eu un Kanban pour préparer cela aussi. Cela comprenait d’ailleurs une expérimentation du concept, avec un séjour de 4 jours à Londres.

WIP limite

Un problème récurrent avec les enfants : le bordel dans la chambre ! Un problème qui ne s’est pas posé durant leur voyage, car la quantité d’affaires à transporter était limitée. Alors on utilise le même système : on limite le nombre de vêtements à ce que peuvent contenir les tiroirs !
Un système qui s’étend ensuite à la cuisine, pour le lavage de la vaisselle, avec une pincée de « definition of done ».

Burnup chart

Junior a du mal a être dans les clous avec ses devoirs ? Son coach de père lui met au point un burnup chart a suivre lui-même au fur et à mesure qu’il fait ses devoirs.

Autres management visuel

Cartes, « dream gallery », Kaizen boards, Henrik Kniberg n’hésites pas non plus à utiliser tout l’arsenal de management visuel à sa disposition.

Ce que j’en pense

Une vraie mise en oeuvre des principes agiles dans la vie réelle. C’est même assez impressionnant, je dois dire, même si je sais que certains de mes confrères s’essaie au même genre de chose..

Et moi alors ?

Eh bien non. En ce qui me concerne, je préfère laisser mon arsenal d’agiliste hors de la famille…

Soirée « fails » de l’agilité : une exclu du SUG !

Le par addinquydans Compte-renduLaisser un commentaire

Une soirée consacrée aux échecs de la mise en oeuvre de l’agilité, cela devait nécessairement commencer par un beau « fail ». Le mien fut d’oublier mon appareil photo ! Me voici condamné à utiliser mon téléphone portable et les images partagées par les autres participants !

Qu’à cela ne tienne, une excellente soirée s’annonce, bien que nous ne fassions pas salle comble. Mais avec au moins une quarantaine de participants, nous avons largement de quoi nous divertir. C’était annoncé : il fallait venir avec un « fail ». J’étais un peu inquiet, aurions-nous suffisamment de cas à nous mettre sous la dent ?

J’étais moi-même sollicité pour être l’un des membres du SAV, mais n’ayant jamais opéré avec Raphaël, Bertrand et Gwenael, impossible de savoir si notre quatuor allait fonctionner !

image

Pitchons !

Finalement toutes ces craintes se sont avérées vaines ! Des cas proposés, nous en avons eu près d’une trentaine ! Tous proposés de bon coeur et dans la bonne humeur. En fait, ce succès a même un peu dépassé nos espérances. Nous n’avons pas bien correctement maitrisé la durée des pitches, ce qui au final s’est avéré un peu long.

image

Un point d’amélioration pour la prochaine fois.

Votons !

Un simple vote à points pour prioriser nos cas. C’est quelque chose que nous savons bien faire. En quelques minutes, nous avons réglé cela.

image

Jusqu’ici, le SAV n’a guère eu besoin de beaucoup s’activer. Ca va changer !

Le SAV à votre service !

Ce qui est au SAV reste au SAV ! Cela m’interdit d’être trop précis et surtout de nommer les cas représentés. Si le thème de la soirée n’avait exclu aucune approche agile, tous les cas tournaient autour de mises en oeuvre de Scrum. Les problèmes évoqués tournaient beaucoup autour des thèmes suivants :

  • Mise en oeuvre problématique de l’approche.
  • Casting des acteurs, beaucoup autour du PO.
  • Contexte inapproprié : budget fixe / coût fixe, contractualisation mal ficelée.
  • Jeux politiques ou relationnels.

Certains des cas exposés étaient même des combinaisons de plusieurs points énumérés ci-dessus !

Nous avons cherché à comprendre en remontant au mal se cachant derrière les symptômes. Le public a bien joué le jeu en rebondissant sur les points investigués. Parfois avec des questions « sans issues », mais l’investigation est un art difficile. Je me suis pour ma part efforcé de poser des questions inquisitrices. Dans un style complètement différent, Bertrand Dour nous a proposé ses résolution de problèmes façon « terminator ». Le moins que l’on puisse dire, c’est que ça change ! J’en suis en tout cas reconnaissant à Bertrand : je manquais un peu d’énergie en fin de journée, ayant enchainé cette soirée avec une journée de formation !

image

Notre quatuor a finalement bien fonctionné, malgré ou à cause de 4 styles différents ? L’un de nous 4 avait souvent une idée d’angle d’attaque quand les autres étaient à sec, même s’il est vrai que nous avions souvent des manières différentes de voir le problème. Cela n’a pas semblé être une gêne au final.

Le deal était de trouver des solutions, pas moins ! Pas de rester en posture coach. Ne soyons pas prétentieux, je n’espérais pas aller jusqu’à la solution clé en main, pour autant que cela existe. Non, mais il était raisonnable d’espérer proposer des pistes sérieuses à explorer. Nous l’avons fait finalement souvent, quelques cas ardus s’étant par contre soldés par quelques idées pas forcément tangibles, donc que je ne classerais pas dans les solutions.

image

Nos chers animateurs ont demandé à l’assistance de voter sur la qualité des réponses. Si nous l’avons fait pour les premiers cas, cela est vite tombé aux oubliettes. Dommage, l’idée est bonne et aide à impliquer le public.

image

Enfin, nous avions prévu un « time boxing » de 15 minutes par cas. Je pense que c’est la bonne dose. Même si vu du côté du SAV, ce n’est pas si facile à tenir !

image

After !

Soat qui nous accueillait dans ses locaux proposait aussi les sandwiches pour se sustenter. Un accueil impeccable de bout en bout, je dois dire.

Hélas, je ne me suis pas tellement attardé, juste le temps d’échanger quelques mots avec les uns et les autres (et oui : seconde journée de formation le lendemain !). Le prochain rendez-vous devrait se caler vers la fin du mois prochain pour un « open-space de préparation du Scrum Day ». Annonce faite par Arnaud !

image

Entre-temps, ce même Arnaud nous aura organisé une Scrum Beer !

Cette soirée change résolument de ce que le Scrum User Group avait organisé jusque là ! L’agenda est probablement à adapter un peu. Nous avons été trop gourmands, je pense, concernant le nombre de cas. Mais le mot de la fin revient aux participants : voici leur appréciation :

image

La rentrée en open space !

Le par addinquydans Compte-renduLaisser un commentaire

Il n’aura pas fallu attendre longtemps pour voir notre premier rendez-vous agile de la rentrée. C’est d’ailleurs un agenda assez rythmé qui nous attend dans les semaines qui viennent !

Mais en ce 4 Septembre, c’est un open-space auquel Yannick nous a convié dans les locaux de Zenika. Beaucoup d’inscrits, peu de venus (environ une quinzaine), mais comme on dit dans les open spaces : les personnes qui sont là sont les bonnes personnes. Petit avantage : l’achalandage de notre place de marché va plutôt vite. C’est bien car ce sont 3 créneaux qui sont prévus pour ce soir !

image

1er round : où il est question de (non) estimations…

3 sujets sont proposés dans chaque tranche de temps, avec 45 minutes consacrées à chacune q’entre-elle ! Voilà, c’est parti.

image

Chaque groupe prend possession de son espace. J’avoue apprécier d’avantage les petits groupes de 5 comme c’est le cas ici.

Il faut faire des choix, parfois difficiles. Ce groupe a choisi d’aborder la définition de « done », un sujet pour lequel j’éprouve un certain intérêt … 

image

Je me décide finalement à rejoindre le groupe de Dov pour débattre du « no estimates ». Je me suis dit que cela faisait une bonne suite à ma rubrique de l’été : en finir avec les estimations !

image

J’ai été rapidement déçu par la direction qu’a prise la discussion, ou plutôt l’exposé que nous a fait Dov de son contexte. Outre que je suis plus intéressé par la discussion que par écouter une seule personne discourir, il ne nous parlait pas de « no estimates », mais plutôt de « diluate estimate » !

Supprimer les estimations « parce qu’elles font durer le planning meeting trop longtemps » sans changer la logique de travail entre le PO et l’équipe, c’est un peu mettre un sparadra sur un bobo. Certes, cela fait diminuer la pression … mais ce n’est pas du « no estimates ». Où plutôt cela l’est au sens littéral, comme quoi le terme n’est pas bon, du moins à mon avis.

Un avis apparemment partagé par Arturo ! Du coup, nous réorientons la discussion sur le changement de focus : la valeur et la définition de succès, du projet ou du rôle du product owner. Dans le cas du projet de Dov, on parle d’implémenter ce qui est dans le backlog : tant que l’on en est là, il n’y a pas de changement de logique et cesser d’estimer est futile, peut-être même malhonnête par rapport au client ?

J’aurais aimé avoir plus de temps pour creuser la question du changement de logique avec Arturo, mais le gong nous a rattrapé. Nous avons à mon goût passé bien trop de temps dans une direction qui ne m’intéressait pas. Oui, je sais j’aurais dû appliquer la loi des deux pieds. Mais le sujet m’intéressait et je préférais le rediriger dans une voie qui me convenait plus.

2nd round : Trop d’agile tue l’agile ?

Pour faire 3 round, Yannick nous a proposé un timing assez rythmé, pour ne pas dire serré. Ca ne laisse pas beaucoup de temps au partage ni au « slack », c’est un peu dommage.

image

Pour ce second round, je me suis joins à Renaud. Je ne suis pas fan de la manière dont il a exprimé le sujet. Peut-être même pas fan du sujet, d’ailleurs. Mais je me dis qu’au pire, il se prête assez bien au hacking !

Renaud s’étonne d’un certain nombre de sujets abordés dans le cadre de Scrum qui sont justement incompatibles avec Scrum. Sans aucun doute, il a raison. Renaud profite de l’occasion pour nous parler de Shu Ha Ri, cela vous rappelle-t-il quelque chose ?

Je ne vois pas trop où le « trop d’agile » intervient dans cette discussion, car on en arrive à évoquer le « Scrum by the book », ce qui est un peu normal quand on parle de Shu, mais pour le seconde fois de la soirée, je m’aperçois que ce n’est pas une direction de la discussion qui m’intéresse !

image

Le « trop d’agile », c’est pour moi trop se focaliser sur le fait de faire effectivement de l’agile au travers de telle ou telle pratique. Et s’intéresser à l’orthodoxie des pratiques (comme nous le faisons là), c’est se focaliser sur les choses qui sont au final inintéressantes. L’agilité est un moyen, c’est aujourd’hui devenu une fin ! On est d’ailleurs en train de parler « d’audit agile » dans cet ordre d’idée, une perspective que je trouve déplaisante.

Merci une fois encore à Arturo pour m’avoir épaulé pour chercher à explorer cette voie. Une fois encore je me trouve un peu frustré par le gong qui raisonne…

3ème round : Convaincre sur l’agile

Rapide partage avant le dernier round. Trop rapide encore. Hélas encore !

image

Nous commençons à nous dépeupler. Ce dernier round ne comptera que 2 sujets, le 3ème passera à la trappe : c’était le mien ! Mais il semble n’intéresser que peu de monde. Peut-être même personne.

Un débat plus intéressant cette fois autour d’un cas réel : quelle prise pour convaincre un management par ailleurs dans l’échec !

image

On a beaucoup parlé de construire un argumentaire, enquêter, chercher des éléments… Tout cela ne vas pas me convaincre. Plutôt que d’argumenter avec de grands mouvements de manche, pourquoi ne pas faire ? Quelle expérimentation mener pour prouver ? Quel investissement semble assez raisonnable pour essayer quelque chose ? Après tout si la situation actuelle ne marche pas …

image

Conclusions

Ce n’était pas la grande forme pour moi, ce jour-là. Mais je souligne 4 éléments à l’issu de cette soirée.

Un petit groupe pour l’open space et des petits groupes de 5 pour discuter, c’est plus convivial et plus interactif !

Le timing était un peu serré du fait de la contrainte que l’on se donnait sur les 3 tranches de temps. C’est dommage ! Je pense que j’aurais préféré deux créneaux de qualité avec un peu de mou et un temps de partage prolongé.

Un peu frustré par la direction prises par les deux premiers sujets. C’est nécessairement un point de vue personnel, je ne peux escompter que tout le monde partage la direction que j’aimerais faire prendre à la discussion.

Enfin, mon sujet n’a finalement pas été abordé. En soi, cela n’a aucune importance. Mais il s’agissait du seul sujet traitant de conception, de craftmanship. Lors des rendez-vous agiles, j’entends toujours des participants parler du TDD « il n’y a que ça de vrai » … mais traiter vraiment du coeur du sujet, en l’occurrence de la conception émergente, cela finalement n’intéresse personne. Est-ce la différence entre l’intention et la réalité ?