Walkingdev permagilité @Toulouse

Sur l’impulsion de Stéphane à la sortie de ma présentation permagilité faites à AgileFrance (voir slides ici) nous voici donc embarqués dans la préparation d’un walkingdev avec Claude et Fabrice.

Walkingdev?

Le pitch des walkingdev c’est « Apprendre avec ses pieds et découvrir des endroits insolites ». En pratique c’est : une journée autour d’un thème défini. Des créneaux de 45/60 minutes max alternés par un peu de marche pour passer d’un lieu à un autre. Pour ce walkingdev nous étions à Toulouse ce mercredi. Nous avions fait les repérages la veille et au final notre périple de mercredi fut celui-ci :

carteWalkingDev

Démarrage

A notre point de rencontre le matin nous sommes donc 8 pour démarrer par cette belle journée. Un petit checkin et nous attaquons le vif du sujet : introduction à la permaculture, ses origines puis présentation rapide des éthiques et principes.

Après cette rapide intro, nous prenons la route en direction du très beau jardin japonais :

A l’abri de notre chalet nous discutons librement de pas mal sujets :

  • Association de plantes
  • Rôle des « mauvaises herbes »
  • Phase d’observation
  • Autonomie
  • Durée de la transition
  • Pierre rabhi
  • Les colibris

Un peu de marche pour aller au point suivant et nous voilà sur la terrasse intérieure d’une grande librairie. Nous creusons lors de cet arrêt la notion d’écosystème (thème d’AgileTour Toulouse cette année). Un retour à la définition s’impose :

En écologie, un écosystème est l’ensemble formé par une association ou communauté d’êtres vivants (ou biocénose) et son environnement biologique, géologique, édaphique, hydrologique, climatique, etc. (le biotope). Les éléments constituant un écosystème développent un réseau d’échange d’énergie et de matière permettant le maintien et le développement de la vie.

Nous sommes parties sur ce thème car on dit que le but de la permaculture est de créer un écosystème (viable, durable, autorégulé). Une discussion enrichissante qui nous amène sur quelques points :

  • Les consommateurs doivent faire partie de l’écosystème
  • L’écosystème doit être autonome. Les fonctions transverses doivent donc autant que possibles devenir des activités faisant partie de l’équipe plutôt que des fonctions externes.

Claude en profite pour faire une rapide introduction à la méthode de conception OBREDIM souvent mentionné en permaculture et David nous présentent les habitats participatifs. Stéphane nous glissent quelques pistes à creuser :

Après-midi

Une pause déjeuné bien mérité s’impose. Puis nous allons au couvent des jacobins situé à proximité. Le cadre est très inspirant et Claude nous propose un petit jeu sympa :

Objectif de celui-ci : retrouver le principe de permaculture en partant du symbole :

principes-blanc.jpg

Le jeu est intéressant et amène beaucoup de question, nous nous aidons des citations associés aux principes comme par exemple : « Les fautes des pères rejailliront sur les enfants jusqu’à la septième génération » (principe 4 : Appliquer l’auto-régulation et accepter la rétroaction). Pas toujours évident 🙂

Et nous filons à notre prochain lieu, l’anartiste :

Nous profitons du cadre sympathique pour aborder le sujet : « comment la permaculture se débarrasse des éléments toxiques? ». Voici un ensemble de pistes :

  • Avoir des canards coureurs indiens 😉 (trouver le prédateur naturel, dans ce cas celui des limaces)
  • Amener de la terre pour enrichir la terre présente très pauvre
  • Nettoyer la terre polluée par les plantes
  • Mettre en place des stratégies comme le semis dans des boules d’argile pour éviter que les oiseaux ne les dévorent…

Nous en arrivons (comment, je ne sais plus 🙂 ) sur la notion de s’intéresser aux interactions et non pas aux personnes et Philippe nous amène à avoir une discussion fort intéressante sur le standup.

Cloture au jardin des plantes

Pour finir cette belle journée nous faisons une dernière escale sur la terrasse du jardin des plantes. Nous abordons le sujet « reproduire ce que fait la nature » et aboutissons notamment sur le concept de résilience.

Nicolas nous explique de quel manière il vérifie son produit (teammood) en utilisant le net promoter score. Il travaille son réseau d’ambassadeur (NPS à 9 ou 10) et les intègre vraiment dans la conception et la diffusion de son produit (on en revient à l’intégration des consommateurs dans l’écosystème). Accroitre son réseau de partenaire et un bon facteur de résistance dans le temps.

Nous arrivons également à la conclusion que toute forme de dépendance unique et un risque, comme par exemple un sponsor d’une transformation agile voire même le PDG d’une entreprise. Que ce passe-t-il lorsque celui-ci laisse sa place? La permaculture nous dit « chaque élément a plusieurs fonctions et chaque fonction est occupée par plusieurs éléments », une idée à développer pour nos prochaines intervention pour accroitre les facteurs de résilience sur le long terme.

Claude nous présente ensuite la fleur permaculturelle :

fleur-permaculture1

Nous ne sommes pas encore très sur de son objectif et de la manière de l’utiliser. En creusant dans le petit livret « L’essence de la permaculture » je trouve cette définition :

En partant de l’éthique et des principes ancrés dans la thématique cruciale des soins à la nature et à la terre, la démarche permaculturelle progresse en appliquant un par un les principes jusqu’à intégrer chacun des sept domaines qui seront vitaux pour soutenir l’humanité dans la descente énergétique.

La réflexion qui me vient est d’adapter cette fleur aux fonctions de l’entreprises en essayant itérativement de les inclure dans l’équipe : Finance et Economie serait la gestion budgétaire du produit, santé et bien être serait la fonction RH actuelle, habitat la gestion de l’environnement de travail, etc…

Et finalement la conclusion revient à Stéphane qui nous amène vers l’éthique, sujet très fort dans la permaculture mais qui est faiblement abordé par l’agilité. Il nous déniche le « Code d’éthique et déontologique de l’ingénieur logiciel« . Encore un sujet à creuser 🙂

 

 

La suite

Vous l’aurez compris ce fut une très bonne journée. Aussi bien sur le fond, car nous avons eu de super échanges, que sur la forme où le fait de nous déplacer de lieu en lieu dans le très beau cadre Toulousain fut très agréable. Un grand merci à tous les participants pour ce bon moment.

Cela me donne donc l’envie de prolonger cette aventure et faire de nouvelles rencontres dans un nouveau cadre.

Je vous propose donc de refaire une expérience similaire, mais cette fois sur Paris vers le début octobre. Si vous êtes intéressés n’hésitez pas à vous manifester !

Permagilité : quand l’agilité rencontre la permaculture

Permaculture et agilité

Il y a quelques mois j’ai découvert avec un grand intérêt la permaculture. Pour ceux qui ne connaitrait pas du tout, la définition de wikipedia est plutôt bien :

La permaculture est une méthode systémique et globale qui vise à concevoir des systèmes (par exemple des habitats humains et des systèmes agricoles, mais cela peut être appliqué à n’importe quel système) en s’inspirant de l’écologie naturelle (biomimétisme) et de la tradition. Elle n’est pas une méthode figée mais un « mode d’action » qui prend en considération la biodiversité de chaque écosystème. Elle ambitionne une production agricole durable, très économe en énergie (autant en ce qui concerne le carburant que le travail manuel et mécanique) et respectueuse des êtres vivants et de leurs relations réciproques, tout en laissant à la nature « sauvage » le plus de place possible.

Avec la permaculture j’ai découvert (et mon potager aussi 🙂 ) un ensemble de pratiques très intéressantes copiant et respectant la nature. J’y ai également découvert une philosophie et des principes dans lesquels je me suis retrouvé et qui peuvent se marier avec notre agilité.

Je me suis essayé à une première présentation de cette permagilité (perma pour « permanent » ie. durable) lors d’Agile France et les retours ont été très positifs. Voici le support de cette présentation :

 

Venez participer au walkingdev permagilité

Je souhaitais continuer le travail autour de la permaculture et de l’agilité et il se trouve que Claude et Fabrice ont eu la même envie. Nous nous retrouverons donc le 30 août à Toulouse pour un walkingdev sur le sujet. Si vous êtes intéressé par ce sujet n’hésitez pas à vous joindre à nous !

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

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

Accompagner les product owners vers la prochaine marche

Dans ce précédent article (Devenir un meilleur Product Owner, une marche après l’autre) nous expliquions que la montée en compétence du Product Owner n’était jamais immédiate et passait par différentes étapes. Nous donnions également quelques pistes pour identifier le principal levier d’action à chaque marche.

Lorsque je démarre un coaching de Product Owner, j’ai cependant besoin de formaliser avec mon coaché les axes sur lesquels nous allons investir en premier.
Afin de rendre cette démarche vraiment efficace je demande au manager également d’être présent dans cette phase afin d’établir un contrat tripartite. Cette présence est déterminante, car d’un côté elle libère le Product Owner et lui donne toute latitude pour avancer et, d’un autre côté, elle me permet en cas de besoin de trouver un relai pour faire avancer les choses.

J’ai essayé plusieurs approches, mais la plus intéressante a été pour moi de m’appuyer sur une matrice détaillant le rôle du Product Owner afin d’ouvrir le champ des possibles. Pour définir cette matrice je me suis basé sur l’excellent article de Marty Cagan (Gourou du Product Management dans la silicon valley). Cette matrice définit le rôle du Product Owner selon 3 axes : Connaissance, Process, Compétences :

Auto-eval

Matrice disponible sur google spreadsheet.

Lire la suite

Devenir un meilleur Product Owner, une marche après l’autre

Nous rencontrons régulièrement des managers qui se disent ravis de la mise en place de l’Agilité mais qui souhaitent aller plus loin et transformer leurs Product Owners en véritables intrapreneurs.

Le rôle de Product Owner nécessite un vaste panel de qualités et de compétences. Devenir pleinement opérationnel et porteur d’une vision génératrice de valeur nécessite plus que quelques formations à l’Agilité. Ceci réclame du courage et du travail de la part du Product Owner mais également beaucoup de support et de responsabilisation du coté de l’entreprise !

Un article intitulé « Evolution of the Product Owner » paru sur le blog de Scrum.org nous a interpellé. Celui-ci propose une échelle d’évolution du rôle qui nous parait pertinente.

Nous vous proposons ici une synthèse de cette échelle d’évolution et nous discuterons de la façon d’en grimper les différents échelons.

1. L’échelle d’évolution des Product Owner

product_owner_niveau
Source : https://blog.scrum.org/evolution-product-owner/

Ces 5 étapes sont les suivantes :

Lire la suite

Gestion des risques en management visuel pour Product Owner

Lorsque l’on gère un produit en Agile, les Product Owner doivent aussi gérer les risques.

Les risques sont comme en parle Jean-Claude Grosjean de différents types (globalement) :

  • Organisation / Produit
  • Métier / Fonctionnel
  • Client / Utilisateur
  • Technique
  • Fournisseur / Service Externe

Donc voici un petit outil visuel à mettre à votre mur ou fenêtre pour le Product Owner :

gestion_des_risques_po_agile

A vous de le mettre à jour à chaque fois que cela change, gérez le temps et l’importance et ne laisser jamais un risque actif dans proche et fort.

exemples :

  • Demander à l’infra les serveurs de prod : 3 mois à l’avance.
  • Pour les vacances : demander le planning des congés pour accorder nos forces.

 

 

Bien débuter en Agile

Voici quelques liens pour commencer seul :

Le site de mountaingoatsoftware avec l’intro sur Scrum : des présentations de Scrum en ppt dans toutes les langues :
https://www.mountaingoatsoftware.com/presentations/an-introduction-to-scrum

scrumlargelabelled

 

En livre :

Le livre de Scrum par Claude Aubry : Amazon  et son blog http://www.aubryconseil.com/

Le livre de Laurent Morisseau Kanban pour l’IT pour les produits multi tickets en mode Kanban : Amazon son site www.morisseauconsulting.com

Pour les User Story (stories) :

Le guide Scrum pour préparer la certification Scrum PSM 1

2016 en anglais must pour la certification :
http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf

2013 en Français pour mieux apprendre :
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-FR.pdf

Passer une certification

Avec Scrum.org passez la certification en ligne de Scrum Master niveau 1 ( Professional Scrum Master™ ) avec le Scrum Guide environ 150$ :
https://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments/PSM-I-Assessment

Utilisez sans modération le ScrumOpen qui est un examen blanc gratuit, sinon j’aide à préparer sur deux jours la certification.

Ou sinon avec la ScrumAlliance et ses formations certifiantes, je vous recommande l’un de ses deux formateurs :

Avec les formateurs d’Agile Tribu

Nous pouvons venir vous former avec votre équipe avec des formations adaptées à vos besoins, contactez-moi : yannick.ameur@gmail.com

Ou encore prenez une demie-journée pour un CUBE

Inscrivez vous sur Paris ou en régions aux Cubes :
http://1cube-and-go.com
Nous pouvons aussi les donner chez vous à partir de 5 personnes.

La tribu fait deux Cubes le Jeudi 26/01

Oyé Oyé

Agile Tribu fait son 2ème et 3ème Cubes : Prioriser, estimer et planifier et Expliquer l’agilité dans mon entreprise

le Jeudi 26 janvier 2017

logo_1cubego_officiel

Cube Après-midi : Expliquer l’agilité dans mon entreprise

Depuis plusieurs jours, semaines ou mois, vous entendez des personnes de votre entreprise dire qu’il faut passer à l’Agilité.

Vous entendez des : « Agile c’est quand tu collabores pour réaliser des user stories grâce au Scrum Master », « Tu es agile, tu mets des post-it au mur, et tu fais des points courts quotidiens » ou encore « Agile c’est un truc de dev, c’est pour qu’ils arrêtent la spec’ ! »…

Deux possibilités : vous ne savez pas exactement ce que c’est et vous aimeriez bien qu’on vous éclaire sur ce qu’est réellement l’agilité ou bien vous connaissez le sujet par cœur mais ne savez pas comment bien l’expliquer aux acteurs de votre projet.

Comment expliquer la démarche à mon équipe de développement sans qu’elle ne prenne peur ? A mon manager pour qu’il se sente impliqué ? A mon métier pour qu’il se sente rassuré ? A mon client pour qu’il se sente valorisé ?

Cube matin : Prioriser, estimer et planifier

De responsable métier avec son cahier des charges à Product Owner avec son backlog produit, prioriser est probablement un des sujets les plus délicats.


Estimer la valeur, le contentement client ou l’effort, tous ces critères sont indispensables pour faire une bonne priorisation et satisfaire tout le monde.


Vous testerez plusieurs techniques de priorisation, d’estimation et de planification. A pratiquer seul ou en équipe, de basique à complexe, il y aura des pratiques pour tous les goûts.

Venez prioriser, c’est une priorité !

Vos hôtes : Nathaniel Richand, Jean-Claude Grosjean et Yannick Ameur.

Rendez-vous chez nous au 4 ter passage de la main d’or 75011 Paris de 8:45 à 12:30
Métro Ledru-Rollin

Tarif : 216 € TTC / cube
Inscriptions à la Billetterie :

Product Owner : études récurrentes, Studies Loop

Comme d’autres Product Owner, dans le monde de l’Agile, j’ai besoin de clarifier certain mode de fonctionnement.

En ce moment, je suis confronté à définir un Produit qui encapsulera et simplifiera d’autres produits. Chaque produit à intégrer se transforme donc en épic.

Donc voici le mode de fonctionnement que j’ai décidé de tester :
Je considère que chaque épic à intégrer représente une release dans ma roadmap, donc un lot fonctionnel à mettre en production en fin de release.

La Release sera composée de tout ce qui est nécessaire pour livrer l’épic : son découpage en stories fonctionnelles, mais aussi les stories techniques ou autres stories transverses nécessaires à la livraison.

Processus de l’étude de la Release commence par un Sprint 0 :

etudeproduitenboucle

Step 1 : Workshop de Définition

  • Timing : Selon l’épic, le workshop prendra entre 3h et 2j
  • Participants : les responsables et acteurs de l’épic
  • Animateur : un facilitateur externe au projet
  • Target / output / livrables :
    • Première vision de la vie actuelle de l’épic
    • Première vision de la cible intégrée et simplifiée
    • Les utilisateurs concernés par la cible : la liste avec nom prénom pour le 2.1
    • Les gains attendus pour établir la business value

Step 2.1 : Découverte des utilisateurs

  • Timing :
    • 30min à 1h par type de end-user,
    • observation de 3 à 4 actions différentes
  • Passer du temps avec les end-users :
    • Laissez-vous guider par leurs explications sur les cas d’utilisations, les besoins
  • Observez leurs manières de travailler et … trouvez le moyen de simplifier leurs actions, interactions, délais d’attentes…
  • Type de rencontre : One To One ou sur les genoux du end-user
  • Target / output / livrables :
    • Affinage de l’épic en end-user Stories dans votre Release Backlog ou Epic Backlog

Step 2.2 : Design cible

  • Timing :
    • en parallèle du Step Customer Discovery
    • cette étape continue dans les sprints de la release, car l’ergonomie, le look&feel, l’UX devront être challengés par vos équipes de réalisation, votre UX designer et par vous.
  • Réalisez vos Mockups des écrans à réaliser
  • Avec un UX (ou pas) alimentez le schéma des écrans avec les chemins d’utilisations de votre application.

Step 3 : Release Roadmap Mapping

  • Timing : 2 heures
  • Target / output / livrables
    • User Stories avec :
      • une priorité
      • une business value
      • une estimation avec vos équipes
    • Une estimation du nombre de sprint

Fin du sprint 0 :

  • Début du sprint 1 de la release
  • Début du sprint 0 de la prochaine Epic pour vous

Voila, merci pour vos commentaires, vous répétez cela en l’améliorant à chaque fois jusqu’à épuisement du Product Backlog ou de vous ;o)

Yannick AMEUR