Catégorie : Apéros Agiles Montpellier

Le thème

Nous avions rendez-vous pour échanger au sujet d’Extreme Programming, que vous retrouverez raccourci dans cet article sous l’acronyme « XP ».

Le contexte

L’entreprise VitrineMedia, leader en communication digitale et affichage lumineux, à Castelnau-le-Lez, nous a hébergés gracieusement. Merci à eux pour leur accueil, ainsi que pour le buffet mis à disposition !

Nous étions 14 participants réunis le jour J autour de ce sujet, un public plutôt composé de développeurs, d’agilistes, et de développeurs agilistes. Les personnes présentes souhaitaient surtout découvrir XP ou approfondir leur connaissance du sujet. Ils cherchent à discuter plus concrètement d’XP afin de voir comment le mettre en œuvre au quotidien et améliorer la qualité de leur production.

Le déroulement

Marc Abegon, senior software engineer de profession et passion, nous avait préparé une présentation aux petits oignons sur le sujet, dont vous pourrez retrouver un aperçu via la carte heuristique ci-dessous.

Une fois la présentation de Marc suffisamment avancée, les participants se sont auto-organisés pour se répartir en petits groupes afin d’échanger sur une pratique particulière de XP. Chaque groupe a ensuite présenté le résultat de ses échanges.

Quelques photos sont visibles dans la galerie ci-dessous.

Propriété collective (« collective ownership »)

• Va de pair avec les notions de résilience, d’intelligence collective
• Impliquer de travailler de manière collaborative
• Apporte de la sécurité psychologique
• En revanche, certains membres de l’équipe peuvent craindre de se sentir dépossédés de leurs connaissances
• Cela nécessite d’être dans des conditions de sécurité psychologique pour être dans les conditions du partage

Développement piloté par les tests (« test driven development », ou TDD)

• Plus simple à mettre en œuvre sur du code backend
• C’est un investissement sur le long terme, il faut donc créer un cadre favorable à cette pratique
• Les suites de tests peuvent être considérées comme de la documentation vivante
• Les cas de test doivent être pertinents pour un maximum d’efficacité
• Comme on remanie le code régulièrement, il faut aussi remanier les cas de tests pour ne pas générer de la dette
• Cela peut s’avérer complexe à mettre en œuvre et nécessite une certaine expertise du sujet
• Le coût d’entrée peut être élevé, en particulier sur un système déjà en place et qui n’aurait pas été élaboré en TDD depuis le départ

Programmation en binôme (« pair programming »)

• Favorise le partage des connaissances et la montée en compétences avec du pair entre senior et junior
• Au-delà de l’effet “canard”, des visions différentes entre la pair de développeurs vont permettre d’aller plus loin dans la conception et l’implémentation
• La revue de code est “immédiate” et le navigateur va avoir un rôle de “garde-fou” par rapport au pilote
• Cela nécessite d’appliquer des règles d’organisation pour que l’exercice soit le plus efficace possible
• C’est un investissement sur le long terme pour la qualité
• C’est parfois difficile à accepter comme pratique de travail pour les personnes qui ont l’habitude de travailler en autonomie
• Cela peut être vu comme une perte de temps par la hiérarchie avec une personne qui semble “regarder” une autre travailler
• Le télétravail peut être un frein à la programmation en binôme, cela nécessite donc des outils adaptés pour le partage du code et le travail à deux
• La taille de l’équipe (trop petite, nombre impair, trop grande) peut avoir des effets négatifs sur l’organisation des pairs, il faut donc l’anticiper
• Parfois, le fait de travailler en pair peut être plus fatiguant/exigeant que le travail individuel

Rendez-vous au prochain Meetup !

Un grand merci aux personnes présentes pour la qualité des échanges, et rendez-vous mercredi 27 juillet pour un prochain Meetup !

Quelques liens utiles

• Retrouvez la page descriptive de cet événement sur le site Meetup.
• Ce sujet est celui qui avait obtenu le plus de votes sur le tableau Trello des apéros agiles.
• Plus d’infos sur le fonctionnement de nos apéros, c’est ici.
• L’entreprise VitrineMedia, leader en communication digitale et affichage lumineux, à Castelnau-le-Lez; nous a hébergés gracieusement. Merci à eux pour leur accueil, ainsi que pour le buffet mis à disposition !

Le thème

Ce mois-ci, nous nous sommes réunis pour échanger sur le sujet des certifications à l’agilité.

Le déroulement

Nous étions assez peu nombreux pour cet apéro, annoncé un peu à la dernière minute (7-8 de mémoire). Cela dit, les échanges ont été variés, argumentés et nous ont occupés pendant plus d’une heure et demi sans qu’on voie forcément le temps passer !

A noter que le groupe présent était composé de personnes avec des niveaux d’expérience très divers en agilité. Mais même parmi les personnes les plus expérimentées, tout le monde ne disposait pas forcément d’une certification. Deux participants seulement disposaient donc d’une ou plusieurs certifications à l’agilité, en particulier autour de Scrum, éventuellement de SAFe (Scaled Agile Framework).

Les paragraphes suivants n’ont pas vocation à être une bible sur le sujet de la certification. Ils essaient simplement de retracer brièvement les échanges qui ont eu lieu. Vous avez le droit d’être d’accord ou pas avec ce qui a été dit. Toujours est-il que les personnes présentes ont tâché de partager leurs points de vue dans un esprit constructif.

Pour les prochaines fois, venez participer aux débats !😉

Se faire certifier, ça apporte quoi ?

Plusieurs arguments ont été avancés.

La certification peut apporter un sentiment de légitimité. Celle face à un employeur, par exemple dans le cadre d’une recherche d’emploi. Il y a aussi celle face à un client, dans le cadre d’une prestation. Ou face à une équipe, pour se sentir rassuré.e quand on est remis en question, en tant que Scrum Master ou Product Owner par exemple, dans ses pratiques. Enfin, légitimité aussi pour une entreprise, par exemple ESN, qui chercherait à « placer » ses ouailles ou à s’afficher comme une entreprise avec un ADN agile.

La certification peut apporter un sentiment de sécurité. Quand on occupe certains rôles, comme ceux cités précédemment, on peut se retrouver un peu seul, à l’inverse de développeurs qui sont souvent plusieurs dans une équipe. Si en tant que Scrum Master, ou que Product Owner, je me plante, qu’est-ce qui se passe ? Qui peut redresser la barre à ma place ? Un peu comme le gardien de but qui n’a pas d’autre dernier rempart. Etre certifié peut nous rassurer quant à nos pratiques (sans que cela signifie qu’elles sont forcément bonnes…).

La certification peut apporter un vrai avantage sur le marché de l’emploi. Bonne chose ou mauvaise chose, la plupart des offres d’emploi pour recruter un Product Owner ou un Scrum Master aujourd’hui demandent une certification. Cela rejoint ce que nous écrivions quant à la légitimité vis-à-vis de l’employeur, précédemment.

Enfin, la certification reste quand même une machine à cash pour les organismes certifiants. Et quand certains organismes vendent pour un tarif plutôt accessible une certification valable à vie, d’autres n’hésitent pas à demander un renouvellement tous les ans, sans repasser un examen (à part celui d’arriver à saisir son numéro de carte bancaire), sous prétexte que « cela permet de voir les personnes qui sont réellement motivées ». Dans une société capitaliste, n’allons pas dire que tous les organismes certifiants sont des démons, cela reste un business comme un autre. Certains en abusent juste sans doute plus que d’autres.

N’est-ce pas dommage qu’autant de poids soit accordé aux certifications ?

Peut-être, surtout qu’après un certain nombre d’années d’expérience, la pratique terrain remplace sans commune mesure le fameux sésame obtenu après avoir passé un QCM de 80 questions.

Quand on a suffisamment bourlingué, le fait de se faire certifier ne devrait pas peser spécialement lourd. De la même façon qu’après dix années d’expérience professionnelle, on ne ressort pas forcément son CAP, son bac ou son diplôme d’études supérieures à chaque entretien d’embauche.

C’est à chacun de faire la part des choses : agilistes, mais aussi entreprises, et notamment les recruteurs qui doivent être en mesure de comprendre une telle chose.

Deux conseils pour nos lecteurs dans les ressources humaines seraient :

• savoir de quoi vous parlez, afin de pouvoir faire la différence entre les candidats sans vous appuyer uniquement sur la notion de certification : dans une équipe agile, qu’attend-on d’un PO ? d’un facilitateur ? d’un équipier ?
• vous appuyer sur vos équipes pour arriver à ce niveau de connaissance, par exemple par l’intermédiaire de sessions « vis ma vie » qui vous permettront de vous rendre compte des activités et qualités importantes dans vos équipes.

Parmi les personnes présentes pour ce Meetup, certaines avec beaucoup d’expérience en agilité ont d’ailleurs fait le choix de ne pas se faire certifier. Ce n’est pas quelque chose qui a eu un impact négatif quelconque sur leur carrière.

Quelles limites ?

Quand on parle de certification, on parle d’examen, et comme dans tout examen, on peut constater des dérives plus ou moins avouables.

Certaines personnes peuvent donc tout à fait se faire certifier « en groupe », avec quelqu’un qui peut les aider pendant le passage de l’examen, voire se faire compléter le QCM par une personne plus expérimentée. Cela les rendra-t-il de meilleurs agilistes pour autant ? Normalement, non.

Au-delà de ce genre de pratiques, il faut également bien comprendre qu’une certification acquise en 2010 par une personne qui n’aura pas pratiqué depuis n’a que peu de valeur. La personne peut avoir réalisé un sans-faute, l’expérience terrain accumulée par une autre personne non certifiée sur la même période aura énormément plus de valeur. Il faut donc faire attention à comparer ce qui est comparable.

Quoi qu’il arrive, passer une formation de qualité ne peut qu’être un bénéfice pour tout agiliste, débutant ou confirmé. De nombreux organismes proposent des formations à l’agilité aujourd’hui, en français, en distanciel ou en présentiel, avec des formats divers, allant de deux jours consécutifs à deux heures par semaine pendant dix semaines si on prend l’example de la formation proposée par Scrum Life.

Qui certifie ?

Si vous voulez vous faire certifier, il y a plusieurs organismes qui ont pignon sur rue. Si vous jugez qu’une information ci-dessous est inexacte, n’hésitez pas à nous le dire en commentaire, afin qu’on apporte une correction.

• Scrum.org a été créé par Ken Schwaber, co-créateur de Scrum. C’est un organisme américain. Il certifie, notamment, sur les rôles-clé de Scrum : developer, Product Owner, Scrum Master. Les certifications sont valables à vie et ne nécessitent pas de suivre une formation. Les tarifs sont plutôt accessibles (~200 USD). Les examens sont en anglais.
• Scrum Alliance a aussi été co-créé par Ken Schwaber, avant qu’il ne migre vers Scrum.org. Les certifications portent également sur les rôles Scrum. Elles sont valables 2 ans et nécessitent de suivre une formation via un formateur accrédité Scrum Alliance. Les examens sont en anglais.
• Scrum League est un organisme sur lequel nous avons très peu d’informations à ce jour. Il semblerait qu’il s’agisse d’une société francophone, avec des examens en français. Les certifications sont valables à vie et coûtent moins cher que via Scrum.org (80 à 120 €). Il n’est pas évident que cet organisme bénéficie de la même reconnaissance sur le marché que les deux précédents.
• Scaled Agile, Inc. est l’organisme derrière le framework Scaled Agile Framework (SAFe). Ils certifient sur à peu près tous les rôles susceptibles d’exister dans une entreprise agile (en grossissant à peine le trait). A l’inverse des trois premiers, ils certifient les connaissances acquises sur le framework SAFe, et non pas Scrum. Passer l’examen exige de suivre une formation au préalable par un formateur accrédité de niveau SAFe Program Consultant ou supérieur.

Rendez-vous au prochain Meetup !

Un grand merci aux personnes présentes pour la qualité des échanges, et rendez-vous mercredi 22 juin pour un prochain Meetup !

Quelques liens utiles

• Retrouvez la page descriptive de cet événement sur le site Meetup.
• Ce sujet est celui qui avait obtenu le plus de votes sur le tableau Trello des apéros agiles.
• Plus d’infos sur le fonctionnement de nos apéros, c’est ici.
• Nous avons été hébergés gracieusement par la Baraka Jeux à Odysseum. Merci à nouveau à eux pour leur accueil !

Le thème

Ce mois-ci, nous avons pratiqué un atelier nommé « matrice des attentes » ou « matrice des attendus ». Vous pouvez trouver plus d’informations sur cet atelier à cet endroit (atelier-collaboratif.com) ou encore ici (post LinkedIn de Jean-Christophe Pagès).

Ce sujet est celui qui avait obtenu le plus de votes sur le tableau Trello des apéros agiles. Plus d’infos sur le fonctionnement de nos apéros, c’est ici.

Le déroulement

De retour au distanciel suite aux dernières recommandations sanitaires, nous avons pu vivre cet atelier via un mix d’outils collaboratifs :

• Gather pour la visio-conférence, car c’est un outil qui permet très facilement la répartition en sous-groupes et la possibilité pour tout le monde de naviguer d’un sous-groupe à l’autre ;
• Mural pour le tableau collaboratif construit en séance.

En cette période précédant les fêtes, l’histoire de départ était (en accéléré) la suivante.

Le Père Noël a généralement une équipe qui travaille avec lui pour la distribution des cadeaux. Mais malheureusement cette année, son équipe ne pourra pas assurer cette mission ! En urgence, vous voilà prêts à prendre leur place. Cinq rôles sont prévus : le Père Noël, la Mère Noël, les lutins, les rennes et la Poste. Comment allez-vous vous répartir les tâches ? Quelles sont les activités que chacun de ces groupes devrait accomplir ?

L’atelier a été découpé en plusieurs étapes :

1. répartition des participants dans différents groupes, chaque groupe se mettant dans la peau d’un des rôles prévus ;
2. temps d’échange au sein de chaque groupe (environ 15 minutes) avec l’objectif de répondre à la question : qu’attend-on de la part de tous les autres groupes dans le cadre de notre mission ? qu’est-ce que chacun des groupes devrait faire ?
3. retour de tous les groupes dans la « salle principale » et partage des attendus de chaque groupe envers les autres ;
4. clarification des attentes pas forcément bien exprimées ou comprises ;
5. retour de chaque groupe dans sa zone de travail et réflexion quant aux attentes exprimées par les autres groupes envers eux, afin d’identifier celles sur lesquelles nous sommes en désaccord.

La dernière étape qui n’a pas été réalisée afin de pouvoir profiter d’un temps d’échange plus loin consistait normalement à faire discuter ensemble les groupes en désaccord, afin de trouver un terrain d’entente.

Au fur et à mesure des différentes étapes, les groupes ont construit collaborativement un tableau de management visuel :

La vision en lignes et en colonnes est très pratique, car elle permet de visualiser « tout ce qu’on attend de nous » (en colonnes), « ce que nous attendons de tout le monde » (en lignes), « ce que le groupe X attend de nous » (à l’intersection d’une ligne et d’une colonne).

Le management visuel nous permet, par exemple en changeant la couleur des post-its, d’identifier très rapidement les points de désaccord entre les groupes, facilitant leur traitement. L’objectif est justement de se mettre d’accord, donc de transformer les post-its rouges en post-its jaunes par le biais des échanges.

Nous avons pu échanger sur la mise en pratique de cet atelier en conditions réelles. Il est important :

• de prendre le temps (compter bien 2 heures pour un groupe d’une dizaine de personnes) ;
• d’avoir un facilitateur ou une facilitatrice dédié.e (permet de prendre du recul et de ne pas se focaliser sur « ses » activités) ;
• de comprendre qu’on ne règlera pas forcément tous les désaccords en séance (au moins, ils sont identifiés, et les groupes concernés peuvent les résoudre ultérieurement).

Cette matrice peut aussi évoluer au fil de la vie de l’équipe qui doit travailler ensemble, afin de toujours être à jour vis-à-vis du mode de fonctionnement de l’équipe.

Merci à toutes et tous !

Nous étions entre 15 et 18 personnes selon les moments dans ce dernier atelier de l’année. L’équipe d’organisation voudrait remercier toutes les personnes présentes pour leur implication, leur bonne humeur et leurs nombreuses contributions pour rendre cet apéro encore plus intéressant !

Et nous vous souhaitons de passer de très bons moments en cette fin d’année 2021. A l’année prochaine !

Le thème

Ce mois-ci, l’objectif était de faire découvrir Kanban via l’intermédiaire du jeu Pizza Kanban Game, dont vous pouvez découvrir la teneur sur le site du créateur du jeu Agile42.com, ou ici en français sur le site oyomy.fr.

Ce sujet est celui qui avait obtenu le plus de votes sur le tableau Trello des apéros agiles. Plus d’infos sur le fonctionnement de nos apéros, c’est ici.

Le déroulement

Les participants (environ 16 hors facilitateurs) étaient répartis en deux équipes.

Le jeu, animé principalement par Maxime, s’est déroulé en quatre étapes.

Une première itération pendant laquelle il était demandé aux équipes de produire un maximum de parts de pizza, sans plus de consigne. Cette étape a conduit chaque équipe à produire énormément de gaspillage, avec des quantités incroyables de jambon et d’ananas produites à l’avance et inutilisées.

Une seconde itération a vu les équipes matérialiser leur processus Kanban (délimitations sur la table) et utiliser le débrief de la première phase pour s’améliorer. Il en a résulté quasiment aucun gaspillage et une capacité accrue à produire.

La troisième itération a vu l’apparition d’un nouveau type de pizza (la Rucola, à la roquette), mettant à mal le processus des équipes, qui ont dû s’adapter à la volée.

La quatrième itération leur a permis de s’améliorer une nouvelle fois après le débrief.

Entre la première et la deuxième itération, une présentation théorique de Kanban en une vingtaine de minutes a permis de réaligner tout le monde sur les fondamentaux de cette approche :

• Commencer par le processus tel qu’il est réellement
• Visualiser le flux
• Limiter le travail en cours
• Implémenter du flux tiré plutôt que du flux poussé
• S’améliorer au fur et à mesure

Et les trois itérations suivantes ont donc permis de mettre en pratique ces fondamentaux.

Merci à toutes et tous !

Nous étions presque une vingtaine ce mercredi 27 octobre pour notre second apéro en présentiel de l’année. L’équipe d’organisation voudrait remercier toutes les personnes présentes pour leur implication, leur bonne humeur et leurs nombreuses contributions pour rendre cet apéro encore plus intéressant !

Pour aller plus loin

Quelques ressources intéressantes dont nous avons parlé ce mercredi soir :

• Un excellent ouvrage sur Kanban signé Laurent Morisseau et Pablo Pernot : Kanban, l’approche en flux pour l’entreprise agile
• Une vidéo de Scrum Life sur comment Tesla met en application des principes différents de Toyota pour gagner en réactivité et en productivité : Tesla, SpaceX : AGILE/SCRUM poussé à l’EXTRÊME ! Retour d’expérience JOE JUSTICE

S’il y a d’autres ressources à lister ici, n’hésitez pas à laisser un commentaire ci-dessous 😉

Toutes les photos

Le thème

Scaling Agile – Tour d’horizon (SAFe, DAD, LESS, Nexus, SoS…)

L’idée était de présenter, et d’échanger sur, différentes approches d’agilité à l’échelle afin de pouvoir à la fois avoir un tour d’horizon assez complet de ce que propose le marché et de pouvoir les « comparer ».

Cette session impliquait d’avoir une bonne base sur les concepts agiles et les pratiques associées.

Le déroulement

Après un petit sondage pour mieux connaître nos participants et poser le cadre, Benoît a fait une présentation de diverses approches de mise en œuvre d’agilité à l’échelle de l’entreprise. Les questions, au fil de l’eau, ont permis d’échanger sur certains points concrets.

Comme d’habitude, le cadre était le suivant :

Une nouveauté pour cette édition, nous avons utilisé l’outil Gather, qui permet de « gamifier » l’environnement, d’échanger de façon informelle en petits cercles, etc.

Les approches qui ont été évoquées, dans cet ordre en fonction des votes des participants :

• LeSS – Large Scale Scrum
• Scrum of Scrums
• SAFe – Scaled Agile Framework
• L’approche mise en oeuvre chez Spotify

Nous aurions aimé avoir le temps d’aborder d’autres sujets, mais nous avons priorisé et n’avons donc pas pu en discuter :

• DAD – Disciplined Agile Delivery
• Nexus
• Scrum@Scale

Hé oui ! Durée fixe (2 heures), ressources fixes (nous), donc le périmètre est forcément variable.

Merci à Benoît qui a mis à disposition le support de sa présentation !

ROTI

Si vous avez participé à l’apéro et que vous voulez faire part de votre satisfaction ou insatisfaction, on vous lira quoi qu’il arrive ! C’est par ici !

Et pour voir les résultats sans voter, c’est par là.

La prochaine fois…

Les thèmes des apéros agiles sont choisis au fur et à mesure, en fonction des idées que VOUS nous donnez !

La page sur les Apéros Agiles Montpellier explique comment ça se passe. Alors n’hésitez pas, et on espère vous revoir très bientôt.

Le prochain Apéro Agile n’aura exceptionnellement pas lieu le quatrième mercredi du mois de mars, mais le troisième. Ce sera donc le mercredi 17 mars à 18h30. Ce sera sous un format forum ouvert : venez avec VOS sujets, on constituera l’agenda en séance pour parler de ce qui vous intéressera au moment voulu !

Quelques liens en relation avec le sujet traité lors de cet apéro

• Le State of Agile Report donne quelques indicateurs sur les approches d’agilité de l’échelle
• Scaling Agile, dans lequel Henrik Kniberg explique le cheminement de Spotify vers une organisation et une culture agile
• Le REX fait par Le Bon Coin autour de leur implémentation de Spotify
• Une conférence passionnante de Frédéric Laloux autour de l’évolution des cultures d’entreprise et du management, Reinventing Organizations
• Le site de LeSS
• Le site de SAFe

Le thème

Ce mois-ci, nous vous proposions un moment d’échange autour de la version 2020 du Scrum Guide, parue en novembre dernier, et qui apporte quelques changements par rapport à la version 2017.

Qu’est-ce qui change ? Pourquoi ? Pensez-vous que ce soit pour le meilleur ou pour le pire (ou que ça ne changera finalement pas grand-chose) ?

Le déroulement

Merci aux participant.e.s !

Un petit mot sur l’état d’esprit…

Sondage

Quel est votre poste actuel ? Votre connaissance de Scrum ? Vous référez-vous au guide Scrum ? Toutes ces questions ont permis d’échanger très rapidement sur ce qu’est Scrum, le guide Scrum, et de constater que nous avions un public large, pas forcément issu de l’IT et pas forcément connaisseur de Scrum !

Six grands changements

Nous avions listé six grands changements mis en avant dans le Scrum Guide 2020 (version Web en anglais ici, version PDF en français ici) (il y en a d’autres, mais ceux-ci ont été particulièrement mis en avant ici).

Après une explication brève des changements, les personnes présentes ont voté sur les sujets, pour définir dans quel ordre ils allaient être abordés.

Travail en petits groupes et débrief

Les participants se sont organisés en petits groupes de travail (3 à 8 personnes en fonction des sujets) pour échanger pendant 10 minutes de chaque sujet (trois sujets en parallèle).

Après cette séparation en sous-groupes, chaque sous-groupe a restitué aux autres en 5 minutes le contenu de leurs échanges, afin de donner à chacun.e une vision d’ensemble.

C’est ce que vous pouvez voir dans la zone inférieure du tableau Mural.

ROTI

Si vous avez participé à l’apéro et que vous voulez faire part de votre satisfaction ou insatisfaction, on vous lira quoi qu’il arrive ! C’est par ici !

Et pour voir les résultats sans voter, c’est par là.

La prochaine fois…

Les thèmes des apéros agiles sont choisis au fur et à mesure, en fonction des idées que VOUS nous donnez !

La page sur les Apéros Agiles Montpellier explique comment ça se passe. Alors n’hésitez pas, et on espère vous revoir très bientôt.

Le thème

Vous connaissez Scrum ? Vous connaissez les Lego ? Vous avez déjà entendu parler du Lego4Scrum, ce jeu qui permet d’expérimenter Scrum dans le cadre d’un jeu avec des briques Lego ?

Avec la distanciation physique, difficile de jouer à un Lego4Scrum ces derniers temps. C’est pour cela qu’on vous propose une version « numérique » du jeu, le Pixel4Scrum, qui se jouera… sans Lego. On revient donc à un mode « chacun chez soi » malheureusement, un mal nécessaire en ce moment.

Vous jouerez avec une équipe à la construction d’une ville virtuelle en utilisant les principes de Scrum, et en utilisant un outil numérique que vous découvrirez le jour J (mais que vous avez probablement tous déjà utilisé !).

Si vous connaissez les principes de Scrum, c’est mieux, mais sinon, ce n’est pas grave, on est là pour découvrir en jouant. Si vous avez déjà joué à un Lego4Scrum, et que vous en connaissez donc les ficelles, préparez-vous à être dans un rôle un peu différent du reste du groupe lors de cet atelier. Il n’y a pas de prérequis en termes de matériel : un PC et une connexion Internet suffiront. Et évidemment, c’est un apéro agile, donc prévoyez un petit verre (pas forcément alcoolisé évidemment, on rappelle que l’abus d’alcool est dangereux pour la santé).

Le jeu est un peu long, donc on commencera à l’heure pour pouvoir finir à l’heure également. Merci pour votre compréhension 😉

Le déroulement

Nous étions 22 à jouer, chacun chez soi évidemment, une même partie de Pixel4Scrum. 4 équipes composées de 4-5 bâtisseurs ont eu fort à faire pour satisfaire M. le Maire (Benoît), dont les requêtes farfelues n’avaient de pair que le magnifique costume, casquette comprise, qu’il portait pour l’occasion.

La plupart des joueurs présents ce mercredi connaissaient déjà bien Scrum, mais très peu avaient déjà joué au Lego4Scrum, voire animé des parties. Cela a donc été l’occasion de la découverte de la version numérique de ce jeu, jouable avec un seul outil rassemblant la gestion des exigences, la planification, la construction et la phase de rétrospective : l’incroyable Google Sheets, pour reprendre les mots de M. le Maire, pas peu fier de l’outillage mis à disposition des bâtisseurs.

Après une première phase de présentation des exigences, les équipes se sont réparties le travail afin de maximiser l’apport de valeur et ont itéré dans le respect du framework Scrum. Réunions de planification de sprint, phases de construction, revues de sprint et rétrospectives de sprint ont rythmé les deux heures du jeu, qui sont passées très vite au vu du ROTI. Les bâtiments ont vu le jour de façon progressive, peuplant une cité jusqu’alors bien vide, et donnant le sourire à un Maire satisfait du travail des équipes.

Merci à toutes / tous les participant.e.s pour votre présence et merci de vous être prêté.e.s au jeu ! On espère vous voir bientôt pour un prochain apéro agile !

Vous voulez jouer au Pixel4Scrum ?

Ce jeu est une version numérique du Lego4Scrum qui a été conçue par Elie Théocari dans le cadre de son travail de coach et formateur agile chez l’entreprise SmartView, à Montpellier, et qui a été améliorée grâce à de nombreuses personnes depuis, notamment les membres de l’association Agile Montpellier.

Il est mis à disposition de toutes les personnes qui souhaitent l’utiliser ou le modifier, même dans le cadre d’une utilisation commerciale (équivalent licence Creative Commons CC BY 4.0. Il est très probable qu’il évolue dans le futur, en fonction des feedbacks que nous recevrons et que nous vous invitons, dans le même esprit, à partager avec le plus grand nombre.

Vous retrouverez à cet emplacement le plateau de jeu et un document PDF que nous vous invitons à lire si vous avez l’intention d’animer une partie, ou d’en savoir plus sur le jeu.

« ‹ de 2 › »

Le thème

Et si vous étiez plus agile que vous ne le pensez?

Quels sont les valeurs, principes et techniques pour développer l’adaptation, la collaboration et l’apprentissage dans une organisation agile ?

Quels que soient vos situations, métiers ou secteurs d’activité , découvrez le Manifeste Agile et expérimentez la discussion en Fish Bowl.

Pour cet événement de rentrée nous vous proposons de découvrir un lieu : « La Halle Tropisme » et d’échanger sur l’agilité avec des personnes de différents horizons artistiques et culturels : graphistes, communicants, TV, spectacles, agences d’attachés presse, réalité virtuelle, animation 3D, studio de danse, yoga, formations autour de la culture…

Les informations d’accès à la Halle Tropisme :
https://www.tropisme.coop//pratique

Si vous souhaitez partager votre expérience, prendre du recul sur vos pratiques, ou tout simplement, découvrir de nouveaux horizons, rejoignez nous !

Le déroulement

Les participants, répartis en trois groupes, ont discuté autour des valeurs du Manifeste Agile. En raison du nombre moins élevé que prévu, le format fish bowl a été abandonné pour revenir à une discussion sur un format plus classique.

Chaque groupe (6-7 personnes) a échangé pendant 20 minutes sur une valeur donnée, avant de changer de pièce pour aborder une nouvelle valeur.

L’important est que chacun.e a pu s’exprimer sur les trois valeurs que sont :

• Les individus et les interactions plutôt que les processus et les outils
• L’adaptation au changement plutôt que le suivi d’un plan
• La collaboration avec les clients plutôt que la négociation contractuelle

En restitution, l’accent a été mis sur le fait que ce sont les quatre valeurs, ensemble (avec également un logiciel opérationnel plutôt qu’une documentation exhaustive), qui permettent le fonctionnement agile que l’on connaît aujourd’hui.

Les échanges avec des personnes hors des métiers du logiciel, qui était le facteur différenciant de cet Apéro, ont été très intéressants (mais ceux avec les personnes habituelles aussi, évidemment 😁).