Kanban : évolution des tableaux - maturité de l'équipe

La mise en oeuvre de Kanban pour l'IT dans l'équipe se fait autour de deux tableaux qui représentent les deux flux de demandes que reçoit l'équipe.

Depuis la première version du tableau "Support" initialisée au lendemain de la formation de Laurent Morisseau - fin avril, début mai - les deux tableaux ont beaucoup évolué.

Le Kanban Support a été mis en oeuvre en premier, car plus simple, le second Kanban permettant de visualiser le flux des demandes projets a été après la seconde formation que j'ai dispensée au reste de l'équipe à la mi mai.

Etant donné que notre équipe se trouve éclatée principalement sur deux sites, Gradignan  et Nantes, nous avons deux tableaux pour chaque flux de demande : un à Gradignan et un à Nantes. Leurs évolutions se font en parallèle, certaines améliorations étant portées sur les deux sites, d'autre pas.

Il nous reste ensuite un architecte tout seul à Montreuil (assez isolé donc) et un DBA tout seul à Arras, mais qui viens régulièrement sur le site de Gradignan. Pour ces deux collaborateurs, aucun tableau n'est mis en place et il n'y pas eu de virtualisation des tableaux à ce jour. L'objectif est de gérer 80 % de notre acvtivité sur les deux systèmes et d'étendre ensuite la portée par opportunités une fois les systèmes suffisamment matures.

Voici un petit extrait des diverses évolutions que nous avons apporté au Kanban Support de Gradignan, la suite et le compléments viendrons dans d'autres billets :

Kanban Support :

Première version du tableau support

Aie! ça coince aux limites de l'activité "Analyse et correction" : on ne tiens pas les limites!
(on ne le voit pas, mais il y a un post-it "Aie" placé à coté de la limite)

Les indicateurs Diagramme de Flux Cumulés et Carte de contrôle son remplis à la main pour une meilleure appropriation par chaque membre de l'équipe - nous sommes passés depuis à une feuille Excel!

Carte de Contrôle (temps de cycle des demandes)

Digramme de flux cumulés : évolution du stock, de l'encours et du fini

Les règles de la mêlée Kanban

Certaines activités doivent être réalisées mise en visibilité par rapport aux autre : nous ajoutons un couloir de nage de nage pour toutes les activités Base de Données réalisées exclusivement par les DBAs.
Dans nos bureaux deux représentants d'un autre pôle sont en forte interaction sur nos actions. Afin de fluidifier les interactions, nous leur ajoutons leur propre Kanban en dessous du notre. Il porte leurs actions, et les demandes que nous recevons lorsqu'ils sont contributeurs (Nous suivons comme ça tout le flux, ses blocages etc...). 
Les limites ont aussi évolué depuis leur intialisation, certaines à la hausse, d'autres à la baisse

L'intégration est poussée plus loin : leur tableau deviens partie intégrante du notre

A présent les activités sont parfaitement intégrées dans le même flux, on a ajouté des acteurs et les limites tiennent bon. Le flux est bien maîtrisé, même lorsque tout d'un coup une pluie de demandes arrive.
A ce stade nous avons également ajouté les classes de services (on voit des post-its roses) et affiché les règles du système : cadences des réunions, d'injection, de purge, définitions de terminé ...

Les diagrammes (CFD et CC) du Kanban Support à Gradignan
C'est bien, parce qu’on y revoit certaines évolutions dans notre approche
C'est bien aussi de voir que l'équipe gère bien le flux et absorbe les pics.

Rétrospective Annuelle et Innovation Games

Animer une rétrospective avec des Innovation Games

En cette fin d'année j'ai été missionné pour animer la rétrospective annuelle de notre support technique.
Habituellement cette réunion est unidirectionnelle : le manager présente un PPT à son équipe et relate les événements marquants de l'année.

Cette forme a vécu et l'équipe a proposé une nouvelle version plus interactive, plus vivante et plus constructive.

Reposons le décor 

Il s'agit d'une équipe constituée d'experts techniques - DBA, développeurs ... Le gros de l'équipe se trouve localisée en région Bordelaise - même bureau- mais quelques membres sont répartis sur d'autres sites - Aix-en-Provence, Nantes ... . 
Le client principal est le pôle Internet, mais il y a aussi un département GED et un département Intranet. Quelques membres de l'équipe sont de nouveaux arrivants, d'autres sont arrivés en cours d'année et certains sont présents depuis la création du service il y a 3 ou 4 ans.
L'équipe était initialement positionnée sur la résolution des problèmes de production, puis a essayer de se recentrer sur des activités plus en amont afin d'anticiper les problèmes et de ne plus subir les choix réalisés par d'autres tout en ayant une augmentation conséquente de ses effectifs et de son périmètre.

Faire un bilan est devenue plus qu'une nécessité, un élément vital!

C'est là que les Innovations Games nous ont apporté une solution.

Au programme

Une présentation des faits marquants de l'année sur le thème de la voile illustrée par un tour du monde en équipage. Un parallèle est fait entre les valeurs de l'équipe et les valeurs véhiculées par le sport - rugby et voile- .

• Un mur de feedback placé prés de la porte de sortie de la salle pour collecter les retours après chaque atelier.
• Un atelier Vision Box afin que chacun contribue à la constitution de la vision idéale de ce qu'est cette équipe : son rôle, ses forces, son périmètre - 4 équipes
• Un repas convivial tous ensemble,
• Un atelier Remeber The Future pour se projeter dans trois scénarios idéaux à l'horizon 2018 - pour laisser un peu de place à l'imaginaire et au progrès que pourrait faire l'équipe et l'entreprise - 3 équipes
• Un atelier Speed Boat pour identifier dans le contexte actuel les forces et les freins de l'équipe en vue d'un objectif idéal à court terme - tous ensemble
• Débriefe du mur de feedback pour chaque atelier puis débriefe des retours plus globaux (la journée, l'équipe... complètement ouvert en fait!)
• Un ROTI de la journée pour finir ( des 4 et des 5 : ça fait plaisir!)

Durant cette journée, j'ai pris quelques 222 photos - très utiles pour se remémorer l'ambiance et les attitudes - et des vidéos lors de la présentation des travaux des différentes équipes constituées pour les jeux  - très riches d'enseignement également car le discours est également riche en enseignement.
Pour chaque équipe de travail et chaque atelier il y avait un observateur/facilitateur, également membre de l'équipe. Mon rôle était celui de facilitateur, animateur des jeux, et time-keeper.

Bilan en images

Bon assez de Bla Bla, voici quelques unes des photos réalisées, c'est parlant:

Rétrospective : introduction

Les valeurs du sport comme métaphore

Atelier Product Box

Product Box : L'organisation des thèmes

En pleine création

Des échanges animés

La "vente" de la "Box"

Les quatre box produites

Le mur de feedback s'alimente par atelier

Un repas tous ensemble c'est ^lus convivial

Remember the future : la timeline en cours de construction 1

Remember the future : la timeline en cours de construction 2

Remember the future : la timeline expliquée au reste de l'équipe

Le Speed Boat : tous ensemble

Le mur de feedback se rempli

La mascotte échouée prés du bâteau de l'équipe

Speed Boad : Le débriefe des ancres et des vents

En conclusion : 

Une journée ou tous les participants 

• ont été très actifs, 
• ont passé une journée agréable, 
• ont eu le sentiment d'être une seule et même équipe
• ont partagé leurs réussites et leurs problèmes

Beaucoup de matière a été récoltée et en plus d'un compte rendu des ateliers, nous avons synthétisé une vingtaine de problèmes. Ces problèmes ont été ordonnés par importance et valeur - merci Fibonacci - ce qui nous a permis de définir les 3 problèmes les plus importants et pas trop complexes à traiter en priorité.

Parmi ces problèmes, le premier est le manque de vision commune et partagé des missions de l'équipe et de son périmètre. 
Une fois réglé il est fort possible que d'autres problèmes disparaissent d'eux-même.

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.

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.