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 :

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

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

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 🙂 )

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.

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à 🙂

<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 :