Product Team Canvas

Here is a proposition / draft of a canvas for a product team.

The idea is to use it as a conductive thread for initialisation workshops focused on the team (environment, purpose and self-organization).
It doesn’t address detailed product vision, this could be completed by a Lean Canvas or Business Model Canvas.
Some boxes are a little bit redundant between this Product Team Canvas proposition and a BMC for example, but I chose to keep it that way so that each Canvas can be consistant by itself. But it could be adapted of course.

This Canvas could be filled as a draft when the team is formed, and completed/update throughout the duration of the activity.

It is a little loaded, in terms of size I imagine it on a paperboard big enough to put the width of an A4 format in each column.

What do you think about it ?

Product Team Canvas.png

Agile Tour Rennes 2018

Je n’ai malheureusement pu participer que à la première journée… Mais c’était déjà très riche !

Et voici ce que j’en ai retenu, en images 🙂

Mais pour moi le plus marquant, ce qui m’apporté le plus de valeur, l’effet « whaou!!! » de cette édition… C’était l’atelier des « Pas Japonais » proposé par Benjamin Cabanne (ancien collègue ! C’est ça aussi les Agile Tour, le plaisir des retrouvailles !)

Je ne peux pas en dire plus. Cet atelier, il faut le vivre ! Et j’espère vraiment avoir l’occasion de l’animer bientôt 😉

Acculturation et atelier Lego pour des stagiaires de 3ième

Et hop, une petite animation qui a bien marché pour ce type d’intervention.

Déjà, on les réparti en équipes. Ils sont 9, je fais donc une équipe de 4 et une équipe de 5. Ils donnent des noms à leur équipe, c’est plus sympa… du coup j’ai l’équipe « Ninja-go » et l’équipe « Anonyme ».

Première phase : le bon vieux waterfall

Je leur répartis mes legos sur les deux tables et je leur donne des « specs ». Ce sont des notices de montage que j’ai imprimés…

2018-06-28+18_02_12-10693+Building+Instructions.pdf+-+Adobe+Reader.png

 

Je leur demande une estimation du temps de production.

Je paye en bonbons, avec bonus s’ils ont de l’avance, pénalité s’ils ont du retard !

Et c’est parti pour un bon vieux effet tunnel… Je chronomètre le temps.

Rapidement ils se rendent compte qu’ils n’ont pas forcément les bonnes pièces pour faire les modèles (forcément, j’ai imprimé des notices au hasard sur internet) et qu’ils n’ont pas estimé le temps de trier les pièces 🙂

Je leur dit de faire avec ce qu’ils ont, que c’est les imprévus des projets : on ne peut pas toujours faire exactement comme dans les « specs » et que pour toutes les autres questions le client n’est pas dispo >:-)

Ils optent pour une stratégie singulière : ils adaptent largement les modèles, voir se limitent à quelques pièces empilées quand le temps arrive vers la fin en partant du principe que « puisqu’on ne peut pas faire autrement, le client sera bien obligé d’être content » (?!?). Et ils comptent sur les bonus en livrant en avance !

Mais malgré les bonus, les modèles n’ont plus grand chose à voir avec les specs et je reprends des critères d’acceptations que j’avais préparé : est-ce que le crocodile a bien 4 pattes ? Non. Etc etc. Le butin en bonbons est assez maigre par rapport à ce qu’ils espéraient…

La petite perle

Quand j’annonce le nombre de bonbons final une élève s’exclame :

« Ah ben si c’est comme ça, la prochaine fois qu’on me demande une estimation je multiplie au moins par deux ! »

… elle a tout compris 🙂

Deuxième phase : agile !

Maintenant je leur donne plutôt l’équivalent de user stories : une maison, un poisson, ils peuvent me poser des questions et on fait des petites itérations à l’issue desquelles on mesure la valeur produite.

Forcément… Ça se passe beaucoup mieux 🙂

20180219_171329.jpg

Debriefing et vernis sur Scrum

Jusqu’à ce moment je n’ai donné aucune théorie, je profite donc du débriefing pour citer les 4 valeurs agiles et on termine sur un schéma à la volée pour leur parler un peu de Scrum en quelques minutes :

20180219_171325.jpg

Conclusion

Je me suis bien amusée à préparer et animer cet atelier, et je l’ai trouvé très efficace !

Le même genre d’atelier réalisé un peu plus tôt avec un marshmallow challenge avait donné de moins bons résultats je trouve en terme d’appropriation des concepts par les élèves… peut-être un peu trop abstrait 😦
Je resterai donc sur l’option Lego en deux phases si c’était à refaire 🙂

Rétro MMA (Memories Mood Actions), c’est le bonheur assuré !

(désolée pour le jeu de mot « un peu » pourri ^^’, je suis en manque d’inspiration pour trouver un nom à ce format de rétro…)

Ce petit guide d’animation est un assemblage de techniques que j’avais déjà utilisées par ailleurs. Rien de très original donc… mais je trouve que cet ensemble fait sens globalement et c’est l’enchaînement et le fil conducteur qui me semble intéressant.

Outils utilisés :

  • Timeline
  • Moodgraph
  • 1 word
  • Synergy4
  • DESC

L’idée globalement est d’amener l’équipe à passer des faits (en les aidant à se les remémorer), aux sentiments éprouvés, puis aux actions, le tout en passant alternativement par des phases d’auto-inspection individuelle, de partage et d’auto-inspection sur le collectif.

Voici le détail du déroulé, dans un contexte de rétro++ sur une mini-release (2 sprints), 8 participants, 1h30.

Je mets une photo du paperbaord pour que vous visualisiez le rendu, ça devrait aider à comprendre les explications ci-dessous 🙂

20180629_114853_censored.jpg

  • Icebreaker : j’ai choisi le bâton d’hélium pour débriefer sur le lien entre objectif individuel / objectif collectif et ressenti individuel / ressenti collectif
  • (prime directive + point sur les actions de la rétro précédente bien sûr 🙂 )
  • Timeline
    • Représenter la ligne de temps de la release (horizontale) et les différents sprints (colonnes)
    • Collectivement, se rappeler les faits marquants de cette release et les représenter sur la timeline avec des post-its (jaunes sur la photo)
  • Moodgraph
    • Sous la timeline, préciser une échelle des ressentis (simley très content, smiley pas content)
    • Individuellement, tracer le graphe de son humeur au cours de la release
    • Debriefing collectif : (sans rentrer dans les explications individuelles), quelles tendances peut-on observer ?
    • (bien rassurer sur le fait qu’une phase d’explication / partage est prévue sinon c’est très frustrant pour les participants de ne pas expliquer la ligne qu’ils viennent de tracer)
  • 1 word
    • Individuellement, chaque participants peut annoter sa ligne d’humeur avec des post-its en se posant la question de ce qui a fait qu’elle a baissé ou monté.
    • Contrainte : 1 mot par post-it. Pas de partage collectif à cet étape, c’est une phase d’introspection.
    • On peut utiliser un code couleur (vert pour le positif et rose pour le négatif par exemple sur la photo)
  • Tour de table à la mode Synergy4
    • Principe : chacun prend la parole à tour de rôle, les autres écoutent. Si la personne n’a rien à dire/ajouter, elle peut passer son tour (« je passe »), on continue les tours de table jusqu’à ce que tout le monde dise « je passe »
    • Utilisation du formalisme DESC pour que chacun à son tour
      • Décrive un fait
      • Exprime l’émotion associée (utilisation du « je »)
      • (éventuellement) propose une solution
      • (éventuellement) présente les conséquences de cette solution
    • Le paperboard réalisé précédemment reste affiché. Les participants peuvent y faire référence, mais ce n’est pas obligé. Il a simplement servi à bien préparer cette phase de partage et sert de support visuel pour faire référence aux faits (post-its jaunes) et aux émotions (graphes).
  • Actions
    • Enfin, compte tenu de tout ce qui a été partagé précédemment on revient sur un format plus classique pour identifier les actions et améliorations à mettre en place.
    • Avantage non négligeable, l’utilisation du formaliste DESC fait que des propositions de solutions ont déjà été formulées. Il faut ensuite juste discuter de leur acceptabilité par l’équipe globalement.
  • (ROTI)

Je pense que c’est particulièrement adapté en cas de tensions latentes, ou tout simplement pour une équipe qui a l’habitude des rétros + / – / delta et avec qui il faut un angle différent (en passant ici par les ressentis) pour générer de nouvelles pistes d’amélioration.

En prérequis je dirais qu’il faut de bonnes conditions de partage, donc plutôt avec des personnes qui se connaissent bien (je ne le proposerai pas avec des équipes qui ne travaillent ensemble que depuis peu de temps).

Bref, j’en suis très contente et je le ré-utiliserai !

En complément : la fiche fait-maison que j’ai utilisé pour expliqué le formalisme attendu lors du tour de table. Je l’ai maintenu visible des participants pendant toute cette phase de partage.

20180629_132612.jpg

Une journée pour construire ensemble une roadmap sur une thématique métier

La demande :

  • partager les besoins client recensés aujourd’hui sur cette thématique
  • éventuellement en identifier de nouveaux besoins en séance
  • les challenger par rapport à la valeur apportée, la complexité de mise en œuvre, la différenciation concurrentielle
  • … le tout afin de les prioriser et construire/enrichir les roadmaps des produits existants ou à venir.

Animation de la matinée :

  • Icebreaker
  • Partage de la vision sur la thématique
  • Création de personae
  • Identification besoins et features (animation inspirée de la technique de l’Impact Mapping que j’affectionne particulièrement ^^)

2018-01-25+16_37_17-Workshop+Flexible+Manager.pdf+-+Adobe+Reader

Animation de l’après-midi :

  • Complexity / value matrix
  • Roadmap design

2018-01-25+16_39_33-Workshop+Flexible+Manager.pdf+-+Adobe+Reader.png

Malgré une grosse difficultés (un des participants-clé n’a pas pu rester pour l’après-midi), le feedback de cette animation était positif pour les participants et très positif pour le demandeur.

Point de vigilance pour éventuellement une prochaine fois : avoir les bons participants et s’assurer (en insistant) de leur disponibilités, y compris des représentants des clients.
Nous avions sur cette session une très bonne représentation technique (développeurs, qualif, experts…), mais peu de représentants business 😦

Formation Kanban 1j

A la demande d’une équipe projet, j’ai monté cette session d’une journée d’acculturation/formation à Kanban. C’était une demande spécifique, mais les feedbacks étant très bons et le contenu dispensé assez générique, je me suis dit que c’est un déroulé qui pourrait être capitalisé dans d’autres contextes… quitte à adapter un peu en fonction des besoins spécifiques de chaque groupe.

Icebreaker / intro : Flip Coin Game

Ce petit jeu permet (notamment) d’introduire les notions de flux, de « juste à temps » et d’optimisation globale vs. optimisation locale.

Cette vidéo montre très bien de quoi il s’agit, c’est celle dont je me rapproche le plus pour l’animation de ce jeu : https://www.youtube.com/watch?v=oOGwFRuHuJ4

Cette autre vidéo est sur un format légèrement différent mais est intéressante aussi à voir : https://www.youtube.com/watch?v=fh4nkQnWL6I

20180419_105832.jpg

Dès le débrief de ce premier icebreaker, on rentre dans le vif du sujet ! Ici la notion d’optimisation globale vs. optimisation globale a été beaucoup discutée, l’approche étant assez différente de ce dont l’équipe avait l’habitude…

Commencer à rentrer dans le détail… en continuant à jouer : Pizza Kanban Game

Toujours sur un format jeu, on va un peu plus loin que la notion de flux en introduisant les 4 principes et 6 pratiques coeur de Kanban.

Pizza Kanban Game

J’utilise très souvent cet atelier pour introduire les principes de Kanban. Je trouve qu’il a beaucoup d’avantages : simple, très ludique, assez complet et riche et terme d’enseignement/debrief, ne nécessite pas de matériel très spécifique…

Là encore l’équipe a beaucoup apprécié et nous débriefons sur les bénéfices du management visuel, la limite du WIP, les règles explicites, l’auto-organisation…

Petite astuce : utiliser des feutres lavables à l’eau et/ou recouvrir les tables de kraft si on ne veut pas avoir à les nettoyer après…

Maintenant qu’on a des bases solides, la théorie

Je me suis largement inspirée de la formation que j’ai suivi avec Laurent Morisseau (notre expert Kanban national !), à partir de laquelle j’ai essayé de synthétiser et prioriser le contenu pour transmettre à l’équipe les bases utiles pour commencer.

  • Kanban : les bases théoriques
    • Introduction
    • Principes
      • 4 principes
      • 6 pratiques coeur
      • Ce que ça change
        • Juste à temps plus que cadencé
        • Flux tiré plus que flux poussé
        • La performance collective plus que la performance individuelle
        • La régularité plus que la performance singulière
    • Pré-requis
      • Division du travail
      • Valeur des items
      • Indépendance des items
      • Flux
      • L’équipe est propriétaire de son système
    • Définition du système
      • Interface d’entrée, interface de sortie
      • Granularité des éléments
      • Règles aux interfaces
      • Carte Kanban, tableau Kanban
      • Limites
      • Règles internes
    • Mesures du système
      • Cumulative Flow Diagram
      • Control chart
      • Blocages
    • Gestion du système
      • Injection / triage / sélection des éléments
      • Traitement des blocages
      • Rôle : facilitateur Kanban (proposition)
    • Initialisation du système
      • Voir
      • Maîtriser
      • Optimiser
  • Scrum vs. Kanban
    • Points communs
    • Différences
    • Exemples de métissages
    • Proposition d’approche pour choisir entre Scrum et Kanban

Retour à la pratique : initialisation du système avec Kanban Bootstrap

Cet atelier se base sur les animations/conférences de Romain Couturier dont voici une des vidéos : https://www.infoq.com/fr/presentations/kanban-bootstrap-romain-couturier

L’idée est de terminer la formation en commençant à initialiser le système Kanban de l’équipe.

Les différentes phases de l’animation :

  • Phase 1 : identification du système et de ses frontières avec l’extérieur
    • Individuellement, je demande aux participants de dessiner chacun sur une feuille
      • Eux au centre
      • L’équipe autour (je leur demande d’entourer l’équipe pour bien représenter la frontière)
      • Les demandeurs à l’extérieur
      • Les demandes qui leur génère du travail (flèches + libellé)
    • Chacun présente son « oeuvre » et collectivement je leur demande de converger vers une représentation de leur équipe/système (un volontaire la dessine alors sur un premier paperboard)
  • Phase 2 : identification du flux
    • Individuellement sur une nouvelle feuille, je leur demande de représenter le flux en commençant par la fin (DONE) (cf. guide ci-dessus)
    • Chacun présente son « oeuvre » et collectivement je leur demande de converger vers une représentation de leur flux (un volontaire la dessine alors sur un premier paperboard)
    • Lors de cette phase de convergence, j’en profite pour questionner sur la « definition of done » de chaque étape : je trouve que ça aide beaucoup à la réflexion et à la convergence en apportant du concret
  • Phase 3 : peupler le tableau
    • Collectivement, ils remplissent le tableau avec les items qu’ils ont aujourd’hui
    • On affiche les DoD en bas de chaque colonne
  • Phase 4 : prendre du recul
    • Phase de questionnement :
      • Avec cette nouvelle représentation de votre travail, qu’est-ce qui vous saute aux yeux ? Qu’est-ce que vous ne voyez pas ?

Je conclus en rappelant qu’il s’agit bien d’un draft, qu’ils vont le tester et certainement le faire évoluer dans les jours / semaines qui viennent.

Checkin / checkout : autoévaluation

En orange : autoévaluation des participants en début de session

En bleu : même exercice en fin de session

2018-07-02+10_25_27-20180419_164130.jpg+-+Visionneuse+de+photos+Windows.png

Coaching agile, une image

Ah… Définir le coaching agile. Qu’est-e qu’un coach agile ? Quelles sont ses compétences ? A quoi ressemblent ses journées ?

Encore et toujours les mêmes questions. Evidemment, si ça revient encore et encore c’est qu’il n’y a pas de réponse simple, évidente, toute faite.

C’est dans ce contexte que je voulais apporter un nouvel élément de réflexion.

En revoyant cette image très connue, je me suis dit que j’allais la réutiliser pour parler du coaching agile :

Image1.jpg

Comme dans cette image, pour moi le coaching agile a deux visages :

  • Le visage « coach » du coach agile : accompagnement / coaching –> plutôt soft skills
  • Le visage « agile » du coach agile : connaissance des valeurs & principes de l’agilité, méthodes, outils (« agilité » à comprendre au sens large, du Design Thinking au Devops) –> plutôt hard skills

Ce n’est pas l’un ou l’autre. Et ce n’est pas l’un, puis l’autre alternativement en fonction des situations.

C’est l’un ET l’autre simultanément qui alimentent l’action de coaching agile, comme le vase dans l’image.

Pour moi c’est un peu comme un mélange dont on ajusterait les proportions en permanence, en fonction des besoins, de la phase dans laquelle on est…

Qu’en pensez-vous ? 🙂

Agile France 2018

Cette année encore, j’ai eu la chance de pouvoir participer à Agile France.

J’aime beaucoup cet événement, notamment pour son cadre et l’aspect « 0 sponsor ». Ça a ses inconvénients (notamment sur le prix du billet), mais je trouve que c’est vraiment reposant et que l’atmosphère est plus sereine quand personne n’essaye de vendre son business ou sa solution.

Les formats « Agile Tour » avec sponsor ont également leurs avantages notamment au niveau de l’accessibilité à tous avec des prix de billets très bas… chaque système à ses avantage et ses inconvénients et je trouve ça chouette qu’ils co-existent 🙂

Bref. Ça c’était pour la petite spécificité d’Agile France, mais rentrons dans le vif du sujet : les conférences !

Make Architecture Great Again !

J’ai vraiment beaucoup aimé cette conférence pour 3 raisons :

  • l’intégration des architectes dans les équipes agiles est une situation que j’ai souvent rencontrée et qui n’a jamais été simple… Je me pose donc beaucoup de questions à ce sujet
  • le conférencier était clair, précis dans son message
  • le message transmis justement correspondait à une vision de l’architecture qui s’intègre parfaitement à la culture agile, se positionnant comme un enabler de l’agilité

Les messages que je retiens :

  • on ne peut pas appliquer à l’IT les processus prédictifs dans lesquels une personne conçoit (l’architecte) et une autre réalise (le maçon, charpentier etc.) pour deux raisons :
    • Quand il s’agit de code, la réalisation produit une suivre binaire, et c’est le compilateur qui s’en charge. Ecrire du code c’est faire de la conception. Les spécifications sont une aide à la conception. Il n’y a donc que des concepteurs, qu’ils soient architectes ou développeurs.
    • Quand on fabrique un pont, re-fabriquer quand on s’est trompé, ça coûte très cher. Une approche prédictive est donc justifiée. Quand on fait du code, re-fabriquer ne coûte pas cher.
  • On devrait parler d’ingénierie de la structure logicielle plutôt que d’architecture
  • L’architecture d’une application DOIT être évolutive afin de commencer petit et de s’adapter au fur et à mesure (nouveaux devices, plus de traffic, nouveaux besoins clients…)
  • Il y a un lien fort entre l’organisation sociale d’une entreprise et l’architecture des solutions qu’elle produit
    • Loi de Conway « L’organisation influence l’architecture »
    • Ex Amazon : Pizza Teams, architecture organique, « you build it, you run it »
  • Rôle de l’architecte
    • Extraite l’architecture de l’équipe plus que penser l’architecture pour l’équipe (facilitateur)
    • Repousser les décisions le plus possible, ne pas figer l’architecture ! (car c’est en début de projet que nous en savons le moins, c’est donc là que les décisions sont les plus difficiles et les plus dangereuses à prendre !)
      • “Une des tâches les plus importantes de l’architecte est de trouver des moyens d’éliminer l’irréversibilité dans la conception des logiciels.”
      • “La valeur de l’architecte est inversement proportionnelle au nombre de décisions qu’il prend” (Martin Fowler)
    • Réduire les dépendances entre équipes (architecture organique)
  • Conclusion
    • Ne pas construire un logiciel comme un construit un pont. 
      Le logiciel évolue, son architecture aussi.
    • Considérer l’autonomie et l’organisation des équipes.
      Elles influences l’architecture.
    • Repousser les décisions importantes.
      Les prendre quand il y a assez d’information, idéalement les supprimer !

Les slides : https://docs.google.com/presentation/d/1T4mhTjyBt1SS8XJ7NPHigNmvYc9jghjfSBgG2j9xAUg/

Morceaux choisis :

2018-06-28+14_38_01-20180614_101629.jpg+-+Visionneuse+de+photos+Windows2018-06-28+14_37_39-20180614_101119.jpg+-+Visionneuse+de+photos+Windows2018-06-28+14_37_51-20180614_101146.jpg+-+Visionneuse+de+photos+Windows2018-06-28+14_38_13-20180614_101729.jpg+-+Visionneuse+de+photos+Windows

Danse avec une unicorn

Le REX d’une équipe qui a développé un produit en collaborant avec une startup (unicorn)

  • Collaboration d’une grande boite avec une startup
  • Intégration de profils spécialisés comme « data engineer » et « data scientist » dans une démarche agile

REX sur l’intégration de ces nouveaux métiers, bonnes pratiques :

  • mob programming pendant 1 semaine au début (métiers complexes, environnement technique complexe, beaucoup d’inconnues)
  • pair programming
  • code review
  • TDD

Surtout, REX sur la notion de valeur livrée : le produit développé en anticipation a plu aux utilisateurs mais personne n’a été prêt à payer pour le run… échec

  • Ils ont livré des features et le feedback sur les features était OK
  • ils n’ont pas vraiment mesure la valeur
  • Importance de la phase exploratoire avant de se lancer dans le dev
  • Ecrire du code pour développer ce n’est pas construire un produit
  • Introduire l’exploration dans le flux

2018-06-28+14_50_48-20180628_144940.jpg+-+Visionneuse+de+photos+Windows

Art Thinking

Une keynote sur le parallèle entre création d’entreprise et création artistique

Au 20ième siècle, on cherchait à fabrique du certain

Aujourd’hui une startup cherche à fabriquer de l’improbable

On va donc chercher à « créer de l’improbable avec certitude »

Il faut bien différencier

  • un univers risqué (compliqué, dans lequel les risques ont une probabilité)
  • d’une univers incertain (complexe, dans lequel les risques / opportunités sont impossibles à estimer)

REX sur des atelier « Art Thinking » proposé à des étudiants d’école de commerce et à des entreprises

2018-06-28+14_58_35-20180628_145536.jpg+-+Visionneuse+de+photos+Windows

6 pratiques clé :

  • Donate (pas de calcul de RoI, proche du principe don/contredon)
  • Deviate (voler, s’inspirer des autres)
  • Destroy (critique, remise en cause)
  • Drift (dériver, cheminer sans connaître l’objectif)
  • Dialogue (pitcher, collaborer, construire ensemble)
  • Display (montrer, soigner le contexte, la mise en scène apporte de la valeur)

Transmettre sa culture en 5 semaines, embarquement agile

Excellente conférence qui fait un peu rêver sur des conditions et moyens de recrutements assez idéaux… Embarquer dans une nouvelle équipe est un moment crucial et pourtant souvent trop négligé… Ce REX montre à quel point il peut être l’objet d’un investissement collectif important de la part de l’équipe accueillante !

(Pour une fois que je trouve mes notes à peu près lisibles, je vais me contenter du scan plutôt que de recopier 🙂 )

1131_0011131_002

Forum ouvert

Je suis allée à la session « Code Of Conduct » par curiosité et j’ai découvert ce principe déjà souvent utilisée dans l’événementiel… Mais il y aussi eu des REX d’application en entreprise.

Exemple : https://events.linuxfoundation.org/code-of-conduct/

J’ai également été à la session « travail à distance ». Discussions intéressantes avec es REX parfois positifs (même si tout le monde s’accorde à dire que la distance est toujours une difficulté). Mais

Ça a pas mal parlé outils, mais je n’en retiens pas vraiment de nouvelles pratiques.

20180614_170215

Le gouvernement de Nouvelle Zélande s’inspire d’Agile pour améliorer les conditions de vie dans les banlieux

Un REX très intéressant et inspirant sur le Co-Design Lab d’Auckland

https://www.aucklandco-lab.nz/

Le conférencier a participé pendant 6 mois à un projet dont l’objectif était de travailler sur les problèmes liées à la difficulté et complexité d’obtention du permis de conduire (ils nous a présenté le truc, ça avait l’air d’être en effet une vraie usine a gaz… avant leur action 🙂 )

Ce que j’en retiens :

  • Constat que beaucoup de problèmes sont tout ou partie lié à la multiplicité des acteurs institutionnels impliqués avec une très mauvaise communication entre eux
  • Constitution d’une équipe pour une durée limitée de 6 mois
    • Détachement des personnes à 100%
    • Mandat très fort : « ont la totale confiance de leur hiérarchie et sont habilité à prendre des décisions comme leur représentant hiérarchique le plus élevé »
    • Le représentant du ministère des transport est donc à 100% dans l’équipe pendant 6 mois et a une délégation qui lui permet de prendre des décisions comme le ministre des transports (en théorie, la pratique nécessitait souvent quand même une validation).
  • Espace neutre, pas de politique
  • Démarche Design Thinking avec immersion, entretiens, détourage d’une problématique…
  • Des résultats concrêts et des améliorations sur le terrain !

Alice In Wonderland

« Mais alors, si [la gestion de projets] n’a aucun sens, qu’est-ce qui nous empêche d’en inventer un ? » — Lewis Caroll [ou presque]

Rien de nouveau dans les message, mais une manière vraiment novatrice de les transmettre.

Grâce au dynamisme et à l’interprétation théâtrale des speakers, j’ai vraiment bien rigolé !

Extrait :

« Avant on avait des esclaves ! Et on construisait des pyramides à coup de fouet ! (photo de hiéroglyphes en colonnes) Oh !!! regardez ! Le tout premier Kanban ! »

Une conférence bien déjantée et qui transmet plein d’énergie ! 🙂

Voici un petit teaser : https://www.youtube.com/watch?v=Sk5rq44grzI

Et les slides : https://fr.slideshare.net/alicebarralon9/alice-in-agile-land  (mais franchement c’est pas fait pour être vu sans la mise en scène associée  )

Thermodynamique de l’Agile

Alors… euh… cette conférence était un peu fumeuse, et le peu que j’en ai compris a généré des questions que le conférencier n’a pas compris quand j’ai voulu lui poser… donc bon.

Grosso-modo : tout peut être modélisé sous forme de système, y compris une équipe agile.

Un système répond aux lois de la thermodynamique, elles peuvent donc être appliquées à une équipe agile aussi.

  • On peut réaliser une sorte de bilan énergétique des équipes agiles
  • Une équipe agile génère de l’entropie, c’est une dissipation irréversible de l’énergie et ça a un impact sur « le reste du monde » (ie. le système englobant = l’entreprise)
  • La dissipation d’énergie via l’entropie doit donc être équilibré par un apport, et cet apport c’est l’information (concept de neguentropie, le contraire de l’entropie, l’explication du vivant)

Ma question concernait l’intention d’une équipe agile / d’un système. Son but. Sa raison d’être. Je pense que c’est quelque-chose de fondamental, que ça peut influencer le modèle et les flux (entropie ou neguentropie), mais il n’a pas du tout été question de cette notion pendant la conférence.

J’ai donc essayé de poser la question au conférencier après : dans ce modèle issu de la thermodynamique, comment pourrait-on modéliser et quelle serait l’influence de la raison d’être d’un système, ou son intention propre ? Mais je crois qu’on ne s’est pas compris, ou alors ma question était vraiment hors de propos… tant pis 🙂

Pour le reste, je vais mettre mes notes et puis voilà 🙂

1131_0032018-06-28+15_45_06-1131_004+(3).jpg+-+Visionneuse+de+photos+Windows
<h1>Comment planter son projet sans se faire choper ?

Est-il encore besoin de présenter Frédéric Leguédois ?

Ses conférences font toujours sensations et j’ai déjà eu la chance de le voir à Lean Kanban (conférence « qui a volé l’Orange » sur le thème de la recherche de coupable vs. recherche de solution) et au Printemps Agile de Caen (conférence « cessons les estimations ! »).

Je dis « conférence », mais c’est plus un one-man-show… et c’est donc difficile à raconter !

Ici, les premiers mots sont : « Alors… Comment planter son projet sans se faire choper… La conférence qui amène à s’interroger sur la motivation de ceux qui viennent y assister ! »

Le message principal est : pour être sûr de foirer un projet, créer de la distance entre les personnes

  • distance géographique
  • distance culturelle
  • distance organisationnelle
  • distance hiérarchique
  • distance temporelle (silos conception/dev/qualif etc…)

Tous les types de distance sont « bons » à prendre.

Réduire la distance coûte cher ? (co-localiser les équipes par exemple quand on veut externaliser les devs pour faire baisser le TJM ?)

Rappelez-vous ceci : quelque soit le TJM, un projet qui se plante coûtera TOUJOURS plus cher qu’un projet qui réussi.


Voilà, c’est tout pour cette année ! 🙂

Quelques photos random pour finir :

20180615_11481120180615_11475620180614_17205320180614_172042

Pizza Kanban Game

Je voulais juste partager cet atelier que j’ai eu l’occasion de faire jouer trois fois et que je trouve vraiment génial 🙂

Objectif : Acculturation Kanban

En quoi est-ce qu’il me plaît : je trouve que c’est un très bon compromis entre

  • des petits jeux comme le « Flip the coin » qui introduisent des notions Kanban mais sans être très concrets
  • des jeux plus longs et complexes comme Kanbanzine

C’est à la fois ludique est assez complet sur les notions abordées.

De plus le matériel à prévoir n’est pas très compliqué et courant en papeterie classique !

Je ne vais pas réécrire ici le guide d’animation car il est parfaitement détaillé sur cette page, avec tous les supports dont vous aurez besoin disponible au téléchargement : https://www.agile42.com/en/training/kanban-pizza-game/

Juste pour introduire le concept : vous êtes une équipe dans une pizzeria. Votre objectif est de produire des part de pizza, c’est à dire une base de pâte (papier jaune), de la sauce tomate (feutre rouge) et de la garniture (bouts de post-its et roses). Forcément il y aura des étapes de fabrication, d’assemblage, et également de cuisson 🙂

Le jeu se déroulera en plusieurs étapes avec à chaque fois un petit debriefing, et l’introduction des pratiques Kanban au fur et à mesure. Donc aucune théorie nécessaire au départ, on découvre en jouant !

Voici quelques photos pour vous donner une idée de ce que ça donne :

20171006_161249_censored

Premier round, le stock s’accumule !

20190114_171926.jpg

On compte les points et on clarifie la « definition of done » :

20190114_172720.jpg

La production s’organise…

20180419_105845_censored

Et hop, une belle commande, cuite à point 🙂

20190114_180058.jpg

Mes adaptations par rapport au guide d’animation proposé sont minimes :

  • On ne fait pas toujours les mesures dans le jeu (même si j’explique toujours le principe bien sûr). Ça dépend du profil des participants, de l’objectif (simple découverte ludique ou introduction d’une formation Kanban…)
  • J’ai ajouté un petit support pour matérialiser la file d’attente des commandes, je trouve ça plus pratique :

20190114_174658

En conclusion, si vous cherchez un atelier ludique et simple à préparer pour introduire Kanban, je trouve que le Pizza Kanban Game est une excellente option 🙂