Scrum de Scrum et autres pratiques

Scrum de Scrum

Notre équipe projet est constituée de 3 POs, un CP et de deux équipes Scrum (11 développeurs et 2 Scrum Masters). 

Les 2 équipes fonctionnement en mode Scrum de Scrum et nous réalisons des mêlées Scrum de Scrum 2 fois par semaine. Les deux équipes se trouvent dans le même espace et la collaboration quotidienne entre les Scrum Master quotidienne et très efficace. Du coup les mêlées Scrum Scrum restent très utiles mais certaines actions/décisions sont prises en dehors de l'instance avec une meilleure réactivité que ce que nous imaginions. Sur ce point nous ne pouvons que féliciter l'excellent travail réalisé par nos deux Scrum Masters et leurs Backups!


Nous avons aussi amélioré notre communication à destination des équipes Scrum notamment par voies d'affichage : 

• La roadmap et la fiche de vision A3 du projet est affichée pour l'équipe et mise à jour régulièrement, 
• Une charte projet a été réalisée conjointement par les Scrum Master, les équipiers, les POs et notre Chef de Projet. Elle décrit les rôles et responsabilité de chacun, le fonctionnement des équipes. 
• Lorsque des compléments d'information sont demandés nous diffusions l'information à tous les membres de l'équipe et pas aux seul Scrum Masters qui devenaient des goulets d'étranglement.

Pratiques de développement 

Nous avions déjà mis en place une intégration continue et les pratiques agiles des équipes de développement continuent d'évoluer pour assurer une meilleur qualité du code.  :

• Mise en place du Pair Programming (développement en binôme)  
• Développement en TDD

Afin d'assurer la montée en compétence e tous les équipiers sur ces pratiques, nous avons un Expert eXtreme programmeur qui a intégré l'équipe. Merci et bravo à Mickael pour le sérieux et la qualité de son intervention. 

Organisation des POs

S'il est préconisé en Scrum d'avoir un et un seul PO pour un produit, ce n'est pas l'organisation que nous avons mise en oeuvre. Cela nous a exposé à plusieurs difficultés organisationnelles et de partage des documents. 

De ces difficultés est ressortie la nécessité de mettre en oeuvre des outils de travail collaboratif pour la gestion de la Backlog et des autres documents associés comme un wiki.

Management visuel et amélioration continue

L'organisation des POs

En début d'année je vous publiais un post sur notre mise en oeuvre de Kanban au sein de notre équipe de "PO". Notre objectif était de mieux suivre notre flux de production des US afin d'être en mesure d'alimenter convenablement nos équipes Scrum, de visualiser les goulets d'étranglement et d'améliorer la communication au sein de l'équipe.

Aux mêlées des POs participent : 

• Les POs - 8 personnes,
• Les Chefs de Projet - 5 personnes : exerçant parfois le rôle de PO,
• Les Coordinateurs Fonctionnel - 2 personnes : identifient les impacts entre projet et coordonnent les évolutions fonctionnelles par version (vision macro),
• Les experts métier/testeurs - 2 personnes : aident les POs à la conception fonctionnelle et renforcent leur capacité de test de fin de Sprint. Leur feedback sur la logique métier et le fonctionnel est très précieux,
• Un représentant de l'équipe de graphistes / intégrateurs Web,
• Deux architectes techniques

Lors de nos mêlées, nous tenons le 1/4 d'heure sans dépassement, il arrive même qu'elle soit finie avant la fin du temps. Personnellement, je trouve que nous sommes trop nombreux et que l'on n'optimise pas la communication, mais en même temps cela fonctionne et globalement nous en tirons tous des éléments importants. En attendant que nous trouvions un meilleur mode de fonctionnement, nous continuerons donc nos mêlées quotidiennes à 20 personnes... 


Après 6 mois d'utilisation, nous avons abandonné notre tableau de suivi de la production des US : le suivi au niveau des US trop fin entre la livraison de la dernière version et le lancement des devs de la nouvelle version,

•  les équipes surchargées n'ont plus pris le temps de mettre à jour le tableau trop d'info tue l'info : le tableau devenais illisible tellement il comprenait d'US (nb US >100)
• pour chaque équipe Lors d'une rétrospective nous avons donc décidé d'abandonner ce format pour un autre, mieux centré sur nos problématiques. 

Nous avons mis en oeuvre un tableau affichant la roadmap des projets permettant visualiser les dépendances qui peuvent exister entre projet. 

L'objectif est donc de pouvoir augmenter notre réactivité lors des changements de planification et ainsi de mieux maîtriser notre gestion du périmètre. La roadmap est enrichie de différentes affiches sur sa gauche : Fiche de vision A3 Toyota du projet, tableau de présence/absence....

Pour l'instant tout le monde a mis en oeuvre ces changements sur son projet et nous allons suivre cette amélioration de près afin d'en mesurer les gains et les difficultés rencontrées. 

Reste à faire en sorte que nos mêlées se focalisent aussi sur ces points.

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....

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.

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.

Mission de coaching

Depuis début Mai j'ai commencé une mission de coaching agile chez un nouveau client.

A fin juin, après une formation à Scrum, et plusieurs journées de collaboration nous avons mis en place l'organisation du projet sur des voies agiles. Tout n'est pas parfait, mais nous progressons.

Un wiki projet pour travailler et valider les travaux suivants

• définition des exigences avec le métier
• maquettes d'écran conçues par un ergonome
• scénarios de navigation
• afficher la roadmap et le release plan
• centraliser les documents projet

Une Backlog Produit a été commencée bien avant mon arrivée pour travailler avec le métier. Elle est déjà trop détaillée mais nous ferons avec.

Un tableau Kanban pour

• suivre l'avancement de l'expression des exigences 
• suivre les travaux et de recette
• mesurer les temps de passage des fonctionnalités dans le wokflow
• fluidifier les travaux du Product Owner, de la MOA et des utilisateurs
• s'assurer que l'équipe de développement ait assez de User Stories prêtes à chaque Sprint

Une liste des problèmes et des urgences

• pour connaitre les problèmes
• suivre leur résolution

Tableau de suivi Kanban et de suivi des erreurs (initialisé)

Graphique de suivi du tableau Kanban (projection)

BurnUp de Produit et vélocité de l'équipe Scrum (projection)

Le Sprint 0 est prévu pour le mois d’août,

En septembre, après les vacances (si tout va bien ...) nous commencerons les premiers Sprints