Scrum

Des conseils dans la mise en œuvre de Scrum.

Fil des billets - Fil des commentaires

Les activités de l'affinage du backlog

L'affinage du backlog (en anglais Backlog Refinement) se pratique avant le premier sprint puis pendant chaque sprint.

L’objectif de l'affinage est d'entretenir le backlog pour augmenter les chances de succès des futurs sprints.

Voici les activités qu'on y mène, en équipe :

Les 6 activités de l'affinage

Le moyen mnémotechnique pour retrouver ces activités : ADAPTER.

L'affinage se déroule entre le Product Owner et le reste de l'équipe, à un moment laissé à l'appréciation du collectif, soit sur un rythme régulier (ce qui est plus facile), soit à la demande.

Voici un enchainement possible des activités d'une séance d'affinage :

  • On regarde le nombre de stories prêtes. S’il n'y en a pas assez, l’approvisionnement est primordial. Pour y parvenir, on s'appuie sur les 6D.
  • On identifie ensuite les stories épiques qu’il faut décomposer.
  • On examine le bac à sable et le tableau de features en vue d’approvisionner en nouvelles stories à affiner.
  • On purge en éliminant des stories devenues inutiles et on trie en plaçant certaines dans le bac à glace.
  • On fait une estimation des nouveaux éléments approvisionnés ou décomposés.
  • On réordonne les stories par priorité, ce qui permet d'actualiser le plan de release.

C'est donc au cours de l'affinage qu'on estime, priorise et planifie. Nous en parlerons dans le Cube de jeudi à Toulouse. Il reste des places pour cette session.

Affiner le backlog, c'est le titre du chapitre 7 de mon livre Scrum.

Les 6 activités de planification du sprint

La planification du sprint (en anglais Sprint Planning) est un événement Scrum qui se déroule à chaque début de sprint.

L’objectif de la planification est de mettre l’équipe en situation de réussir le sprint en se focalisant sur un objectif et s’accordant sur des stories.

Voici les activités qu'on y mène :

6 activités de planification du sprint

Voici un enchainement possible des activités :

L’équipe embrasse le contexte du sprint. Pour chaque story prête, en commençant par la première, l’équipe confirme avec le PO sa confiance pour la finir dans le sprint.

Pour faciliter la réalisation de la story, on prépare la tactique d’essaimage et on procède à l’identification des tâches.

Avec cette connaissance du travail à faire, l’équipe s’engage sur l’objectif du sprint. Le sprint est alors lancé et chacun, aligné sur l'objectif et la tactique collective, part réaliser une tâche.

Lectures en compléments :

Tableau Scrum

La story, élément du backlog, a une vie qui passe par 5 états.

La tâche, travail contribuant à une story, se représente sur 3 états.

Un tableau Scrum avec les 2 niveaux montre à la fois l'avancement des travaux pendant le sprint (la vie des tâches, les stories en cours de réalisation et finies) et le backlog pour les sprints suivants (bac à sable, stories en affinage, stories prêtes). C'est tout simple, pas besoin de plus d'états (et donc, ni de colonnes supplémentaires).

tableau Scrum avec stories et tâches

Cela peut s'appliquer dans tous les usages de Scrum. Pour les features, c'est également recommandé de faire un tableau, mais les états sont spécifiques à chaque contexte.

Bon Scrum 2017

Pour ma carte de vœux, j'ai repris et détourné la couverture de l'édition 4 de mon livre Scrum (qui a bien marché en 2016, merci à tous mes lecteurs) :

Bonne année 2017

Scrum ? mon scrotum ! version 3

Après la keynote d'Agile Pays Basque et la session à Agile tour Rennes, j'ai présenté une nouvelle version de Scrum ? mon scrotum ! jeudi dernier à Toulouse.

Ceux qui étaient présents sur place ont assisté à un bonus exceptionnel, le meilleur moment de la journée, avec la clownanalyse orientée scrotum absolument géniale des Bataclowns.

bataclowns.JPG

Voici les slides de cette présentation à Agile tour Toulouse 2016.

En discutant le soir et le lendemain à propos de ma présentation, je me suis aperçu que sur deux points, j'ai pu être mal compris.

Ultime session

Il s'agissait de ma dernière présentation de Scrum ? mon scrotum ! dans une conférence, mais je ne me priverai pas d'en parler dans des entreprises et il est possible que je développe ces idées sous une autre forme.

Néocons

Quand je parle des néocons, il ne s'agit pas des utilisateurs de l'agilité et Scrum, de ceux qui les pratiquent.

Je vise explicitement ceux qui influencent, les coachs, vendeurs d'outils, promoteurs de méthodes, etc.

Y compris, allez, les néococons :

  • ceux qui pensent que les certifications c'est pipeau mais qui en font passer quand même parce qu'il y a de la demande,
  • ceux qui considèrent que SAFe est un retour à un ancien paradigme mais qui le promeuvent quand même parce que ça rassure la direction.

La quintessence de la passe

La semaine dernière, à la fin de ma keynote Scrum ? mon scrotum ! pour Agile Pays Basque, j'ai fait deviner un mot.

J'ai donné 2 citations de Daniel Herrero, le chantre du rugby : Derrière une apparente simplicité, la passe cache le mystère des arts du lien.

et

…la passe est la quintessence du jeu collectif, un acte de vie.

Ces deux belles citations sont extraites du Dictionnaire Amoureux du Rugby, qu'un ami bienveillant m'a gentiment offert.

Si Scrum est bien évidemment associé au rugby, les exemples qu'on donne pour montrer l'analogie font généralement référence au pack qui pousse en mêlée.

Mais la passe est aussi un bel exemple de collaboration dans une équipe, comme le dit si bien Daniel Herrero. Dans sa première citation, on retrouve un peu ce qu'on dit de Scrum :

Scrum est facile à comprendre, mais difficile à appliquer.

Pour avoir joué trois-quarts pendant quelques années, je sais que réussir une passe en match n'est pas si facile. Même la simple passe en arrière. Dans le rugby moderne, on trouve de nouvelles formes de passe, notamment la fameuse passe après contact qu'on appelle offload.

Il fallait deviner ma forme de passe préférée, celle qui nécessite une belle technique du passeur mais surtout une grande confiance entre le passeur et le receveur :

Pour moi, la ……… est la quintessence de la passe.

Auriez-vous deviné ? Pas trop difficile, on était dans le Pays Basque. C'est un ancien rugbyman bordelais qui a répondu le premier et gagné le livre Scrum offert par les éditions Dunod.

J'espère en voir de belles, et réussies, par le Stade Toulousain ce soir contre Grenoble. Ce serait le signe d'une confiance retrouvée.

Nouveau guide Scrum

Pendant les vacances, j'ai participé à la traduction du nouveau guide de référence de Scrum, les règles du jeu. Dans cette version de juillet 2016, la nouveauté est l'ajout du paragraphe Les valeurs Scrum.

Les 5 valeurs dont il est question ne sont pas nouvelles. J'en parlais dans un billet de 2013, intitulé Les valeurs de Scrum et elles figurent dans mon livre Chapitre 3 §3.1.2 Valeurs partagées.

Mais c'est la première fois qu'elles apparaissent dans le guide de référence. Avec les traducteurs agiles, nous avons profité de cette nouvelle version pour revoir le texte en entier. La quinzaine de pages, disponible sur le site en différents formats, est maintenant beaucoup plus facile à lire.

Une bonne préparation pour ma keynote à Agile Pays Basque : Scrum mon scrotum !

Contextualiser Scrum

Pour utiliser le cadre Scrum, il faut d’abord y insérer des pratiques complémentaires, variables selon le domaine, et adapter le tout au contexte.

Lire la suite...

Équipes features façon puzzle

Je continue avec mes retours d'expérience sur l'atelier Puzzle grand Scrum que j'ai animé une quinzaine de fois.

Après des discussions sur par quoi commencer et sur la synchronisation des sprints, revenons sur l'organisation des équipes.

Pour réaliser le puzzle avec 3 équipes, on a besoin de définir sur quoi chacune va travailler.

Nous sommes dans le cas où il n'y a qu'un seul produit et je fournis au participant au jeu un seul backlog, sous la forme de 20 features (ou stories peu importe). Nous avons vu dans un épisode précédent comment ça se passait pour définir l'ordre dans ce backlog.

Les participants disposent également d'un tableau préparé, avec un colonne (ou une ligne) pour y mettre les features prêtes. Je leur dis simplement que pour y mettre un élément, il conviendrait de lui associer l'équipe ou les équipes qui vont le développer.

Le tableau de features est un outil de management visuel qui reste unique même quand le produit est gros et que plusieurs équipes y travaillent.

Dans le Scrum multi-équipes mono-produit, il y a donc une activité supplémentaire d'affinage, qui est de définir cette association entre une équipe ou plusieurs et une feature.

Dans le jeu, la plupart du temps, on a associé une feature à une seule équipe. C'est pour former ce qu'on appelle les "feature teams". À noter que je ne dis rien, quand j'anime le jeu, qui pousse les joueurs dans ce sens, ce qui laisse à penser que la notion est familière aux participants.

Il y a eu cependant quelques exceptions, en général au début et à la fin du jeu. Parfois, au début, comme lors du dernier Raid, il est d'abord prévu de mettre 2 équipes sur une feature. En général, cela ne dure pas et quand le sprint démarre, la feature est faite par une seule équipe.

Pourtant, en ayant suivi tous ces puzzles, je pense que le tri des pièces pose des problèmes aux équipes features. Sans un tri grossier, c'est difficile de savoir si on pourra assembler et intégrer un personnage dans un sprint. C'est un peu l'équivalent de l'infrastructure dans les gros projets, qui pousse parfois les organisations à choisir des structures hybrides, avec une component (ou infra) team à côté des features teams.

Ce ne serait pas une bonne idée d'avoir une équipe tri pour toute la durée du puzzle. En tout cas, personne ne l'a fait dans les ateliers que j'ai animés. Mais on peut ajouter des features de tri au backlog, qui seront prises par les features teams, en plus de leurs features à valeur client. C'est arrivé, mais seulement 2 fois sur les 15.

Feature tri ajoutée

À la fin du jeu par contre, dans le 4e sprint, il y a une volonté collective de faire participer toutes les équipes à la réalisation d'une seule feature. Il faut dire que les circonstances ont changé (héhé).

Sur quoi se base le choix de mettre telle ou telle équipe sur une feature ?

Dans le jeu, il arrive qu'une équipe soit associée à une zone du puzzle et ensuite s'occupe de tous les personnages de cette zone. Ce critère de choix se retrouve sur les projets, quand on donne à une équipe un domaine fonctionnel (dans LeSS, on retrouve cette idée avec les requirements areas). Sinon la plupart du temps, le choix se fait de façon opportuniste, sans réelle stratégie.

Qui décide du choix d'une équipe pour une feature ? Nous le verrons dans un prochain épisode sur le volet PO et Cie.

Sprints synchronisés façon puzzle

Dans l'atelier Puzzle grand Scrum dont je parlais dans mon dernier billet, il y a donc 3 équipes qui concourent à la réalisation du puzzle. Le format du jeu pousse les équipes à se caler sur le même rythme.

C'est à dire que toutes les équipes commencent et finissent le sprint en même temps.

Avec les mises en œuvre de Scrum multi-équipes que j'accompagne, c'est ainsi que ça se passe, je pense notamment à Intel et Airbus.

Au cours de la quinzaine d'ateliers "puzzle" que j'ai animés, jamais personne n'a émis une proposition différente, des sprints décalés, qui serait par exemple : l'équipe bleue commence puis au bout du tiers du sprint, l'équipe verte commence, et aux deux tiers l'équipe rouge commence.

Dans mon livre édition 4, chapitre 21 "Développer des produits à plusieurs équipes", je ne présente pas d'alternative à la synchronisation des sprints pour du Scrum multi-équipes (§21.2.1). Je mets en avant l'intérêt de l'intégration fréquente entre les équipes pour cette approche.

Une discussion avec Pablo[1] lors du dernier Raid Agile m'a fait percevoir que cet argument n'était pas décisif : on peut aussi intégrer régulièrement si les sprints ne sont pas synchronisés.

Un intérêt plus évident est que cela facilite la tenue des événements du sprint[2]. Il est bien mis en évidence par l'atelier, en particulier pour l'organisation de la revue avec les parties prenantes. L'affinage multi-équipes cadencé est aussi facilité par la synchronisation des sprints.

Dans le chapitre 15 de Scrum et XP depuis les tranchées, Henrik Kniberg raconte qu'il avait d'abord expérimenté les sprints désynchronisés, avant d'être convaincu par Ken Schwaber de les synchroniser.

En plus des arguments évoqués, Kniberg évoque aussi la réorganisation des équipes, faisable en cas de sprints synchronisés, mais qu'il est probablement plus raisonnable de repousser en fin de release.

Notes

[1] Pablo, un partisan revendiqué des sprints multi-équipes désynchronisés.

[2] Dans mon livre, je fournis un tableau récapitulatif des événements du sprint à plusieurs équipes, page 277.

- page 1 de 7