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 bien devenir et être Agile !
Vidéo disponible sur InfoQ : https://www.infoq.com/fr/presentations/player-france-televisions-passer-de-faire-de-l-agile-a-etre-agile
Agile En Seine 2017 - Retour d'expérience France Télévisions - Passer de faire de l'Agile à être Agile
1. REX Player Agile en Seine
Jean-Pierre Lambert
@jpierrelambert
https://medium.com/@jplambert
Richard Sourianarayanane
@Witchatt
https://twitter.com/witchatt
Nos partenaires :
REX Player à France Télévisions :
passer de faire de l'Agile à être Agile
20/09/2017
22. REX Player Agile en Seine
Lenteur
Développements
Tests de
non-reg
à la main
Régressions en
preprod
Elargissement
du scope de
release
RELEASE
TOUS LES
2- 3 MOIS
Vieilles
technos,
Architecture à
reprendre
Aucun test
Produit
fourre-tout
Dépendances
externes
23. REX Player Agile en Seine
Chapitre 2 :
Entrée du Scrum Master
Scrum is in da place
2018201720162015
+1
24. REX Player Agile en Seine
Enfin de l’aide !
Coucou !
Test Facilitator
25. REX Player Agile en Seine
Bonnes pratiques techniques
Plan de test
en amont
Boy-scout Rule
Tests
d’acceptation
automatiques
Pair-programming
Code review
Test First
GitFlow
Intégration
Continue
Build > Dev
26. REX Player Agile en Seine
Chapitre 3 :
Arrivée d’un nouveau sponsor
Tin tin tin !
(bruitage de rebondissement)
2018201720162015
+1 +1
29. REX Player Agile en Seine
Chapitre 4 :
Traumatisme → Electro-choc !
Aïe, ça fait mal !
2018201720162015
30. REX Player Agile en Seine
Tout est parti d’un besoin simple...
“Ne pas pouvoir passer la pub sur le player web”
“Y compris sur iPhonequi
utilise le lecteur natif”
“Empêcher l’utilisateur d’avancer
dans la barre de seek”
35. REX Player Agile en Seine
Management visuel plus puissant que JIRA ?
36. REX Player Agile en Seine
Chapitre 5 :
En cure de désintox
Plus jamais ça, jamais !
“Un élément fondateur de la culture ingénierique de l’équipe”
2018201720162015
41. REX Player Agile en Seine
Fin de JIRA
Avatars :
bonhommes
aimantés
Critères
d’acceptation
Statut, en attente
d’une entité externe
Definition
of Done
Objectifs de sprint
et quotidiens
Mises en
production
42. REX Player Agile en Seine
En fait, on est libre
On a arrêté JIRA
On s’est organisé
On nous a laissé gérer
43. REX Player Agile en Seine
Chapitre 6 :
Passage à l’échelle à 15
On manque de place dans l’open space !
2018201720162015
44. REX Player Agile en Seine
Toujours plus nombreux !
Equipe grossit, petit à petit, pour atteindre :
● 8 dev JS (+2)
● 2 dev Android (+1)
● 2 dev iOS (+1)
● 1 test lead (+1)
● 1 PO
● 1 SM
+1
+1
+1
+1
+1
45. REX Player Agile en Seine
Agilité à l’échelle (petite échelle)
1 mission = 1 équipe
Séparation : backlogs, stands-up, reviews et rétros !
46. REX Player Agile en Seine
Réticence de l’équipe de se séparer
Non mais pour
quoi faire, ça
va créer des
problèmes !
54. REX Player Agile en Seine
Déclaration d’autonomie Player
Ne pas être un simple exécutant
Personne ne sait mieux que mon
équipe quel est le meilleur choix et
quelle décision prendre
63. REX Player Agile en Seine
Une mission plus claire que jamais
Web : fin de Flash qui devient urgent
(Chrome, Embed Twitter…)
Mobile : ré-architecture nécessaire
pour gérer le payant (DRM)
64. REX Player Agile en Seine
Chapitre 9 :
Toujours plus de maturité
“Toujours plus loin, toujours plus haut, toujours plus fort”
2018201720162015
71. REX Player Agile en Seine
“Être Agile” ???
Mindset ! Et Sinon… ?
Manifeste Agile
Suivre les règles ✓
Comprendre la raison d’être des règles ✓
Définir nos propres règles ✓
✓
✓
✓
73. REX Player Agile en Seine
Les leçons à retirer — Produit
AVOIR UNE DIRECTION CLAIRE
74. REX Player Agile en Seine
Les leçons à retirer — Orga
Management
Visuel
Accompagnement
75. REX Player Agile en Seine
Les leçons à retirer — Tech
Excellence
ingénierique
Build > Dev
76. REX Player Agile en Seine
Merci !
Jean-Pierre Lambert
@jpierrelambert
https://medium.com/@jplambert
Richard Sourianarayanane
@Witchatt
https://twitter.com/witchatt
? !
Notas del editor
JP + Richard : bonjour !
Talk Format
50 minutes, Q/R incluses
Remerciements sponsors
Richard
Richard
Richard
Richard
Richard
Comme on peut le voir on est au service de tout le monde = on a les problématiques des centres de support
On n’est aucun produit mais les produits ne sont rien sans nous
Richard
Richard
Richard
Au service de nos différents clients internes
Pas ou peu de voie directrice, drivé par les deadlines essentiellement
Bordel niveau backlog, mais dans JIRA
3 backlogs :
web
natif iOS
natif Android
Richard
Au service de nos différents clients internes
Pas ou peu de voie directrice, drivé par les deadlines essentiellement
Bordel niveau backlog, mais dans JIRA
3 backlogs :
web
natif iOS
natif Android
Richard
Au service de nos différents clients internes
Pas ou peu de voie directrice, drivé par les deadlines essentiellement
Bordel niveau backlog, mais dans JIRA
3 backlogs :
web
natif iOS
natif Android
Richard
Au service de nos différents clients internes
Pas ou peu de voie directrice, drivé par les deadlines essentiellement
Bordel niveau backlog, mais dans JIRA
3 backlogs :
web
natif iOS
natif Android
Richard
Au service de nos différents clients internes
Pas ou peu de voie directrice, drivé par les deadlines essentiellement
Bordel niveau backlog, mais dans JIRA
3 backlogs :
web
natif iOS
natif Android
JP
JIRA + “rituels Scrum” = Agile
JP
PO et dev qui se disputent → les plannings
Réunion = 1 personne qui tape sur 1 PC dans JIRA, tout le monde regarde (et s’ennuie)
On note tout dans JIRA -- alors qu’on est colocalisé
Stand-up = autour d’une TV (pas de board physique) + digressions techniques + échanges sur les vrais sujets en post-stand-up
JP
PO et dev qui se disputent → les plannings
Réunion = 1 personne qui tape sur 1 PC dans JIRA, tout le monde regarde (et s’ennuie)
On note tout dans JIRA -- alors qu’on est colocalisé
Stand-up = autour d’une TV (pas de board physique) + digressions techniques + échanges sur les vrais sujets en post-stand-up
JP
Pas de review, seulement une démo, justement avec “effet démo” récurrent
Parties prenantes pas toujours là aux démos
Pas de DoD
Rétro toujours au même format :
expédiée en 1h
plein de digressions techniques
peu d’actions (réussies) sur le process et peu d’expérimentation
surtout des tâches concrètes corrigeant directement les problèmes concrets
Rituels en commun (stand-up, démo, rétro…) : web + iOS + Android (alors que produits, code et backlogs distincts)
JP
Pas de review, seulement une démo, justement avec “effet démo” récurrent
Parties prenantes pas toujours là aux démos
Pas de DoD
Rétro toujours au même format :
expédiée en 1h
plein de digressions techniques
peu d’actions (réussies) sur le process et peu d’expérimentation
surtout des tâches concrètes corrigeant directement les problèmes concrets
Rituels en commun (stand-up, démo, rétro…) : web + iOS + Android (alors que produits, code et backlogs distincts)
JP
Pas de review, seulement une démo, justement avec “effet démo” récurrent
Parties prenantes pas toujours là aux démos
Pas de DoD
Rétro toujours au même format :
expédiée en 1h
plein de digressions techniques
peu d’actions (réussies) sur le process et peu d’expérimentation
surtout des tâches concrètes corrigeant directement les problèmes concrets
Rituels en commun (stand-up, démo, rétro…) : web + iOS + Android (alors que produits, code et backlogs distincts)
JP
Pas de review, seulement une démo, justement avec “effet démo” récurrent
Parties prenantes pas toujours là aux démos
Pas de DoD
Rétro toujours au même format :
expédiée en 1h
plein de digressions techniques
peu d’actions (réussies) sur le process et peu d’expérimentation
surtout des tâches concrètes corrigeant directement les problèmes concrets
Rituels en commun (stand-up, démo, rétro…) : web + iOS + Android (alors que produits, code et backlogs distincts)
JP
on ne peut pas se permettre de faire des régressions en prod
tests de non-reg à la main
cahier de test de non-reg pas formalisé + - régressions trouvées en preprod
release retardée
élargissement du scope de release
rebelotte…
JP
JP
Je rejoint l’équipe en tant que Test Facilitator puis Scrum Master
MàJ/expérimentation process JIRA 2 fois par semaine (j’exagère à peine) → sans parler des cas où j’ai pas créé de ticket !
Notamment sur les tickets terminés, parfois en prod, parfois pas, releases, etc. (bref les sujets qui sont en fait pas très importants)
JPL
Juste quelques exemples -- survoler !
Richard
1er changement de PO, mais pas encore Richard !
Richard
Nouveau Sponsor tech, impliqué et moteur
Une première vision
Urgence de la sortie de Flash acceptée par la hiérarchie → +2 dev web
Richard
Nouveau Sponsor tech, impliqué et moteur
Une première vision
Urgence de la sortie de Flash acceptée par la hiérarchie → +2 dev web
Richard
Richard
Richard
Richard
Richard
Grillé deux-trois-quatre mois… À apporter quasiment ZERO valeur, et avec tout le monde qui galère à mort
Richard
Début management visuel + stop d’être devant une TV + arrêter de perdre du temps à créer des tickets JIRA
→ 1 ticket jira et après on met tout sur le tableau
… précurseur de l'arrêt de jira, plus tard...
JPL
On réalise que c’est cool
JP
“Un élément fondateur de la culture ingéniérique de l’équipe”
JP
Impact côté process MEP etc.
“Un élément fondateur de la culture ingéniérique de l’équipe”
JP
raconter l’histoire de l’écran géoblocage : qu’est ce qui risque d’être cassé ?
JP
JP
JP
Fin de JIRA ! On a bien vu qu’on s’en sortait très bien sans… Et mieux avec un board physique.
On peut rajouter plein d’infos… Bonhommes, critères d’acceptation, statut en attente d’une entité externe, DoD, objectifs de sprint et quotidien… Les tâches tech et les MEP.
Et tout le monde voit et peut toucher à tout, tous ensemble, en même temps.
JP
JPL
JPL
+2 dev JS
Dev mobiles x2 (+1 Android, +1 iOS)
+ nouveau rôle : test lead
JPL
Séparation au fur et à mesure malgré la réticence des équipes
JPL
Séparation au fur et à mesure malgré la réticence des équipes
JPL
Séparation au fur et à mesure malgré la réticence des équipes
JPL
Créer un espace qui permet aux équipes de continuer de se mélanger, et compenser le défaut d'équipes séparées
Concentrer et borner les réunions des dèv pendant cette journée au lieu stopper la productivité pendant la semaine
Richard
Richard
Sponsors laisse autonomie au PO
Richard
Objectif aucun utilisateur sans réponse -> c'était par rapport aux anomalies ou incompréhensions liés au player et remontées par les utilisateurs des sites/apps éditeur
JPL
JP
JP
JP
“JP prend de la hauteur”
Appropriation des rituels par les équipes, notamment la Rétro
JP
JP
JP
EN VRAC : Implémentation CI, framework automatisation des tests, outillage, build et passage à Webpack, tests auto sur Push GIT, BrowserStack, pilotage de devices
JP
JP
Montée en puissance sur la fréquence des MEP ; utilisation du board de MEP en planning, coordination essentielle, dès qu’on arrête de faire des MEP on perd le rythme -- process de MEP (jeu de l’oie)
Et on mesure notre temps à MEP !
Richard
Richard
Pression projet pour lire des contenus payants avec DRM
Mais l’archi actuelle ne le permet pas vraiment
… On arrête de bricoler et on se débarrasse enfin de la dette accumulée ! (on en parlait depuis longtemps, mais de là à passer à l’acte…)
Richard
JP
JP
Projets organisationnel → Volonté de fusionner Android+iOS
Décision de l’équipe !
JP
Passage en Kanban d’une équipe, we’re not looking back
Ce passage en Kanban permet de cadrer une grosse équipe (fusion de 4+2=6)
Le lien est fort entre fonctionnement du Kanban, modélisation visuelle du Kanban, et respect des règles de fonctionnement
JP
Passage en Kanban d’une équipe, we’re not looking back
Ce passage en Kanban permet de cadrer une grosse équipe (fusion de 4+2=6)
Le lien est fort entre fonctionnement du Kanban, modélisation visuelle du Kanban, et respect des règles de fonctionnement
Richard
process de MEP (jeu de l’oie) plus utile car intégré par tous ; board de MEP perd de son intérêt aussi car les sujets sortent aussi vite qu’ils sont terminés ; on ne se force plus à MEP
JP
JPL
JPL
On est d’accord que c’est avoir le bon mindset !
Notre proposition de définition : bonne vision produit + excellent techniquement + orga adaptée et efficiente
Richard
Richard
Tout à découler de ça
Si l’équipe s’approprie cette direction, c’est jackpot
Avoir une direction claire… À cause des urgences france.tv & fin de Flash. 1 évènement fort, fin du monde, acculé, obligé de changer.
Sinon : Sujets en parallèle...
Notre conseil si pas possible d’avoir une unique direction : 1 team (+ PO) par sujet
1 vrai PO = avec une vraie vision produit
Vision : embarque tout le monde (y compris les dev)
JP
SM dédié, un vrai, expérimenté et à temps plein, qui prend de la hauteur et qui aide à la rigueur et à ne pas faire d’inutile
Management visuel : jeu de l’oie de mise en production, board de synchro des MEP
JP
Build > Dev
Pour de vrai !
CI, environnements, MEP… Tests !
Culture
Équipe autonome et responsable