# Agile Grenoble 2019

## Mardi 12

### S'il suffisait d'oser

Témoignage de Marie-Laure Brunet, ancienne médaillée olympique de biathlon. C'est un peu toujours pareil les témoignages de sportif de haut niveau, "oui j'étais déterminé, j'ai toujours su où je voulais aller, et ça a marché jusqu'au jour où ça n'a plus marché mais j'ai sur rebondir blablabla"

### Les accords toltèques

Clairement beaucoup trop orienté développement personnel (mais c'est une dégénerescence habituelle de l'agilité je trouve). Speakeuse pas à l'aise du tout, et qui demandait des témoignages au public sur des trucs plutôt perso, donc forcément peu de gens avaient envie d'interagir.

### Architecture évolutive et fitness functions

C'était pas mal, mais il a fait trop d'effort pour être "tout public" je pense, du coup beaucoup de temps pour rentrer dans le vif du sujet : bien choisir sa fitness function permet de bien choisir son architecture (ex avec Netflix, 90% des usagers doivent avoir la première image de leur film 1 seconde après avoir cliqué)

### Et si on redémarrait l'agilité

slides : https://speakerdeck.com/lilobase/et-si-on-redemarrait-lagile-agile-grenoble-2019?slide=30

Keynote de l'aprem par Arnaud Lemaire qui envoie des baffes à tout le monde. Ça riait énormément dans la salle, mais à mon avis beaucoup riaient jaune ("arrêtez de faire gagner des boîtes de LEGO pour choper des CV de développeurs", les sponsors en PLS).

Son constat : on a changé le nom des choses en faisant de l'agile, mais au final on fait la même chose qu'avant. C'est la qualité et l'excellence technique qui permettent la predictabilité et délivrer de la valeur au client.

"9 femmes ne peuvent pas livrer un bébé en un mois"

Le constat a 40 ans (in The Mythical Man Month), mais on a toujours les mêmes problèmes.
Le scope est la seule chose de flexible (vs le temps ou les ressources), sauf que le scope c'est ce qui est signé, donc on y touche jamais.

La gestion de projet est une méthode de gestion de risque pour le management. Il faut une nouvelle méthode de gestion de risques. Il propose de faire des sprints plus petits. Comme ça on dit des "mensonges" plus petits :grin: .
Il faut passer de la planification à la priorisation.

On est tous dans le même avion, il faut changer la posture de project manager "ce qui part en production est ce que les développeurs ont compris". Tout ce qui aide à cette compréhension (impliquer plus les devs dans les specs par exemple) est essentiel. Il faut donner de la confiance, pas des jouets. Les devs sont les pilots, le product owner le copilote. Le copilote ne doit pas toucher le volant !

### Transformation agile : arrêtons de suivre aveuglément des frameworks

Ça part d'un très bon sentiment : vous n'avez pas besoin de framework, il suffit de convaincre au moins une équipe de se mettre à l'agilité, s'il y en a qu'une il faut que ce soit la direction pour donner confiance aux autres. Enfin il faut mettre en place des objectifs mesurables, la création d'un groupe d'agents volontaires du changement, communiquer régulièrement ... bref finalement un framework ça m'a l'air plus simple !

### Les sciences du numérique et l'agilité : coup de foudre ou mariage d'intérêt ?

Les orateurs font un jet de charisme. C'est un échec critique.

Mais sinon ils étaient fort sympathiques, et le sujet est assez intéressant : comment on fait pour que des chercheurs passent à l'agilité ? Réponse : c'est compliqué ! Mais ils ont quand même réussi à mettre quelques trucs en place, notamment les outils de versionning (oui dans la recherche c'est pas toujours ça), et une CI. Pas mal de problématique qu'on retrouve dans la data science à ce sujet (mais c'est normal, c'est beaucoup fait par des chercheurs encore).

### Dépoussiérons l'apprentissage

Deux ergonomes qui ont créé des jeux pour convaincre les gens d'impliquer l'utilisateur beaucoup plus tôt et plus souvent dans la boucle de conception du produit (conception centrée utilisateur) On a joué au premier jeu pendant la conf, et effectivement on comprend tout de suite le problème.

https://www.ergogames.fr/

### L'équipe qui communiquait

Cette présentation portait sur les OKRs. OKR est un framework sur la définition d'objectifs de valeur. Transformer une mission et une vision en objectifs, donnant des résultats clés mesurables (pour déterminer sa réussite).
Un OKR doit être formulé de la manière suivante : je vais accomplir l'objectif xxx mesuré par yyy. Les objectifs doivent être suivis, accompagnés et font la source d'un feedback.

/!\ Le speaker insiste bien sur le fait que ce n'est pas un outil de mesure de performance. Dans le cas contraire, la personne objectivée peut redouter le jugement, ce qui n'est pas du tout le but de ce framework.

### La CNV dans la vraie vie

Petit speech sur la communication non violente, plein d'exemples et d'annecdotes du speaker. Il en ressort 4 piliers :
* Observer
* (+) observer et partager un fait mesurable
* (-) éviter les évaluations (porte au jugement)
* Sentiment
* (+) exprimer une information sur le degré de bien-être
* (-) éviter les mots vagues et les termes qui interprètent les actes d’autrui
* Besoin
* (+) être conscient du lien entre sentiment et besoin
* (-) éviter d’attribuer notre besoin aux actions des autres
* Demande
* (+) exprimer sa demande
* (-) ne pas l'imposer

Un moyen de faire de la CNV est également de se poser et de faire des feedbacks. L'orateur cite 2 méthodes :
* DESC (Décrire, Exprimer, Spécifier Conclure)
* Wrap (décrire le contexte, lister les observations, exprimer ses sentiments, montrer que ça a de l’importance, suggérer des solutions)

### The fast and furious developper

Une présentation destinée aux non développeurs (entre autre aux PO, coachs et recruteurs) qui présente les développeurs comme des être humains avec un petit coeur battant sous leur poitrine. Il y explique que les 10x engineers n'existent pas et parle de comment travailler avec les devs en mettant en avant ce qui peut potentiellement les énerver dans le cadre des projets auxquels ils sont rattachés :
* Les projets trou noir (avec la tête dans un projet et ne pas en sortir, ne pas comprendre pourquoi on code)
* L'ajout de développeurs sur un projet en s'attendant à ce que l'équipe se débrouille avec (ajout de ressources 'pour que le projet avqnce plus vite')
* La malhonnêteté et les stand up en mode "t'en es où ? t'en es où ? t'en es où ?..."
* Entendre que le pair est une perte de temps, ou bien ne pas acheter de licences parce que ça ne sert à rien et c'est cher
* Les réunions brillantes dans l'open space, les casques sont souvent signe de 'je fais quelque chose, je suis concentré'

## Mercredi 13

### Keynote: Construire collectivement les décisions, un processus vertueux pour l'entreprise et les personnes

Une présentation du fonctionnement et des bienfaits d'une structure coopérative (scop).
Les employés remontent les besoins, plutôt que de compter sur la hiérarchie pour les identifier.
Les décisions sont prises ensemble par votes, et tout est annoncé très tôt pour une transparence maximale.
Les équipes choisissent leurs responsables/managers.

### Les 20 questions qui font "tilt" lors de mes ateliers

Les questions sont un outil puissant. Elles peuvent ouvrir ou fermer une discussion, la guider dans une direction ou dans une autre.

Cette présentation nous propose quelques points clés pour choisir et formuler la bonne question, aussi bien pour les autres que pour soi-même.

Une bonne question doit être :
- ouverte, mais pas trop
- intéressante, et non intéressée
- issue de la curiosité, et non du jugement

### Scrum vs Kanban, le choc des titans

Rien de bien intéressant...

Une tentative de parallèles bancaux entre les 2 frameworks, un mini teasing en fin de pres' avec seulement une slide qui contenait "Et du coup, Scrumban ?", et c'est tout.

### Keynote: La collaboration, signe d'une véritable agilité

### Mythes, fausses idées, et poudre de perlimpinpin

Une conf vraiment très intéressante, pleine d'exemple parlants mais qui peuvent tous se résumer en :
- ne croyez pas tout ce qu'on vous dit, vérifiez les sources
- une corélation n'est pas nécessairement une causalité
- faites confiance à la méthode scientifique, mais pas aux scientifiques

### Rétrospective !! Rétrospec'quoi ?

Deux speakers d'une même équipe qui font de l'agilité depuis quelques mois, l'un d'entre eux était le Scrum Master.
Ils ne jurent que par le Scrum Guide, ET POURTANT il a osé affirmer que, toujours d'après le Scrum Guide, le Scrum Master ne DOIT PAS participer à la rétro, il l'anime seulement et ne donne pas son avis. En plus de ça, pour lui, la rétro tourne autour des stories du sprint.
À partir de là, j'ai compris que je n'allais rien apprendre. Mais ça parlait de Game of Thrones, donc c'était pas si pire.
-1/10

### Faire de l’amélioration continue une habitude quotidienne : introduction aux Toyota Kata

Toyota ils sont vraiment bons et ils faisaient de l'agilité avant que l'agilité existe. Bravo les nippons.

## Jeudi 14

### Keynote: Les intéractions entre les personnes

Quelques sketchs pour démontrer des choses un peu bateaux.
Un peu de psychologie par-ci par-là.
Et du Rock (AC/DC, Aerosmith, etc)

### Le Product Owner pour les débutants

### Conception Emergente

Généricité vs Spécifité ? Quand est-ce que l'on veut écrire une feature générique, qui coûtera plus cher au développement mais réutilisable, contre une feature spécifique à un besoin, qui elle ne sera pas réutilisable.

Un petit jeu a démontré que beaucoup de développeurs présents dans la salle paient de la généricité, alors qu'ils ne savent même pas si le code sera réutiliser.

Si on peut résumer ce talk par une phrase : "Three strikes and you refactor", _Martin Fowler in Refactoring_

### Valoriser son backlog

Le talk portait sur l'évaluation de la Valeur Métier des User Stories d'un backlog.
L'objectif est de priorisé ses User Stories en maximisant la Valeur Métier des features qui doivent être développées. Pour rappel, la priorisation peut s'effectuer par les variables suivantes : Valeur Métier, Complexité, Dépendences, Risques

Différentes techniques de mesure de la valeur métier ont été proposées, dont 3 ont été détaillées. Je vais pas entrer dans le détail de chacune, vous pourrez trouver des explications partout sur le net.

Liste des noms des méthodes :
* Moscow (Très Simpliste)
* Kano (Enquête User pour déterminer les Must-be)
* NPS
* Priority Poker (Idem que pour l'estimation de la complexité par un scoring avec la suite de Fibonacci)
* Business Value (Simpliste)
* Poids Relatif (prend en compte les bénéfices de réalisation & les pénalités de non-réalisation)
* Buy a feature
* Theme Scoring (Evaluation par critères, un peu plus lourd à mettre en place)
* Analyse financière

### 50 shades of SM

A priori, 95% des gens étaient SM et 2 étaient Scrum Master :laughing:
Un talk très complet sur le rôle du Scrum Master au sein de l'équipe Agile.

Elles ont détaillés chacune des nuances qu'elles estimaient être représentatif d'un bon Scrum Master, ces nuances étant : Servent Leader, Facilitateur, Leveur d'obstacle, Agent du Changement, Formateur, Mentor, Coach. _(il y en a pas 50 sorry)_

On peut voir plusieurs niveaux de Scrum Master :
* Celui qui colle les post-its et planifie les réunions
* Celui qui emmène l'équipe vers la performance
* Celui qui va coacher son équipe

Il y a eu aussi un rapprochement entre le rôle de Scrum Master et le Management 3.0 mais ca sortait un peu de la discussion.

### Mon manifeste de manager agile

Quels sont les avatanges d'introduire l'agilité au niveau du management (managers au dessus des équipes de développement) ? Beaucoup de bon sens dans cette présentation, qui venait principalement des court échanges entre participants, plus que de la speaker, qui s'est contenté de nous présenter différents "styles" de management.

Elle a conclut en nous montrant une slide avec de nouveaux _statements_ "à la manifeste agile" (**ça** plutôt que **ça**) et en nous disant "si vous deviez en ajouter 3 pour votre situation".

Il y avait des managers dans la salle, c'était peut être + utile pour eux que pour moi, étant déjà convaincu par l'intérêt de plus d'agilité.

### Innovation managériale : sommes-nous des innovateurs, des inno-vanteurs, ou des restaurateurs ?

J'avais déjà vu une conférence de Vanessa Humphreys l'an dernier (l'agilité mis en pratique dans le cadre familial — c'était drôle mais je sais pas si j'en ai retenu grand chose).

Cette année elle revient avec une "réflexion" sur qu'est-ce que c'est qu'être innovateur. Avec des définitions sorties de différentes sources. Beaucoup de questions, mais peu d'enseignements.

### Keynote: Charisme et Fellowship du manager

_par Arnaud Riou, conférencier, auteur, et guide spirituel_

lolwat.

Plus sérieusement, s'il faut sauver quelque chose de cette conférence c'est le fait que **le sens** est primordial au travail et que les gens se lèvent le matin s'ils savent _pourquoi_ est-ce qu'ils viennent travailler.

À part ça il a parlé de physique quantique et de chamanisme.

### Comment tester au plus tôt : agilité dans le cycle en V en contexte normé

Comment Thalès a introduit l'agilité dans un contexte devant fonctionner en cycle en V (domaine de la santé & ses réglementations).

Le sujet était intéressant. Comment est-ce que cycle en V et agilité peuvent cohabiter. Au final ils sont arrivés à faire plusieurs petits cycles en V pour réduire la quantité de retours du client à la fin (au moment du seul livrable).

Beaucoup de bon sens, on revoit là les avantages de l'agilité. Speakers peu à l'aise, dommage.

### Mais bordel pourquoi on ne m'écoute pas ?

_"Sois le changement que tu veux voir dans le monde" - Gandhi_ :pray:

So deep. C'était a priori la 6ème édition de ce talk mais je n'ai pas senti le speaker très à l'aise et les participants étaient dubitatifs. Les énoncés des expériences étaient flous et on ne voyait pas trop la finalité.

En très résumé : il faut se mettre à la place de l'autre pour mieux comprendre & faciliter les discussions.

Le speaker a présenté
- les cadres de référence (il y a une vérité, et chacun voit cette vérité à sa manière)
- le great gift (ce pour quoi on est fait) & l'ikigai (pour avoir lu sur ce sujet, il avait pas l'air très au courant ; il prononcait d'ailleurs _igikai_ :facepalm:)
- un modèle étrange de "--", "+-", "-+", "++" ; là vraiment tout le monde était flou sur la finalité. Si j'ai bien compris c'est juste de se mettre dans un mindset positif lorsqu'on engage une discussion (je vais tirer quelque chose de cette discussion, et mon collègue aussi)

C'était un genre d'introduction à des principes de développement personnel, vaguement appliqués au monde du travail. Il aurait sûrement été + pertinent de faire une conférence détaillée sur un sujet plutôt que de tout balancer comme ça.

Ah et la réponse au titre de la prés serait : C'est pas qu'on ne vous écoute pas, c'est que vous n'écoutez pas.

#deep

### Construisez-vous le bon produit ?

Des rappels assez basiques sur ce qu'est la construction d'un produit et les outils adaptés. Garder l'utilisateur au centre de ses préoccupations, les personas, etc.

Globalement intéressant.

Point à retenir

> **S'il y a une chose difficile à changer... c'est la culture**
> Cultural change comes last, not first
> To change the culture, you have to change the organization and the practices
> _House of Lean_

à méditer

### Concevoir pour des futurs désirables

TL;DR: L'écologie c'est l'avenir, votez les verts.

C'était principalement une présentation de notre futur proche (d'ici une 50aine d'année), différentes "versions" sérieusement envisagées et étudiées, pour prédire ce vers quoi on tend. On ne parle pas d'overboard, ni de voiture volante, mais de casatrophes; soit écologiques, soit économique, soit démographique.

Concrètement, on fonce dans le mur avec les émissions carbones actuelles, soit on va tous crever de chaud, soit une entité va contrôler les naissances pour qu'on soit moins nombreux, soit on doit retourner à un mode de vie low-tech, sans voiture, etc.

### Et si nos managers étaient indispensables ?

Une contre-conf face à toutes les conf qui tendent à dire que le middle-management est obsolète et qu'il faut du management 3.0 parce que les managers actuels sont coincés dans le siècle dernier et qu'on évolue trop vite pour eux et ils sont sûrement reptiliens.
C'était une présentation du "Lean management", démontrant qu'un bon manager "Lean" était, non pas obsolète, mais essentiel pour garantir l'épanouissement et l'efficacité des employés.
Ça ressemble un peu à l'idée du *servant leadership* (comprendre: le manager au service de ses employés)

Le manager lean a 5 axes de travail

#### 1. Challenge
Le but du produit est de satisfaire le client, le manager doit donc aligner l'équipe vers cet objectif, via des KPI qui concernent le client, et non des KPI internes (ex: le taux de couverture du code n'impacte pas le client)

#### 2. Gemba (endroit où se crée la valeur)
Il doit être proche de l'équipe, et attentif à leurs problèmes.

#### 3. Teamwork
Il doit notamment encourager et aider la mise en place de management visuel. Via le management visuel, les problèmes deviennent **visibles**, et il est plus simple de voir des axes d'améliorations émerger.

#### 4. Amélioration continue

PDCA / Kaizen

L'idée est d'identifier des problèmes (quantifiables), et de :
- mesurer le problème
- rechercher les causes
- mettre en place des contre-mesures pour rapprocer la mesure de la quantité souhaitée
- apprendre des contre-mesures, qu'elles soient efficaces ou non

(PDCA : Plan, Do, Check, Act)

#### 5. Show respect

> "Être doux avec les personnes, et dur avec les situations"

> "Les problèmes ne viennent pas des personnes, mais des systèmes au sein des quels elles se débattent"

Quand un problème surgit, plutôt que de chercher la personne responsable et de la blâmer, il faut identifier le problème clairement et chercher des solutions.
Le droit à l'échec est essentiel, pour permettre aux personnes d'expérimenter, et d'exprimer leurs créativité.
Les solutions doivent aussi émerger des employés, et non être "poussées" par la hiérarchie
Le respect de l'intelligence et des connaissances des personnes est au coeur du lean management

Dark lean = lean - show respect. Pas bien. :speak_no_evil:

### Mindset : c'est quoi ce truc ?

Une conf relativement abstraite, sur un genre de retour d'expérience de quelqu'un doit veut essayer de présenter le mindset agile sans trop le faire, et qui nous dit qu'il en a eu besoin à plein de moments et pour plein de raisons, mais voilà.

Dans l'idée, on a tous des croyances, des façons de penser, et selon les situations on est soit fermés "fixed", soit ouverts "growth", et qu'on fait le pendule entre les 2. Et qu'il faut se pousser à être plus ouverts d'esprit.

En gros.