jeudi 4 juin 2015

mercredi 25 mars 2015

Cetifications Scrum.org

Ce n'est pas un gage de compétence, mais ça valide les connaissances et ça fait très plaisir ;-)
La PSMI est vraiment difficile et elles n'ont rien d'évident au premier abord et l'obtenir est le fruit d'un vrai travail personnel.
C'est toujours l'occasion de progresser et de s'assurer que l'on a bien compris comment faire.

Je détiens maintenant deux certifications de scrum.org : 

  • Professional Scrum Master level 1
  • Professional Scrum Product Owner level 1




Sur la base de cet apprentissage entre formateurs agiles de l'Institut Capgemini Sogeti nous avons monté un cursus de formation qui prépare à la certification PSMI. 

Comme ça fonctionne bien, on construit le même type de cursus de formation pour la certification PSPOI. 
Et maintenant nous devons nous préparer pour la Professional Scrum Developper!

Former les autres et partager les connaissances acquises est toujours très enrichissant et permet de renforcer ses acquis, d'avoir une vision plus complète du sujet.
Ce sera également l'occasion de se remettre un peu plus à la technique et de refaire du dev! C'est cool!





mercredi 5 novembre 2014

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

jeudi 30 octobre 2014

Agile Tour Bordeaux 2014

Rendez-vous dés demain, le vendredi 31 octobre 2014 et le 1er novembre à l'Agile Tour Bordeaux 2014 à L'Epitech pour faire le plein de nouvelles idées!
http://lanyrd.com/2014/agile-tour-bordeaux/ et http://agiletourbordeaux.fr/


J'aurais le plaisir de participer à la Coaching Clinic (http://agiletourbordeaux.fr/2014/08/27/coaching-clinic.html) organisée par Fabrice Aimetti avec plein de super coachs agiles!


vendredi 19 septembre 2014

10 000 vues!

Merci à vous tous, ça fait plaisir de voir un tel trafic sur son blog!

Depuis quelques années je vous partage mes retours d'expérience sur l'agilité et vous êtes nombreux a venir consulter mes posts.

10 000 pages vues en France et à l'international!








Merci à tous ceux qui me suivent régulièrement, et n'hésitez pas à poster des commentaires ou me poser des questions je serais heureux de vous répondre !


Olivier Patou

vendredi 27 juin 2014

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.