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 2

La première version de notre tableau est terminée. Depuis deux semaines, nous avons commencé la mise en oeuvre :

• Initialisation de la backlog des Features
• Harmonisation des backlogs produit 
• Mêlées quotidiennes façon "Scrum"
• Refactoring du tableau Kanban des activités
• Tableau des problèmes et actions pour le facilitateur
• Initialisation des burnups d'activités par projet, et consolidation des résultats

Ce que nous ne faisons pas encore :

• Tracer les dates d'entrée / sortie dans notre système
• Suivre les indicateurs induits par les mesures de temps de passage
• Limiter le WIP (travail en cours par activité)

Voici nos tableaux :

Tableau des problèmes / actions du facilitateur

Tableau des Features pour l'établissement de la Roadmap produit

tableaux de suivi de la production des US

BurnUp d'activité des tableaux Kanban et BurnUp de produit des équipes Scrum 

Mêlée : retour aux fondamentaux

Notre équipe accueil deux nouveaux équipiers, et bientôt nous serons 7.

Lors de la dernière rétrospective de Sprint nous avons choisi comme amélioration de revenir aux fondamentaux de la mêlée : 

1. qu'ai-je fait hier 
2. quels problème ai-je rencontré 
3. que vais-je faire

• A la question "qu'ai-je fait hier", il convient d'indiquer le reste à faire sur les tâches non terminées.
• A la question  "quels problème ai-je rencontré" il est important de ne rien dire si il n'y en a pas eu. Si on en a eu, il ne faut pas rentrer dans les détails, il seront discutés hors mêlée. Le but est de trouver le ou les interlocuteurs au sein de l'équipe qui qui nous aiderons à débloquer la situation.
• A la question "que vais-je faire", simplement prendre et lire à haute voix les post-its qui correspondent aux travaux que vous souhaitez/devez faire aujourd'hui.  

Si on veux garder l'attention de toute l'équipe et encore plus des nouveaux arrivants tout en ne dépassant le 1/4h, il ne faut pas s'étendre sur les sujets. Nous avons la possibilité de détailler au PO ou membres les plus concernés plus tard dans la journée. Cela peut éventuellement donner lieu à la création  d'une tâche non planifiée que l'on ajoute pendant la mêlée. 

Premier bilan à 6 équipiers nous avons traité toutes nos activités en 9 minutes. Si on continue comme ça, tout ira bien.

Notre tableau de suivi après la mêlée de ce matin :

Tableau de suivi des tâches, Sprint 44

Les dérives de la mêlée

Les dérives de la mêlée from Olivier Patou

Formation Scrum des 21 et 22 Septembre 2011

Dernière formation planifiée à ce jour :

• 8 personnes étaient présentes,
• 2 products owners identifiés, 
• 1 chef de projet qui se voit bien devenir product owner
• Les autres personnes avaient besoin de connaitre et comprendre la méthode afin de pouvoir travailler avec des équipes Scrum, des stakeholders en somme.

Pour cette formation, je me suis inspiré du Scrum Café Bordelais : j'ai introduit le rôle d'observateur dans les ateliers. 

Les règles du jeux, décliné ensuite au niveau des Users Stories

Lorsque le product owner présente son projet (vision) et cherche à identifier des features, puis des user stories il était intéressant de voir la pertinence des questions, et le niveau de compréhension des participants qui s'affine. 
Il faut rester vigilant à ce que les discussions servent l'objectif, sinon, les participants racontent volontiers leur vie. Une fois cadré, en 1/4 d'heure, le jeux produit ses effets.  On recommence ensuite avec l'identification des premières user stories à planifier dans le(s) premier(s) Sprint(s).

Le résultat : les Backlogs

Je doute qu'un cahier des charges ou autre expression de besoin puisse être aussi efficace ( rapport temps passé/compréhension). 

Il est vrai que ces documents servent surtout à fixer les responsabilités une fois que les premiers problèmes font surface...