Bilan de l’année 2022

Comme tous les ans, voici ci-dessous le bilan de la tribu et de ses actions.

L’agile tribu est composée de 12 membres + 1 avec Moïra

Ce que nous avons fait

  • 14 formations données par les formateurs Agile Tribu
  • 7 journées ouvertes via meetup (via https://www.meetup.com/AgileTribu/events/past/)
  • 70 locations de salle rémunérées (formation extérieur)
  • Une participation à la conférence Flowcon (Conférence ou atelier)
  • Sponsoring Flowcon.

Les sujets que nous avons travaillés

  • Initiation de la conférence #demain
  • Reprise de l’activité après le COVID

Nos charges

Voici nos principales sources de dépenses cette année, soit prêt de 26 500€ :

Montant mensuelMontant unique
Loyer main d’Or1770
Electricité main d’Or40
Assurance main d’Or44
Internet main d’Or40
Gestion administrative300
WordPress – blog tribu4
Nom de domaine .fr et .com3
Meetup6
Sponsoring et intendance1000
Sessionlab13
Internet40
Total à l’année27 1201000

Les frais sont vraiment partagés entre tous les membres, avec une contribution libre et volontaire (via une feuille de calcul partagée entre tous les membres).

Product Owner et Proxy Product Owner

Article d’origine : http://yannick.ameur.free.fr/dotclear/index.php?post/agile/Product_Owner_Proxy_PO

De plus en plus d’organisation Agile sont confrontées au problème de la scalabilité des processus Agiles.

Safe, LeSS, Scrum Of Scrum, ScrumBan, Kanban et multi-flux

Je vous propose de redéfinir l’un des principes : la mis en place d’un Proxy Product Owner ou d’un Product Manager Owner (PMO).

Principe du Proxy Product Owner

Petit rappel : Le rôle du Product Owner

Définissons le mot Proxy

Dans le cadre plus précis des réseaux informatiques, un proxy est alors un programme servant d’intermédiaire pour accéder à un autre réseau

Pourquoi un Proxy PO

Le cadre de travail du Proxy PO est rattaché à la scalabilité d’un Produit nécessitant de le découper en plusieurs sous produits. Il faut de l’énergie et du courage pour être un facilitateur de PO et faire circuler l’information.

Rôle du Proxy PO (PPO ou PMO)

  • Etre au service des Products Owner
  • Défendre la roadmap, être le représentant des PO
  • Aider à trouver des solutions et à les mettre en place.
  • Il est le garant des processus mis en place au sein de l’équipe PO.
  • Canalisateur de l’information et de la transparence qui en découle.

Je rejoins le point de Bertrand présenté au ScrumDay 2011 ici.

L’objectif du Proxy PO :

  • Aider à la décision entre plusieurs PO ou trouver la ou les bonnes personnes pour prendre la décision.
  • Le Proxy PO Priorise la RoadMap mais il ne peut pas dire comment réaliser les sous produits,
  • Il est facilitateur et doit connaitre un maximum de personne pour orienter et aiguiller les PO : Aiguilleur du ciel.
  • Le PPO est sur le terrain avec les PO et donc il sait qui fait quoi dans la team de PO.
  • Comme pour une team de développeur avec son Scrum Master, chaque PO de son équipe va présenter les éléments de son produit aux CODIR et démos externes.
  • Facilitateur des autres PO (au préalable les autres PO lui auront donnés mandat de PPO), le Proxy Product Owner peut même être élu dans une équipe de PO par élection sans candidat.
  • Le PPO n’est pas obligatoirement hiérarchiquement supérieur au autres PO.
  • Avec le temps le proxy PO devrait disparaître, pour redevenir PO à plein temps, il devrait garder et gérer le sous produit le plus petit.
  • Le Proxy PO doit responsabiliser son équipe, l’équipe doit rechercher ses coéquipiers.

Contre exemples

  • Le PPO n’est pas un PO bouche trous (amicalement)
  • Certain MANAGER s’improvisent Proxy PO et confondent Proxy et Firewall…
  • Certain manager pratique le « Juste in time », traduisez par : Je te donne l’information au dernier moment (voir pas du tout).
  • Le Proxy PO n’est pas un PO secrétaire entre les équipes de dev et les responsables de marchés et/ou le métier (ex AMOA).

Pour finir la définition de votre Proxy PO est la vôtre dans le cadre de votre entreprise avec les contraintes qui sont les vôtres.


C’est ma vision biensur.

La Covid a tué le Marshmallow Challenge. Vive l’Agile Mind !

Tl;dr

Dans cet article je vous partage un atelier ludique que j’ai créé pour introduire l’agilité par les concepts d’expérimentation (droit à l’erreur / l’expérimentation), d’itération et d’apprentissage
Comment ? Je me suis inspiré du Mastermind (lien vers le jeu original), en faisant varier les règles.

L’Agile Mind se joue en 30–45 minutes par groupe de 3–4 en présentiel ou en ligne.

Après ce résumé en moins de 80 mots… Rentrons dans les détails 🙂

Histoire & contexte

Nous (L’agile tribu) animons pour l’un de nos partenaires (organisme de formation) une initiation présentielle à l’agilité sur 1 jour. Cette formation se veut très générique et se focalise sur la culture et l’état d’esprit. C’est un prérequis au reste du cursus de formation. Dans cette formation, nous utilisions le Marshmallow Challenge pour faire vivre aux participants le droit à l’expérimentation, les itérations rapides et l’apprentissage. Cet atelier était un choix explicite de l’organisme. 

Personnellement, j’ai trop vu le marshmallow challenge. Il est utilisé à toutes les sauces. Imaginez, vous arrivez en formation, prêt à découvrir des notions nouvelles et on vous sort un atelier que vous avez déjà vu. 3 fois. Décevant ? Je suis d’accord. Il m’est arrivé d’avoir la moitié des apprenants qui le connaissait. Ils s’ennuyaient sur cette séquence. 1 h d’ennui sur 8h de formation, c’est trop pour moi. Avec la Covid, j’ai sauté sur l’occasion pour concevoir une version en ligne du Marshmallow Challenge. Plutôt que de livrer à chaque apprenant des pâtes et un marshmallow, j’ai décomposé le marshmallow challenge pour créer un jeu qui aboutit aux mêmes enseignements.

Objectif pédagogique de l’Agile Mind

L’objectif pédagogique principal de l’Agile Mind est de faire vivre le droit à l’expérimentation et l’importance du feedback utilisateur. L’enseignement secondaire est de tester différents rythmes d’expérimentation (nombre de tests parallèles et durée du test).

Déroulé du jeu

Séquences

L’agile Mind se joue en 30–45 minutes par groupe de 3–4 en présentiel ou en ligne.

  1. Répartition par groupe de 3 à 4
  2. Explication des règles
  3. Partie 1 : 12 propositions et micro débrief
  4. Partie 2 : 2 fois 6 propositions et micro débrief
  5. Partie 3 : 6 fois 2 propositions et micro débrief
  6. Débrief global et apprentissage

L’atelier complet se compose de 3 parties. 

Règles

Atelier complet pour 1 équipe (Miro)

Les équipes doivent découvrir le besoin d’un client. Ce besoin est représenté par une combinaison. Une combinaison est une suite de 3 couleurs (doublons et triplons autorisés) parmi un ensemble de 6 couleurs.

Exemples de combinaisons valides et invalides:

Résumé des règles — Proposition

Chaque équipe aura 12 propositions de combinaisons par partie pour trouver celle du client (le facilitateur). Le client donne son feedback sous la forme de : nombre de couleurs bien placées, nombre couleurs présentes mal placées.

L’équipe gagne uniquement si elle propose la combinaison exacte (même couleurs, même ordre) du client en moins de 12 propositions.

Exemple de feedback du client
  • Déroulé de la première partie : les équipes donnent les 12 propositions d’un coup. Le client donne son feedback.
  • Déroulé de la seconde partie : le facilitateur définit une nouvelle combinaison. Les équipes testent 6 propositions, le client donne son feedback. Répéter une fois (12 propositions au total).
  • Déroulé de la troisième partie : le facilitateur définit une nouvelle combinaison. Les équipes testent 2 propositions et le client donne son feedback. Répéter jusqu’à 6 fois (12 propositions au total).
Résultat d’atelier en fin de partie (Miro)

Setup du jeu

Pour chaque partie : 1 tableau de 3 colonnes, 1 combinaison choisie par le client.

Setup d’atelier (Miro)

Débriefing

Je recommande de faire un bref débriefing (3min) à la fin de chaque partie puis de faire un grand débriefing (10–15 minutes) à la fin des 3 parties.

Comme le marshmallow challenge, il y a plusieurs axes possibles pour le débrief. Je vous laisse les choisir et/ou en mélanger. Les axes peuvent être :

  • Ressenti : Quel a été votre ressenti durant et après première itération (aucun feedback / partie à l’aveugle) ? Comment vous êtes-vous senti à chaque retour du client ?
  • Collaboration : comment avez-vous pris vos décisions ? Avez-vous tous pu vous exprimer ?
  • Stratégie et apprentissage : Pour les parties 2 et 3, quelles ont été vos stratégies sur les premières propositions ?
  • Rythme d’expérimentation : Avez-vous eu des stratégies différentes sur les parties 2 et 3 ? Auriez vous voulu un feedback plus rapide ?
  • Autres axes que vous allez proposer en commentaire de cet article 🙂

“Notre stratégie pour la première partie ? Le hasard. De toute façon on avait aucune chance” — Un participant

La première partie ressemble à un projet qui serait livré en 1 fois en essayant de toucher du premier coup un utilisateur. Spoiler : cela revient à un hasard complet. Il y a 216 combinaisons possibles. Avec 12 essais vous avez donc 5,5% de chance de trouver la combinaison sans feedback utilisateur.

“… 1 chance sur 20 de satisfaire notre utilisateur… C’est pas mal comparé à un vrai projet.”

Variante (en ligne / hors ligne), outils et conseil de facilitation

Présentiel

Cet atelier peut être fait en présentiel avec 1 feuille par équipe. Dans ce cas, je recommande de remplacer les couleurs par des lettres (combinaisons : [A,B,C], lettres possibles : A B C D E F) pour simplifier le matériel à prévoir et la lecture.

Distanciel

Cet atelier est agnostique (❤) pour l’outillage ! Vous pouvez utiliser n’importe quel outil.

Je l’ai joué avec Miro, Klaxoon, Mural, Draft.io, Excel (+partage d’écran) … et même en messagerie instantanée dans un contexte ultra sécurisé!

Pour améliorer la visibilité sur ces outils, vous pouvez créer le tableau et mettre des billes de couleurs à disposition des participants (cf image au dessus).

Timing

Je donne une contrainte d’une minute max par proposition (12 propositions : 12 minutes max, 2 propositions : 2 minutes max), cela permet de rythmer sans être trop contraignant. Dans tous les cas la première partie sera très rapide car… C’est qu’un jeu de hasard.

Si vous voulez faire moins de 30 minutes d’atelier vous pouvez faire uniquement les parties 1 et 2 (12 essais d’un coup, 2 X 6 essais). Dans ce cas, évoquez en débrief qu’on pourrait aller jusqu’à avoir du feedback à tous les essais et d’amener l’échange sur les notions de flow (coucou Kanban).

Détail du processus de conception de ce jeu

Si vous voulez savoir comment j’ai créé ce jeu (design, itération, simplification)… Voici un article qui l’explique !

Petit guide d’animation à distance

Après de nombreuses expérimentations, je vous propose ce petit guide pour vous aider à rendre vos ateliers ou formations à distance efficace et surtout agréable à tous.

ÉTAPE 1 : Créer un espace chaleureux

La distance rend les interactions potentiellement plus « froide » : moins de non verbal, une synchronisation plus difficile et plus la possibilité de discuter avec son voisin avant le démarrage pour créer du lien.

Il faut donc plus en faire en tant qu’animateur pour créer un cadre ou les participants vont se sentir à l’aise.

Lire la suite

Confinés mais formés : un retour d’expérience

Quand il y a un mois de ça, l’idée est apparue de transformer un cours sur l’agilité que je devais donner pour l’école Skema en cours distanciel, je dois avouer que l’idée ne m’a franchement pas emballé… Les étudiants sont un chouette public mais pas le plus facile : il est notamment plus difficiles d’avoir des interactions et de maintenir leur attention, que lors de formations professionnelles. Alors migrer un cours pour 44 étudiants ?

Choisir les bons outils

L’outil ne fait pas la pédagogie, mais dans le cas de la formation à distance avoir de bons outils va clairement participer à la qualité de la formation. Que ce soit pour le participant, pour qu’il se sente embarqué tout au long de la formation, que pour le formateur, si l’outil est simple et l’accompagne il sera plus détendu et plus à l’écoute des interactions plutôt que concentré sur la « technique ».

Pour ma part j’ai fait le choix de 3 outils principaux :

  • Zoom pour la vidéo. J’apprécie le fait de pouvoir avoir une mire des participants, le fait de pouvoir lever la main, le partage d’écran efficace, le fait de pouvoir streamer une vidéo et enfin surtout de pouvoir faire des groupes de travail et de pouvoir naviguer à l’intérieur des groupes.
  • Klaxoon pour tout ce qui est interaction globalement avec les participants. J’ai demandé aux participants de l’ouvrir à côté (onglet ou smartphone, tablette) et de le garder ouvert. J’en reparlerai plus bas mais vraiment Klaxoon est excellent pour garder le contact et pour pousser du contenu.
  • Draft pour les ateliers ou les participants sont libres de s’auto-organiser, de créer des boards par eux-même.

J’ai complété de temps en temps par un tout petit peu de framapad ou google docs pour de micro besoins (leur laisser créer des groupes par eux même par exemple ou produire un devoir évalué).

Avoir les bons outils et surtout se sentir à l’aise avec est pour moi indispensable pour que la formation se passe bien (un peu comme avoir une bonne salle bien équipée, pas surchauffée, peu bruyante dans un monde non confiné 🙂 ).

Lire la suite

Bilan de l’année 2019

Comme tous les ans, voici ci-dessous le bilan de la tribu et de ses actions.

L’agile tribu est composée des mêmes 11 membres (cf https://blog.agiletribu.com/2018/12/19/bilan-2018/ )

Ce que nous avons fait

  • 65 formations via nos partenaires
  • 12 journées ouvertes via meetup & 5 meetups ouverts en soirée (via https://www.meetup.com/AgileTribu/events/past/)
  • 19 locations de salle rémunérées (formation extérieur)
  • Une dizaine de participations à des conférences (Conférence ou atelier)
  • Sponsoring Flowcon et Agile Pays Basque
  • Nous avons désormais l’aide d’Emilie, assistante administrative, sur la répartition des frais de la tribu et sur tout l’administratif.
  • Un weekend de travail commun sur la tribu.

Les sujets que nous avons travaillés

Nos biens communs

Identique à l’année dernière (voir https://blog.agiletribu.com/2018/12/19/bilan-2018/ )

Nos charges

Voici nos principales sources de dépenses cette année, soit prêt de 26 500€ :

Montant mensuelMontant unique
Loyer main d’Or1770
Electricité main d’Or50
Assurance main d’Or30
Internet main d’Or40
Gestion administrative40
WordPress – blog tribu5
Nom de domaine .fr et .com3
Meetup5
Sponsoring et intendance3000
Sessionlab13
Total234723000

Cette année les frais sont vraiment partagés entre tous les membres, avec une contribution libre et volontaire (via une feuille de calcul partagée entre tous les membres).

Même

Pourquoi et par qui automatiser les TNR (tests de non régression) pour l’intégration d’un progiciel en TDS

La pyramide des tests impose de garder une bonne proportion de l’effort de test à réaliser sur son produit (produit réalisé en pratiques agile) :

Voici une très belle présentation du sujet par Damien Beaufils

Pyramide des tests

Ce que Damien nous montre est dans le cadre du développement de votre produit, mais comment faire si vous avez un produit non maintenue (legacy) et que vous devez faire des modifications ?
Comment faire si mon produit est basé sur un progiciel (logiciel propriétaire, sur étagère à paramétrer) dont je ne connais pas la qualité ?

Il faut mettre en place une chaîne de test TNR ( test de non régression) fiable et sécuriser avec vos scénarios les plus importants.
L’automatisation de vos tests de non régression permet de faire vivre votre produit dans un cycle agile afin de vous permettre de le modifier quand vous voulez et d’avoir un feedback immédiat pour mettre en production dans la journée.
Vous y gagnez du temps de réaction et réduirez votre coût de recette car votre équipe recettera uniquement les changements.
Dans le cadre du logiciel à intégrer dans votre entreprise , les paramétrages du logiciel doivent être sous le contrôle de tests automatisés.

Si votre produit est prioritaire, stratégique pour votre entreprise, vous comptez l’utiliser sur plusieurs années et le faire évoluer, vous devriez faire appel à un qualiticien expérimenté pour la mise en place des outils de tests et son DSL de test.

Deux approches de test à faire :
Via la couche API :
Si votre produit est récent, vous devriez avoir accès aux APIs des services du produit (rest, soap, client-serveur).
Cette méthode est privilégié car plus simple à mettre en place afin d’éviterez les temps de latence de la couche IHM ou le scripting sur l’XLM qui provoque souvent des faux-positifs.
Via la couche IHM :
Utiliser des robots via des scriptes pour remplir les champs et valider les résultats via votre IHM logiciel : voir Robot Framework ou Cucumber.

Dans votre stratégie de test, chaque paramétrage a un objectif de comportement du produit, c’est ce comportement que vous devez tester et que vous devez rendre testable.
Pour cela votre qualiticien basera ses efforts en suivant le pattern SOLID :

Responsabilité unique (single responsibility principle)une classe, une fonction ou une méthode doit avoir une et une seule responsabilité
Ouvert/fermé (open/closed principle)une entité applicative (class, fonction, module …) doit être ouverte à l’extension, mais fermée à la modification
Substitution de Liskov (Liskov substitution principle)une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme
Ségrégation des interfaces (interface segregation principle)préférer plusieurs interfaces spécifiques pour chaque client plutôt qu’une seule interface générale
Inversion des dépendances (dependency inversion principle)il faut dépendre des abstractions, pas des implémentations

Pourquoi un qualiticien pour réaliser votre stack de tests ?
Le plus compliqué n’est pas d’écrire le test ou de tester, le plus compliqué est de définir les bons outils à mettre en place pour tester votre produit, et ensuite de mettre en place une mécanique de test résiliant aux changements des données sur votre environnement de test et minimiser les faux-positifs.
Ensuite, son travail est de gérer l’effort à mettre dans chaque test par rapport à son ROI car rappelez-vous la pyramide de tests présenté par Damien plus haut, les tests d’IHM et d’intégration sont les plus chers à faire et maintenir.

C’est la mission du Qualiticien Agile afin de vous permettre de sécuriser votre produit avec la mise en place du BDD Behavior Driven Development ou pour nous ici du TDS : Test Driven Settings.

Si besoin, nous travaillons avec des partenaires experts dans la mise en oeuvre de l’automatisation de vos tests de non régression TNR.

Permaculture 2 ans après, le chemin – partie 1

J’évoquais dans l’article précédent (Permaculture 2 ans après, la découverte) comment une expérience très simple m’avait amené à découvrir la permaculture.
Dans celui-ci je vais essayer de retracer toutes les découvertes que j’ai fait, de livre en livre, de rencontre en rencontre, d’expérimentation en expérimentation.

Il se peut que ceci soit un brin décousu, mais je vais tâcher de faire au mieux 🙂

Permaculture & agroécologie

Ma première rencontre avec la permaculture se fait donc via le livre de Perrine et Charles Hervé Gruyère. Si vous souhaitez voir à quoi ressemble leur ferme je vous conseille de jeter un coup d’oeil à leur chaine youtube :

La permaculture c’est avant tout une philosophie, une manière d’être qui nous invite à revoir notre mode de vie. Je ne vais pas rentrer dans le détail car j’ai déjà écrit un article sur le sujet, que je vous invite à découvrir si vous ne l’avez pas encore lu : Pourquoi s’intéresser à la permaculture ?

Restons sur Youtube, quelques chaînes très intéressantes que j’apprécie beaucoup, tout d’abord celle de Damien Dekarz, Permaculture agroécologie etc… Damien est passionnant à écouter et restitue vraiment parfaitement la philosophie de la permaculture dans ses vidéos :

Lire la suite

Agile Tribu Enterprise

Espace, frontière de l'infini, vers laquelle voyage notre Enterprise Agile.
Sa mission : explorer de nouveaux mondes étranges d'entreprises libres, découvrir de nouveaux styles de vie, d'autres civilisations bienveillantes, et au mépris du danger et de l'Etat, reculer l'impossible de l'employabilité...
Espace, frontière de l’infini, vers laquelle voyage notre Enterprise Agile.
Sa mission : explorer de nouveaux mondes étranges d’entreprises libres, découvrir de nouveaux styles de vie, d’autres civilisations bienveillantes, et au mépris du danger et de l’Etat, reculer l’impossible de l’employabilité…

J’aimerais travailler dans une entreprise où je me sens moi avec des collègues qui partagent les mêmes socles de valeurs.

Cette entreprise nous permettra de grandir ensemble et de prendre du plaisir.

Yannick AMEUR

Notre raison d’être :

Participer à la création d’un concept d’entreprise Libre et Agile, devenir des équipiers et co-construire notre entreprise afin de travailler ensemble dans un environnement qui nous ressemble.

La Vision :

Une Structure Agile, équitable, exemplaire, transparente sur sa stratégie et ses chiffres, qui permet l’accompagnement de ses équipiers et la gestion collaborative de la vie de cette entreprise.

  • besoin de sens et de raison d’être,
  • besoin d’écoute,
  • être fier de faire partie de l’Agile Tribu Enterprise,
  • besoin d’être responsabilisé (adulte à adulte),
  • envie de partager des valeurs,
  • besoin d’être acteur dans son entreprise,
  • besoin de transparence sur tout,
  • besoin d’un engagement solidaire et d’investir sur la planète : pour soi, pour ses collègues, pour l’entreprise via des actions et non des promesses,
  • besoin d’exemplarité de l’entreprise, de ses collègues et de soi-même.

Les hypothèses issues des interviews de futurs équipiers

A qui adressons-nous cette entreprise Agile ?

A ceux qui veulent :

  • entrer dans un modèle salarié équitable en gardant de la liberté,
  • partager et compter sur des collègues réellement bienveillants,
  • avoir une gestion de l’administratif centralisée et commune,
  • travailler avec un ADN Agile et une culture ouverte en interne.

Ceci est la première version de la vision l’Agile Tribu Enterprise.
Merci à vous de venir participer et de nous aider à grandir.

Vous pouvez nous rejoindre via le MeetUp :
https://www.meetup.com/fr-FR/AgileTribu/