samedi 31 mars 2012

Scrum Day 2012 : "Le jour où Josiane sauva notre projet" par Nicolas Jozwiak et Nathaniel Richand

Le titre est intriguant au premier abord : on pourrait penser que Josiane est une super développeuse ou scrummaster ou coach agile qui serait intervenu et aurait sauvé le projet en 4 mois. Ce n'est pas exactement ça. Mais cette personne, ou plus justement ce persona, a eu une importance toute particulière au sein du projet dont Nicolas Jozwiak et Nathaniel Richand nous font le retour d'expérience.

Tout d'abord, il faut situer le contexte :
- un projet en crise commencé 8 mois plus tôt mais qui part en effet tunnel.
- des acteurs (métier, managers, développeurs) qui ne s'entendent pas sur la vision du produit.
- une deadline archi non négociable.

Nicolas et Nathaniel sont alors appelés pour intervenir sur ce projet et redresser la situation. Avec leur expertise de l'Agile et Scrum, ils mettent alors en oeuvre les outils à leur disposition pour identifier les problèmes et les résoudre, afin de permettre à leur projet de vivre. Parmi les outils présentés tout au long de leur conférence, on trouve l'emploi de product box, de story mapping, de timeline, et surtout Josiane.

Mais alors, qui est Josiane ? Car elle figure bien au titre de leur conférence.
Josiane est un persona, un personnage de fiction qui représente l'utilisateur qui accèdera à l'application. On lui attribue certaines compétences qui doivent être représentatives de l'utilisateur final lambda. C'est d'autant plus important lorsque, comme c'est leur cas, vos utilisateurs sont extérieurs à la société. Ils ne sont pas aussi disponibles que des utilisateurs internes vers lesquels on pourrait se tourner à tout moment pour poser des questions ou obtenir des précisions. Ils ne transigeront pas avec les fonctionnalités proposées et le risque est de les voir partir vers la concurrence s'ils ne sont pas satisfaits.

Le but est donc de bien comprendre les attentes de ces utilisateurs.
Et c'est là que se situait le problème : chaque acteur du projet avait une vision différente de la définition du produit qui serait proposé. Chacun voyait des fonctionnalités indispensables de son point de vue mais différentes du point de vue des autres parties.

Josiane a permis à tout le monde de parler la même langue si on peut dire. Josiane peut être vue comme un canal de communication entre des acteurs avec des compétences différentes et des connaissances différentes. Elle servait de référence pour que chacun utilise le même point de vue utilisateur et s'entende sur ce qui était prioritaire et/ou indispensable pour le produit.

Bon, le duo n'a pas utilisé que Josiane pour remettre en selle leur projet. Le concept de MVP (Minimum Viable Product) a permis de prioriser les fonctionnalités réellement indispensables pour leur deadline et les ateliers product box ont été utiles au début pour permettre à chacun d'exprimer sa propre vision du produit fini et la partager avec les autres. Mais l'artefact qu'est Josiane (et d'autres personas) semble être le pilier qui a permis à tout le monde de se comprendre et ensuite de travailler pour aller dans le même sens.

Aujourd'hui, le projet n'est pas bouclé à 100% mais il a été livré à la date souhaitée avec les fonctionnalités indispensables permettant acceptation du produit.
Ce projet prend l'allure d'une aventure avec des hauts et des bas. Elle inspirera peut-être des personnes qui se retrouveraient dans une situation similaire et pourrait utiliser leur Josiane...

En tout cas, la conférence fut un très bon moment, comme un bon film avec une happy end :)

ROTI : 5/5

Ce feedback est également disponible dans une version retravaillée avec Thierry Leriche sur son blog sur developpez.com

2 commentaires:

  1. Quel est pour toi le principal point qui fait qu'une tel méthodologie puisse reussir et surtout comment faire accepter ce "coup de pocker" au décideurs du projet?

    RépondreSupprimer
    Réponses
    1. Clairement, il faut que la hiérachie joue le jeu. Les décideurs ont suivi ces deux coachs car ils avaient confiance en eux. Ceci parceque Nicolas et Nathaniel avaient eu des succès auparavant sur d'anciens projets.
      Donc le contexte étaient particulier et n'importe qui ne pourrait pas faire passer le même genre de coup de poker chez son client.

      Ensuite, sur le concept de MVP, il faut que le client accepte aussi de prioriser son backlog et renonce à certaines fonctionnalités.
      Si un client vous dit "je veux tout, tout est indispensable", alors vous n'êtes pas sorti de l'auberge...

      Supprimer