Le programme de l’Agile Tour Montpellier 2023

« On déteste Scrum ! Les équipes sont épuisées, c’est trop de contraintes et ça ne marche pas ! » De plus en plus d’équipes et d’organisations peinent ou échouent à être efficientes et à créer de la valeur avec Scrum. Découvrons le Scrum de l’enfer, celui qui est vécu au quotidien dans de nombreuses organisations, sans même le savoir ! Démystifions les plus profondes certitudes et découvrons comment sortir du mauvais Scrum pour renouer avec le plaisir, la confiance et la productivité. Jean-Christophe est PST Scrum.org et n’a pas la langue dans sa poche ! Une conférence à succès à l’Agile Tour Montréal 2022 et à l’Agile Tour Sherbrooke 2023 !

L’auto-organisation est le credo de toutes les équipes agiles, mais est-ce que beaucoup l’appliquent vraiment? Qu’est ce que ça signifie concrètement? qu’est ce que ça implique? Est-ce que ça peut fonctionner?

Dans ce talk nous souhaitons vous raconter l’histoire de la Crèmerie, épicerie coopérative auto-gérée à Clapiers que nous avons créé il y a trois ans avec un groupe de personnes qui ne se connaissaient pas, avec pour principal objectif de prendre le contrôle sur notre consommation. Dès le départ, l’épicerie applique les principes de l’agilité, met en place des groupes de travail (feature teams?), des rituels etc et se retrouve vite face à des lourdeurs et difficultés à avancer malgré la motivation de toustes.

Le passage à un modèle horizontal auto-organisé, basé sur la confiance et la responsabilisation nous a permis de faire décoller l’épicerie et d’être plus efficaces et plus engagé.e.s

Nous aimerions faire le parallèle entre cette organisation et notre vie professionnelle, et voir comment on peut s’inspirer des succès et difficultés de la Crèmerie pour progresser dans nos équipes respectives.

En janvier 2023, je me suis lancée le challenge de questionner au moins une fois par jour chatGPT afin de me créer une habitude. En quelques mois, chatGPT m’a fait gagner de précieuses heures chaque jour en tant que first Product Manager dans une startup montpelliéraine en pleine croissance. J’aborderai mes utilisations quotidiennes de l’IA en tant que Product Manager. Je vous montrerai comment je gagne plusieurs heures par jours sur certaines actions grâce à chatGPT ou d’autres outils du marché.

A travers ce retour d’expérience, j’expliquerai comment nous avons mis en place un mécanisme d’innovation, par les équipes et pour les équipes, qui a permis

• à chacun d’apprendre sur des sujets choisis et non imposés,
• de mieux connaitre les autres et d’améliorer la collaboration,
• de tester des choses sans risque d’impact sur les projets (nouvelles technologies, nouvelles méthodes, nouvelles fonctionnalités, etc), et donc d’encourager la prise de risque
• in fine de gagner en motivation et de fidéliser les équipes.

Cette méthode a été mise en place dans une équipe de 25 personnes (dev / SM / POs), dans un contexte d’une R&D pour un grand groupe pharmaceutique et a montré de nombreux avantages, sans impacter la vélocité des équipes voire en l’augmentant légèrement, alors que 10% du temps des équipes y a été dédié sur plus d’un an.

“Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s’adaptent le mieux aux changements.”

Cette citation de Charles Darwin est souvent associée aux méthodes agiles, montrant la nécessité d’adapter en continu les priorités produits pour survivre aux évolutions du marché. Mais qu’en est-il de l’architecture et du code en lui-même ? Un logiciel ne serait-il pas finalement une espèce vivante, évoluant au fil des mutations, et où seules les solutions répondant au besoin peuvent survivre ?

Xtreme Programming a popularisé la notion de design évolutifs par opposition aux méthodes waterfall classiques, et le débat « Design Emergeant » contre « Design Planifié » faire encore rage aujourd’hui au sein de la communauté. Nous verrons comment tirer parti de ces deux approches et comment concevoir une architecture évolutive sans qu’elle devienne un empilage de solutions adhoc.

Pour finir, nous étudierons quel est le rôle de l’architecte dans tout ça. Est-il une force bienveillante, guidant l’évolution du logiciel pour lui permettre de survivre ? Est-il au contraire un prédateur, éliminant les parties faibles au profit des parties les plus fortes, ou n’est-il finalement qu’une proie cherchant juste à ne pas se faire manger ?

Récemment je proposais à un projet l’idée d’un tableau Kanban pour les aider. La réaction fut immédiate : “Mais Sébastien, Kanban ça ne va pas nous aider, c’est juste un tableau avec des colonnes et des post-its !”. De toute évidence certains préjugés ont la vie dure !

Dans cette session, je vous propose de commencer par un rapide rappel de la méthode Kanban. Puis nous explorerons quelques points méconnus qui sont au cœur de la méthode Kanban et de son efficacité, tout en déconstruisant quelques mythes et préjugés.

Cette session vous permettra de :

• mieux comprendre les mécanismes sous-jacents au cœur de la méthode Kanban et vous
• vous apporter des idées pour (re)dynamiser votre Kanban
• changer vos éventuels préjugés sur Kanban

Depuis que Marty Cagan a sorti son livre « Inspired », le mot Discovery est dans la tête de toutes les équipes Produit et des Product Managers.

Au point que plus un Product ne veut sortir quelque chose sans une phase de discovery menée dans les règles de l’art en amont.

Le problème : Dans la majeure partie des organisations, ces méthodes sont très éloignées de la réalité et sont difficilement applicables sans un changement profond des manières de faire.

Pire encore, elles ne répondent pas toujours aux enjeux bien spécifiques de ton projet 😬

Dans beaucoup de cas, c’est donc inévitable : ça ne fonctionne pas, il y a des frictions entre les métiers, la sensation de ne pas bien faire son job et à la fin on n’est plus écouté par sa hiérarchie.

Comment se réapproprier les méthodes de discovery et les ramener dans ta vraie vie pour le succès de ton projet ?

Nous aborderons :

➡️ Les cas dans lesquels une démarche Discovery est souvent néfaste à la réussite d’une boîte/un produit

➡️ Comment on peut intégrer les bénéfices de la démarche en se concentrant d’abord sur le delivery

➡️ Les clés pour ne plus avoir à convaincre sa hiérarchie, mais prouver par le concret

Rares sont les développeurs qui ont une façon de penser qui leur permet une vraie agilité. Dans les entreprises, cela se traduit par des conflits entre les “métiers” et la “tech”, chacun disant que l’autre “est trop nul(le) et que c’est sa faute que tout se plante”… Et le plus fou, c’est que chaque camp a raison !

Dans cette conférence, on va rapidement voir pourquoi ça arrive, “a ki c la fote”, mais surtout, des astuces pour s’en sortir et ENFIN commencer à bosser mieux.

Après une levée de fonds, la start-up Fabriq souhaite accélérer son expansion en France et à l’international. Pour y parvenir, elle triple les effectifs de son département produit. Cet accroissement des salariés s’accompagne d’un changement total des pratiques, des process, des comportements et de la politique managériale. En piochant du côté du lean, de l’agilité et de la sociocratie, le département produit souhaite grandir en nombre mais aussi en maîtrise. L’objectif est multiple : profiter de l’arrivée de nouvelles personnes pour produire plus, produire mieux et produire plus vite – le tout en s’assurant d’offrir aux employés un cadre de travail épanouissant. Un an après : qu’avons-nous pu réussir, rater et apprendre ?

Il y a 20 ans, quelques pratiques agiles peu documentées permettaient à des équipes volontaires de produire de la valeur pour leurs clients.

Aujourd’hui, sous prétexte d’exhaustivité, l’agilité s’est enrichie de nouveaux frameworks, de nouvelles pratiques et d’une pléthore d’outils.

Alors :

• Produisons-nous plus de valeur ?
• Sommes-nous plus heureux ?

Et si notre quête de la complétude nous avait tout simplement fait oublier l’essence même de l’agilité ?

Et si nous parlions d’anatomie ? D’ailleurs comment innover seul ? comment faire pour concevoir le bon produit et bien le réaliser ?

Présentation de la mécanique d’innovation et d’ateliers collaboratifs permettant de bien innover.

Cette conférence est centrée autour du « bon » produit, quand innovation produits et services riment avec performance technologique.

N’avez vous jamais rêver de produire votre documentation depuis votre environnement de développement, et avec les mêmes processus que le code de vos applications ?   La promesse des outils de Documentation as Code est de vous aider à vous focaliser sur le contenu, en leur laissant la charge de la mise en forme. Mais si vous avez déjà utiliser ces syntaxes, en dehors de gestionnaires Git (GitLab, Github, …), vous avez sans doute rencontré quelques difficultés pour partager vos contenus.

Mais par où commencer ?  Nicolas, tombé  par hasard dans l’écosystème Asciidoc, n’a pas échappé à ces écueils et vient aujourd’hui vous partager quelques astuces.  Alors venez (re)découvrir quelques outils de base pour bien vous lancer dans votre histoire avec la Doc as Code…

L’éco-responsabilité est l’affaire de tous. Partant de ce constat, comment faire face aux défis de demain en tant que Product Manager ? Je vous propose d’approfondir 3 leviers que j’ai expérimentés en tant que PM pour un impact plus responsable.

L’écoconception est un concept flou et souvent employé à toutes les sauces.

Nous allons voir pourquoi et comment on peut écoconcevoir nos services numériques, et spoiler: ce n’est pas une histoire d’optimisation de code mais concerne bien toutes les équipes.

A l’aide du Référentiel général d’écoconception de services numériques (RGESN), nous allons explorer de quoi il s’agit et surtout lister les co-bénéfices pour nos applications (performance, sécurité, et respect de la loi).

“The free lunch is over”, alors formez vous sur l’écoconception !

Lorsqu’il s’agit de développement logiciel et d’agilité, il est souvent question de livrer rapidement des fonctionnalités, en faisant parfois des compromis en termes d’architecture ou de design (bien entendu, sans sacrifier la qualité, n’est-ce pas ? :-p). Ces raccourcis pris pour fournir de la valeur à l’utilisateur le plus rapidement possible et obtenir son feedback handicapent les développements futurs, rendant les nouvelles fonctionnalités de plus en plus complexes à développer et les gros changements plus difficiles à réaliser.

On appelle cela la dette technique, et n’est pas forcement une mauvaise chose (même c’est souhaitable de n’avoir un peu) car elle nous permet d’avancer plus rapidement dans un premier temps et de valider plus rapidement la fonctionnalité, le produit ou le service.

Cependant, tout comme la dette économique, il ne suffit pas de la cacher sous le tapis, car elle génère des intérêts qu’il faut payer à un moment donné, à moins que l’on ne décide de tout abandonner et de recommencer à zéro. Mais comme cette dernière option est la plus coûteuse (même si c’est celle que nous, les développeurs, préférons), une bonne gestion de la dette est indispensable : il faut la visualiser, la comptabiliser, savoir l’expliquer et trouver le bon moment pour la rembourser.

Avec cette présentation, je vais traiter:

• Comprendre la dette technique: Qu’est-ce que c’est ? Elle est positive ou négative ?
• Compromis de l’agilité: Livrer tôt vs livrer plus tard mais « parfait » ? Avantages et limites de l’approche.
• Gérer la dette technique: Rex de la méthode que j’ai déjà utilisé auparavant dans certains de mes projets. Comment faire le choix de prendre de la dette, de la payer
• Trouver l’équilibre entre rapidité et « qualité ».

Le Product Led Growth (PLG) ou « croissance axée sur le produit », est l’une des stratégies les plus populaires pour les produits B2B aujourd’hui, mais qu’est-ce que la PLG exactement ? Quelles différences avec les traditionnelles SLG (Sales Led Growth) et MLG (Marketing Led Growth) ? Pourquoi faut-il commencer à structurer votre stratégie PLG ? Comment implémenter cette stratégie ?