samedi 16 mars 2013

Scrum Night IV : Et alors ce petit prince ?


Choses promises, choses dues... Je vais vous faire ici un retour sur le jeu Agile "le Petit Prince" que nous avons présenté avec Tony Blanchard à l’occasion de la Scrum Night IV.

Je tenais avant toute chose à remercier les nombreux participants à cet atelier, car nous avons fait salle comble. Il semblerait que le mystère entretenu par le nom du jeu ait piqué la curiosité de certains.


Avant de débuter, je vous demande de m'excuser, mais dans le feu de l'action j'ai complètement oublié de prendre des photos. Je vais essayer de faire des reconstitutions pour illustrer le billet, mais ce ne seront malheureusement pas les photos de la Scrum Night. 

C'est l'heure, on va commencer...


Après les présentations d'usage, nous débutons la séance. Etant donné que nous avons une quinzaine de participants, nous décidons avec Tony de changer un peu nos plans, et de couper la salle en deux. Le jeu sera joué par 2 groupes en parallèle, et un débriefing commun sera fait à la fin.

Je me retrouve donc avec un groupe de 7 personnes un grand tableau blanc et quelques feutres. Nous pouvons entrer dans le vif du sujet...

Première étape, distribuer les rôles. Il nous faut un utilisateur/client (là ce sera moi), un Product Owner et un développeur. Le reste du groupe se positionnera en observateur, ils participeront à la rétrospective. Le développeur se positionne face au tableau de façon à pouvoir dessiner, et le Product Owner tourne le dos au développeur et au tableau. Product Owner et développeur doivent pouvoir facilement s'entendre, mais ne doivent pas se voir.


Les préparations faites, nous sommes prêts à commencer. Je m'approche du Product Owner et en tant que client je lui exprime mon besoin (sous forme d'un dessin), je lui demande de se charger de le faire réaliser par l'équipe de développement. Pour cela il a 5 minutes, tic, tac, tic, tac...

Il faut noter ici que le dessin qui est donné au PO est sur une page A4 en orientation portrait, et que la surface de dessin du développeur est un grand tableau en orientation paysage. Ceci et très important pour la suite, mais ne doit pas être signalé aux participants.

La description du Product Owner est faite très rapidement. En 3 minutes, il a parlé de tous éléments du dessin. Le développeur avait beaucoup de mal à suivre de rythme, mais ne disait rien. Quand la Product Owner a vu qu'il avait de l'avance, il est revenu sur certains détails. Biiiiiip, ça fait 5 minutes, on arrête tout, le client reprend le dessin au Product Owner et on passe à la demo.

Comme pour toute approche Scrum, on invite plein de personnes pour la démonstration, le client, le Product Owner qui peut alors se retourner, etc...

<< Photo à venir >>

On demande alors au Product Owner de donner une note de satisfaction pour le résultat de cette itération. Après un peu d’hésitation le couperet tombe, 8/20. Le client prend alors la parole en confirmant la note de satisfaction, pour lui cette livraison ne vaut pas plus de 7/20.

L'étape suivante est bien sûr une rétrospective. Il faut être capable de faire mieux pour l'itération suivante. Pour la rétrospective tout le monde peut participer, développeur, Product Owner, et observateurs.
Dés les premières secondes de la rétrospective, il est ressorti qu'il ne fallait pas tout mettre sur le dos du développeur et qu'il fallait trouver les causes du problème. Je vous passerais ici toutes les discussions, mais le point le plus important est qu'ils sont allés voir le client pour lui demander d'expliquer sa note et sur quoi il se basait pour la donner. Le client leur a donc donné ses conditions d'acceptation pour ce sprint :

  • le dessin doit prendre toute la surface disponible (divise la note par 2 si pas la condition n'est pas respectée)
  • il doit y avoir un mouton dans une (4 pts)boîte
  • 2 trous de la boîte doivent être au-dessus du mouton (3 pts)
  • 1 trou doit être à moins de 5 cm du bord gauche de la boîte (3 pts)
  • l'herbe doit toucher le bord droit de la zone dessin (3 pts)
  • la boîte doit être centré dans la zone de dessin (3 pts)
  • la tête du mouton doit être au-dessus de l'herbe (3 pts)
  • Il doit y avoir au moins les 3 éléments de décors suivants : un arbre, une montagne, un nuage. (1 pt)

Les conditions d'acceptation ont été notées sur le tableau pour que le développeur les ait sous les yeux. L'équipe à ensuite continué à réfléchir et a mis en place le plan d'action suivant :

  • A la moitié de l’itération, on effectue une revue intermédiaire, le Product Owner pourra se retourner 10s pour voir le travail du développeur.
  • Les observateurs qui eux voient le dessin se construire peuvent intervenir pour signaler une erreur d'interprétation
  • Le développeur doit poser des questions au Product Owner

Fort de toutes ces informations, tout le monde se remet en place. Le client demande si tout le monde est prêt... C'est parti, on donne un Product Owner le dessin de la seconde itération et on recommence. Le développeur commence par un travail de rework de l’itération 1 pour essayer de respecter les conditions d'acceptation. Il est fortement aidé par un observateur qui prétexte qu'on avait dit qu'il n'avait pas le droit de dessiner, mais qu'on n’avait jamais dit qu'il ne pouvait pas effacer. Il y en a qui osent tout, et ça marche.


À mi-itération le Product Owner se retourne, et on continue...

<< Photo à venir >>

Au bout de 5 minutes, on refait la démonstration. La note du Product Owner est de 14/20, c'est beaucoup mieux. Par contre le client se manifeste en indiquant que pour lui ça ne va pas du tout. Sa satisfaction est de 7/20.

L'équipe avait en effet bien toutes les conditions d'acceptation du sprint 1, mais le Product Owner n'a pas pris le temps de lui demander les conditions d'acceptation du sprint 2. Pour ce sprint le client souhaitait avoir des éléments de volume ou d'ombrage sur le mouton, s'ils n'y sont pas la note est divisée par 2.

Nous avons conclu la séance par un débriefing entre les deux groupes, et une lecture d'un passage du Petit Prince, qui colle parfaitement au sujet.

Mon analyse

Je dois dire que j'avais affaire ici à un groupe particulièrement efficace, qui ne s'est pas laissé avoir par les apparences et qui a réellement cherché les causes des problèmes.

En effet les 2 notes très proches à la fin du premier sprint, auraient pu laisser penser qu'il n'y avait qu'un seul problème. Malgré cela, ils ont cherché toutes les causes, à savoir un problème de communication entre le Poduct Owner et le client (d'où la mauvaise note du client), et un problème de communication entre le Product Owner et le développeur (d'où la mauvaise note du PO). Pour traiter le 1er point, ils ont pensé à demander au client ses conditions d'acceptation. Pour le 2eme point, ils ont réfléchi à un plan d'action permettant d'identifier au plus tôt les écarts.

Selon moi, la seule erreur qu'ils ont commise est d'oublier de demander au client ces conditions pour la 2eme itération.

Autre petit retour d’expérience

Pour de la préparation de la Scrum Night, j'ai fait tester le jeu du Petit Prince à un groupe en formation. A la fin de la 1ere itération, ils ont obtenu les notes suivantes PO : 14/20; client 1/20.

Lors de leur rétrospective, ils ont beaucoup discuté sur les façon d'améliorer la précision de la communication entre PO et développeur.
  • Définition d'un vocabulaire commun
  • Définition d'un Système de coordonnées pour placer plus précisément les objets
Tout cela est bien sûr important, mais le groupe ne s'est pas concentré sur le bon problème. La note du PO était bonne. Ce n'est donc pas entre le PO et le développeur qu'il y a un problème, mais plutôt avec le client.


 


2 commentaires:

  1. Je vois dans ce jeu l'illustration de ce qui n'est pas rare il me semble: il ne faudrait pas (voeux pieux) se laisser prendre par le stress de l'insatisfaction du client et/ou du product owner (auxquels on voudrait souvent faire plaisir!), pour réussir à prendre assez de recul tout en gardant le cap... A l'aide le scrummaster?! Car au final l'amélioration de l'existant, qui focalise souvent beaucoup les énergies, est perçu par le client comme "un dû" et n'a pas la part la plus belle dans la note finale...
    Comment faire apprécier tout le travail accompli?
    Aline (qui a suivi la formation)

    RépondreSupprimer
  2. Je pense que la question réel à se poser n'est pas "comment faire apprécier tout le travail accompli ?", mais plutôt "Comment réaliser un travail qui sera apprécié ?". Et pour cela il faut connaitre les attentes réelles de notre client, pour ne pas s'éparpiller et ne pas réaliser des choses qui ne seront pas appréciées à la hauteur du travail fourni. C'est ce que tente de mettre en evidence ce jeu.

    RépondreSupprimer

N’hésitez pas à laisser des commentaires, pour faire part de retours d’expériences sur le sujet, pour exprimer votre accord ou votre désaccord, ou tout simplement pour poser une question. C'est toujours avec plaisir que je vous répondrai.