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

 

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

Scrum poster

Il existe des tonnes d’illustrations de Scrum sur internet, très bien réalisées.

Mais parce que je préfère utiliser mes supports que des images dont je ne suis pas sûre de pouvoir citer correctement les sources, j’ai eu envie de faire une version perso…

N’hésitez pas à la réutiliser, j’ai mis un tout petit @elodescharmes en bas à droite et ça me suffit largement comme « copyright » 🙂

Scrum

Toute remarque sur le contenu est également la bienvenue, je pourrai faire des mises à jour si nécessaire.

Télécharger la version pdf

Et quand personne n’a envie d’être ScrumMaster ?

Vous avez peut-être déjà été confronté à cette situation… De ma courte expérience de coaching agile j’ai l’impression que ça peut arriver assez souvent finalement.

Vous avez une bonne équipe, tous les « team members » (au sens de Scrum, toutes spécialités confondues) sont compétents et motivés… Et personne n’a envie d’être le Scrum Master.

Bien sûr tout ça dépend du contexte, mais j’ai l’impression que les causes sont souvent un peu les mêmes :

  • Le rôle n’intéresse pas : quand ma passion c’est le dev, le design, l’ergonomie… je veux avant tout faire, pas être en support
  • Le rôle paraît rébarbatif : trop souvent on confond « être au service de l’équipe » avec « faire tout ce que les autres n’ont pas envie de faire et qu’il faut faire quand même ».
  • Le rôle n’est pas reconnu dans l’entreprise : méconnu, pas valorisé, voire même complètement ignoré

Romain Couturier explique ça très bien dans sa conférence « Qu’est-ce qu’un ScrumMaster » : quand Scrum arrive dans l’entreprise, il est logique de se demander comment s’en sortir avec ces nouveaux rôles et l’organisation existante.

  • Team Members, c’est facile
  • Product Owner… entre responsable produit, chef de projet, marketing, c’est pas super simple mais on devrait quand même arriver à trouver quelqu’un pour ce rôle (et souvent on se plante, mais je ferais peut-être un autre article à ce sujet ^^)
  • Mais Scrum Master ? Qui est-ce que ça peut bien être ? C’est complètement nouveau.

Ce n’est pas une fonction de production, ni une fonction décisionnaire. C’est une plutôt une fonction support. On pourrait penser aux managers, mais le changement de posture est tellement radical que j’ai du mal à l’envisager (et même avec un manager qui renonce complètement à tout pouvoir et tout contrôle sur l’équipe, encore faut-il que TOUS les membres de l’équipe le perçoivent ainsi… car les relations c’est dans les deux sens !).

Alors du coup on se retrouve avec des Scrum Masters tournants. Personnellement je n’aime pas vraiment cette pratique, tout simplement parce que se passer la patate chaude ça n’aide pas à monter en compétence sur le rôle et donc à avoir de bons Scrum Master. Forcément, quand on n’a pas envie et qu’en plus on a autre chose à faire…

Et quand ça va mal parce que on n’a pas investit le temps l’énergie et la compétence dans ce rôle, on appelle un coach agile 🙂

L’équipe en a marre. Personne ne voulait faire Scrum Master, un rôle tournant a été mis en place (par exemple), mais ça se passe mal, il y a de plus en plus de tensions, et du coup plus personne ne veut être Scrum Master.

Ce n’est qu’une proposition, mais voilà ce que j’ai tenté et qui s’est bien passé dans ce type de situation.

On suppose que l’équipe veut continuer à travailler en Scrum, ce qui dans les situations auxquelles je pense était le cas.

1. Recadrer Scrum

C’est souvent l’urgence. Alors oui, ce n’est pas du coaching agile et c’est plutôt prendre temporairement (et malheureusement partiellement si je ne suis pas à temps plein dans l’équipe) le rôle de Scrum Master.

Mais pour désamorcer les tensions, je pense qu’il faut souvent passer par là : re-clarifier les rôles, redonner du sens aux cérémonies…

2. Animer une décision collective par consentement sur un mode de fonctionnement autonome pour la suite

Ça doit être clair dès le début : en tant que coach agile, je ne resterai pas dans l’équipe, mon premier objectif est qu’on n’ait plus besoin de moi ! Je ne peux donc pas rester en tant que Scrum Master, mais je peux les aider à trouver un mode de fonctionnement autonome.

Pour cela, quand Scrum a été recadré et les tensions liées à ce rôle désamorcées, je leur propose un atelier spécifique.

Déjà, on clarifie les attentes de l’équipe vis à vis du rôle de Scrum Master.
En mode brainstorming, chacun note sur de post-its ses attentes. Pour le regroupement, j’utilise ce type de paperboard :

20171012_163502

Remarque : la première fois que je l’ai animé, je n’avais que l’axe vertical sur la criticité du besoin. Mais j’ai eu des attentes qui ne faisaient pas vraiment partie du rôle de Scrum Master… du coup je pose maintenant deux questions à l’équipe :

  • Est-ce que cette activité fait vraiment partie du rôle de Scrum Master ? (et j’en profite pour rappeler un peu ce qu’est le rôle, vis à vis de l’équipe de réalisation, du PO, et de l’organisation)
  • A quel point est-ce que vous en avez besoin ?

Une fois ce paperboard réalisé, je le laisse de côté pour le moment. Il a servi à aligner les membres de l’équipe sur leurs attentes, mais on devra peut-être y revenir…

Ensuite, je leur demande de lister les différentes possibilités d’organisation. J’avoue que là je les aide un peu avec ce que j’ai pu observer dans d’autres équipes. En gros ça donne :

  • Une personne de l’équipe prend le rôle –> –> je précise tout de suite que si cette option est sélectionnée, on continuera avec une élection sans candidats
  • Rôle tournant
  • L’équipe recrute un Scrum Master (si c’est envisageable)
  • L’équipe se réparti les tâches du Scrum Master
  • L’équipe fait appel ponctuellement à un facilitateur pour l’animation des rétros, mais se réparti les autres tâches

Ensuite, j’anime une prise de décision collective par consentement, on retient l’option pour laquelle il reste le moins d’objections (sachant bien sûr que j’insiste sur le côté expérimental, quelle que soit la décision prise il faudra en discuter aux prochaines rétros pour la valider ou non).

Dans le cas où l’équipe se réparti les tâches (dernière et avant-dernière option), on reprend alors le paperboard précédent pour décider de qui fait quoi.

Au final, je ne l’aurais pas cru au premier abord, mais cette option de se répartir les tâches a l’air de plutôt bien fonctionner…  Je pense qu’il y a trois raisons à ça :

  • ça limite la charge de travail : on peut prendre la tâche de l’animation des rétros uniquement par exemple et se concentrer la plus grande partie de son temps sur son rôle de Team Member ou Product Owner
  • c’est issu d’une réflexion collective et chacun a eu l’occasion de se positionner sur les tâches qui lui plaisaient le plus
  • ça permet quand même la montée en compétence, même partielle : celui ou celle qui a pris l’animation du sprint planning par exemple va être de plus en plus à l’aise d’itération en itération dans ce rôle. Et c’est pareil pour tous les autres rôles (animation, organisation logistique des cérémonies, gardien des règles Scrum et des valeurs agiles… c’est en général ce type de tâches qui ressortent)

Pour moi c’est une vraie surprise mais pour les deux équipes que je connais et qui ont choisi cette option ça a l’air de leur convenir et de bien fonctionner… alors pourquoi pas !

Et vous, comment gérez-vous cette situation ?

Estimations

Les estimations agiles

Déjà, pourquoi ne pas estimer en hommes*jour ?… PARCE QUE !!!
Allez, on lit cet excellent article, et on passe à la suite 🙂 : La malédiction du jour homme

Bon. maintenant que ça c’est fait, du coup, comment on fait des estimations agiles ?

En général dans les équipes agiles on a besoin d’estimer deux choses :

  • la valeur business d’un item
  • la complexité technique d’un item

La priorité d’un item est déduite de ces deux estimations.

NB : Je vois souvent la notion de priorité confondue avec la notion de valeur business (j’ai entendu « priorité business »). Pour moi ce n’est pas une bonne pratique et c’est symptomatique d’un product owner qui priorise son backlog seul (sans impliquer l’équipe de réalisation). Bref. Fin de la disgression.

On veut des estimations simples, rapides, relatives.

fichier_0021.png

Si je prends la pomme dans une main, ce serait compliqué d’estimer combien de grammes elle pèse. Même chose pour l’orange. Mais si je prends la pomme dans une main et l’orange dans l’autre, c’est assez facile de dire laquelle est la plus lourde… Et c’est tout ce que j’ai besoin de savoir pour prioriser !

J’ai essayé de lister ici différentes techniques… Est-ce que vous en connaissez d’autres ?

T-shirt sizes

Cette technique peut être utilisé pour les estimations de complexité comme pour les estimations de valeur. Mais concrètement je ne l’ai utilisé que pour les complexités techniques.

C’est très simple, très connu. Concrètement pendant un workshop je divise un paperboard en 6 parties.

  • XS
  • X
  • M
  • L
  • XL
  • NSP

Point de vigilance : essayer d’avoir une vraie répartition des items, pas tout en M…

Estimation line

Cette technique peut être utilisé pour les estimations de complexité comme pour les estimations de valeur (et je l’ai déjà utilisée dans les deux cas ^^).

Sur une grande table ou sur un mur : demander aux participants de simplement classer les items (epics / features / user stories) du plus simple au plus complexe (ou du moins de valeur au plus de valeur).

Interdit d’en mettre deux au même niveau ! (vous allez voir, c’est toujours difficile ^^)

On se met ensuite d’accord sur où placer les limites entre des groupes d’items et on fait la correspondance avec Fibonacci (ou des T-shirt size). Et hop, emballé c’est pesé, voilà une manière très rapide d’estimer 🙂

2017-10-29 13_45_10-IMG_0101.PNG ‎- Photos.png

Buy a feature

Cet atelier peut permettre d’estimer rapidement la valeur business des features.

Pour le détail du déroulé : GIYF 🙂
… Notamment cet article avec plein de déclinaisons possibles de l’atelier : http://blog.xebia.fr/2014/08/20/les-differents-usages-de-buy-a-feature/

Quand on utilise une atelier « buy a feature » pour estimer des valeurs business, la question à poser aux participants est : « Imaginez que vous êtes tel ou tel client. Combien seriez-vous payer pour avoir cette fonctionnalité ? »

C’est mieux si on a fait des personae avant, on peut demander aux participants d’essayer de les incarner lors de cet atelier.

Complexity / value matrix

Si on veut aller encore plus vite sur les estimations (en comme il ne s’agit pas d’une session de backlog grooming mais bien d’un workshop d’initialisation, je pense que c’est tout à fait acceptable), on peut utiliser une matrice complexité / valeur.
Personnellement, je trouve cet atelier très efficace et je crois que c’est l’option que je retiens le plus souvent.

Pour le détail du déroulé : GIYF 🙂

Quand je l’anime, je suis assez stricte sur les règles :

  • d’abord le PO (ou équivalent) présente l’item
  • ensuite le PO, représentant marketing ou représentants clients  (premier groupe) le placent en hauteur dans la matrice
  • ensuite l’équipe de réalisation (deuxième groupe) le placent à gauche ou à droite.
  • s’il y a discussion / débat, j’ai toujours ces deux règles :
    • le premier groupe ne peut déplacer les post-its que verticalement
    • le deuxième groupe ne peut déplacer les post-its que horizontalement

Fichier_002 (4).png

Planning poker

Bien sûr, il y a le classique planning poker. Il peut être utilisé pour tous type d’estimations, complexité technique, valeur business…

Pour le détail du déroulé : GIYF 🙂

Il se différencie des techniques ci-dessus car il est plus long, amène des discussion et des débats beaucoup plus riches. De ce fait, je préfère ne pas l’utiliser à l’initialisation d’un backlog (quand on a vraiment beaucoup d’items à estimer), mais plutôt en backlog grooming quand il y a peu d’estimations à faire et qu’on veut aller plus dans le détail. En général on a estimé et priorisé le backlog grosse maille avec les autres techniques, et on « n’investit » dans un planning poker que pour les user stories complexes (on a besoin de discuter pour aligner nos vision sur le quoi et le comment), et/ou les user stories très court terme (pour le(s) prochain(s) sprint(s)).

Conseil : prévoir de quoi noter les choix techniques ou les précisions fonctionnelles qui émergent des discussions sur planning poker.

Point de vigilance : le planning poker implique une obligation de converger vers une estimation unique. Ne pas oublier le risque d’incertitude (notamment quand il y a divergence importante entre les estimations initiales).