agile

Product Owner et Proxy Product Owner

| Yannick Ameur

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.

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

| Yannick Ameur

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.

Agile Tribu Enterprise

| Yannick Ameur
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/

Chaîne de valeur : comment la définir ?

| Yannick Ameur

La chaîne de valeur dans votre Produit ou dans votre entreprise est spécifique, donc je vous propose une solution à adapter avec si possible un coach Agile.

La recherche de chaînes de valeurs est pour moi la résultante d’un système complexe dans certain grand groupe, ou dans des contextes de Produits imbriqués nécessitant une gestion scallée des équipes.
Quand les membres d’un système ne comprennent plus ce qu’ils apportent comme valeur dans le système : quêtes de sens, responsabilités, valeurs.

Voilà donc une façon d’aborder la définition d’une chaîne de valeur(s).

Merci à Béatrice Kreng d’avoir scribé la Chaîne de Valeur

Définition de la chaîne de valeur : la chaîne de valeur est l’ensemble des produits et des personnes qui participent à la réalisation de votre Epic.

L’Epic est une fonctionnalité Macro à réaliser, elle peut se découper en plusieurs Users Stories.

Release glissante : c’est un ensemble d’Epic qui représentent 3 mois de production estimée des Produits de votre système.

Chaque Epic doit aller en production le plus rapidement possible et permettre à une nouvelle Epic de rentrer dans la release, d’où la notion de Release Glissante.

Lire la suite →

Agile Framing

| Yannick Ameur

Le Framing Agile donne du sens à nos initiatives de BootCamp et des starterKit Agile qu’AgileTribu a lancé ces dernières années.

Le Framing Agile est née de différente aventures initialisées avec Nathaniel Richand, poursuivi avec Judicael Paquet lors de nos missions communes.

Judicael à réussi à formaliser les réflexions sur : comment industrialiser le bootstrapping de Produit Agile avec Agile Framing sur son blog MyAgilePartner :

framing-agile-2

Bravo pour cette synthèse que nous partageons et qui évolue avec les différents coach, clients, Produits, tests réalisés autour des différents éléments du Framing.

Je conseils de lire les articles liées ici :

https://blog.myagilepartner.fr/?s=framing

A suivre pour 2019.

Chaîne de valeur pour l’entreprise et le Produit

| Yannick Ameur

Actuellement, l’agilité sur la création ou la gestion de Produits se concentre sur la valeur pour nos utilisateurs.

La valeur ?

La valeur se représente le plus généralement en :

  • Valeur monétaire :
    Quels sont les gains potentiels de cette fonctionnalité, si nous la réalisons ?
  • Valeur de gain de temps : 
    Comment pourrions-nous réduire le temps entre le paiement et la livraison ?
  • Valeur émotionnelle :
    Comment créer une relation durable avec nos clients ?
    Qu’est-ce qui permet à notre client d’être satisfait de notre application ?
  • Valeur de réputation :
    Comment faire pour communiquer sur nos succès ?

Les agilistes vont vous pousser à valider vos hypothèses :
Comment pouvons nous démontrer que nos utilisateurs utiliseront cette fonctionnalité ?

Ici, je présente un processus d’accompagnement traditionnel pour les coachs agile qui cible un Produit pas trop complexe avec une à deux équipes.

Alors comment gérer le passage à l’échelle ? Spotify, Safe, Nexus …

Spotify est souvent mis en avant comme l’exemple à suivre, mais de quoi parle ton ?
On parle du premier modèle qui a fait son succès avec les tribus, les chapitres et les guildes :

Screenshot-2017-11-16-spotify-engineering-culture-part1-jpeg-Image-JPEG-5000-×-2700-pixels1-1024x581

Cependant la réalité est différente :

  1. Spotify est un service suédois de streaming musical sous la forme d’un logiciel propriétaire et d’un site web. Donc votre organisation ou votre produit n’est pas Spotify.
  2. Spotify n’est plus sur ce modèle… (la version présenté en conférences à depuis bien évolué, Spotify ayant expérimenté et appris beaucoup de nouvelles choses).
  3. Spotify à l’Agile c’est comme Toyota au Lean : c’est avant tout une culture d’entreprise et le développement de leurs modèles de travail pour eux et utilisable chez eux.
  4. Spotify a aussi aplatis la pyramide managériales MAIS ensuite la re-créé en rapport à leurs besoins.

Tout ceci n’est pas nouveaux pour les connaisseurs, Je vous invite à lire cette article : Ne copiez pas le modèle Spotify .

Alors comment passer à l’échelle ?

J’aimerais vous faire réfléchir à un autre axe si vous souhaitez construire votre modèle comme Spotify, alors vous devez penser à votre entreprise comme un organisme vivant de grande taille avec des équipes qui se croisent, s’entrechoquent ou s’ignorent.  La transformation est donc organique et elle se structurera autour de la chaîne de valeur intrinsèque dans votre organisation.

Comment travailler ses Chaînes de valeurs ?

Il faut apprendre à écouter son organisation, redécouvrir les cellules qui l’a font vivre.
Ensuite vous devez faire confiance à ses organes, les consultants sont bons pour aider mais se sont vos collaborateurs qui font la richesse de votre organisation et son avenir.

À la tribu, nous avons co-créé un atelier de prise de conscience et d’acculturation pour vous aider dans vos organisations à démarrer une démarche « chaînes de valeurs » : http://www.agiletribu.com/contenu.html?uid=atelier-poupee-lego

ChaineDeValeurDansLEntreprise

Notre proposition est de réaliser cet atelier dans votre organisation et ensuite de vous accompagner dans une démarche de co-création et co-apprenance pour permettre de mettre en place :

  • vos chaînes de valeurs
  • une organisation organique et mobile avec des équipes BizSecDevOps : équipe représentante l’ensemble des acteurs d’une chaîne de valeurs
  • un recrutement par les pères et de la formation pour vos équipes par les membres de votre organisation
  • la gestion du bien être du collaborateur au sein de sa chaîne
  • une vision Permagile de votre organisation.

L’Agile Tribu est là pour vous aider à transformer votre organisation vers une organisation apprenante, responsable, proche de ses valeurs et de sa vision.

Contactez-nous : contact@agiletribu.com

ScrumBan en Action

| Yannick Ameur

Why de l’article

Je ne trouve pas sur le web de définition du ScrumBan qui me satisfasse.

How

J’ai cherché à avoir un schéma proche des habitudes Scrum mais plus orienté ScrumBan.
Mais la littérature web ne montre que des images de board Kanban.

What
ScrumBan

 

Quelques explications :

Pour rester simple, cela représente un flux continu avec en entrée le backlog qui est entretenu par le processus ScrumBan et en sortie l’incrément qui est alimenté en continu comme en méthode Kanban.

La particularité du flux ScrumBan, quelque soit votre workflow, est que vous devez réaliser les actions en « just in time ».

Le ScrumBan est un mélange de Scrum (cérémonies et sprint) et Kanban (le flux tiré, la gestion des limites du travail en cours, du just in time ..) adapté à l’équipe et par l’équipe, dans mon cas voici la description des actions de notre flux :

  • Pas de sprint planning en début d’itération, mais des cérémonies d’affinage pour lever les loups entre analyste / dev
  • et des cérémonies d’estimation pour valider le ready d’une user story.
  • Nous avons gardé la rétrospective de fin d’itération.
  • Nous avons des rétrospectives technique.
  • La mise à disposition des US Done sont délivrées toutes les nuits, via le déploiement du ‘master‘ du gestionnaire de code source.
  • Nous avons aussi gardé le sprint review de fin d’itération pour communiquer vers les clients et sponsors les réalisations Done du Sprint.

Quand déclencher une action just in time ?

Quand une limite est atteinte ou quand le flux tiré le demande.
C’est à dire pour nous quand la limite de 3 US dans la file « A affiner » ou quand la file « Prête pour dév » est vide, alors nous déclenchons un atelier d’affinage ou d’estimation.

Un des objectifs de l’équipe et du coach est d’avoir un flux équilibré et fluide.

Vous pouvez lire le livre de Laurent Morisseau Kanban pour l’IT.

Dans mon cas, le kanban commence de la planification des prochaines études et fini à la mise en place de la feature dans le master de notre GitLab.

Vous pouvez lire l’article de Martin Fowler sur le FeatureBranch.

Je serai ravi de discuter avec vous de ce sujet à un Meetup Agile Tribu ou lors d’un BBL.

Un bon Debrief de jeux Agile

| Yannick Ameur

Happy_Game

Lorsque vous jouez un jeu agile avec vos équipes :

  • ice breaker,
  • Serious Game
  • ou encore un jeu d’apprentissage

Il est préférable de  préparer, en amont, ses questions de debrief. Elles doivent suivre le cheminement intellectuel suivant pour amener les membres de l’équipe à tirer du jeu des changements concrets  :

  1. Evoquer les sentiments et les émotions pour établir un climat de confiance et les mettre en condition pour accueillir le changement (y compris dans leur corps) : qu’est-ce que vous avez ressenti durant le jeu ?
  2. Mettre au jour les difficultés rencontrées et les succès atteints : est-ce que vous avez réussi ? Quels sont les problèmes que vous avez affrontés ? Comment les avez-vous surmontés ?
  3. Pousser l’équipe à faire des analogies avec leur quotidien : est-ce que vous voyez des similitudes entre ce que vous avez vécu pendant le jeu et votre vie d’équipe ?
  4. Amener les participants à utiliser les enseignements du jeu : qu’est-ce que cela vous a donné envie de mette en oeuvre dans votre fonctionnement d’équipe ?

Afin de pousser  l’équipe à mettre en oeuvre les changements identifiés pendant le jeu, nous vous encourageons à garder une trace écrite du débrief, un simple paperboard avec les éléments clés est suffisant, et d’afficher cette trace dans un lieu de vie de l’équipe. Vous pouvez aussi donner les objets utilisés pendant le jeu. L’équipe se fera une joie de les ressortir pendant leur quotidien, ce qui facilitera l’ancrage.

Pendant le débrief, ménager des silences et créer de l’espace pour que les plus introvertis puissent également partager leurs impressions. Ne pas hésiter à gentiment proposer aux extravertis de laisser la parole aux autres. Pendant les silences, inviter du regard ceux qui n’ont pas encore parlé. Cependant, la prise de parole de tous n’est pas indispensable, d’autres occasions pourront se présenter ultérieurement. Dans le cas où, l’ensemble de l’équipe reste peu loquace, prendre 5 minutes pour que les participants écrivent leur débrief avant de partager tous ensemble.

Suite au debrief des participants, un coach partage souvent ce qu’il a perçu du jeu et du fonctionnement de l’équipe (uniquement de l’observation, effet miroir). Il peut aussi aller plus loin et proposer des parallèles avec le vécu des participants.

Co-écrit par : Loïc Delcros, Thibaut Appert, Swann Bouvier-Muller, Yannick AMEUR, Arnaud Gonzales

Tribu_du_20180124

Ateliers, Rétrospectives, réunions … où trouver l’inspiration ?

| Nathaniel richand

Il m’arrive fréquemment de chercher de l’inspiration pour faciliter un atelier ou une rétrospective. On me demande aussi régulièrement de l’aide (notamment des ScrumMasters qui débutent) pour trouver des idées.

Ce post à donc pour vocation de centraliser toutes les sources d’informations pertinentes qui pourraient vous aider. Si vous jugez qu’il en manque, n’hésitez pas à les mentionner en commentaires pour que je les ajoute !

Gamestorming

Le site de gamestorming est une mine d’informations (souvent reprise d’ailleurs sur le web) pour trouver des idées de format. Avec plus de 100 activités il est cependant difficile de s’y retrouver facilement. C’est cependant souvent ma première destination. J’ai pendant longtemps utilisé une grosse cheatsheet disponible sur leur site.

Cependant, elle est difficile à lire et à manipuler (il faut aller ensuite sur leur site et faire une recherche ce qui est peu pratique). Je vous propose donc une traduction de celle-ci et mieux que ça, une version cliquable qui vous emmènera directement vers les détails de chaque activité :

Gamestorming cheat sheet FR

Lire la suite →