L’équipe ne trouve pas le temps de préparer les sujets à venir

Test avec un forum d’une journée dédiée

Jean-Pierre Lambert
Jean-Pierre Lambert's blog

--

J’ai évoqué à la fin de mon précédent article la difficulté à pratiquer l’architecture logicielle dans un contexte Agile, ainsi que les changements structurels de l’équipe que nous allions mettre en place pour y répondre. Autre changement que nous mettons en place au projet Player de la Direction du Numérique de France Télévisions : regrouper toutes nos réunions annexes et la préparation de l’itération suivante lors d’une journée dédiée.

“Forum Hors du Guidon”

Éviter l’effet tunnel : on sait quand on rentre, pas quand on sort ni où on arrive

Nom de code de la journée : Forum Hors du Guidon. Par analogie avec l’expression commune sortir le nez du guidon, le but de cette journée est de regarder au-delà de l’itération courante et de préparer l’avenir, pour éviter l’effet tunnel.

Problèmes à résoudre

L’équipe ne prend pas assez de temps pour préparer l’itération suivante et définir l’architecture à implanter

  • En parallèle de l’itération courante, l’équipe doit préparer l’itération suivante. Trop souvent, elle ne le fait pas, ou ne mène pas suffisamment loin la préparation.
  • Dans la même veine, l’équipe ne prend pas assez souvent le temps pour définir l’architecture à implanter, en amont, ou encore en impliquant toutes les personnes nécessaires : les choix d’architecture d’une équipe impacteront toutes les équipes utilisant ou dépendant de ce code.
  • Les réunions en cours d’itération interrompent l’équipe. En général l’équipe est plongée dans un sujet, et oublie complètement qu’il y a une réunion. Résulte un manque d’engagement de l’équipe, qui a déjà la tête bien remplie par un autre sujet. Difficile aussi de démarrer la réunion à l’heure quand on attend les retardataires. Et bien entendu, même planifiée, cela reste une interruption du flow qui se traduit par une perte de temps.
  • Nous avons besoin de mettre en place un mécanisme de dual-track Scrum, à savoir un fonctionnement à deux backlogs, avec un backlog discovery qui s’ajoute en plus du backlog delivery. Concrètement, nous réservons de temps en temps des journées pour concevoir des POC sur des gros sujets à venir, sur lesquels nous avons besoin d’expérimenter et d’explorer. Nous aimerions bien formaliser ces besoins et ce fonctionnement, le rendre à la fois plus récurrent et plus efficace.

Buts du Forum Hors du Guidon

  1. Ne plus interrompre l’équipe avec des réunions, depuis le début de l’itération (Sprint Planning) jusqu’à sa conclusion (Sprint Review)
  2. Faire tout ce qui doit être fait en parallèle de l’itération, c’est à dire préparer l’avenir : refinements, préparation de l’itération suivante, discussions d’architecture, POC et développement exploratoires

Format du Forum Hors du Guidon

Nous utiliserons un format de forum, quelque chose de peu structuré. Après un démarrage où nous rappelons le principe et le but de la journée, le PO énonce la liste des sujets qui doivent être préparés. Puis chacun organise la journée au mieux. Plusieurs petits groupes se forment en fonction des besoins, les personnes passent d’un groupe à un autre de manière fluide.

Règle de la journée : tout le monde peut être interrompu

Règle de la journée : tout le monde peut être interrompu. C’est le but de cette journée : que tous les échanges nécessaires aient lieu.

Le PO, en particulier, s’assure de bien réserver la journée et d’être disponible pour les équipes.

Livrables en fin de journée

  • Chaque User Story de la prochaine itération doit être prête à être démarrée : un document de design existe, et a été revu et approuvé

Prêt à être démarré : nous introduisons deux Definition of Ready.

La première, classique, consiste à s’assurer que l’équipe de développement a bien compris le besoin fonctionnel. L’US peut être planifiée dans une itération. La balle est dans le camp du PO.

La seconde, nouvelle, consiste à s’assurer que l’équipe de développement a suffisamment creusé l’US pour pouvoir en démarrer l’implantation. Ce qui se matérialise par un doc de design qui indique, dans les grandes lignes, comment l’équipe va s’y prendre et quelle architecture sera mise en place. La balle est dans le camp de l’équipe de développement.

  • Les designs ont été revus et approuvés par toutes les équipes concernées : les besoins et contraintes (techniques) des autres équipes doivent avoir été prises en compte → c’est tout l’intérêt du format forum qui permet de mélanger les équipes
  • Les refinements et POC ont avancé : on a appris quelque chose. Le besoin est mieux défini, on est capable de le prioriser, de le mettre sur une roadmap, ou on connait le next step à investiguer ou explorer

Déroulé de la journée

Présentation de la journée par le Scrum Master

Je rappelle donc le principe de la journée, sa raison d’être et ses buts. J’insiste sur les quelques règles que nous nous donnons.

Le board, avant remplissage des sujets : rappel du concept et des règles

J’indique également la présence de cookies, pour ceux qui n’auraient pas déjà remarqué.

A peine le Scrum Master a-t-il déposé des cookies sur la table, qu’il n’en reste déjà plus que la moitié (OK le Scrum Master est le plus gros mangeur de cookies, mais ce n’est pas de sa faute, ils sont trop bons ces cookies d’abord)

Enfin, juste avant de laisser la place au Product Owner, je précise bien que c’est un test que nous faisons, qu’il faudra voir ce que ça donne ! Je donne rendez-vous en fin de journée pour le debrief.

Présentation des sujets par le PO

Le Product Owner prend donc la parole et présente les sujets :

  • Les refinements à mener
  • Les sujets de fond à explorer (la partie discovery du dual-track Scrum)
  • Les sujets de l’itération à venir, qu’il faut donc préparer
Kickoff du premier Forum Hors du Guidon, le PO a bientôt fini de parler pour laisser place à l’effervescence du forum

Time-box d’une journée et priorisation des sujets

Si tous les sujets de l’itération à venir doivent être préparés, l’équipe n’aura pas forcément le temps de préparer tous les sujets de refinement, POC et exploration. Je challenge donc un peu le Product Owner et le force à noter des priorités sur tous les refinements et sujets à explorer. On n’aura peut-être pas le temps de traiter tous les sujets.

J’en profite pour rappeler qu’en Scrum tous les rituels doivent être time-boxés.

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Finalement, cette journée dédiée est un excellent moyen de construire une telle limite de temps sans être trop rigide ni faire incomber cette responsabilité uniquement au Scrum Master.

Le forum démarre

Très vite, les membres de l’équipe s’éparpillent pour aller creuser divers sujets. Avant de partir, ils ont mis leurs noms sur le board pour bien indiquer qui travaille sur quoi.

Un peu plus tard, on les voit échanger, tantôt à plusieurs derrière un même poste, tantôt à dessiner des diagrammes sur un tableau blanc.

De son côté le PO sollicite certains membres de l’équipe pour procéder au premier refinement. Plus au second, au troisième… Tantôt ils demandent le support du Scrum Master pour cadrer le refinement, tantôt ils s’en sortent tous seuls.

Les tableaux blancs sont pris en photo. Des notifications Confluence indiquent la création de pages de documents de design. Des coches vertes apparaissent sur le board pour indiquer les sujets qui ont été traités. Ça roule quoi !

Alternance entre refinements et investigations techniques

Un des sujets de refinement consistait à intégrer un SDK tiers. Nous coupons vite court au refinement, dans un soucis d’efficacité et car l’essentiel des inconnues dépend du SDK en lui-même.

L’équipe creuse le SDK de son côté et commence même un POC d’intégration.

Nouveau refinement : sont identifiés les éléments nécessaires et les risques. La journée permet d’alterner les refinements et investigations techniques, avec succès et efficacité.

Investigation technique multi-équipe

Un des sujets touchait à une évolution impactant un ancien produit que personne ne maintient, que personne ne veut maintenir !

Une refonte du produit en question étant beaucoup trop longue et pas encore à l’ordre du jour, se pose la question de faire évoluer ce code orphelin, juste pour cette fois et pour pouvoir avancer, aujourd’hui.

Passée une première levée de bouclier de l’équipe, qui refuse d’endosser la maintenance de ce code, je pose la question :

Arrêtons de penser à notre équipe. Pensons à toute l’entreprise. Il n’est absolument pas question ici de devenir mainteneurs officiels de ce code. Mais peut-on, aujourd’hui, faire un petit quelque chose qui débloque la situation ? Peu importe à qui est ce code. Peut-on aider toute l’entreprise ?

Démarre une petite investigation technique pour essayer de voir quel changement minimal peut être fait. Nous rejoint un développeur d’une autre équipe, qui a trempé un peu dedans. Le collectif finit par trouver une solution, minimale, qui devrait faire le job. Permettant ainsi à la fois de ne pas perdre d’audience tout en temporisant la refonte du produit en question.

C’est pour moi le plus grand succès de la journée : sans ce format libre et sans contrainte, ce sujet n’aurait jamais été adressé.

Fin de journée : ROTI et améliorations à apporter

Board en fin de journée. On a bien bossé ! Et un super ROTI unanime de 4 !

En fin de journée, le ROTI n’indique que des 4. Quel succès !

L’équipe relève immédiatement des points d’amélioration :

  • Journée un peu chaotique. La mise en place de spécialités transverses entre les équipes, en charge des questions d’architecture, devrait faciliter tout le forum, en guidant qui participe à préparer quel sujet. L’arrivée de notre second PO, aidera également à structurer et fluidifier la journée.
  • Réussir à préparer tous les sujets dans la journée, ce n’est pas simple. Vers la fin de la journée, l’équipe a eu un petit coup de bourre pour aller au bout. À mon sens c’est plutôt un point positif, c’est le time-boxing en action. D’autant plus que l’équipe s’en est bien sortie. La prochaine fois l’équipe sera certainement plus efficace et fera plus attention à l’horloge.
  • On a regretté l’absence de certains partenaires ou experts, externes à l’équipe, qui auraient permis d’avancer bien plus vite sur certains sujets. Cela tombe bien, c’est dans le backlog du Scrum Master de faire en sorte qu’on travaille mieux avec ces personnes. Je leur parle donc du principe de Forum Hors du Guidon, en leur demandant d’essayer d’être disponibles au maximum ces jours-là. Ils sont séduits par le concept et sont partants. J’essaierai de les faire passer la journée dans notre Open Space pour faciliter tout ça !

En conclusion, le format est adopté. Nous le ritualisons à chaque itération !

Et vous, que pensez-vous de ce format ? Est-ce qu’il pourrait être utile sur votre projet ? À bientôt !

--

--

Software engineer with special interest in quality and business value, now a technical/Agile coach helping teams to deliver high-value, high-quality products.