Les 3 et 4 Novembre dernier se tenait l’Agile Tour Nantais 2022 à l’IUT de Nantes.
Cette année le thème était :
Valeur et agilité ?
Si je vous dis : “valeur et agilité ?” Avez-vous pensé immédiatement aux 4 valeurs du manifeste agile ? Et c’est peut-être là une source de confusion ! Si vous relisez le premier principe, il est question de livrer des fonctionnalités à haute valeur ajoutée. Et si on parle de Scrum, il y a aussi 5 valeurs. Pis, si on parle de code, certains estiment la valeur au nombre de lignes…Il y a de quoi y perdre son Latin UTF8 !
Et VOUS, comment vivez-vous cette notion de valeur en agilité ? Comment cela s’exprime-t-il au quotidien ? Venez partager votre vision de la valeur, en participant à des ateliers ou des conférences autour de ce sujet, qui nous glisse entre les doigts dès qu’on pense l’avoir saisi =)
Et surtout, demain, de retour dans vos équipes, qu’allez-vous en faire ?
Nos 4 membres Nantais de la Practice Agile ont eu la chance d’y participer.
Nous reviendrons à travers cet article sur les principaux talk et ateliers qui ont retenu notre attention.
Nous vous proposons une série de 3 articles consacrés à ces deux jours.
Ce premier article sera consacré à la journée du Jeudi 3 Novembre.
Vous retrouverez l'article dédié à la journée du vendredi ici, et le dernier article consacré à "Gunther Le Jeu" ici.
La co-conception est morte... Vive la co-conception !
Sébastien Viozat - SQLI
Les ateliers de co-conception sont un vrai concentré de créativité "prestataire + client", permettant d'éviter les travaux design en circuit fermé avec ses interminables itérations à la clé.
Et pourtant, la grogne monte : trop encadrée, trop stricte, trop gourmande en temps... Assistons-nous à la fin de la co-conception telle que nous la connaissons aujourd'hui ? Une belle occasion de repérer ce qui coince, et d'adapter nos pratiques pour faire encore mieux, ensemble !
Le point de départ de cette conférence : beaucoup de clients ne sont pas contents des méthodes et des ateliers de co-conception : déjà fait, appliqué bêtement, etc…
Mais pour commencer, la co-conception c’est quoi ?
Définition de Sébastien : “C’est une méthode créative impliquant les profils métiers et utilisateurs dans le processus même de conception d’une solution : collaborer et ne pas travailler en antichambre, pas de boîte noire, on le construit ensemble et sans surprise.
Le résultat : Moins d’itérations post conception, plus d’implications des utilisateurs.”
Qu’est ce qui coince ?
1er constat : Nous utilisons beaucoup trop de jargon.
Des buzzwords en anglais que tout le monde ne comprend pas. Et parfois même dans le nom de nos métiers : Scrum Master, Product Owner…
Il en résulte parfois une déconnexion avec le métier.
La conférence suivante de Nathasha Jen de Pentagram “Design Thinking is bullshit” résume très bien cette partie :
2ème constat : Trop suivre la méthode peut tuer la méthode.
L’utilisation stricte de la timebox peut couper des échanges importants qui nous serviront plus tard.
« Design thinking is All » → Nous n’avons pas besoin de toujours faire tous les ateliers si les précédents ont déjà répondu aux questions.
3ème constat : On en a marre des post-it !
Les post-it ne font pas de bons livrables. En effet, réutiliser toujours les mêmes méthodes amène un sentiment de déjà vu et une lassitude chez les participants, qui entraine une baisse de la productivité.
Conclusion : La co-conception est très fragile !
Mais alors, comment trouver la bonne méthode de co-conception ?
Malheureusement, il n'existe pas de formule magique pour la trouver.
L’important, c’est d’abord de prendre en compte tous les paramètres que nous avons à notre disposition :
- La difficulté du projet
- La sensibilité à l'UX et la motivation des participants
- L’expérience de l’animateur et des UX
- L’organisation : en présentiel, en distanciel , mixte
Exemple qu’on a déjà tous connu : la veille de l’atelier, nous sommes prévenus que quelqu’un est à distance alors que tout est prévu en physique.
Mais, comment faire mieux ?
En prenant en compte tous ces paramètres ainsi que la connaissance de votre client, adaptez vos méthodes et vos discours, devenez un caméléon :
- Sortez du dogme
- Écoutez les contraintes de vos clients
- La disponibilité des collaborateurs, le temps, les cours etc
- Adapter les méthodes avec votre grain de sel
- Transmettez votre savoir : pas besoin qu’ils deviennent experts mais donnez leur des billes
“Voilà pourquoi, voilà la bonne pratique” → Faites un détour s’il y a un manque de connaissance - Soyez réalistes
Qu’est-ce qu’on peut faire ? Ça sert à rien d’imaginer des choses sans prendre en compte le cadre technique s’il y en a un - Gardez l’esprit auto-critique
Le résultat escompté ne sera peut-être pas au RDV, mais avec une prise de recul et un sens critique, vous comprendrez ce qui n’a pas été et vous saurez rectifier le tir.
Sébastien finira son talk sur ces belles paroles :
Au départ, en essayant d’adapter vos méthodes, vous allez vous planter !
Mais tomber fait partie du voyage, et quand on se relève, c’est beaaaauuuu !
REX : L'architecture hexagonale est-elle la clé de la transformation des SI vieillissants ?
Bertrand Matamon, Bastien Cruz - Pole Emploi
L'évolutivité des systèmes monolithiques dans les grandes DSI est un problème de plus en plus récurrent. L'essor des technologies de conteneurisation et de Cloud ont amené à un changement de paradigme via un découpage des systèmes en microservices. En parallèle, les approches métiers ont évolué avec l'émergence du Domain Driven Design (DDD), ce qui nous oblige à appréhender l'architecture logicielle différemment. A la croisée de ces évolutions se situe le pattern d'architecture hexagonale, qui se présente comme un acteur majeur dans l'accompagnement à la modernisation des systèmes d'information.
Au travers de ce retour d'expérience, nous vous présenterons un projet de migration d'une architecture monolithique vers une architecture hexagonale. Vous découvrirez nos pérégrinations au sein de cet écosystème en pleine transformation, dans notre quête de l'évolutivité : L'architecture hexagonale est-elle le graal qui ouvrira les portes aux systèmes de demain ?
A l'issue de cette lecture, vous ne saurez pas comment mettre en place une architecture hexagonale sur votre projet, mais vous connaîtrez un des cheminements possibles, logique, qui amène à son adoption.
Contexte
Les deux intervenants Bertrand Matamon et Bastien Cruz travaillent à l'ANPE, sur un mécanisme de cartographie interne (identification des ressources, des serveurs, des applis, ...).
C'est un système vieillissant, qui accumule la dette technique.
Un seul exemple : le plus gros POJO fait 25 000 lignes et contient 400 attributs.
Et c'est le point de départ de cette longue épopée, qu’ils nous racontent à la manière d’un roman d’aventure.
Tome 1 : L'état des lieux
Le SI d’une entreprise peut être vu comme un ensemble de petites civilisations. Et comme tout système, il finit par vieillir.
Une architecture monolithique est une architecture sur-mesure répondant précisément à un besoin initial. Elle est autonome (peut fonctionner seule) et ses composants sont fortement couplés. Et ce couplage étroit est un des principaux inconvénients des architectures monolithiques. Au fil du temps, les composants deviennent de plus en plus liés et enchevêtrés.
Ce phénomène affecte la gestion, l'évolutivité et le déploiement continu. Plus la complexité augmente, plus le système évolue difficilement. Et plus il devient nécessaire de retester tout à chaque évolution, même ce qui en apparence ne semble pas lié.
L’ANPE s’est trouvé précisément dans ce cas. Les estimations de complexité devenaient de plus en plus compliquées, des User Stories (US) qui auraient pris un sprint pour être développés quelques mois auparavant prenaient désormais plusieurs sprints. “Choisir une US, c'est jouer à pic pirate”.
Et visuellement, c'était flagrant, la courbe de vélocité commençait à ressembler à un burndown chart !
Les dernières rétrospectives se passaient mal (mauvaise ambiance, moral dans les chaussettes, relations conflictuelles avec le PO, vote de confiance à 1/5, ...) mais un phénomène de Déni était quand même présent qui a ralenti la décision de changer les choses car “ça tourne bien en production” !
Tome 2 : le début de la quête
A l'opposé du monolithe, les microservices sont des composants petits, simples et indépendants.
Cela solutionne bon nombre de problèmes rencontrés par nos deux speakers, mais ce n'est que le début de la quête du Graal. La mise en place s’est bien passé, mais si les problèmes techniques ont été adressés, le découpage mis en place a éparpillé la logique métier. Métier qui est pourtant le besoin initial.
Ils se sont alors tournés vers le DDD (Domain Driven Design), une technique de conception logicielle orientée métier, fondée sur 2 principes :
- Les conceptions complexes doivent être basées sur un modèle (= la sphère d'un métier ou d'une activité pour lequel on développe l'application)
- L'accent doit être mis sur le domaine et la logique associée.
Comme l'explique un des orateurs, le DDD peut être vu comme la pierre de rosette de l’informatique, qui permet aux métiers de comprendre les développeurs et réciproquement.
Cette découverte va permettre d’amorcer une nouvelle trajectoire, centrée sur la valeur.
Suite à une longue phase de 3 mois d'Event Storming (atelier permettant de redéfinir correctement le périmètre, ainsi que les rôles et limites de chacun des acteurs), le Graal n'était pas encore atteint. En effet, DDD est “juste” une approche et l'absence d'un cadre de développement a entraîné un certain nombre d'inconvénients. Par exemple, une contamination du langage : les US contenaient des termes techniques (Kafka, batch, …) là où on aurait souhaité qu'elles ne parlent que de métier.
Tome 3 : la fin de la quête
C’est là que l'architecture hexagonale entre en jeu. Son principe est simple : elle permet de créer des systèmes à base de composants d'application qui sont faiblement couplés et qui peuvent être facilement connectés à leur environnement logiciel au moyen de ports et d'adaptateurs. A noter que le terme hexagonal est purement arbitraire : elle aurait très bien pu être nommée heptagonale, voire hendécagonale.
Elle fait parfaitement le liant entre DDD et microservices.
Et elle répond aux obstacles rencontrées précédemment :
- le Domaine (le métier) est bien protégé grâce à la frontière, clairement formalisée, entre le monde métier, et le monde technique (= pas de contamination du langage)
- excellente testabilité
- code (uniquement métier) facile à lire, la connaissance du code (et donc la montée en compétence) est facilitée
- les estimations sont facilitées
Épilogue : ne pas oublier une dose de pragmatisme
Attention à ne pas mettre de l’architecture hexagonale partout (syndrome de la ruche). Chaque hexagone a un coût, important, à l'entrée (mise en place des contrats d'interface, mise en place d'une couche anti-corruption ACL : Access Control List, ...).
Si on raisonne "by the book", il ne faut aucune dépendance. Pourtant, nos deux orateurs ont pris quelques libertés :
- afin de ne pas réinventer la roue sur certains composants (librairies de traitement de chaînes de caractère, gestion des logs avec log4j)
- Spring est très contaminant, mais ses annotations ont pourtant été utilisés (relativement facile et immédiat si on veut les changer)
En résumé, une conférence très intéressante, avec une narration vraiment originale.
Changement de culture bien ordonné commence par soi-même
Haja Rambelontsalama - Orange
Qui veut du changement ? 😎 Yeaah
Qui veut se changer ? 😬 Euuh
Qui veut mener le changement ? 😵. . .
Ok, juste mettre en place une nouvelle culture alors ? 😱 Fuyez c’est le plus dur !!
À la recherche de moyens, d'outils pour générer/accompagner/pérenniser le changement de culture dans votre organisation, venez découvrir les leviers pour mieux se comprendre et mieux comprendre les autres pour mieux travailler/collaborer/coopérer/vivre ensemble.
Travailler sur soi c'est déjà travailler pour l'équipe et "il n'y a pas d'excellence technique sans excellence humaine"
A la sortie de ce format inédit : conférence-retex-atelier-échange, oseriez-vous réveiller tous ces leaders qui sommeillent ?
La culture c’est ce que l’on fait quand personne ne nous dit quoi faire.
Est-ce que la culture c’est important ?
Ce qui est le plus important pour les collaborateurs à travers le monde c’est la sécurité psychologique, le respect des personnes.
Une étude Glassdoor montre que ce qui importe le plus au moment de choisir une entreprise ce sont ses valeurs et sa culture.
Melvin Conway dit : “Ce que l’on produit est à l’image de notre organisation”
Est-ce que la culture est mesurable ?
Culture pathologique : orientée pouvoir, à la gloire du décideur. Donne des KPI pastèques (vertes à l’extérieur, rouges à l’intérieur)
Culture bureaucratique : à la gloire du service, “pas nous, pas nous” . La hiérarchie est là pour ne pas se faire court-circuiter
Culture générative : orientée performance, tout le monde est dans le même bateau, co-responsabilité, culture d’apprentissage, droit aux erreurs.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/pdf/v013p0ii22.pdf pour plus de détails
Une fois dans une culture d’apprentissage, comment bien travailler et apporter de la valeur à l’équipe ?
Planificateur vs Créatif. comment faire bien travailler ensemble ces deux profils ?Au long de la vie d’un projet :
- Vision / Idéation : domaine des créatifs
- Structuration : Créatifs en lead, planificateur en soutien
- Derniers préparatifs : Planificateur en lead et créatifs en soutien
- Pendant : Les créatifs gèrent les imprévus, les relations extérieures, les incidents. Les planificateurs exécutent le plan, organisent, coordonnent
- Après / Bilan : Rétrospective tous ensemble. Les planificateurs donnent les KPI et analyses chiffrées, les créatifs donnent du feedback, des verbatims
- Nouvelle idéation : on recommence
Pour bien travailler ensemble :
- Apprécier la qualité du défaut de l’autre
- Aller un peu vers l’autre
- S’accepter soi-même
NB : La culture de toute organisation est façonnée par le pire comportement toléré par le management.
Conclusion : Le format un peu hybride de la conférence avec beaucoup d’échanges donne un sentiment de multiplicité des sujets abordés, tous intéressants mais peut-être trop nombreux pour être traités correctement en une heure.
On en retient néanmoins que la culture d’une entreprise est primordiale et peut être comprise comme pathologique, bureaucratique ou générative. Et qu’on a des leviers pour profiter des talents de l’entreprise à condition de respecter leurs tendances naturelles dans le travail.
Passons maintenant aux ateliers de ce Jeudi
De toute façon, l'important c'est les valeurs
Gilles Brieux
Combien de fois avez-vous entendu un « spécialiste » de l’agilité vous dire que l’important c’est d’apporter de la valeur aux utilisateurs.
Facile à dire. Mais ça veut dire quoi créer de la valeur ? Et comment estime-t-on celle-ci ?
Je vous propose de percer ce mystère dans un atelier fun et ludique. Vous découvrirez également différents outils de priorisation et surtout comment les utiliser.
Après une rapide introduction de Gilles, il nous propose de mettre en pratique une suite d'ateliers sur la priorisation de notre nouveau produit, “Adopte un agiliste.com”, fruit de son imagination. : cette nouvelle plateforme permettrait de mettre en relation des agilistes et des entreprises, mais pas que.
Nous sommes répartis en groupe de 4-5 personnes et recevons une enveloppe contenant un ensemble d’US/Feature imaginés pour notre produit.
On ne jugera pas lors de l'atelier la valeur des US/Feature ou du produit, qui ne sont données que pour base de travail.
1. Pyramide des valeurs de Bain & Company :
https://media.bain.com/elements-of-value/#
Sur leur site, plusieurs exemples sont donnés en fonction du domaine.
L’exercice ici sera de sélectionner 5 valeurs que le produit portera.
2. Buy a Feature
A faire avec les parties prenantes de votre produit :
Chacun se voit distribuer 100€ en tranches de billets de 10€ (de monopoly bien sûr…) et doit les répartir sur les différentes features/US proposées.
Nous n’avons aucune limite de répartition : nous pouvons tous mettre sur une seule et même feature, nous pouvons ne pas tout utiliser, etc…
Cela permet à chacun d’exprimer sa vision de sa priorisation.
https://blog.myagilepartner.fr/index.php/2018/12/13/innovation-game-buy-a-feature-pour-prioriser/
3. Présentation des matrices valeur/effort et urgence/impact
4. Présentation du coût du délai
https://coach-agile.com/2018/11/priorisez-avec-le-cout-du-delai/
5. Calcul de WSJF de SAFe
https://www.scaledagileframework.com/wsjf/
L’atelier et le partage d’expérience montre qu’il est souvent difficile pour les parties prenantes d’appliquer les notions d’urgence et de réduction de risque.
6. Framwork AARRR
Acquisition, Activation, Rétention, Referral, Revenue
Nous essayons de placer nos US dans les différentes catégories.
Certaines se retrouvent forcément entre plusieurs.
http://www.ymasc.fr/ameliorer-vos-ventes-la-methode-du-pirate-aarrr/
Les valeurs de Kanban
Olivier My et Loïc Seyer
Les valeurs aident à évoluer dans un écosystème en servant de guide et en donnant du sens aux actions.
Vous connaissez peut-être les valeurs de Scrum mais connaissez-vous celles de Kanban ? Élaborées vers 2013 par Mike Burrows, elles sont au nombre de 9.
Que vous soyez débutant(e)s ou expérimenté(e)s, je vous propose de venir les découvrir pour prendre du recul sur cette approche et trouver des axes de mises en oeuvre dans votre contexte !
Si je devais résumer cet atelier en quelques mots je dirais, “échange”, “partage” et “confrontation”. En effet tous les exercices qui nous ont été proposés avaient pour vocation de nous faire réfléchir au “pourquoi celles-ci ?’ mais aussi de confronter nos points de vue et apprioris vis-à-vis de ces valeurs.
“Le Kanban ou « l’intention d’amélioration continue » comme le décrit David J. Anderson, est souvent introduit par ses 6 pratiques fondamentales et ses 4 principes fondateurs. Mike Burrows, auteur de l’excellent Kanban from the inside, nous offre une toute nouvelle perspective en tentant d’identifier les valeurs derrière la méthode.”
Voilà comment Olivier MY a introduit le sujet de l’atelier que nous allions dérouler. Ce que je retiens également de cette introduction est cette ligne directrice : on part avec ce que l’on a et on améliore au fil de l’eau ce qui peut/doit l’être. De plus, le changement ne doit pas venir d’une seule personne mais de toute l’équipe. N’importe qui peut avoir une bonne idée. Le leadership doit être porté par l’équipe et non pas par une unique personne.
Pour la suite de l’atelier, nous avons été divisés en groupe de 4 personnes afin de simplifier les échanges et de travailler en mode collaboratif.
Exercice 1 : Associer chaque valeur à sa définition
Dans cet exercice, le but est de confronter les définitions que chaque membre du groupe associe aux valeurs. Nous nous sommes rendus compte que plusieurs définitions pouvaient convenir à plusieurs valeurs ce qui a permis de nombreuses discussions et argumentations. Les valeurs sont classées autour de 2 axes :
- Principes fondateurs
- Pratiques fondamentales
Exercice 2 : l’ordre des valeurs
Avant de commencer à réfléchir en petit groupe, Olivier et Loïc nous ont présentés les 3 agendas de l’ordre des valeurs selon Mike Burrows.
- Equipe : Transparence, Équilibre, Collaboration
- Client : Focus Client, Flux, Leadership
- Organisation : Compréhension, Respect, Entente-Accord
S’en est suivi une session de Codev (co développement) express ou l’un des participants nous a explicité une situation complexe à laquelle il fait face. L’objectif de l’exercice était donc d’identifier les 3 valeurs qui selon nous manquaient à son dispositif. Quelles sont les valeurs à travailler en priorité pour sortir de cette situation ?
Exercice 3 : Dessiner les valeurs
Après avoir passé 1h30 à discuter des valeurs, de leurs définitions mais aussi de leur mise en place au sein des dispositifs, il nous a été demandé de définir un visuel qui permettrait de mettre en image toutes les valeurs Kanban.
Il s’avère que chaque équipe a eu une perception totalement différente de cet atelier et chaque groupe a imaginé un univers totalement unique pour mettre en avant ces valeurs. Certains les ont imaginées selon les composantes du maison (Fondaction = Transparence, Toit = Collaboration, Porte = Flux, …) d’autres ont utilisé le schéma de la roue de Deming (voir photo plus bas) et pour notre groupe nous avons utilisé la représentation de l’arbre de vie selon les croyances Nordiques. Chaque planète représente une valeur. Au centre, la transparence et plus les planètes étaient proches, plus les valeurs étaient importantes pour nous.
L’atelier s’est terminé avec une proposition, pour aller plus loin : Lire le “Kanban Maturity Model” rédigé par David J.Anderson. J’ajouterai également de parcourir le site d’Olivier MY qui a été un excellent animateur et très pointu dans ce domaine.
https://oyomy.fr/
