Scrum en vacances

Pendant les périodes de congés et encore plus pendant la période estivale, l’organisation du projet en mode Scrum est impactée sur son premier élément de stabilité : la disponibilité des membres de l’équipe. Que ce soient le Product Owner ou l’équipe de développement qui sont absents, que cette absence soit partielle ou totale, chaque équipe met en place une stratégie pour maîtriser au mieux les impacts sur les différents artefacts ou évènements de ses itérations Scrum. Bien que cette contrainte d’indisponibilité soit identifiée par tous comme non souhaitable, force est de constater que la réalité nous rattrape et qu’il faut bien apporter des réponses là où la méthode reste muette.

Cet article vous propose de revenir sur les différentes options qui s’offrent à une équipe Scrum qui fonctionne en mode « dégradé » temporairement.

Absence d’un ou plusieurs co-équipiers, quels impacts ?

Cette liste non exhaustive ne tient pas compte du niveau de maturité de l’équipe dans ses pratiques agiles.

Si un ou plusieurs membres de l’équipe sont absents :

  • Moins d’histoires utilisateur seront produites, votre vélocité chutera (plus ou moins fortement),
  • La tentation de se relâcher sur le rythme sera grande, encore plus si le Product Owner n’est pas là pour assister à la démonstration de l’itération,
  • La motivation de l’équipe changera (en bien ou moins bien),
  • Plus d’inconnues resteront en suspend pendant les planifications d’itérations si une ou plusieurs compétences sont absentes, encore plus si le Product Owner n’est pas là pour répondre aux questions de l’équipe,
  • L’auto-organisation de l’équipe évoluera : l’équipe prendra (encore) plus de décisions (et certaines seront mauvaises). La réciproque est vraie, certaines équipes arrêteront de prendre des décisions (même si elles ne devraient pas),
  • Certains membres de l’équipe auront à travailler sur des parties du produit qu’ils maîtrisent moins voire pas du tout,

Des idées pour agir …

Chaque artefact et évènement Scrum (voir le Scrum Guide pour plus de détails) peut être adapté pour limiter les impacts ou les contourner. Dans tous les cas, ces adaptations restent ponctuelles, courtes dans le temps et ne sauraient constituer de nouvelles règles pour l’équipe.

Itération

Si un ou plusieurs développeurs sont absents, le premier dilemme concerne généralement la durée de l’itération : devons-nous l’augmenter pour retrouver notre vélocité moyenne ? Devons-nous la raccourcir pour en redémarrer une autre proprement après ? Vous pouvez toujours vous contorsionner, chaque solution sera certainement valable. L’option la plus simple consiste à maintenir la durée de l’itération et donc à préserver l’autre élément de stabilité de Scrum : la durée des itérations. Certes l’équipe produira moins, mais rien ne l’empêche de produire.

Le deuxième dilemme concerne les compétences. Oui en agile les équipes doivent être cross-fonctionnelles, oui elles échangent quotidiennement mais échangent-elles du savoir-faire ? Est-ce que chaque membre de l’équipe est capable de travailler sur n’importe quelle partie de l’application ? Souvent ce ne sera pas le cas, alors pourquoi ne pas prévoir dans le contenu de l’itération une tâche « transfert de connaissance » qui sera estimée par tous ? idem pour le retour de ces personnes, sauront-elles prendre le train du développement en route ? Au-delà de l’itération en cours, l’équipe devra donc anticiper une absence en prévoyant des tâches sur l’itération précédente et la suivante pour garder un rythme de développement optimal. C’est une évidence, mais cela va mieux en le disant.

Enfin si le Product Owner est en congés, l’équipe peut-elle continuer le développement ? Oui ! Pourquoi ne pas faire une revue des histoires utilisateur et des critères d’acceptation plus tôt (voir plus bas la création du stock d’histoire par le Product Owner) ? L’atelier de planification d’itération se déroulera sans le Product Owner mais au moins l’équipe ne fera pas seule la découverte des nouvelles priorités fonctionnelles.

Backlog

Vous êtes Product Owner et vous prévoyez de prendre 3 semaines de repos bien mérité. Pour maintenir un rythme de travail plutôt fluide, votre backlog contient toujours suffisamment d’histoires pour l’itération suivante. Or dans ce cas il faut se rendre à l’évidence, vous allez créer du stock, et prévoir des histoires utilisateur pour au moins les 2 prochaines itérations. Cette situation ne vous enchante guère car vous allez encore plus solliciter les parties prenantes, les décideurs et les managers qui sont déjà partis ou bouclent eux aussi leurs dossiers. Dans tous les cas, votre responsabilité est de ne pas laisser l’équipe avec un backlog vide et de trouver une solution (regardez bien, elle est souvent très simple). Privilégiez une granularité d’histoire la plus fine possible et assurez vous que vos critères d’acceptation sont sans ambiguité et qu’ils proposent des exemples clairs. Un Product Owner qui part en vacances mettra les bouchées doubles voire triples.

Si ce n’est pas possible, l’équipe peut aussi proposer ses histoires techniques (avec les critères d’acceptation) avec un accent tout particulier par exemple sur la réduction de la dette technique ou l’implémentation d’exigences non-fonctionnelles. C’est une opportunité  pour l’équipe de contribuer encore plus au contenu du backlog.

Enfin le backlog doit être réalisable par l’équipe disponible pendant la période de congés (cf. dilemme des compétences plus haut). La priorité des histoires sera adaptée et réévaluée en tenant compte des compétences restantes. Il vaut mieux produire moins de valeur temporairement que de mettre en difficultés l’équipe sur un point fonctionnel qui pourra être plus facilement traité dès que la ou les personnes compétentes sont de retours. Egalement, évitez dans la mesure du possible d’avoir des histoires qui font appel à des compétences en dehors de l’équipe qui peuvent elles aussi être absentes.

Daily Meeting

Un daily meeting, même seul, a lieu (c’est moins drôle nous sommes d’accord). Mettez à jour quotidiennement votre tableau Scrum, déplacez les post-its, continuez à tracer la courbe du Burndown Chart. Prenez des photos, ce seront autant d’éléments à partir desquels vous pourrez communiquer au retour du reste de la troupe.

Vous aurez certainement des obstacles. En ayant suivi les conseils précédents pour établir votre Backlog, ils devraient se limiter à votre travail et vous saurez comment les éliminer. Si ce n’est pas le cas, abandonnez l’histoire en cours et passer à la suivante. La probabilité du blocage total est faible mais existe. Dans ce cas, quelle valeur pouvez-vous produire ? Vous ne subissez pas le système, c’est à vous de le gérer.

Démonstration

Une démonstration est toujours organisée ! Mais à qui la faire si votre Product Owner est absent ? Invitez des utilisateurs, votre manager ou celui d’un autre service, vos collègues, un commercial, un administratif, … Encore une fois, seul le public change mais votre démonstration a bien lieu. Si personne n’est intéressée, soyez créatifs, en préparant par exemple une petite vidéo commentée de démonstration que vous publierez sur Youtube ou ailleurs. Il parait que certaines personnes ne coupent pas leur téléphone pendant les vacances, envoyez leur le lien, cela les rassurera et vous contribuerez à la sérénité de leur repos.

Rétrospective

Comme pour la démonstration, la rétrospective est conduite, peut-être dans un format différent, ce n’est pas ça qui manque (par exemple « Un oeil dans la rétro (partie 1/3)« , « Un oeil dans la rétro : la « ligne de temps » (2/3)« . J’aime également utiliser le format Dialogue Sheet dans ce genre de circonstances. Il laisse l’équipe complètement autonome et évite d’imposer un facilitateur si certain(e)s ne sont pas particulièrement motivés pour faciliter la rétrospective. Pour celles et ceux qui partiraient avant la fin de l’itération, pensez à leur demander leurs feedbacks que vous prendrez en compte dans vos échanges. Enfin, pensez aux absents en gardant une trace visible et concrète de vos actions de rétrospective. A leur retour, ils/elles apprécieront de voir que l’amélioration continue est restée active.

Conclusion

Ces phases de congés ou d’absence sont de vrais révélateurs de la maturité et de l’engagement de l’équipe dans ses pratiques agiles. Elle devra faire preuve d’encore plus de discipline et de rigueur pour maintenir une production certes réduite mais optimale. Dans tous les cas, les artefacts et les évènements Scrum sont maintenus. La seule véritable raison pour arrêter de fonctionner en Scrum que j’ai pu observer : toute l’équipe est absente en même temps (Product Owner et développeurs).

LinkedInBufferViadeoEvernote
Ce contenu a été publié dans Agile, Equipe, Product Owner, Retour d'expérience, avec comme mot(s)-clé(s) , , , , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *