Ca Scrum !

Nous venons de démarrer ce matin le dernier Sprint de la release 1 du projet Marguerite. Je voulais organiser un jeu/évènement afin que l’équipe reste focalisée sur la qualité du produit et qu’elle réflechisse à la gestion des risques. Ayant découvert récemment le jeu « Remember the Future« , je voulais organiser un jeu placant l’équipe 1 semaine après une mise en production « ratée » de notre produit et que l’on cherche les causes de cet échec.

Je partage cette idée avec notre « Super P.O » qui trouve cette approche « anxiogène » à quelques jours d’un évenement important. Je repars un peu frustré. Quelques jours plus tard, je tombe sur Alex qui se promenait dans notre entreprise et je lui raconte cette histoire.

Moi : « Ben, euh, il parait que c’est anxiogène comme idée, t’en penses quoi »

Alex : « Faut pas faire un Remember the Future, mais un Pré-Mortem ! »

 

Motivé, gonflé à bloc et persuadé que c’est bon pour le produit et pour l’équipe, je décide d’organiser tout de même ce jeu. Je trouve sur le net cet article très intéressant, surtout illustré par ce dessin :

 

 

 

 

 

 

 

 

 

 

Je décide donc de commencer notre Sprint Planning Meeting (exceptionnellement plus long que d’habitude) par ce jeu.

1 – J’accueille l’équipe dans la salle avec une affiche collée au mur où il est écrit « Que s’est-il mal passé » ?

2 – J’explique le but du « jeu ». L’équipe est réunie autour de la table sur laquelle une frise chronologique est dessinée. 2 dates sont inscrites : Le soir de l’installation et le lendemain matin 7h, heure de première utilisation du produit. Chaque membre de l’équipe a son tas de Post-It, un stylo et 5 minutes pour laisser libre court à son imagination sur ce qui pourrait mal se passer … et à quel moment.

3 – Nous faisons une lecture commune de la frise chronologique, nous supprimons les doublons, les blagues (Effectivement, c’est mal s’il n’y a pas de croissant le lendemain matin … Mais peut-être pas critique :p)

4 – Chaque membre de l’équipe a maintenant en main des gomettes pour marquer sur les Post-It les évènements qui lui parait critique pour l’application.

5 – Une fois les évènements priorisés par criticité, l’équipe échange sur les solutions que l’on peut mettre en place MAINTENANT (durant ce dernier Sprint). Le P.O étant présent, il convient que ces actions sont plus prioritaires que les dernières fonctionnalités attendues : Les Story sont donc rajoutées au backlog de produit et mis dans le Sprint Backlog.

Pour que ces actions soient bien visibles, nous dessinons une nouvelle frise chronologique … D’aujourd’hui à la date de mise en prod ! Sur cette frise, nous placons à la fois les actions à faire durant le Sprint, mais aussi celles qui ne sont pas des actions de création du produit mais importante pour la réussite du projet (Formation, prise de contact, administration des serveurs, …) .

Petite rétro de cette nouvelle expérience : l’équipe n’a pas du tout semblé angoissée par ce jeu, au contraire : les craintes, les doutes sont exprimés … Avant la fin du projet, ce qui était bien le but recherché. Mon seul « regret » et d’avoir fait ce jeu un peu trop tard : il aurait peut-être été plus efficace 1 ou 2 Sprints plus tôt.

PS : Alex, pour te remercier de ton soutien, tu noteras que cette fois, l’article est illustré de plusieurs photos :)