Combien de temps passez vous en réunion d’équipe (avec la totalité de l’équipe) par sprint et comment vous gérez l’équilibre temps de réunion / temps de travail.
De manière général, voici la liste de nos points d’équipe, sans compter des réunions entre dev, PO avec le client, PO / testeur etc
une demi-journée pour le sprint planning
une quinzaine de minutes tous les matins pour le daily + si besoin, une quinzaine d’autres pour discuter sur la priorité.
une grosse demi-journée pour le review+ la rétro
une demi-journée au milieu du sprint pour la lecture des US candidats du prochain sprint + 3 amigos (donc une semaine sur deux)
une demi-heure de jeux pour la cohésion d’équipe le vendredi soir une semaine sur deux
chaque fois qu’un dev terminer à développer une fonctionnalité, il fait une petite démo devant toute l’équipe et on discute rapidement si ça pas en test ou il y a des choses à corriger- 15 à 20 minutes - au fil de l’eau pendant le sprint
une fois par mois (ou moins, en fonction de mon dispo) un atelier serious game - une demi-journée.
Mon équipe, travaillant tous à distance, réclame un côté plus de temps de cohésion d’équipe, autre côté, veulent réduire le temps de réunions pour avoir plus de temps à développer.
Qu’en pensez vous de notre agenda ?
Dans vos entreprises, qu’avez vous de plus ou de moins par rapport du notre ?
Je vais être un peu du même avis que @Alexandre_Quercia sans vrai contexte sur ta durée de sprint, il est compliqué de s’avancer sur les temps de cérémoniaux SCRUM (si l’on part sur 2 semaines cela semble cohérent).
Pour les autres temps, cela varie en fonction de beaucoup de facteurs. La question à se poser est surtout la suivante. Pourquoi on fait cet événement ? Quel est le réel besoin ?
Une demi-journée pour la lecture d’US ? Pourquoi faire ? Savoir si elles sont assez clairs ou pour faire du raffinage avec l’équipe (estimation, découpage, …) ? Dans mon cas, je ne suis pas fan de ce process sur le PBR, je préfère largement des événements de travail court et concit (30min) pour traiter d’un soucis sur une US.
Un atelier Serious Game là aussi dans quel but ? Une demi journée si c’est pour faire du Serious Gaming c’est aussi assez long et je pense qu’à terme surtout si ils sont autour de l’agilité cela pourra devenir contre-productif. Tu peux par contre transformer cette demi-journée en Slack Day qui est un événement « Off » en terme de développement pour l’équipe pour travailler sur d’autres sujets. On l’utilise par exemple nous dans notre cas pour tout ce qui relate du mob programming.
Réduire le temps de réunion ? Avoir besoin de plus de temps pour développer? Encore une fois quel est le problème ou pourquoi ?
Les réunions cela les ennuient ? Creuse le pourquoi.
Ils n’ont pas assez de temps de développement ? Encore une fois, pourquoi ? Est-ce que les sprints sont trop chargés ? Ils manquent d’expérience ?
Je viens de découvrir ce que c’est Le Swarming Les dev de mon équipe sont déjà dans un channel vocal ensemble une bonne partie de la journée, et ils font déjà Swarming & pair programming quand nécessaire.
Je voulais parler du temps des événements dont toute l’équipe est mobilisée (PO + dev + testeurs).
Nous sommes effectivement sur des sprints de 2 semaines.
Je viens de mettre en place cela parce que un côté, je me rends compte que les dev ne lisent pas assez les US et oublient parfois des exigences techniques lors du développement. L’autre côté, je voulais expérimenter le Tres Amigos, afin de mobiliser équipe dans la réflexion des scénarios de test possible (avant je faisais seule, et demande les autres de faire des feedback mais je n’ai jamais rien recu, en conséquences, parfois, on oublie des petits détails, à tenir compte dans un redux par exemple.
Peux-tu m’expliquer davantage comment ça déroule une journée Slack ?
L’intégralité de l’équipe, moi + les dev + les testeurs sont tous issus d’une reconversion professionnelle et manque encore expérience.
Les réunions ne nous ennuie pas, bien au contraire. Ils apprécient ces moments d’échange. Cependant, Toute l’équipe est très engagée et motivée à délivrer le MVP dans le meilleur délai. Depuis 2 sprints, on arrive à estimer notre charge de travail relativement correct. Les sprints ne sont plus trop chargés comme avant. mais ils ont tous envie d’aller plus vite, et me demande comment optimiser le temps pr pouvoir prendre plus d"US à chaque sprint.
Wow ! Le but c’est pas la vitesse. Le but c’est la vélocité. Plutôt que d’aller travailler sur de la production de feature, je vous invite à vérifier que ce qui est livré apporte de la valeur de manière formel et empirique. Aller à 150km/h vers un mur sans pouvoir changer de direction parce qu’on est dans le brouillard, c’est pas ce qu’on a inventé de plus… survivable.
Ca doit faire beaucoup de temps tout ça dans un sprint non ? Le client final est-il invité à ce point ? Car il a peut être son avis également à donner…
c’est une démo en interne, avant même les tests, juste pr vérifier que la fonctionnalité développée correspond à la compréhension de tout le monde. On aime bien ce moment. Le dev peut montrer son travail à l’équipe, et en général, on trouve toujours quelques petites améliorations à faire. Ce n’est qu’une fois les améliorations intégrés qu’on faire passer la fonctionalité au testeurs.
les clients ne sont invités qu’au rétro, et ils ne voient que les fonctionalités testés. Ils ont aussi les feedback qu’on discutera par la suite entre nous si l’on les prend, quand et comment.
Comment va passe chez vous Franck ?
A quel moment le PO prend connaissance du US développé ?
Moi, c’est au moment de cette démo & je découdrai ensuite en profondeur en participant aux tests
Plusieurs manières différentes selon les équipes… mais le mieux a été quand le client est également présent et valide au fur et à mesure plutôt qu’à la fin… mais bien sûr, ça n’a été possible que rarement.
Le dev peut montrer au PO ce qu’il a fait pour demander la confirmation que c’est bien ce qui est attendu, le partage avec les autres devs à ce moment-là n’a pas vraiment lieu d’être… tant qu’on parle de fonctionnel et d’UX… si tu parles de tech, la revue de code est mieux pour ça.
L’idée de discuter avec l’équipe un dev fait avant de tester… je me dis qu’il y a quand même un minimum de tests qui ont été faits… et à part le fait de valider ça par la QA sur des environnements différents du poste du dev, je me dis que vous pourriez gagner ce temps-là dans le temps que vous essayer de diminuer en réunion… mais cela n’engage que moi et ce n’est qu’une proposition !
C’est à l’équipe de décider si ce temps est précieux et utile pour elle !
Les dev de mon équipe sont déjà dans un channel vocal ensemble une bonne partie de la journée, et ils font déjà Swarming & pair programming quand nécessaire.