Archives mai 2014

Construisez votre Roadmap à l’aide du Gamestorming

Le jeu de l’oignon
Le jeu de l’oignon

Ce billet est l’œuvre d’un blogueur invité, Frédéric Vandaele.

Bonjour à tous et ravi d’avoir l’opportunité d’échanger avec vous via ce blog.

En tant que consultant dans les institutions internationales, mon métier de coach agile m’a amené récemment à faciliter une session de planification sur un important projet pluriannuel. Ce projet a démarré avec un objectif apriori clair. Depuis, quelques mois se sont passés et la gestion de priorités devient de plus en plus difficile, que ce soit pour le responsable produit comme pour l’équipe.

Avec les nombreux éléments  à mettre en place en début de projet, l’équipe s’est naturellement focalisée sur les problématiques à court terme en perdant de vue la vision globale. Il était à ce moment important de remettre la partie métier au cœur des préoccupations.

Le chef de projet m’a donc contacté pour animer un atelier spécifique avec les ‘décideurs’. Cette session avait pour objectif d’identifier, construire et visualiser la feuille de route du projet pour les prochains mois et prochaines années.

Pour cet atelier, j’ai privilégié une approche basée sur les interactions entre les personnes, la transparence, la créativité et la communication au sein du groupe: le gamestorming.

Customer-Centric

Le premier exercice (http://www.gogamestorm.com/?s=onion – Customer-Centric) nous a permis de guider le développement de notre produit par l’identification de l’ensemble des personnes concernées. Non seulement celles qui vont utiliser le produit mais également toutes les personnes qui pouvaient être impactées – même de façon indirecte – dans leur travail.

Pour cela, on a représenté sur une grande feuille une série de 4 cercles

Le jeu de l’oignon
Le jeu de l’oignon: Les participants ont identifiés beaucoup d’intervenants en zones périphériques

Les participants ont identifiés beaucoup d’intervenants en zones périphériques

Les participants ont identifiés beaucoup d’intervenants en zones périphériques

concentriques libellés comme suit:

  • Le produit
  • le système – intervenants direct
  • le système environnant – intervenants du système, même si ils n’interagissent pas directement avec lui et
  • l’environnement large – les intervenants en dehors du système.

On a distribué des marqueurs et des post-its aux participants et on leur a demandé d’identifier les acteurs ainsi que de les situer dans chaque zones.

La « Timeline »

Le second exercice s’inspire d’un jeu qu’on utilise lors des rétrospectives: la Timeline (tiré du livre Agile retrospective de Esther Derby). La différence ici étant qu’on ne souhaite pas revenir sur l’itération passée mais qu’on veut se projeter dans le futur.

L’intérêt de la précision s’amenuisant au fur et à mesure que l’on se projette dans le futur, on a représenté une ligne du temps dont on réduit la précision au fur et à mesure que l’on se projette dans le futur. On a ainsi visualisé les 3 prochains mois, les prochains trimestres etc.

Chaque participant note sur les post-it les prochaines échéances auxquelles il pense. Chacun des participants positionne ses propositions sur la ligne de temps et les présente à l’ensemble du groupe. L’intérêt de l’exercice est à nouveau de susciter le dialogue et l’échange d’idées entre les personnes ainsi que de clarifier les choses.

Les participants ont visualisés la charge de travail pour l'équipe au dessus de la ligne de temps
Les participants ont visualisés la charge de travail pour l’équipe au dessus de la ligne de temps

L’atelier est un franc succès;  en quelques heures, les principaux jalons métier ont été identifiés et la feuille de route a été mise en place et approuvée par l’ensemble des intervenants.

A noter que le poster a été gardé sur le mur pour aider l’équipe à garder le cap sur le long terme.

On a par ailleurs observé que les post-it ont été par la suite déplacés pour représenter l’apparition de nouvelles priorités et pour visualiser les retards du projet.

Même si vos projets n’utilisent pas les méthodes agiles, une approche telle que celle-ci vous permettra d’apporter une dynamique de groupe qui donnera la bonne direction à vos développements futurs.

Un tout grand merci à Bruno pour m’avoir donné l’occasion de partager cette expérience avec vous. En espérant qu’elle vous inspire dans vos propres projets.

Agilement vôtre,

Frédéric.

@fredvandaele

Frédéric travaille chez Trasys. Praticien Agile, Il est passionné par les nouvelles méthodes de travail et les nouvelles formes de collaboration. Il intervient au sein des équipes comme coach Agile et est un speaker régulier des conférences Agiles comme en 2013 à l’Agile Tour Brussels. Vous pouvez le retrouver sur twitter (@fredvandaele)


Le Core Scrum: le noyau de Scrum.

Core Scrum...?
Core Scrum…?

Lors du dernier ScrumDay et suite à la keynote d’Allistair Cockburn, nous avons eu pas mal de discussion sur ce qu’est Scrum. Et principalement le « Core Scrum ».

Si l’on n’utilise pas des User Stories est-ce que l’on peut dire que l’on fait du Scrum ? Réponse: oui !

Si l’on ne fait pas de planning poker est-ce que l’on peut dire que l’on fait du Scrum ? Réponse: oui !

A l’inverse il y a la tendance des « Scrumbuts« . A savoir: on fait des réunions debout et on colle des post-its (et rien d’autre) peut-on dire que l’on fait du Scrum ? Réponse: non !

On ne fait jamais de rétrospectives peut-on dire que l’on fait du Scrum ? Réponse: non !

Est-ce que Scrum va répondre à tous mes besoins et problèmes ? Réponse: non ! Scrum est un framework, c’est un squelette. A vous de l’enrichir avec ce dont vous avez besoin.

Depuis quelques années il existe un document appelé le Scrum Guide qui décrit le Core Scrum. Une initiative des créateurs de Scrum.

Ce document est très utile car il résume en une dizaine de pages ce qu’est le « Core Scrum ». Si vous voulez faire du Scrum, tout est dans ce document.

SHU-HA-RI

Bien entendu Scrum peut évoluer, c’est ce qu’on appelle l’approche SHU-HA-RI un principe venant des arts-martiaux. Au début, le « SHU » on applique toutes les règles, sans nécessairement comprendre le « pourquoi » de chacune. Ensuite le « HA » on comprend profondément le pourquoi derrière chaque règle et on s’affranchit de certaines. Et enfin le « RI » on s’affranchit des règles, tout en conservant l’essence et le pourquoi.

Un des risques courant d’échec de Scrum est de commencer directement par le « RI »: on travaille comme avant mais avec les « étiquettes » Scrum.

Le Core Scrum correspond au niveau SHU.

Bonne lecture !

Bruno.