Retour d’expérience équipe Player à France Télévisions : “Passer de faire de l’Agile à être Agile”
Présenté à Agile en Seine 2017 !
Présenté à Agile en Seine 2017 !
This article is also available in English.
C’est avec plaisir qu’avec Richard nous avons présenté un sujet à Agile en Seine.
Agile en Seine
Organisée par l’association French Kanban User Group, Agile en Seine se veut une conférence multi-pratiques, ouverte …www.agileenseine.com
De quoi parlait notre session ?
Revivez avec nous la grande aventure Agile de l’équipe Player à France Télévisions ! Au début de notre histoire, on pourrait la qualifier d’équipe comme les autres, qui tente de faire de l’Agile. Au fil des chapitres, les changements vont s’opérer pour bel et bien devenir et être Agile !
Il y a quoi dans cet article ?
Forcément, je vais vous vendre cette session comme un truc à ne pas rater et vous serez obligé de regarder la vidéo 😋
Justement vous trouverez des liens vers la vidéo et les slides — que bien sûr vous vous empresserez de regarder si ce n’est pas déjà fait !
Enfin, vous trouverez une transcription des nombreux outils et conseils clé-en-main que nous avons introduit dans notre session. Vous pourrez ainsi les retrouver et les ré-utiliser plus facilement. En bonus, j’indiquerai d’autres articles en lien direct et qui vous permettront de creuser le sujet.
Vous avez raté l’évènement ? Est-ce que c’est grave ?
Plutôt que de vous expliquer comment elle était trop bien cette session, voici quelques feedbacks que vous avons eu :
Vous voulez voir la session en entier ? Voici les ressources
Vidéos
Notre intervention a été fimée et est disponible publiquement sur InfoQ :
Player @France Télévisions : passer de faire de l’Agile à être Agile
Revivez avec nous la grande aventure Agile de l’équipe Player à France Télévisions ! Au début de notre histoire, on…www.infoq.com
Nous avons également été rapidement interviewés à chaud après notre session. La vidéo est disponible sur YouTube :
Pour la petite histoire, Richard et moi-même se sommes également prêtés au jeu du teaser vidéo en amont de la session. Pas mal pour des amateurs !
Support de présentation (les slides)
Les slides de la session sont disponibles sur SlideShare et sur Google Slides:
Agile en Seine
JP + Richard : bonjour ! Talk Format 50 minutes, Q/R incluses Jean-Pierre Lambert @jpierrelambert https://medium.com…docs.google.com
Les conseils et outils clés-en-main présentés durant cette session
Cette section n’est pas un substitut à la session elle-même. L’idée est plutôt de compléter le contenu de la session.
En tant que telle, vous trouverez un récapitulatif de tous les conseils et outils que nous avons introduit durant la session, accompagnés de quelques commentaires ainsi que de liens pour continuer de creuser le sujet.
Veuillez noter que l’ordre présenté ici n’est pas directement lié à l’ordre dans le support de présentation.
La vision produit est essentielle
Pas de vision produit implique que vous devez faire tout ce qu’on vous demande, sans distinction. La vision produit étant justement ce qui permet de savoir dire ‘non’.
Sans vision produit vous créez une usine à gaz, à toujours ajouter de nouvelles fonctionnalités au prix d’une dette technique grandissante.
Vous finissez noyé sous la dette technique. Un des symptômes est une difficulté à mettre en production, et le rythme de release est lent.
D’un autre côté, avoir une direction claire fera une grande différence.
Cela peut venir de la part du Product Owner ou, mieux encore, de l’organisation qui donne une grande vision, bien claire.
Mieux vaut une mauvaise vision que pas de vision du tout — il faut bien commencer quelque part !
Aussi essentielle que soit la vision produit, ce n’est pas un exercice simple pour autant.
Il est donc normal de tâtonner au début. Les itérations suivantes seront meilleures.
Un Product OWNER doit être libre de pouvoir dire “NON”
Plus facile à dire qu’à faire, c’est un élément fondamental du rôle de Product Owner : être libre de prendre des décisions sur le produit qu’il gère.
Le Scrum Guide est par ailleurs clair sur le sujet.
Dire “NON” est un des éléments qui définissent le mieux un PO réellement dans le rôle du PO.
Définir une vision (et l’afficher en gros) a plus d’impact qui préparer les N prochaines itérations
L’équipe savait qu’elle manquait de vision et que c’était à la racine de pas mal de problèmes. Ce n’était pas nouveau.
Le “correctif” semblait évident : demander au Product Owner de préparer plus d’itérations à l’avance, pour que l’équipe soit au courant des prochaines choses à venir. Ce fut un échec cuisant. Malgré l’effort énorme que cela demandait au PO, les choses ne s’amélioraient pas vraiment côté vision.
À l’inverse, tous ces problèmes ont disparu le jour où le Product Owner a réellement fourni une vision à l’équipe. Encore mieux, le PO a pris l’initiative d’afficher la vision sur toute la largeur de l’open-space, de sorte que personne ne puisse l’ignorer.
Cet article donne plus de détail sur cette histoire et essaie de tirer quelques conclusions :
L’importance d’une vision pour l’équipe Scrum
Le fondement de la cross-functional teammedium.com
Utilisez des outils comme le Squad Health Check pour suivre la santé de l’équipe
Des outils comme le Squad Health Check de Spotify vous donneront des éléments intéressants sur l’équipe, à plusieurs niveaux :
Fait régulièrement, vous pourrez voir les tendances et mesurer l’impact des changements
Fait par plusieurs équipes, vous pourrez mettre côte-à-côte les résultats des différentes équipes et obtenir une vue intéressante du système global, comment les contextes de chaque équipe sont différents mais aussi quels problèmes partagent-ils en commun
Je décris dans cet article notre utilisation du Squad Health Check dans le cadre de nos Rétrospectives :
Rétro : Squad Health Check
Construire la Rétrospective autour d’un modèle de maturitémedium.com
Le but de la Rétrospective est d’améliorer en profondeur les process, pas de simplement corriger des problèmes
Ne vous arrêtez pas au premier pourquoi et continuez de creuser jusqu’à atteindre la véritable cause du problème, d’un point de vue systémique.
Et seulement alors, corrigez cette cause et améliorez le process — faites en sorte que le problème ne se produira plus.
C’était quoi cet atelier ? Cocktail Factory
J’ai écrit un article à propos de ce jeu d’eau sérieux :
Cocktail Factory : équilibrer spécialistes et généralistes dans une équipe
Un jeu d’eau sur l’organisation des équipes pluridisciplinairesmedium.com
JIRA n’est pas une recette miracle
Utiliser JIRA ne vous rend pas automatiquement Agile… Qui plus est, vous devez même prendre garde à comment vous utilisez JIRA.
JIRA peut être un outil d’une grande aide, mais attention au syndrome “il n’y a qu’une personne à la fois au clavier” qui mène à une réunion remplie de participants passifs.
Sans Scrum Master, difficile de se forcer à expérimenter avec son workflow JIRA
L’équipe se doit d’expérimenter avec les différents workflows de ses tâches techniques, User Stories, Epics, bugs et releases. L’utilisation de JIRA rend ces expérimentations plus complexes que nécessaire.
L’équipe finira probablement en utilisant le workflow par défaut plutôt qu’en challengeant leur manière de travailler.
Un rôle possible du Scrum Master est de faciliter ces expérimentations avec le workflow.
La présence d’un Scrum Master dédié et expérimenté est réellement utile
Un Scrum Master à temps plein dans l’équipe sera très utile car il pourra donner des conseils pertinents à l’équipe.
Il aura également a rôle clé dans la mise en place du management visuel and que pour aider l’équipe à respecter les règles qu’elle se fixe elle-même.
Voici un précédent article que j’ai écrit qui explique pourquoi les équipes ont besoin d’un Scrum Master :
Est-ce que j’ai besoin d’un Scrum Master ?
Probablement ! Voici les critères pour décider.medium.com
Cet autre article passe en revue le génialissime livre de Jimmy Janlén à propos du management visuel :
Lecture : “96 Visualization Examples” par Jimmy Janlén
Un petit livret plein de fantastiques conseils sur le management visuel d’une équipe Scrum ou Kanban !medium.com
Un traumatisme peut être salvateur
Un gros traumatisme (long de plusieurs mois dans notre cas), avec la bonne introspection, peut être la graine qui mènera à la construction de fondations en béton armé.
Plus tard dans ce projet, nous avons senti que nous allions rencontrer une situation similaire sur un autre de nos produits. Cette fois, nous avons faire en sorte d’éviter le tunnel.
La leçon pourrait être : comment créer un sentiment d’urgence plutôt que d’attendre qu’un tel traumatisme se produise ? L’article suivant élabore la question :
Cette satanée zone de gris…
Nommer ce qui ne va pas dans nos organisations et équipesmedium.com
Faites des analyses de risque et évitez à tout prix des non-régressions complètes
Dans l’article suivant je détaille toutes les sections de ce rapport de gestion de risque, et j’explique comment nous l’utilisons :
Gestion de risque : formalisation et communication
Quand l’information se perd, c’est tout le process qui menace de s’enrayermedium.com
Écrivez vos process, et assurez-vous qu’ils prennent en compte les réalités du terrain
Poser clairement le process de mise en production a été une étape importante pour l’équipe.
Nous nous sommes assurés que ce process tenait compte de tous les problèmes bien connus qui sont régulièrement rencontrés.
Tout cela est expliqué en détail dans l’article suivant :
Détail de notre process de mise en production
Conçu pour compenser les difficultés connuesmedium.com
Faites en sorte que les process aident l’équipe plutôt que de la contraindre ; le management visuel est votre meilleur ami
Votre Graal n’est évidemment pas de fliquer l’équipe pour s’assurer qu’ils respectent les process. Vous préfèreriez que l’équipe respecte spontanément les process, d’elle-même.
C’est ce qui arrive lorsque l’équipe trouve les process utiles. J’explique toute cette philosophie dans l’article suivant :
Un process est un outil, pas une contrainte
Comment faire pour que vos process soient plus qu’une doc !medium.com
Dans cet autre article, j’explique comment nous avons mis en place ce process des mises en production via le management visuel :
De 1 release par trimestre à plus de 2 par semaine
Management visuel et gamification pour le process de mise en productionmedium.com
Les boards physiques c’est génial !
On peut stocker tellement d’information sur un board physique… C’est difficile de retourner à un board électronique une fois qu’on a goûté à un vrai board physique.
Ce board montre plusieurs éléments que j’ai détaillé dans d’autres articles :
Le stand-up : point de synchro release
Le moment où prend vie le management visuelmedium.com
S’assurer que la Definition of Done est bien respectée
Utilisation de fiches pense-bêtemedium.com
Le Definition of Done est un indicateur intéressant de maturité de l’équipe
À quoi ressemble le Definition of Done de l’équipe ? Plutôt à une liste exhaustive d’éléments à faire, ou bien plutôt à un ensemble de critères holistiques qui doivent être satisfaits ?
La maturité de l’équipe peut être évaluée à partir de cette simple observation. Une équipe mature se préoccupera plus de s’assurer que le problème est corrigé plutôt que de cocher toutes les cases de la solution. Cibler ses efforts non pas sur le respect d’un framework mais bien sur ce qui compte vraiment.
J’ai développé cette réflexion dans l’article suivant :
Être Agile : avoir un DoD qui se focalise sur les problèmes à résoudre
Plutôt que Faire de l’Agile et respecter une checklist décrivant la solution !medium.com
Le management visuel permet la synchronisation de plusieurs équipes
Le management visuel est également un fantastique outil pour synchroniser plusieurs équipes. Dans notre cas, nous l’avons utilisé avec succès pour organiser les mises en production de trois équipes qui travaillent simultanément sur le même produit et la même base de code — jusqu’à faire du continuous release.
L’article suivant explique comment nous l’avons mis en pratique :
Cadencer les mises en production et en démultiplier le rythme
Avec toujours plus de management visuel, bien entendu !medium.com
Scrum c’est sympa, mais Kanban c’est génial (si votre orga est compatible)
J’adore Scrum mais passer à Kanban est un choix que nous ne regrettons absolument pas. Il est avant tout question d’état d’esprit, de mindset, de passer du push (pousser du travail par l’entrée) au pull (tirer le travail par la sortie). J’aurais tendance à dire que le niveau supérieur de l’Agilité pourrait bien être de réussir à faire travailler l’organisation avec cet état d’esprit pull.
Si le sujet vous intéresse, je vous invite à lire cet article :
Pour le meilleur et pour le pire : Scrum et la planification
À la fois la plus grande force et la plus grande faiblesse de Scrummedium.com
L’excellence ingénierique est à portée de main
Mais le Continuous Delivery c’est difficile !
Je ne vais pas dire que c’est facile, mais si notre équipe a réussi à le faire en moins d’un an et avec une couverture de code par les tests automatiques toujours trop faible, alors pourquoi est-ce que votre équipe en serait incapable ?
Ce monde est à portée de main, vous pouvez vous en saisir si vous en avez la volonté.
Si vous voulez creuser la question plus en profondeur, voici mon article qui résume comment nous nous y sommes pris :
Notre recette pour des mises en prod’ quotidiennes
Il était une fois une équipe qui galérait à mettre en prod’…medium.com
Vous savez que c’est rentré dans la culture de l’équipe quand ils blaguent dessus, que ça les fait rire, et qu’ils affichent fièrement la blague
Sur l’affiche ci-contre, on parle d’un sujet très important : la couverture de code par les tests automatiques.
Et on en blague.
Et on en rigole.
Et on n’a pas honte de l’afficher.
Parce que sur le fond, il y a un vrai message. Oui, on doit améliorer la couverture de code par les tests automatique.
Dans cette équipe, améliorer la couverture de code par les tests automatiques fait partie de sa culture.
Assurez-vous d’être en capacité de livrer la fonctionnalité au client avant d’écrire le code
Il est essentiel de fluidifier votre process de livraison. Être en capacité de livrer souvent et rapidement ouvre tout un monde de possibilités.
Passez moins de temps à vous assurer que rien n’est cassé et saisissez-vous à la place d’opportunités supplémentaires.
Qu’arrive-t-il si vous vous êtes trompés et que vous cassez quelque chose quand même ? Et bien vous allez le réparer si rapidement que les clients le remarqueront à peine.
Nous n’avons jamais utilisé le mot dans notre équipe mais quand on y réfléchit, toute cette philosophie “assurez-vous d’être en capacité de livrer la fonctionnalité au client avant d’écrire le code” est en fait l’état d’esprit DevOps.
Une équipe ne doit avoir qu’une seule mission
Focus est une des valeurs de Scrum et elle est essentielle à la réussite de n’importe quelle équipe.
Selon notre expérience, s’il n’est pas possible de n’avoir qu’une et une seule mission pour l’équipe, alors il peut être plus pertinent de couper l’équipe pour faire en sorte que chaque équipe n’ait qu’une et une seule mission.
Et tant pis si vos équipes deviennent ridiculement petites — le focus sera un plus grand atout.
Sur un sujet similaire, cet article parle d’objectifs d’itération et quotidiens, et comment ne pas fixer deux buts en un — la même idée que celle de n’avoir qu’une seule mission pour l’équipe :
Du bon usage des objectifs
Notamment en Scrummedium.com
Ne faites pas en commun les rituels Scrum de plusieurs équipes
Comment organiser une grosse équipe qu’on a découpé en plusieurs équipes plus petites ?
Arrêtez de faire vos réunions en commun !
Faites en sorte que tous les artefacts et réunions d’équipes soient bien séparés, et aidez chaque équipe à définir leur propre identité et leurs propres process.
Cela ne s’est pas fait en claquant des doigts. Je raconte cette petite aventure dans cet article :
L’équipe s’agrandit : comment s’organiser ?
Comment mettre en place des feature teams quand le projet gagne en ampleur et nécessite plus de collaborateursmedium.com
Plusieurs équipes ? Vous avez besoin d’une solution organisationnelle pour garder l’alignement technique entre les équipes
Les équipes n’aiment pas qu’on les sépare. Et pas uniquement parce que ses membres adorent être ensemble ; mais aussi parce qu’en étant ensemble il leur est facile d’être alignés techniquement sur tout ce qui touche aux process, bonnes pratiques, bases de code partagées…
Une fois composé de plusieurs équipes, vous aurez en effet besoin d’une solution au niveau organisationnel pour encourager et conserver cet alignement technique.
Ce article creuse le sujet et raconte ce que nous avons essayé pour apporter des éléments de réponse :
Distribuer le rôle d’architecte au sein des Feature Teams
Notre expérience similaire aux Chapters de Spotifymedium.com
Le Forum Hors du Guidon : garder les équipes alignées et réduire le temps perdu à cause des réunions
Le “Forum Hors du Guidon” est un évènement partagé entre toutes les équipes, qui dure une journée entière et qui a lieu une fois par itération. Les équipes utilisent cette journée pour préparer ensemble les itérations à venir.
Regrouper ainsi toutes les équipes permet de les garder alignées et de s’assurer que les besoins partagés entre les équipes sont bien gérés avec toutes les personnes concernées.
Qui plus est, cette pratique élimine quasiment complètement la nécessité d’avoir d’autres réunions pendant le reste de l’itération (excepté bien entendu les rituels Scrum : stand-up quotidien, Revue, Rétro, Planification). C’est une très bonne chose car les réunions interrompent l’équipe, ce qui réduit la productivité, fait partir ces réunions sur de mauvaises bases, et génère de la frustration.
Cet article décrit plus en détail cette pratique :
L’équipe ne trouve pas le temps de préparer les sujets à venir
Test avec un forum d’une journée dédiéemedium.com
Encourager l’auto-organisation des équipes en disant clairement que c’est ce qui est attendu
Les équipes auto-organisées.
C’est un pré-requis fondamental de Scrum.
Et pourtant c’est tellement difficile à mettre en pratique par les équipes.
Et si la première étape serait de dire clairement aux équipes que c’est ce qu’on attend d’eux ?
C’est là le principe même de cette “Déclaration d’Autonomie” :
Comment l’équipe devrait travailler — on vous a donné de la liberté, faites-en bon usage
Qu’est-ce que nous attendons des membres d’équipes — c’est grâce à vous si ça va fonctionner
Vous trouverez le contenu complet de la Délaration d’Autonomie ainsi que l’histoire qui est derrière dans l’article suivant :
Déclaration d’Autonomie : expliciter la vision des équipes auto-organisées
Poser le contrat de fonctionnement de l’équipemedium.com
Plus souvent qu’on ne le pense, les limites de l’équipe sont celles qu’elle s’impose
On a arrêté JIRA.
On s’est organisé.
On nous a laissé gérer.
Personne ne nous en a empêché !
Être Agile = Excellence Technique + Véritable Vision Produit + Organisation Efficace
Cette définition de l’Agilité n’engage que nous.
Excellence technique : sans quoi toute mise en place de l’Agilité est compliquée.
Véritable vision produit : il faut prendre des décisions difficiles, ce qui n’est pas possible à moins d’avoir une vision claire pour le produit
Organisation efficace : qu’il s’agisse de Scrum, Kanban ou autre, peu importe… Faites ce qui est pertinent dans votre contexte — et surtout, ne faites pas ce qui n’apporte aucune valeur ! Favorisez autant que possible les processus légers.
Encore merci à tous ceux qui ont voté pour notre session, qui y ont assisté, ou qui nous ont donné du feedback ! 😘
Dernier bonus, le résumé de la session en facilitation graphique par Julien Carreaud :
Cet article vous a plu ?
Abonnez-vous à mon profil via le bouton Follow pour être notifié de mes nouveaux articles !
Et n’oubliez pas de m’applaudir 👏 et de partager l’article ! N’oubliez pas que c’est votre amour 💗 qui me fait mettre autant de cœur à l’ouvrage.
Merci 😄