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