mercredi 4 septembre 2013

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.




lundi 11 mars 2013

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

mardi 22 janvier 2013

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 








vendredi 4 janvier 2013

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.

 

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.