Les activités de la rétrospective

Mon premier article sur les activités de la rétrospective, en 2007, avait eu gros succès. Quand je relis ce billet aujourd'hui, je me dis que j'en garde l'essentiel, 10 ans après, quand j'anime des rétrospectives (ce que je fais assez souvent).

Ma présentation des activités de la rétro a un peu évolué, voilà ce qu'elle donne maintenant :

activités de la rétro

Mais surtout ce que j'ai changé, c'est le résultat de la rétro. Plutôt que d'essayer à tout prix d'obtenir un plan d'actions, ce qui est assez vain, je pousse les participants à définir un objectif.

En gros à se mettre d'accord sur l'impact qu'ils visent à la fin du sprint suivant. Et je leur laisse le sprint pour définir le comment. Mais à condition qu'ils affichent cet objectif d'amélioration sur leur beau tableau, bien visible, et qu'ils en parlent tous les jours à la mêlée.

La rétrospective, c'est le chapitre 12 de mon livre Scrum. 12 pages illustrées et une technique de rétro originale, la rétro-glandouille.

Prioriser avec CD3

Le Cube de jeudi portait sur Prioriser, estimer et planifier.

J'ai présenté plusieurs techniques de priorisation : HIPPO, 10/10, VRAC et CD3.

CD3, c'est le Coût du Délai Divisé par la Durée.

Le coût du délai est une approche économique : on calcule le coût de ne pas faire une feature et on fait en premier celle qui a le coût du délai le plus élevé.

Bien sûr, cela n'est pas facile. Voyons avec un exemple, celui que j'ai donné aux participants du Cube.

J'ai repris le projet Grands Sites d'Occitanie d'Al tablèu. L'objectif de la région est d'avoir 10 millions de visiteurs sur 12 sites sélectionnés.

Par quel site commencer ? Prenons en 2, la cathédrale d'Albi et les Arênes de Nîmes, et essayons CD3.

exemple pour le coût du délai

On voit sur les cartes un nombre de visiteurs prévus (on va dire que c'est par semaine, soyons optimistes) et l'effort pour les travaux estimés en taille de Tee-shirt. Sachant que L correspond à 5 semaines de travaux et M à 3, par quel site commencer ? ou faut-il commencer les 2, en divisant la force de travail ?

Pour Albi, le CD3 est 24. Pour Nîmes, il est de 33. Il faut faire Nîmes puis Albi. Au bout des 8 semaines nécessaires pour avoir les 2, on gagne 140 000 visiteurs (500 000 contre 360 000). Évidemment ce n'est pas une bonne idée de faire les 2 en parallèle, on n'a pas de visiteurs avant la 6e semaine.

La technique VRAC aurait donné le même résultat (pas de risque, ni d'apprentissage).

Cependant CD3 présente des différences d'approche intéressantes :

  • l'alignement de la réflexion sur un objectif (ici 10 M de visiteurs est la métrique qui compte),
  • l'optimisation économique qui pousse à plus étudier les hypothèses,
  • la prise en compte de la variation dans le temps en définissant des profils d'urgence.

Pour ce dernier point, imaginons qu'un spectacle d'orgue soit prévu pendant les 7e et 8e semaines à Albi et qu'il attire du monde, ce qui fait qu'on passe à 200 000 visiteurs ces 2 semaines. Le coût de ne pas avoir Albi à cette date augmente. Avec cette nouvelle hypothèse, il vaut mieux commencer par Albi, on aura gagné 20 000 visiteurs après les 8 semaines.

Les participants au Cube m'ont paru quelque peu désorientés avec CD3, peut-être aurait-il fallu y passer plus de temps. Pour moi, c'est très séduisant.

En savoir plus sur CD3.

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'augmenter les chances de succès des futurs sprints, en entretenant le backlog.

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.

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

Prioriser, estimer et planifier

Lire la suite...

Prochain Cube Agile à Toulouse : prioriser, estimer, planifier

Cube_marche2_600_263.svg.png

Comment on priorise ? Pourquoi on estime ? À quoi ça sert ? Qu'est-ce qu'on estime avec Scrum et l'agilité ? Comment faire en sorte que le planning poker ne prenne pas trop de temps ? Comment éviter que la vélocité ne tue l'agilité ?

Lire la suite...

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 :

Planifier pour réussir le sprint

En parcourant mon livre à la recherche du 6e D, je m'arrête par hasard sur les pages 108 et 109. Et là, je constate que les titres des paragraphes 9.1 et 9.2 sont quasiment identiques, à l'article près. Évidemment ce n'est pas ce que j'ai voulu. C'est un bug.

Je mène l'enquête et découvre rapidement que le bon titre du §9.1 est "Planifier pour réussir le sprint". D'ailleurs ce titre était déjà présent dans l'édition 3 et il apparaît dans les fichiers que j'ai conservés pour la fabrication de l'édition 4.

En fait, lors de ma dernière relecture juste avant mise en production, j'ai demandé à ce qu'on ajoute "Les" devant le titre du §9.2, par souci de cohérence. Voici un extrait du fichier markdown que j'ai utilisé pour communiquer mes retours de lecture :

Capture_d_e_cran_2017-01-31_a__06.23.36.png

L'éditrice de réalisation s'est trompée en l'appliquant au §9.1. Je ne m'en suis pas rendu compte avant la publication et je m'en excuse auprès de mes lecteurs. Je l'ajoute immédiatement aux quelques errata de cette édition. Voici ce que cela aurait dû donner :

Capture_d_e_cran_2017-01-31_a__05.52.59.png

J'en profite pour mettre en évidence le titre du § "C'est la story qui sprinte". Oui, l'idée que ce soit l'équipe qui sprinte pose problème, c'est pourquoi je préfère appliquer cette notion de sprint à la story.

Boite et outil

De 2005 à 2013, j'étais impliqué –et même très impliqué, ce blog en témoigne– dans le développement de l'outil iceScrum.

J'ai quitté Kagilum, la startup dédiée à la diffusion d'iceScrum, il y a 4 ans et je me suis converti, un peu plus, au management visuel physique.

Mes anciens étudiants ont continué leur chemin avec iceScrum. Je viens de visiter leurs nouveaux locaux, dans un lieu convivial très sympa : Ô local. Avec babyfoot.

À cette occasion, ils m'ont fait une démo de la nouvelle version d'iceScrum, la R7, peaufinée depuis si longtemps. Ça a l'air pas mal au niveau UX.

Ils m'ont aussi montré la Kagibox, une boite avec plein de trucs pour le management visuel physique. Belle idée pour tenter de concilier outil et note collante.

Séduit par les locaux, je vais y organiser mon prochain Cube "Prioriser, estimer et planifier", le 23 février matin. Et pour 3 billets achetés, j'offre une Kagibox. De quoi bien affiner et estimer en équipe.

La boiboite qui vous attend dans la salle de formation ô local :

ô boite ô local

Critères VRAC pour la priorité dans le backlog

Les critères VRAC

Lire la suite...

Expérimentations pédagogiques

Quand j'étais prof à la fac, j'avais expérimenté pas mal de façons d'enseigner avec les étudiants de l'IUP ISI. Mais j'ai arrêté la fac.

Cependant je donne toujours des formations et je continue à expérimenter.

  • Cela fait des années que je fais du #noSlides.
  • Avec Pablo, nous avons lancé le Raid Agile et cela dure depuis quelques saisons. Une formation vraiment différente.
  • En fin d'année dernière, j'ai organisé le premier Cube à Toulouse. Bientôt le 2e, qui porte sur Estimer, pour prioriser et planifier. Le concept 1CUBE&GO repose sur une pédagogie modulaire originale.
  • One step beyond. Demain je participe à mon premier WalkingDev avec Stéphane : Détournons GitHub.

- page 2 de 131 -