Concevoir un Kanban Utile, Utilisable, Utilisé

Concevoir un tableau kanban n'est pas toujours facile!

Il s'agit d'abord de comprendre le processus de fabrication et de le rendre visible. 

Les "éléments du flux" (les "choses à fabriquer") peuvent être différents : la granularité peut varier fil du processus avec des éclatement d'un élément en plusieurs, et différents types peuvent coexister. 

Il n'y a pas non plus une seule bonne solution, mais plusieurs options qu'il s'agit d'explorer pour que le processus soit juste, pour que l'équipe le comprenne, et enfin et surtout pour que l'équipe l'utilise et en tire profit. 

C'est bien cette dernière étape qui est la plus cruciale et sur laquelle nous butons encore sur un de nos systèmes Kanban. 

Contexte de l'équipe: 

Notre équipe de "Support Technique" aux équipes de développement est distribuée sur 4 sites. Deux personnes se trouvent seules chacune sur un site différent (Montreuil et Arras), quatre autres sont à Nantes, deux ressources sont en centre de service à Bordeaux et les reste de l'équipe est également à Bordeaux, dans les locaux de la DSI. En tout nous sommes une équipe de 18 personnes. 

Une autre caractéristique est que les équipes a qui nous apportons notre support ne sont pas homogènes dans leurs activités, leurs processus. Certaines équipes travaillent essentiellement avec des progiciels qui nécessitent parfois des développements spécifiques, d'autres développent des application en mode cycle en V tandis que le plus gros client est plutôt agile avec une organisation comprenant des Chefs de Projet, des Product Owner et plusieurs équipes Scrum.

Dans ce cadre il est difficile d'avoir une animation d'équipe homogène, avec des échanges réguliers et fluides. Notre difficulté principale est le manque de communication entre tous les membres de l'équipe, surtout lorsque des activités passent par des acteurs situés sur les différents sites.

Démarche de changement :

Dans notre démarche agile, nous avons (cf. posts précédents) mis en place plusieurs tableaux Kanban pour répondre initialement à deux types de demandes différents :

• Les demandes panifiables et planifiées (en mode "Projet") faites à l'équipe sont suivies dans le kanban "Projet"
• qui se décline avec des objets "projet", des objets "Cas d'usage" et des objets "action/tâche"
• Les demandes de support suite à un problème technique par exemple sont suivies dans le kanban "Support"

Premier problème : où mettre les tableaux, sur quel site(s)? 

Et forcément une question : doit-on les virtualiser?

Dans un premier temps, nous avons suivi les conseils de Laurent Morisseau et nous avons cherché à rendre compte de 80 % de notre activité afin de trouver un format qui marche et pouvoir l'enrichir et l'adapter au fur et à mesure.

Constats Kanban "Support" :

• Notre premier constat a été que le Kanban "Support" avait été facile à mettre en oeuvre à Bordeaux et qu'il avait permis de fluidifier le traitement des demandes en portant "physiquement" l'attention sur elles et en limitant le WIP.
• A l'inverse l'équipe de Nantes ayant moins de demande de cette nature que l'équipe de Gradignan, le tableau Kanban a progressivement été abandonné. 

Constat Kanban "Projet" :

• Les premières versions du système étaient assez compliquées. Il pouvait y avoir plusieurs profils intervenant sur une même colonne qui comportaient plusieurs activités distinctes. 
• Les éléments du flux projet, quelque soit la forme donnée au tableau restaient longtemps au même endroit car le process est long. 
• Pour son initialisation il fallait déployer beaucoup d'énergie à vaincre les résistances des uns et des autres qui ne le trouvaient pas utile. "Du temps perdu c'est tout."

Nous avons donc itéré sur le tableau, modifié nos définitions de fini pour les étapes du processus.
Nous avons également changé la portée du tableau : au commencement il était dédié à l'ensemble de l'équipe, puis nous avons sorti les activités des DBA pour la déporter dans un Kanban virtualisé afin d'intégrer une ressource distante. De plus cette activité est maintenant visible depuis l'ensemble de nos sites. Nous avons également exclus l'activité des architectes de nos systèmes Kanban : nous reportons à plus tard les travaux sur cette activité afin de nous concentrer sur le plus important. 

version 1

version 2

Dans ces deux premières versions nous avions trois granularité pour les éléments du flux : Des projet/commandes qui donnent lieu à des Cas d'Usage (Epics/Features) qui eux-même donnent lieu à des actions de support aux projet... compliqué dans notre contexte! 

version 3

Un autre point était frein à l'utilisation : l'injection des éléments du flux et le processus en amont qui ne dépend pas directement de nous.La difficulté était d'avoir une source fiable et à jour. L'injection des éléments à la demande nécessite une bonne discipline personnelle et un peu de temps. Çà ne fonctionnait pas.

Nous sommes remontés à la source (la gestion des commandes) et travaillé avec la personne en charge de leur suivi. Nous avons mis en place un export des commandes depuis l'outil de gestion dans une feuille Excel. A partir de cette liste d'éléments une macro VB nous permet d'appliquer les codes couleurs associés à nos projets et ensuite de générer des post-its automatiquement que nous avons juste à imprimer et, découper et afficher sur le tableau. 

Alléger le processus amont et l'automatiser nous a permis de simplifier le processus global et de lever certaines résistances.  

Nous pouvons donc à présent nous concentrer sur deux éléments important : les actions/tâches à réaliser et le flux projet.

A ce stade, le système semble enfin être devenu utilisable. S'il est utilisé correctement nous pourrons en tirer partie pour l'équipe (et aussi pour les managers) et le système deviendra utile.

Constat Kanban DBA :

Ce système a tout de suite trouvé l’adhésion en remplaçant un fichier Excel peu pratique. Nous avons choisi l'utilisation de KanbanFlow (http:\\kanbanflow.com). Les trois DBA listent leurs actions et les priorisent, c'est un excellent support pour le partage. 
Nous nous réunissons une fois par semaine en visioconférence pour parcourir l'activité, trier nos files d'attente et partager les difficultés rencontrées.

Prochaines étapes :

     Une fois le système "Projet" validé nous le virtualiserons afin qu'il puisse être partagé entre tous les sites. 

Il faudra mettre en place des écrans au mur afin que le tableau soit visible en permanence et que nous puissions organiser nos mêlées de façon efficace en s'appuyant sur les éléments du flux.

     

     Repenser à l'activité des architectes et les intégrer dans un système existant OU en créer un spécifique.

     Evidemment, nous ferons le point sur tous ces aspects pour la dernière rétrospective de l'année, à la mi-décembre...

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.

Formation Kanban : acte II

Après la formation Kanban pour l'IT de Laurent Morisseau avec Fabrice Aimetti, destinée aux internes, j'ai repris le flambeau pour une formation sur un jour et demi avec l'aide d'Aline Renan.

Un grand merci à elle pour son animation et la traduction en français d'une bonne partie du jeu GetKanban (http:\\www.getkanban.com).

Pour débuter la formation, chacun a décrit ses attentes par rapport à la formation. J'avoue que ce premier échange m'a un peu surpris :
"Je n'ai aucune attente....", "de toute manière c'est un truc de managers pour avoir des indicateurs..."

Du coup, après avoir le jeu, nous avons refait un tour de table, et là, les attentes étaient plus claires, le jeu étant très bien fait, et l'animation d'Aline très réussie.

  

L'équipe A

Aline et l'équipe B

Les résultats du jeu : l'équipe B gagne avec 71 000 points contre 37 700 pour l'équipe A

Pour relier la théorie à la pratique, je me suis appuyé sur les expériences acquises pendant le jeu et sur le premier tableau Kanban mis en oeuvre pour l'activité de support aux équipes (gestion de tickets).

Nous avons également partagé ensemble les problématiques liées à l'éclatement de l'équipe sur deux sites : à Nantes et à Gradignan. Par chance, nos équipes ont globalement des activités sur des projets distincts en fonction de leur localisation géographique, ce qui permet d'avoir des tableaux distincts avec peu d’interactions entre les deux sites.



Durant toute la session, le mur de feedback était présent. Peu de post-its malgré mes relances répétées. L'équipe a pourtant déjà utilisé ce mur pour la rétrospective de fin d'année et nous avions récolté beaucoup de retours. Qu'est-ce qui n'a pas marché cette fois-ci?

Le bilan de la formation a été fait à la toute dernière minute, les Nantais rentrant en voiture juste après la dernière journée : plutôt satisfaisant malgré les délais de préparation très court (6,5 jours de travail  effectif).
Il en ressort un axe d'amélioration principal sur la durée de la formation, trop courte. 

Évaluation de la formation

L'axe respect es attentes est mitigé : puisque certains n'avaient pas d'attentes particulières au départ, la note fut basse : "soit on mettait tout à 100% soit on mettait faible, puisque pas d'attentes!")

De mon coté, si pour une première formation Kanban, j'ai bien tenu mon timing, je dois améliorer certaines explications et corriger le support qui comportait quelques petites coquilles (notamment des animations de post-its impromptues - le copier coller est toujours source de surprises!)

Un gros manque cependant, mais l'information est passée à l'oral : les 4 valeurs et 12 principes de l'agilité sont à ajouter au support de formation!

Formation Kanban : la suite

La formation Kanban de Laurent Morisseau s'est déroulée sur 2 jours et demi.

Nous avons commencé par le jeu très instructif GetKanban (on trouve tout sur leur site http://getkanban.com).
Ce jeu nous a permis une mise en situation projet dans un contexte de développement avec des enjeux Business. Deux équipes étaient en compétition et cela a stimulé les participants :

• Mise au point de stratégies différentes, 
• Mise en place de mêlée naturellement et systématiquement : devant les enjeux, on s'organise et chacun veut naturellement contribuer à établir la meilleure stratégie.
• Compréhension intuitive des goulets d'étranglement et la stratégie vient naturellement protéger le goulet en cherchant à lui fournir en permanence de l'activité.
• Construction des graphiques pour établir nos métriques (réutilisés tout le long de la formation pour illustrer les parties théoriques de la formation)
• Utilisation de cartes kanban différentes (cartes urgentes, cartes "challenges" : a prendre ou pas - question de stratégie) et identification de classes de service : certaines cartes sortent plus vite que d'autres - qu'ont-elles en commun?

Nettoyage des support du jeu en fin de journée

Suivi financier du jeu

Diagramme de flux cumulé

Control Chart : temps de cycle de chaque carte sortie du système

Au cours de la formation, Laurent a su trouver l'argumentaire juste pour convaincre de l'efficacité du système malgré la diversité des activités du service.

Les ateliers nous ont permis d'identifier deux flux et de les modéliser : 

• un flux simple pour la gestion des demandes de support

Le prototype pour le kanban "Support"

• un flux complexe avec deux tableaux imbriqués : toute la vie d'un projet, du cadrage au déploiement en production.

Le prototype pour le kanban "Projet"

La formation terminée, nous sommes repartis avec sous le coude un plan d'action et deux tableaux. Le premier tableau kanban pour la partie support a été partagé avec le reste de l'équipe qui n'avait pas pu participer à la formation. 

A ce jour il a été retravaillé avec la collaboration des principaux intéressés puis initialisé et enfin il commence à être utilisé au quotidien.

La version 1.0 de notre kanban "support"

A présent je prépare une session de formation pour le reste de l'équipe a dispenser dans une dizaine de jours et nous allons en parallèle approfondir la conception du second tableau.

Fabrice Aimetti qui était présent lors de la formation va nous accompagner pour un coaching toutes les 2 à 3 semaines afin de nous aider dans la mise en oeuvre.


Un grand merci à Laurent pour sa formation d'une grande qualité et pour l'efficacité dont il sut faire preuve afin de concevoir des tableaux pertinent pour notre activité.

Un grand merci à Fabrice pour sa participation et sa co-animation des ateliers de la formation ainsi que pour les photos.

Formation Kanban

Deux belles journées instructives nous attendent :


Aujourd'hui avec l'équipe que je coach nous allons commencer la formation Kanban de Laurent Morisseau. 
Fabrice Aimetti sera présent également afin de préparer une intervention de coaching sur la mise en place de la place de la méthode.
Mon rôle est de faciliter au quotidien la mise en place de la méthode.

Ça va être riche et instructif. La suite dans un prochain post?

• Le site de Laurent : http://www.morisseauconsulting.com/
• Le site d'Ayeba ou Fabrice fait son oeuvre : http://ayeba.fr/author/fabrice/

Scrumban

Certains clients grand compte disposent d'équipes de support transverses. 


C'est le cas de mon client, chez qui, plusieurs de ces équipes ont essayé de mettre en place Scrum ou Kanban en attendant une révolution complète et utopique pour passer à une organisation "Full Agile". Dans cet effort ils ont été confrontés à plusieurs problèmes. 
Voici deux des écueils les plus répandus :
Ces équipes souhaitent trouver une méthode agile leur permettant de suivre leurs activités et de gérer au mieux leurs priorités - souvent changeantes - et de favoriser l'auto-organisation chère aux agilistes que nous sommes.

• une équipe Scrum qui souhaite travailler en flux, 

• supprimer les longues réunions de planification de sprint, 

• augmenter la taille d’un équipe Scrum (ex : +12 personnes) 

• gérer des activités qui ne répondent pas à un seul processus défini au sein d'équipes transverse,

•  …

Comment ça marche :

• une réunion de lancement pour un Sprint dans lequel chaque item compte pour 1

• une injection d’éléments à la demande dans la colonne « A faire ». Le backlog sur le tableau devient donc une entée permettant de prioriser dans la colonne « Prêt » les éléments à prendre en priorité (cf pt 1)

• ¼ d’heure tous debout devant le tableau.

• Le Scrum Master/ Manager donne les changements de priorité du jour et les nouveaux éléments sont ajoutés au tableau

• Chacun explique les problèmes rencontrés, fait le point sur son avancement au regard des items, et expose ce qu’il fera dans la journée.

"Scrum c'est super bien, mais entre la réunion de planification du Sprint et les changement incessants de priorités dû à des demandes urgentes de support de la part des projets, on ne peut pas garantir plus de 20% du respect de l'engagement initial...."

ou

"Je voudrais bien que l'on se mette à Kanban pour favoriser l'interaction des équipiers, et gérer nos priorités au jour le jour/à la demande, mais entre les différents domaines d'expertise sur lesquels nous sommes sollicités, il est impossible de définir un processus commun à toute l'équipe, quelque soit la demande."

ScrumBan est un compromis entre Scrum et Kanban. Voici entre autres quelques raisons qui peuvent motiver la mise en œuvre de Scrumban plutot que Scrum, Kanban ou encore XP : 

Je vous propose ci-dessous une vulgarisation des principes de Scrumban pour une mise en oeuvre dans ce type de contexte.

1/ Tableau des tâches :

On se base sur un tableau des tâches Scrum avec les colonnes A faire ->  En cours -> Terminé.

En fait on ajoute une colonne supplémentaire « Prêt » qui permet de prioriser les demandes entre la backlog (A faire) et le travail en cours.

On obtient le tableau suivant : A faire -> Prêt -> En cours -> Terminé

2/  Travailler en flux avec des limites :

Si on ne met pas de limite, on n’obtient pas un système Kanban, et on risque de commencer plein d’activités sans en terminer aucune. On ne travaillera donc pas en flux.

Une bonne limite de départ pour le travail en cours est : nb personnes dans l’équipe * 2.

Cette limite permet de gérer les blocages : je suis bloqué, donc je passe à la tâche suivante en attendant de débloquer la précédente.

3/ Cadence d’injection des éléments

            Dans un système Scrum, on alimente une Backlog avec une liste de choses à faire. Cette Backlog est discutée avec le Product Owner puis estimée en complexité (la « taille » de la Story). La vélocité de l’équipe est un indicateur qui permet de limiter pour un Sprint (« TimeBoxing ») la quantité de travail à réaliser.

            Dans un Système Kanban, la taille n’importe pas. Ce qui compte c’est le nombre d’éléments en cours que l'on limite de manière explicite par un nombre d'éléments (tâches/story) sur chaque colonne du système.

            Avec un Système ScrumBan, une équipe peut choisir le meilleur des deux par rapport à sa problématique :
une réunion de lancement pour un Sprint dans lequel chaque item compte pour 1

ou
une injection d’éléments à la demande dans la colonne « A faire ». Le backlog sur le tableau devient donc une entée permettant de prioriser dans la colonne « Prêt » les éléments à prendre en priorité (cf pt 1)

4/ Cadence de livraison

            Si l’équipe produit une application, le rythme de livraison devra être déterminé en fonction des besoins et des capacités des équipes de déploiement etc…. Si l’on veut, on peut se caler sur la notion de Sprint (itération de durée fixe) pour obliger l’équipe à préparer une version « propre ».
Dans le contexte des équipes de support transverse, il n'y a pas besoin de livrer un produit fini à rythme déterminé, puisque l'on a plutôt une livraison au fil de l'eau à d'autres équipes.

5/ Rétrospectives

            Un point absolument nécessaire et primordial si l’on veut tirer un réel bénéfice de toutes ces méthodes, c’est de faire une rétrospective au minimum une fois par mois avec l’ensemble des équipiers. 
Il est important de rythmer avec une période fixe ces points d’amélioration continue. A l’image du cœur qui rythme nos vies, c’est ce rendez-vous qui permet de s’adapter au contexte de l’organisation et lever les obstacles qui encombrent la route.

• Chacun s’exprime sur ce qui a bien fonctionné, quels problèmes on a rencontré, comment on les a résolus et quels sont les problèmes que nous avons encore.
• Choisir collectivement quelle évolution du système sera mise en oeuvre pour la période suivante
• Choisir les problèmes que le Manager/Scrum Master et l’équipe se chargeront de résoudre pendant la période suivante.

Lors de ces réunions on peut prévoir d’ajouter de nouvelles colonnes au tableau afin coller un peu plus aux spécialités des collaborateurs et au processus de travail.

6/ Animation du tableau

•             Injection des éléments : vu au point 3
•             Mêlées quotidiennes façon Scrum 

Soit :

                       

• ¼ d’heure tous debout devant le tableau.
• Le Scrum Master/ Manager donne les changements de priorité du jour et les nouveaux éléments sont ajoutés au tableau
• Chacun explique les problèmes rencontrés, fait le point sur son avancement au regard des items, et expose ce qu’il fera dans la journée.
• 
  

Bien évidement, à appliquer avec les 4 valeurs, 12 principes du manifeste agile et avec toutes les bonnes pratiques eprouvouées...

Ci-dessous un lien vers un très bon article de Corey Ladas écrit en 2008 qui décrit ScrumBan, traduit par  Fabrice Aimetti : http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/07/01/Scrumban

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 

Présentation Kanban pour l'IT en 5 minutes

Cette présentation a été présentée lors des Scrum Café réalisé chez un des clients pour lesquels j'interviens. Depuis je l'ai un peu améliorée en vue du Scrum Wine du 16 Janvier, ou j'aurais l'honneur de la présenter en 5 min chrono.

 

Kanban pour l’it en 5min v1.1 from Olivier Patou

La version en ligne sur SlideShare a été un peu modifiée afin que l'absence d'effets d'animation en ligne ne détériore pas la qualité de l'exemple.

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

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