FlowCon 2023 Jour 1

FlowCon, conférence Lean et Agile

FlowCon est la conférence française sur l’agilité et le flow que j’aime le plus. Elle me nourrit autant qu’elle me bouscule dans mes croyances et c’est toujours un moment agréable où je retrouve des agilistes passionné.e.s.

J’ai choisi de ne parler que des talks et ateliers que j’ai vraiment apprécié ici.

Sander Hoogendoorn - Beyond the innovator’s dilemma

Sander Hoogendroorn est le responsable technique d’une entreprise de la tech qui s’apelle Ibood.

Il commence son talk par une référence a Ward Cunninghan qui dit : “des lors que tu écris une ligne de code, tu produis de la dette technique.”

Grandir en tant qu’entreprise c’est voir son Système d’information  grossir, devenir hétérogene en terme de solutions et technologies et voir des interactions entre les systemes devenir complexes. C’est une autre forme de dette technique.

La dette technique est un probleme, qui peut devenir telle qu’elle supprime la performance d’une organisation.

La dette technique est une consequence de l’organisation.

Comment sortir de cette orniere dés lors que l’on a pris conscience de cette situation ?

Sander propose de l’appeller l’art de la rénovation continue.

Selon lui pour, pour avancer le plus rapidement possible, il faut utiliser la technique des petits pas et être patient.

Il détaille ces petits pas en 4 thématiques :

• livrer de petites fonctionnalités (et arréter avec les projets)
• dans des cycles toujours plus courts (et avancer vers le flow continu)
• avec des équipes toujours plus petites (qui s’auto-organisent et qui sont autonomes)
• avec des composants toujours plus petits (et aller vers des micro-architectures)

Livrer des petites fonctionnalités

Dans son organisation, les équipes répartissent leur travail de cette manière :

• 70% innovation
• 20% rennovation
• 10% faire que ca fonctionne (keeping the lights on)

Coté roadmap et priorisation, le tech board definit la stratégie de l’entreprise en repondant à ces 4 questions tous les 3 mois.

• Est-ce que ca nous aide à atteindre notre objectif business ?
• Est-ce que ce n’est pas trop gros ?
• Est-on en capacité à la faire ?
• Est-ce que l’on en a besoin MAINTENANT ? ou PLUS TARD ?

Des cycles toujours plus courts

Sander defend l’idée qu’on ne peut pas s’attendre à obtenir les bénéfices de scrum si on ne suis pas TOUTES les règles de scrum.

Sander rappelle aussi que Scrum n’est pas la fin du mouvement vers le toujours plus petit cycle et aussi que Scrum by the book n’est pas la seule façon de faire.

Il rappelle également que le progres n’est pas linéaire, qu’il faut être indulgent la dessus.

Pour lui, les cycles servent a sortir les fonctionnalités le plus rapidement possible. Et pour y arriver, il faut faire de la livraison continue, et livrer de tout petits changement.

Il rappelle la metaphore du bus : rater le bus ce n’est pas grave si vous savez qu’il y en a un autre dans 5mn. De la même façon, rater l’opportunité d’une livraison n’est pas trés grave si vous savez qu’il y en aura une autre demain ou dans quelques jours.

Pour arriver à cela il rappelle une évidence : il faut tout automatiser, investir dans une CI/CD complete, faire de l’infrastructure as code et integrer les tests dans les pipelines depuis les test unitaires jusqu’au test e2e.

Pas si simple Sander :)

Des équipes toujours plus petites

Le code est quelquechose de complexe voir chaotique, ce n’est pas possible pour une personne de tout connnaitre, vous avez besoin d’une equipe.

En faisant une comparaison avec les groupes de musique, Sander explique que les petits groupes peuvent s’autogérer alors que les orchestres sont composés de tant d’instruments differents qu’un chef d’orchestre est necessaire.

Dans son organisation, il n’y a aucune regles scrum. Les membres des equipes decident qui doit travailler sur quel sujet en fonction du probleme et des competences necessaies.

C’est une sorte de mode microteam qui change à chaque nouveau sujet à traiter. Ce cette manière, il obtient le maximum de flexibilité, d’autonomie et de prise d’initiative de la part des équipes.

Sander conclut son talk avec ces quelques mots :

• LESS IS MORE
• never stop learning
• never forget to have fun

Vous pouvez revoir le talk ici

Vous pouvez contacter Sander sur Linkedin ici

Et enfin les slides sont accessibles ici

Product Marketing Manager dans la vraie vie

J’aurais bien fait un debrief plus complet de la conférence de Chloé mais il n’y a pas eu de captation et je n’ai pas retrouvé son support.

Néanmoins, comme c’était un de mes talks préférés, j’ai fait quelques photos sur lesquelles je base ce résumé en complément de ma mémoire.

En gros, le Product Marketing Manager réponds pour moi à la question : comment completer le job de product manager sous l’angle de la promotion du produit vers ses utilisateurs.

Chloé parle de son experience : en théorie les product managers font le discovery, le delivery, parlent à leur client, les équipes savent présenter le produit en utilisants les supports existants, et l’experience client est maitrisée.

Dans la vraie vie, c’est completement faux

Chloé propose une répartition des roles entre PM et PPM.

Son rôle n’est pas simple car il n’est pas vraiment connu ni reconnu, elle doit donc créer des relations avec les équipes et trouver des relais de communication pour que son travail soit efficace.

Pour cela elle parle trés régulièrement de son rôle, elle identifie des champion.nes dans les équipes, et cherche à simplifier la compréhension et l’accés à la connaissance par la vulgarisation, en créant une base de connaisssances, une newsletter interne, et des formations mensuelles pour tous les collaborateurs.

Avant de terminer son talk, Chloé detaille son rôle et ses responsabilité en tant que product maketing manager.

Ce que j’ai beaucoup aimé dans ce talk c’est la clareté de la présentation d’un rôle méconnu qui peut être une solution dans les organisations produit où les product managers sont surchargé.es par d’autres responsabilités.

Dans tout son talk, Chloé envoie des messages subtiles mais bien présents sur un autre sujet qui est trés important pour elle : le féminisme.

Depuis, elle a même créé une chaîne youtube où elle donne la parole à des femmes et des personnes qui s’identifie en tant que telle dans le monde de la tech et du produit.

Il y a deja une quinzaine d’interviews au moment où je rédige ce compte-rendu et elles sont toutes de qualité.

Sa chaine youtube Les meneuses ici

Le compte linkedin de Chloé

Son site qui contient toutes ses ressources sur le product marketing managment

Le design d’organisation produit @ Peaksys

Samuel Retiere travaille chez Peaksys et propose de nous parler de design d’organisation produit en parlant aussi de ce qu’il met en place chez Peaksys.

Il rapelle où se situe la stratégie parmi les différentes strates de fonctionnement d’une organisation.

Puis nous parle spécifiquement des objetifs en détaillant les grandes familles d’objectifs.

• le ‘toujours plus’ de quelquechose
• la satisfaction. Des clients plus contents.
• la marge. Moins de coûts pour le même résultat

Puis décline les tactiques, les options que l’on pourra mettre en oeuvre pour atteindre les objectifs. Il les classe par ordre d’ampleur de l’impact potentiel

• les gros paris. Par exemple ajouter une nouvelle gamme de services
• les nouveaux services. Completer une gamme de service qui existe déjà
• les variations. Ajouter des options a des chaines de valeurs existantes.

Pour atteindre cela il décompte 3 modes d’organisation :

• les chaines de valeur, une organisation de bout en bout pour apporter une valeur à des utilisateurs. Généralement un parcours utilisateur spécifique a construire.
• les équipes impact, une autre organisation de bout en bout mais cette fois orienté client. Ces équipes prennent un probleme ou un besoin pour en faire une réalité.
• les équipes domaine métier, qui se chargent de maintenir et faire évoluer des chaines de valeur existantes.

Samuel a plusieurs inspirations de pratiques qu’il utilise pour le design de son organisation :

• Team topologies, pour les modèles d’organisation et d’équipes.
• Domain Driven Design (DDD), pour rendre visible les assets et les dépendances
• Jobs to be Done (JTBD), pour identifier les parcours utilisateurs.

A partir de la cartographie des domaines, de leurs assets et des parcours illustrés et superposés aux domaines il fait des choix stratégiques pour ajuster l’organisation aux orientations stratégiques selon une approche 1 + 3 étapes.

En première étape, Samuel explique qu’il identifie les équipes qui viendront en support des autres équipes (équipes plateforme et équipes de transformation). Puis :

• choix d’une option d’organisation
• cartographie du modèle de depart et de la cible
• adaptation du modèle à la réalité du terrain

Cette démarche dure environ 1 mois.

Je ne me souviens pas mais il faut rapeler ici que la taille de l’organisation peut influencer le temps necessaire pour son ajustement.

Vous pouvez retrouver une partie de cette présentation

Samuel a écrit un article qui reprends encore plus en détails mon résumé.

Et le compte linkedin de Samuel