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