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

jeudi 29 mars 2012

ScrumDay2012 : "Scrum Master Academy" par Gilles Mantel et Jean-Laurent De Morlhon

Etant un aspirant Scrum Master, j’ai tout de suite été intéressé par cette conférence.

Xebia est une SSII qui propose des formations certifiantes de ScrumMaster. Cette certification fait d'ailleurs l'objet d'un débat au sein de la communauté Agile sur le bienfondé d'une certification à un poste dont les compétences relèvent plus de la pratique et de l'expérience, plutôt que d'une somme de connaissances.

Et le constat sur le terrain des deux orateurs ne fera pas mentir cette polémique. Il faut d'ailleurs beaucoup de courage pour admettre qu'un produit vendu par sa propre société (les formations certifiantes) ne fournit aucune garantie de produire de bons ScrumMasters. Attention, je ne dis pas que les personnes issues de ces formations ne sont pas compétentes, beaucoup le sont même certainement et je compte moi-même dans un avenir proche participer à une telle formation. Mais le succès du rôle de ScrumMaster demande d'avoir été un certain temps au contact des problèmes et parfois d'avoir échouer pour pouvoir rebondir et apprendre de ses échecs. Beaucoup de monde oublie qu'ils dévient de l'agilité en se focalisant trop sur l'application stricte ("by the book" comme on dit) de Scrum.

C'est via leurs observations sur le terrain que Gilles Mantel et Jean-Laurent De Morlhon ont tiré ce constat : certaines erreurs sont commises par des ScrumMasters, dues à l'inexpérience ou simplement car ceux-ci n'avaient jamais rencontré telle ou telle situation problématique. Les réponses apportées pouvant causer du tort au projet et/ou à l'équipe.

Les deux orateurs, qui sont des coachs agile aguerris, nous proposent donc une conférence organisée en une liste de règles à appliquer au jour le jour dans votre role de ScrumMaster. Celles présentées lors de la session étaient toutes pertinentes et pas mal d'entre elles tenaient presque du bon sens ("Connaissez vos valeurs agiles", "Transparence et pas indécence"). Le temps imparti était trop court pour passer en revue la totalité des règles qu'ils ont créées (une cinquantaine en tout). Ils se sont donc restreint à une quinzaine considérées comme importantes et les ont classées en deux catégories : les règles à appliquer en rythme de croisière et les règles de crise, qui court-circuitent parfois celles citées plus tôt dans les slides mais justifiées par le contexte.
La présentation de chaque règle est agrémentée d'exemples de situations vécues et ensuite du scénario de déblocage de celle-ci via l'application de la règle en question. Un point important sur lequel ont insisté les deux coachs était que ces règles ne devaient pas faire office de parole divine.
Lorsqu'en tant que ScrumMaster, on prend de la bouteille, on saura de mieux en mieux désamorcer les situations et sortir des impasses. C'est votre expérience et votre style qui fera de vous un bon ScrumMaster. Par contre, ces règles constituent une très bonne base de départ pour quelqu'un fraichement sortie d'une formation CSM.

La FrenchSUG devrait mettre en ligne la vidéo de cette conférence, je vous encourage fortement à la visionner (je mettrai le lien ici quand elle sera disponible). La présentation est très drôle dans la forme et la Scrum Master Academy a tenu ses promesses : de loin, on dirait un show d'un duo comique; de près, on apprend beaucoup de choses !

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

mercredi 28 mars 2012

Lendemain de Scrum Day 2012

Et voilà, lendemain de Scrum Day et retour au bureau sur mon petit projet en Scrum.

Quel bilan tirer de cette journée ? Du bon, et même de l'excellent, mais parfois du pas très bon... En tout cas, ce fut une journée enrichissante et surtout dense (1 keynote + 2 conférences le matin et 3 conférences puis la keynote de cloture l'après-midi).

Comme d'habitude, c'est toujours un horrible choix cornélien que d'avoir des conférences auxquelles vous aimeriez assister mais programmées à la même heure dans des salles différentes !
Heureusement la FrenchSUG proposera les conférences en vidéo d'ici peu (j'espère très vite :)

Le centre de congrès était classe (forcément, vu le quartier...) et j'ai reconnu des têtes que j'avais croisées à l'Agile Tour.

Globalement :
- une keynote du matin en anglais et un Maarten Volders qui parlait assez vite. Shame on me, je n'ai saisi qu'à peu près 80% du discours;
- un scrum day tourné vers le jeu (game storming, innovation games) pas seulement pendant le keynote mais aussi lors d'autres conférences, chose à laquelle je ne m'attendais pas mais ce fut un sujet plaisant;
- les locaux étaient petit pour 500 personnes, surtout à l'heure du déjeuner où il fallait jouer des coudes;
- dommage que certains ateliers se déroulaient sur plus de 2 heures, ce qui équivalait à manquer 3 conférences !

Je ferai des feedbacks des conférences qui m'ont marqué plus en détail bientôt dans ce blog :)

ROTI : 4

lundi 19 mars 2012

En route pour le Scrum Day 2012

Le mardi 27 mars 2012 aura lieu le Scrum Day 2012 aux Espaces CAP 15 à Paris.

Comme pour le dernier Agile Tour, je tâcherai de faire un retour sur les conférences auxquelles j'aurai pu assister et qui m'auront marqué.

Au menu, des retours d'expérience, du management, du Scrum avancé et des ateliers.

Comme la dernière fois, mon twitter pour me suivre au fil de la journée @HingCChan

samedi 3 mars 2012

Lecture : "Agile Retrospective Making Good Teams Great" d'Esther Derby et Diana Larsen

Dans la méthodologie Scrum (et en Agile), la rétrospective est un des rituels les plus importants, voire le plus important. Les problèmes liés au projet et/ou à l'organisation y sont détectés par l'équipe, discutés et des actions y sont proposées pour améliorer le processus de développement. Consacrer un livre entier à ce rituel semble donc cohérent.

Le livre "Agile Retrospective Making Good Teams Great" se présente comme un mode d'emploi de la rétrospective.
Supposons que vous êtes un ScrumMaster qui cherchez à redynamiser une équipe que la routine a un peu endormi. L'équipe ne participe pas autant qu'avant lors des rétrospectives et vous avez besoin de nouveauté pour revigorer leur intérêt. Ce livre vous permettra d'y faire votre marché dans les différentes formes d'activités pour conduire les phases successives de la rétrospective et apporter du changement, suivi, on l'espère, d'un souffle nouveau.

La première partie du livre passe en revue rapidement l'ensemble du processus du rituel au travers des différentes étapes (set the stage, gather data, generate insights, decide what to do, close the retrospective).
Avec des exemples à l'appui, cela nous donne une idée de la rétrospective "de base". Bien sûr, elle ne doit pas se dérouler de la même façon dans toutes les équipes et les situations, sinon on n'aurait besoin que d'un robot =)

Les deux parties qui suivent donnent justement des conseils pour adapter sa façon de diriger une rétrospective en prenant en compte les spécifités de l'environnement où vous intervenez.

Pour adapter, et donc customiser le déroulement de votre rétrospective, les auteurs donnent ensuite une énorme liste d'activités, ceci pour l'animation de chacune des étapes du rituel. Personnellement, j'ai reconnu des activités déjà appliquées sur d'anciennes missions : - ESVP pour "set the stage", timeline pour "gather data", brainstorming pour "generate insights", SMART Goals pour "decide what to do", ROTI pour "close the retrospective". La richesse du livre est donc de proposer tout un tas d'autres activités pour redynamiser votre équipe et casser la routine instaurée par n rétrospectives d'itérations qui, en se ressemblant toutes, risquent de lasser votre équipe. Chaque activité est à appliquer selon la réaction que vous souhaitez provoquer dans l'équipe.

Puis les auteurs finissent sur une partie, très succincte, qui va plus loin, mais sans entrer dans le détail, en parlant des rétrospectives de releases ou de projets.

Le livre dans son ensemble est axé tant sur des techniques de conduite du rituel que sur la gestion humaine et il conclut en une partie plutôt ciblée coaching et psychologie pour tout ce qui touche à la conduite du changement ou au support.

Comme je le disais, ce livre peut être utilisé comme un livre de recette pour y piocher des activités selon vos besoins ou vos envies. C'est une lecture très intéressante, mais pas forcément à parcourir en un trait donc. Il y a une bonne quantité d'activités à proposer à son équipe pour casser une éventuelle routine.