jeudi 20 décembre 2012

Une mise en oeuvre de Kanban pour l'IT - itération 1


Après un travail de quelques semaines (en délais, pas en charge), nous avons identifié le fonctionnement d'une équipe d'une dizaine de Product Owner alimentant plusieurs équipes Scrum (25 personnes) pour la réalisation de l'espace Internet de l'entreprise.

Ce travail a permis de définir les différentes phases du processus actuel permettant de créer la Backlog Produit utilisée par les équipes Scrum, et d'identifier les points d'amélioration qui pourraient amener plus d'agilité.

Un des objectifs est de forcer les Product Owners à ne pas travailler un cahier des charges en stock avant de le donner à fabriquer, mais plutôt de partir d'une "Vision Produit" avec la liste des fonctionnalités.

Cette liste est ordonnée en prenant en compte le ROI (la valeur métier divisée par la complexité de réalisation).

Les fonctionnalités seront ensuite détaillées par un travail sur les exigences, puis détaillées en User Stories.


A l'issue de cette première phase, nous avons conçu deux tableaux Kanban qui se suivent :




Le premier tableau (en jaune) correspond à des "features" Scrum (MMF - Minimal Marketable Features - en Kanban).


Le second tableau  (en bleu) correspond au redécoupage des "features" Scrum en "User Story".
 

En début d'année nous commencerons la mise en oeuvre de la méthode sur deux projets pilotes avant de généraliser la démarche à l'ensemble des projets.

Les tableaux comprennent la définition de Terminé pour chaque étape du processus ainsi qu'une limite du travail en cours (WIP - Work In Progress) dans chaque phase du processus.

Il nous reste encore à définir les cadences d'injection des éléments, à mettre en place les mêlées quotidiennes, à choisir une fréquence de réunion pour faire le point sur le fonctionnement de l'équipe et d'améliorer le processus.

La suite dans de prochains posts....

vendredi 30 novembre 2012

Scrum Café 12 : Lego4Scrum


Il y a quelques jours, nous avons joué le fameux atelier de simulation Lego4Scrum décrite sur le site http://www.lego4scrum.com/ et que j'avais joué à un rendez-vous du SUG ( le Scrum Wine Bordelais).


Ce fut une très bonne session, aussi stressante que prévue pour tous les participants.



Auto-organisation


Le Product Owner vient de présenter la liste des choses qui doivent constituer sa ville et 3 équipes de 5 personnes s’auto-organisent afin fabriquer cette ville pour le client.



L’auto-organisation se met en place avec 3 Scrum Masters.

Estimation 

Finalement les fonctionnalités de la ville sont estimées selon une technique d’estimation relative en complexité : Faible, Moyen, Complexe


Valeur métier

Les équipes ont demandé au Product Owner de classer les fonctionnalités par importance en plaçant un « 1 bleu » sur celles que je voulais avoir en premier, puis un 2 sur les autres, et enfin un trois sur celles que je ne voulais pas trop rapidement.

La complexité des fonctionnalités a été reportée à partir de la suite suivante : 
  • Faible= 2, 
  • Moyen = 5, 
  • Complexe =8


Des prototypes ont ensuite été présentés aux équipiers afin de mieux visualiser ce qu’il fallait faire.



Certains ont pensé à demander au Product Owner ce qu’il en pensait : il a tout refusé, mais l’information n’a ni été partagée avec le reste de l’équipe, ni suffisamment comprise par les équipiers.


Les itérations

La première des trois itérations a commencé et les assemblages de briques s’enchainent :
Conception du plan de la ville, premiers bâtiments produits







Rétrospective Sprint 1

« Ou est ma ville ! » crie le Product Owner dans la salle à la recherche de sa ville.
Au bout d’un moment, une timide construction vient se poser sur le terrain nu, quelques fondations décorent le bord de la table.


Un plan de la ville a pu être proposé au Product Owner qui a accepté le plan sous réserve que certaines modifications soient prises en compte


Itération 2

Le terrain est préparé et les premières fonctionnalités voient le jour :
  • Le jardin public, 
  • Les routes et intersections, 








La fin de l’itération approche : 

Les équipiers préparent le bilan du Sprint : 
  • Les fonctionnalités produites sont placées sur le terrain 
  • On déplace les post-its initialement prévus dans le Sprint de la colonne « En cours » à la colonne « Fait » 







Rétrospective Sprint 2

Cette fois, le Product Owner n’a pas besoin de demander ou se trouve sa ville :


Les fonctionnalités sont parcourues unes à une et la plus-part sont acceptées par le Product Owner qui réclame tout de même que l’herbe pousse plus vite dans le jardin public….

Sprint 3 : le dernier





La validation des fonctionnalités du Produit est faite au fur et à mesure que les fonctionnalités sont produites (ci –dessus, image en bas à droite avec Benoist et Guillaume qui présentent leur avancement de l’hôpital) : 
  • « Plus grand l’hopital » 
  • « Plus grand le lieu de culte interconfessionnel » 
  • « Plus haut les étages du bâtiment de bureaux »
Les produits sont corrigés et améliorés au fur et à mesure de leur fabrication










Rétrospective finale



Toutes les fonctionnalités sont produites en fin de jeu. La ville et belle et un peu de pelouse a poussé dans le jardin public




Débriefing

Les équipes ont désigné des Scrum Masters pour qu’ils gèrent la relation avec le client, mais ça n’a pas empêché tout le monde de lui poser des questions. Un beau bazar !

La période d’auto-organisation de l’équipe avec l’estimation de la complexité et de la valeur métier a été difficile. Tout le monde posait des questions au PO qui ne savait plus à qui répondre. Stressant !

Les sujets ont été planifiés en 3 Sprints mais sans calculer le ROI. Seule la valeur métier a été utilisée : c’est dommage, l’équipe aurait peut-être pu livrer un peu de valeur au premier Sprint avec l’abri de bus par exemple (très simple à réaliser pour une valeur métier moyenne).

Les informations données par le Product Owner ne sont pas partagées avec le reste des équipes (ex : malgré le refus des maquettes proposées, elles ont été utilisé comme modèle pour le premier Sprint.)

Les équipes ont bien géré leur temps : un chrono a été lancé pour surveiller le temps de production. A la deuxième itération, tout le monde s’est occupé d’organiser la ville sur le terrain avant la fin du temps imparti.

Le jeu a été stressant, comme prévu, pour les joueurs mais aussi pour l’animateur qui devait endosser les rôles distincts d’Animateur, Product Owner et parfois « Super » Scrum Master.


C’était prévu, mais le timing était assez serré. L’organisation des équipes nécessite plus de temps que celui accordé.

Le débriefing final a été un peu écourté également.


Atelier Prune the Product Tree


Prune the Product Tree est un des nombreux "Innovation Game" créé par Luke Hohman.



Sur la base d'un arbre dessiné sur une grande feuille de papier kraft, l'équipe a disposé des post-its sur des branches.

Les branches représentent des regroupement de fonctionnalités et les post-its les fonctionnalités.
Selon la position de la feuille dans l'arbre, on voit les fonctionnalités existantes et les celles qui devront être planifiées dans les versions suivantes. Les couleurs indiquent la technologie utilisée, si elle est obsolète ou cible.

Cet atelier se joue normalement avec des utilisateurs afin qu'ils puissent donner un feedback sur la vision qu'ils ont de votre produit.
Nous avons détourné ce jeu pour représenter quelques fonctionnalités de l'espace Internet du client. Ce travail a été réalisé à partir d'un travail réalisé en atelier pour présenter le plan stratégique annuel.

Ce jeu laisse une grande part de créativité aux participants qui peuvent placer des coeurs, des oiseaux, des fruits plus ou moins mûrs, des fruits pourris.

Il est possible de tailler des branches existantes pour supprimer les fonctionnalités qui ne rencontrent pas leurs utilisateurs etc...

mercredi 3 octobre 2012

Un atelier Product Box

Contexte de l'atelier

Dans le cadre de l'animation de l'agilité chez mon client, nous avons créé un groupe de travail "Product Owner" dont l'objectif est de partager des pratiques permettant de mieux travailler avec le métier, à défaut d'avoir des utilisateurs.
Dans ce cadre j'ai proposé de présenter les plus simples/accessibles des Innovation Games de Luke Hohmann : Product Box, Buy a feature, Spider Web, Speed Boat, Prune the Product Tree.
Après la présentation des jeux à l'équipe, un vote a permis de choisir le premier jeu (Product Box) que nous allions jouer afin de dérouler le processus complet de mise en oeuvre d'un Innovation Game.


Objectif 


Créer une boite de produit (Product Box) décrivant l'agilité afin de vendre la démarche au métier.

Etant donné que les participants sont des "Product Owner", nous sommes pas les vrais clients du produit que nous souhaitons vendre. C'est la MOA des projets (basées sur des sites différents).
Au final, ce que les équipes ont fabriqué est donc plus une "Vision Box" qu'une "Product Box".

Préparation de l'atelier

Les participants ont été invités une quinzaine de jours avant le déroulement de l'atelier afin qu'ils puissent réfléchir à l'atelier.
De mon coté j'ai pillé les fournitures chez le client est dans mon agence, je suis allé faire des achats de gomettes colorées, feutres de couleur, tubes de colle, post-its multicolores....
J'ai également préparé des boites blanches pour que chaque participant puisse réaliser sa propre boite de produit et même recommencer si besoin.


L'atelier

Le jour J, tout est prêt, nous avons 1h30 pour préparer les boites et les vendre.
Les participants un peu intimidés par l'exercice ne souhaitent pas faire leur propre boite de produit, mais ils s'organisent en 2 groupes.

Premier temps : organisation des idées
Second temps : travaux pratiques













Après 1h10 d'effort, les deux équipes ont finalisé leur produits :



boite de produit 1

boite de produit 2


Il est temps de vendre son produit aux autre participants:








Après la vente des boites par chacune des deux équipes le groupe a conclu que :

  • L'équipe 1 a bien mieux vendu sa boite de produit (le discours) que l'équipe 2.
  • Les deux Box sont très belles, mais il faudrait les mélanger pour obtenir la boite idéale
  • L'atelier a été apprécié (évaluation ROTI)  :
    • 4 votes à 5
    • 1 vote à 4


Commentaires des participants :

  • 5 ! car cela permet de définir des objectifs communs de façon ludique et c'est applicable en toutes occasions, même en dehors du contexte métier.
  • Bonne : c'est 2 ou 4 ?
  • 5 sans problème.
=> On a tous eu beaucoup de plaisir à jouer ce jeu, et nul doute qu'il nous servira à l'avenir!

La suite ...

Compiler les observations de chacun des participants, et produire les rapports qui nous permettrons de mieux comprendre notre produit, notre manière de l'envisager et de le vendre.