L’agilité au service des projets numériques : 10 conférences et ateliers phares de l’Agi’Lille 2023

Plus de 700 personnes étaient réunies pour deux journées dédiées à l’agilité et à son impact sur l’approche du travail.

CBTW
L’Actualité Tech — Blog CBTW
13 min readAug 8, 2023

--

Estelle et Antoine reviennent sur 10 conférences et ateliers qui leur ont permis de découvrir ou d’approfondir des approches agiles. Ils en retiennent des bonnes pratiques à appliquer aussi bien individuellement que collectivement.

Stratégie de Tests Agile : Menez l’offensive avec Natacha Fourmy

Dans le monde du développement logiciel agile, nous mettons souvent l’accent sur la rapidité et la flexibilité. Mais parfois, une étape essentielle est négligée : la stratégie de tests. Natacha évoque l’importance de cette pratique généralement sous-estimée et présente les idées novatrices à ce sujet.

Qu’est-ce que la stratégie de tests et qui la dirige ? Dans les projets agiles, la stratégie de tests est considérée comme une pratique cruciale. Elle consiste à définir comment évaluer la qualité des applications à chaque étape du processus de développement. Pour mener cette offensive, il faut une équipe compétente avec à sa tête un “chef de guerre” acculturé, c’est-à-dire un testeur agile. Il guidera l’équipe dans l’élaboration de la stratégie et la mise en place des outils nécessaires.

Quels sont les outils à disposition des équipes de testeurs agiles ? Ils disposent notamment de la fameuse “pyramide de test”, qui illustre la répartition des différents niveaux de tests (unitaires, intégration et interface utilisateur). Cette approche permet d’optimiser les ressources et de détecter rapidement les problèmes. En plus de la pyramide de test, Natacha Fourmy introduit une autre arme puissante : les “quadrans des tests”. Ces quadrans permettent de classifier les tests en fonction de leur impact sur le code et sur les fonctionnalités, aidant ainsi à prioriser les efforts.

Comment établir un plan de bataille ? Tout d’abord, il s’agit de commencer par une introduction claire avec les objectifs et le périmètre des tests. Cela permet à toute l’équipe de comprendre les attentes et les enjeux. De plus, une documentation de référence peut être mise en place pour guider les testeurs tout au long du processus. Cela s’avère particulièrement utile lorsque de nouveaux membres rejoignent l’équipe en cours de route.

Un autre point sur lequel Natacha Fourmy attire l’attention, c’est le reporting dans une équipe agile. Selon elle, il n’est pas nécessaire de se focaliser sur des rapports trop détaillés, mais plutôt de privilégier une communication transparente et régulière entre les membres de l’équipe. Cela permet d’identifier rapidement les problèmes et de prendre les décisions nécessaires pour les résoudre.

Une des idées disruptives de Natacha est également le concept de “no test case”. Elle remet en question l’approche traditionnelle consistant à créer systématiquement des cas de tests. Selon elle, il est plus important de se concentrer sur l’objectif de la fonctionnalité à tester, en fonction du contexte du projet. Cela permet de gagner en efficacité tout en garantissant une couverture adéquate des tests.

Enfin, tous les bugs ne nécessitent pas d’être logués. Natacha met l’accent sur l’importance de prendre en compte le contexte et la gravité des problèmes rencontrés. Cela évite d’encombrer inutilement le système de suivi des bogues avec des éléments mineurs.

En conclusion, la stratégie de tests est un pilier fondamental pour garantir la qualité des applications dans un environnement agile. Grâce aux connaissances et aux idées novatrices de Natacha Fourmy, un véritable arsenal est disponible pour mener à bien cette mission cruciale.

Vous pouvez explorer davantage cette approche et intégrer cette stratégie de tests de manière proactive dans vos projets agiles.

Libérez l’intelligence collective avec la facilitation graphique : Un atelier incontournable avec Benoit Hermant et Michaël Kiecken

Pendant cet atelier, une pratique captivante et efficace a été abordée : la facilitation graphique.

Il s’agissait d’un atelier animé par deux experts passionnés, Benoit Hermant et Michaël Kiecken, sur l’univers fascinant de la pensée visuelle au service de l’intelligence collective.

Qu’est-ce que la facilitation graphique ? En réalité, vous l’avez probablement déjà utilisée sans même le savoir ! La facilitation graphique est une approche qui utilise le langage visuel pour faciliter les interactions, les échanges et la prise de décisions au sein d’un groupe ou d’un collectif.

Au cours de cet atelier, Benoit et Michaël ont détaillé les différentes disciplines de la facilitation graphique, allant du sketchnoting (prise de notes visuelles) à l’utilisation de métaphores visuelles puissantes. Ainsi que les bases de la grammaire visuelle, un ensemble de règles et de techniques pour donner vie à ses idées sur le papier.

Mais ce n’est pas tout ! L’objectif principal de cet atelier est de vous encourager à pratiquer, pratiquer et pratiquer encore ! Car c’est en faisant que l’on progresse.

Cet atelier permet donc d’enrichir sa boîte à outils, renforcer ses compétences en communication visuelle et booster sa créativité et l’efficacité des interactions au sein de son équipe.

En utilisant cette approche visuelle, vous serez en mesure de :

1. Favoriser la compréhension mutuelle : Les images ont un pouvoir universel pour transcender les barrières linguistiques et culturelles, facilitant ainsi la communication entre les membres d’un groupe.

2. Stimuler la créativité : La pensée visuelle permet de visualiser des concepts abstraits et de faire émerger de nouvelles idées en encourageant le cerveau à faire des connexions inhabituelles.

3. Rendre les réunions plus engageantes : Des visuels dynamiques captivent l’attention des participants et rendent les réunions plus interactives et agréables.

4. Synthétiser l’information : Résumer des discussions complexes en quelques images clés facilite la mémorisation et permet de garder une trace visuelle des échanges.

La Keynote dont vous êtes (vraiment) le héros : Explorez les voies agiles avec Nicolas Tondeur

Dans cette keynote interactive, il fallait choisir un héros et le chemin que ce héros agile suivrait, ainsi que les expériences professionnelles qu’il vivrait. Sa destinée était entre nos mains !

L’aventure était passionnante, mais impliquait des choix difficiles. Nos décisions ont eu un impact sur le parcours de notre héros. Nous nous sommes retrouvés avec des votes égalitaires où il a fallu départager l’audience pour avancer dans l’histoire du héros.

Une multitude de possibilités était offerte, et c’est notre créativité, vision et compréhension des méthodes agiles qui guidaient notre héros dans cette quête professionnelle.

Ahaslide, l’outil interactif utilisé pour cette keynote, permet de voter en temps réel pour les décisions clés, et ainsi, influencer le déroulement de l’histoire. Nous étions plongés au cœur de l’action, et chaque moment était riche en suspens.

Ce fût une expérience mémorable et instructive ! Avec à la clé, la découverte des multiples facettes des méthodes agiles, l’exploration de nouvelles perspectives et le développement d’un esprit décisionnaire.

À la suite de la conférence, le speaker Nicolas Tondeur, a lui-même rédigé un article détaillant l’exercice, et partage une version en ligne pour le reproduire.

Et si notre communication était biaisée ? — Conférence présentée Christophe Deniaud

Différents éléments peuvent mettre à mal la communication entre deux individus. Que ce soit une modification du message initial ou du sens du message perçu par des biais.

L’être humain est un être social et communiquer est un besoin. Pour dialoguer nous utilisons alors notre cerveau. Il s’agit d’un outil généraliste très efficace, mais qui utilise la simplification pour de meilleures performances.
En France nous avons un vocabulaire culturel d’environ 30 000 mots usuels, que nous adaptons au vocabulaire de l’interlocuteur.

Le message initial passe donc par une phase de simplification interne, puis de diffusion (avec un risque de parasites), puis à nouveau de simplification dans la compréhension, avant d’être reçu.
Sachant que chaque personne a également un cadre de référence influencé par son éducation, ses croyances, ses valeurs, …

À chaque étape nous pouvons donc être impactés par des biais cognitifs, qui permettent au cerveau d’accélérer ses interprétations.
Parmi les biais les plus courants, nous retrouvons :

  • Le biais de disponibilité — qui consiste à privilégier les informations de notre mémoire plutôt que la recherche de nouvelles informations,
  • La perception sélective — qui consiste à interpréter les informations en fonction de son cadre de référence,
  • La lecture de pensée — qui consiste à interpréter ce que l’autre pense à partir d’éléments subjectifs,
  • Le biais de confirmation — qui consiste à privilégier les informations qui confortent nos idées,
  • L’illusion du savoir — qui consiste à adopter un même comportement dans deux situations qui semblent similaires sans chercher plus loin,
  • La réduction de la dissonance cognitive — qui consiste à modifier son cadre de référence pour s’aligner avec une information en contradiction avec celui-ci,
  • Le biais de la tâche aveugle — qui consiste à penser que les autres personnes sont plus sujettes au biais que nous le sommes nous-mêmes.

Bon et mauvais Scrum par Alexandre Boutin

Sur le ton de l’humour, Alexandre évoque les biais et les erreurs qui peuvent être générés lors de l’application de la méthode Scrum par les différents membres de l’équipe et lors des différents rituels.

Product Owner

Mauvaises pratiques Scrum

  • Se comporte comme un client,
  • Râle sur les retards et les bugs,
  • N’a pas le temps de venir aux rétros,
  • Gère le backlog comme des tickets.

Bonnes pratiques Scrum

  • C’est un leader,
  • Élabore et partage une vision,
  • Prend le temps de partager avec l’équipe,
  • Défend son équipe.

Scrum Master

Mauvaises pratiques Scrum

  • Se comporte comme un chef de projet,
  • Obnubilé par les stories à finir,
  • Veut augmenter la vélocité.

Bonnes pratiques Scrum

  • S’occupe des équipiers, du PO et du management,
  • Sait que Scrum est un framework,
  • Prend le temps de bien faire son travail.

Membre de l’équipe

Mauvaises pratiques Scrum

  • Sa mission est de faire son ticket,
  • Ne veut pas présenter en Review,
  • S’emmerde au Daily et à la Rétro,
  • Se contrefout du produit.

Bonnes pratiques Scrum

  • Contribue à un engagement collectif,
  • Propose son aide aux autres équipiers,
  • Connaît la valeur de ce qu’il réalise,
  • Connaît le DoD et les actions de Rétro.

Sprint Planning

Mauvaises pratiques Scrum

  • Le PO est absent,
  • Le SM donne la vélocité à tenir,
  • Chaque équipier identifie sa/ses Story,
  • Le Sprint Goal = liste des tickets.

Bonnes pratiques Scrum

  • Engagement collectif des équipiers,
  • Travail sur la conception,
  • Initialisation du tableau de l’équipe.

Daily Scrum

Mauvaises pratiques Scrum

  • Dire ce que l’on a fait la veille,
  • Ne pas se préoccuper de ce que font les autres,
  • Vive les Daily à distance pour faire autre chose.

Bonnes pratiques Scrum

  • Inspecter le sprint vis-à-vis de l’engagement,
  • S’engager collectivement sur ce qui sera terminé aujourd’hui,
  • Synchroniser le travail à plusieurs sur une même Story,
  • Savoir qui devra aider qui.

Sprint Review

Mauvaises pratiques Scrum

  • Absence des utilisateurs,
  • Démo au PO,
  • Pilotée par le SM,
  • Story par Story ; AC par AC.

Bonnes pratiques Scrum

  • Mise en perspective de l’incrément du Sprint dans la vision produit,
  • Démo orientée usage,
  • Feedbacks recherchés et appréciés.

Rétro

Mauvaises pratiques Scrum

  • Ne pas évaluer les actions précédentes,
  • Faire des vœux pieux ou des actions non engageantes,
  • Considérer le SM seul responsable des actions.

Bonnes pratiques Scrum

  • Technique de cohésion d’équipe,
  • Prendre le temps de l’analyse et identifier le bénéfice attendu,
  • Obtenir un engagement.

Product Backlog

Mauvaises pratiques Scrum

  • Contient toutes les fonctionnalités,
  • Plusieurs versions distinctes Fonctions/Bug/Tech,
  • Exclusivement utilisé par le PO.

Bonnes pratiques Scrum

  • Évolue en permanence sur base des feedbacks,
  • Contient un buffer pour ce qui n’est pas encore connu,
  • Devient obsolète à la fin du projet.

Incrément/DoD

Mauvaises pratiques Scrum

  • Écrit une fois au début,
  • Personne ne sait ce qu’il y a dedans,
  • Est appliqué s’il y a le temps,
  • S’arrête à l’étape “Validation PO”.

Bonnes pratiques Scrum

  • Évolue et est explicite pour toute l’équipe,
  • Est proposé par l’équipe (PO, SM, équipiers),
  • Plus proche possible du client.

Concernant la vélocité, il faut noter :

  • Qu’elle ne fait pas partir du cadre Scrum,
  • Qu’elle permet de mesure la vitesse et non la productivité,
  • Que les points ne sont pas équivalents à des jours,
  • Et que les estimations restent relatives.

Leia vs Galadriel : Explorer votre leader interne — Atelier animé par Antonio Cobo

Cet exercice collectif permet de découvrir les éléments qui constituent des leaders.

Découper en plusieurs équipes de 3 à 4 personnes, il s’agit de :

1 — Citer 6 personnages représentant des leaders réels ou fictifs, puis définir les caractéristiques qui font d’eux des leaders,

2 — Anonymiser les noms des leaders cités,

3 — Faire tourner les équipes,

4 — Chacun donne son avis sur les différents attributs de leaders définis par l’autre équipe,

5 — Un travail de distinction est mené entre les attributs qui correspondent plus au PO ou au PM.

6 — Révélation des personnages.

Travail équipe 2

Décider qui décide quoi et comment — Atelier de Julie Demanze

Cet atelier était basé sur la mise en place du jeu Décision Poker.

C’est un exercice qui permet de :

  • Gagner du temps,
  • Favoriser un meilleur engagement,
  • Clarifier les rôles et les responsabilités.

Dans ce cadre, les participants reçoivent un jeton de poker pour le Comment et un jeton pour le Qui.

On pose ensuite la question à laquelle on souhaite répondre, par exemple : Comment choisir où aura lieu la soirée de Noël ?

Chacun réfléchit au qui et comment, puis pose ses jetons sur la décision qu’il valide. S’il y a accord sur la décision, le jeu se termine. Sinon il y a discussion autour des choix, puis plusieurs tours peuvent s’enchaîner jusqu’à trouver un accord.

Pour le COMMENT, les propositions peuvent être :
1 — Par décision unilatérale. C’est rapide, avec des responsabilités claires. Mais la décision peut être non acceptée ou peu appropriée.

2 — Par sollicitation d’avis experts. Ce qui permet une responsabilité claire et une décision éclairée.

3 — Par vote. Il s’agit d’un système simple et rapide où chacun s’exprime. Mais l’avis des ‘perdants’ n’est pas pris en compte.

4 — Par pondération, pour permettre une expression plus fine.

5 — Par jugement majoritaire après évaluation de chaque proposition. Il y a ainsi une évaluation qualitative avec une solution qui satisfait le plus grand nombre. Bien que le vote puisse être plus complexe à organiser.

6 — Par décision par consentement. C’est-à-dire une coconstruction de la décision acceptée par tout le monde. Cela permet une forte adhésion, la levée des objections. Mais demande également du temps et de la maturité et peut engendrer une baisse d’exigence.

7 — Par décision par concordance avec appropriation et adhésion totale à la décision. C’est toutefois long et pas toujours applicable.

Pour le QUI, les propositions peuvent être :

  • Par un groupe selon ses fonctions/ rôles (leaders, experts, …),
  • Par la direction,
  • Par un individu ou un collectif.

Et si on arrêtait de produire du software inutile — Keynote de David Laizé

Le but de la keynote est de rappeler qu’il faut bien choisir ce que l’on produit.

En sachant que la moitié des fonctionnalités du backlog ne sera certainement jamais utilisée (source https://www.svpg.com/product-fail/).
Aujourd’hui on est dans une tendance de deliveries factory, alors que la vélocité n’est ni un objectif, ni un KPI. Il faut davantage réfléchir à ce que nous allons produire, avant de produire vite.

Pour remédier à cela, quelques conseils ont été abordés :

1 — Utilisez davantage de persona (représentation des rôles utilisateur), car créer de l’impact, c’est améliorer l’expérience d’un utilisateur.

2 — Si vos US sont des spécifications, il y a un raté dans sa transformation agile.

3 — Mesurez ! Que ce soit avant de réaliser et après avoir livré.

4 — Construisez une équipe proche des utilisateurs avec des approches TDD, DDD, BDD, ou PDD (Pragmatic Driven Design).

5 — Pratiquez la suppression comme un sport de haut niveau !

Il faut concevoir des produits et fonctionnalités : réalisables, utilisables, viables et à valeur ajoutée. Si ce n’est pas le cas, alors ce ne doit pas être fait.

Source : Marty Cagan

Le Digital Lab Kiabi : Moins de framework, plus de #Heart of Agile (et de résultats) — Conférence de Julien Roynette et Romain Poiré

Cette conférence est un REX d’une équipe de développeurs chez Kiabi qui a pour but de tester des concepts et des idées le plus rapidement possible. Cette équipe a réalisé plus de 50 projets en 5 ans.

Leur credo est de ne pas avoir de jugement sur les idées. Une idée mérite d’être testée sur le terrain, avec le principe du “fail fast” pour des tests en cycle court.
Leur recette ? Globalement, être simple et pragmatique et remettre le développement au centre.
En détail :

  • Les développeurs au centre.
    Le porteur d’idée vient avec ces besoins/problèmes et il est mis au contact direct des développeurs qui porteront la/les solutions. Les développeurs doivent être polyvalents afin de casser les silos entre les activités.
  • Les échanges en direct sont privilégiés,
  • Les besoins émergents s’appuient sur des retours terrain,
  • La pratique agile est adaptée à l’équipe (pas de framework). Pas de PO, pas de Scrum Master, pas d’estimation, pas de KPI, pas d’itération (sprint).
  • Le management est au service de l’équipe (Servant Leader),
  • La mise en place du cercle vertueux de confiance afin de responsabiliser l’équipe de développement en lui donnant aussi le droit à l’erreur.

Les difficultés qui ont été rencontrées ou qui s’annoncent sont :

  • L’augmentation de la taille de l’équipe,
  • L’obtention de l’approbation du reste de l’organisation,
  • Le travail sur des projets d’autres équipes,
  • La transition du Lab vers une méthode agile plus classique,
  • Le passage à l’échelle.

Néanmoins forts de leurs expériences, ils partagent ses conseils pour une mise en place dans une autre entreprise :

  • Privilégier la page blanche et repartir de rien,
  • S’appuyer sur 2 à 3 développeurs polyvalents,
  • Se concentrer sur un nouveau/ service produit,
  • Se baser sur des porteurs d’idées ouverts aux tests et disponibles,
  • Bénéficier d’un climat de confiance insufflé par le management,
  • Laisser le droit à l’erreur à l’équipe.

Revenir à l’essentiel de nos pratiques agiles — Keynote d’Alexandre Boutin

Cette keynote démontre que l’agilité est devenue un sujet complexe.

By Christopher Webb

Il est donc important de revenir sur les bases de l’agilité et son utilité.

Le cœur de l’agilité est l’empirisme : c’est-à-dire “Faire”.
Pour cela, il faut aussi accepter l’incertitude, donc parfois commencer sans tout savoir et lâcher prise.
Pour piloter cette incertitude, il est nécessaire de s’appuyer sur des boucles de feedbacks, comme le besoin métier, l’avis des utilisateurs, … Puis prioriser. Faire des choix c’est garantir à quelque chose d’exister, mais aussi accepter que d’autres options ne soient pas retenues.
Dans l’organisation il est nécessaire de faire équipe, donc de connaître la répartition des responsabilités et réaliser ensemble, grâce au management visuel, à des échanges réguliers, …
“Être une équipe est un fait, faire équipe est un art”.
Il est aussi important que le projet est un sens, donc une vraie utilité avec une valeur ajoutée motrice avec laquelle l’équipe est alignée.
Pour cela, il faut définir une vision avec un but à moyen/ long terme.
Et l’agilité c’est aussi rechercher régulièrement et collectivement l’amélioration et la performance à travers la solidarité, l’entraide et la confiance.

En conclusion, peu importent les nombreuses déclinaisons de pratiques agiles, l’essentiel est de s’assurer que ces conditions de base soient présentes.

Nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.

Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, YouTube, Twitch et Instagram.

Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.

--

--

CBTW
L’Actualité Tech — Blog CBTW

Nos experts partagent leur vision et leur veille en développement web et mobile, data et analytics, sécurité, cloud, hyperautomation et digital workplace.