Rétrospective Agile #1 – Le Speed Boat

En agilité, la rétrospective est une des cérémonies les plus importantes se déroulant à la fin de chaque sprint (itération).

Le but étant de faire le point avec l’équipe sur ce qui a été fait lors du dernier sprint en positif ou négatif afin d’en définir des actions d’amélioration pour les sprints suivants.

La rétrospective est donc un élément clef du principe d’amélioration continue rendant une équipe auto-apprenante.

Les rétrospectives peuvent se faire de mille et une façons différentes et se découpent en plusieurs étapes.

Cet article présente une de ses façons : le Speed Boat.

Etape 1 : dessine-moi un … bateau ?

La première chose à faire est le dessin du fameux bateau, c’est en général le Scrum Master qui met à profit ses talents artistiques mais il peut tout à fait en être autrement avec un volontaire (ou alors imprimer un dessin tout fait sur le net).

blog ai3 01 Rétrospective Agile #1 - Le Speed Boat

Le dessin ressemble approximativement à ceci.

Le Scrum Master va ensuite expliquer à l’équipe ce que représente le dessin.

blog ai3 02 Rétrospective Agile #1 - Le Speed Boat

1 – Les propulseurs : Les actions / choses qui font avancer l’équipe à accomplir les objectifs du sprint (ex : Bon esprit d’équipe, bon niveau technique, serveur de tests)

2 – Les ancres : Ce qui a ralenti l’équipe durant le sprint (parfois chaque ancre représente les freins passés, présents et futurs) (ex : vacances, changement de PO).

3 – Les obstacles : Les risques/obstacles que l’équipe va potentiellement rencontrer dans le futur (ex : pas de budget, gel des MEP)

4 – Scrum Team : Le bâteau représente l’équipe et son travail

5 – Sprint Goal : L’île paradisiaque représente les objectifs à atteindre du sprint

Etape 2 : Réflexion et partage

L’équipe entière aura ensuite quelques minutes (généralement 5 min) pour noter les faits marquants sur des post’its. Une fois que tout le monde aura terminé, chacun viendra positionner ses post’its à l’endroit adéquat en expliquant son choix.

Niveau post’its le SM a le choix entre :

Option 1 : une couleur unie pour tous les faits

Option 2 : une couleur par type de fait (Propulseurs, Ancres ou Obstacles)

blog ai3 03-1024x574 Rétrospective Agile #1 - Le Speed Boat

Etape 3 : Actions

Le Scrum Master et l’équipe prendront soin de regrouper les post’its de même sujet.

L’équipe choisira à partir de là et en fonction des capacités des actions à effectuer pour améliorer le prochain sprint.

Ces actions seront écrite sur post’its d’une autre couleur et collées sur les problèmes concernés (ou sur les propulseurs que nous pouvons encore améliorer).

blog ai3 04 Rétrospective Agile #1 - Le Speed Boat

Par exemple sur une ancre « Changement de PO » le plan d’action nécessaire pour palier au ralentissement serait peut-être d’effectuer un On-boarding Agile et fonctionnel rapide.

Avant la fin de la rétro, chaque tâche se verra affectée d’une personne (volontariat) qui se chargera de la traiter au prochain sprint.

Au sprint suivant, un point sur les actions sera fait pour s’assurer d’être le plus efficaces possible.

—————————–

Et voilà, très simple, n’hésitez pas si vous avez des questions. Il en existe plusieurs variantes dont certaines avec les objectifs sur le cocotier ou un soleil représentant les gratitudes, à vous de faire comme bon vous semble 😉

WSJF : Priorisez simplement votre backlog

Qu’est ce que le WSJF ?

Le WSJF « Weighted Shortest Job First » : il s’agit d’un système Agile de priorisation qui vise à effectuer les US (ou features, epics tout dépend de la couche qu’on veut prioriser) dans un ordre optimisé .

L’algorithme utilisé se traduit graphiquement comme ceci :

 

blog ai3 1 WSJF : Priorisez simplement votre backlog

Le but étant de faire dans l’ordre :

  • les US non complexes mais avec une forte valeur
  • Les US complexes mais avec une forte valeur
  • Les US non complexes mais avec une valeur moindre
  • Les US complexes avec une valeur moindre (bien souvent, ces US ne sont jamais faites et finissent par être annulées côtés client car elles ne rapportent pas assez par rapport au coût)

 

Quand l’utiliser ?

Tout comme l’agilité, il faut savoir s’en servir à bon escient. Tous les projets ne sont pas faits pour être conduits en Agile, ils ne sont pas tous bons à prioriser en WSJF.

Il est surtout bon de l’utiliser quand le projet n’a pas de priorités précises ou si vous trouvez qu’elles ne sont pas justifiées.

Quoi qu’il en soit, le résultat n’est pas gravé dans le marbre, il ne permet d’avoir qu’une ligne directrice. A voir ensuite avec le PO pour ajuster à sa convenance.

 

Qui participe à l’atelier ?

  • Le PO
  • Le SCRUM MASTER
  • La Dev Team (toujours bon pour les devs d’avoir un point de vue business sur les US et inversement)

 

Calcul du Cost Of Delay

Le cost of delay est comme son nom l’indique l’impact qu’aura le temps sur le coût de chaque US.

Il se calculera sur 3 axes :

  • La Business Value
  • La Criticité
  • Réduction des risques / Facilitation développement d’une autre US

Pour le calculer, le plus simple est d’utiliser les cartes de planning poker comme ceci :

 

blog ai3 2 WSJF : Priorisez simplement votre backlog

LE PO place ensuite les US sous les valeurs correspondantes.

Si le départ est compliqué car trop vague, il faut essayer de repérer une ou deux US moyennes pour s’en servir comme base de référence.

Cette méthode permet d’avoir une vision d’ensemble et de pouvoir facilement comparer les US entre elles et les revaloriser.

Une fois toutes les US évaluées dans un axe, notez la valeur obtenue pour chacune et effectuez la même chose pour les deux axes restants.

 

Business Value :

US 1

3

US 2

40

US 3

0,5

US 4

8

US 5

13

US 6

13

Etant donné que la manipulation peut être très longue et redondante suivant les intervenants, le dernier axe (Réduction des risques/facilitation développement) est parfois supprimé.

En additionnant la valeur obtenue pour ces trois axes on obtient le Cost Of Delay.

 

Calculer le WSJF

Pour calculer la valeur WJSF permettant d’ordonner les priorités, il vous faut le Cost Of Delay mais également vos compléxités.

Pour cela trois solutions :

  • Soit la DEV Team a effectuer un planning poker en amont et a donc pricé l’ensemble des US (attention, il ne faut pas que le PO voit ses valeurs avant d’effectuer ses choix pour ne pas être influencé)
  • Soit la complexité se calcule de suite de la même manière que les trois axes précédents par la DEV TEAM (mais celle-ci risque d’être influencé par les choix PO)
  • Soit un planning poker sera effectué plus tard par la DEV TEAM (mais celle-ci risque d’être influencé par les choix PO également)

Selon moi, la meilleure solution reste d’effectuer un planning poker avant de venir en atelier WSJF mais de cacher les résultats au PO dans la premier temps.

Une fois la complexité de chaque US effectuée, calculez le WSJF comme suit :

WSJF = Cost Of Delay / Complexité

Une fois que toutes les US ont une valeur WSJF, il suffit des les trier dans l’ordre décroissant pour obtenir les priorités :

 

blog ai3 2 WSJF : Priorisez simplement votre backlog

blog ai3 3-1 WSJF : Priorisez simplement votre backlog  blog ai3 4 WSJF : Priorisez simplement votre backlog

 

Exemple de valeurs :

US

Business Value

Criticité

Opportunité/Risks

Cost of delay

Complexité

WSJF

US 1

3

2

1

6

80

0,075

US 2

40

8

1

49

3

16,34

US 3

0,5

40

20

60,5

8

7,56

US 4

8

2

3

13

1

13

US 5

13

3

1

17

5

3,4

US 6

13

0,5

1

14,5

13

1,11

 

L’ordre serait donc le suivant :

US 2

US 4

US 3

US 5

US 6

US 1

 

Ce qui dans notre courbe représente :

blog ai3 5 WSJF : Priorisez simplement votre backlog

Comme on peut le constater, les US 2,5 et 4 sont à effectuer en premières. Exception faite de l’US 3 qui a été ajoutée à cause de son impact Risque/Dépendance (on peut imaginer qu’elle est nécessaire pour faire le reste).

L’US 6 vient ensuite pour finir par la 1 qui est trop complexe par rapport à ce qu’elle apporte.

Cet ordre est donc le plus optimisé entre plusieurs facteurs clés et les US seront donc traitées dans ce sens.

Le PO peut tout de même faire des ajustements s’il trouve que cela est nécessaire.