French SUG – deuxième soirée mensuelle
Le jeudi 18 Novembre a eu lieu la deuxième soirée du French SUG (Scrum User Group) de l’année. C’est la première pour moi, et j’avoue ne pas avoir été déçu. Je ne parlerai pas des locaux dans lesquels nous avons été reçus pour l’occasion (mais c’est plutôt superbe), mais plutôt des intervenants : Martin Sudmann de la société PriceMinister, Céline Srauder de CLT Services (déjà vue à l’Agile Tour 2010 à Paris) et Ludovic Galabru de la startup Scrumers.
Cette soirée a été l’occasion de partager des retours d’expérience sur la mise en place de l’agilité dans différents types d’entreprises. Mais avant cela une rapide présentation d’un nouvel outil pour promouvoir l’agilité : l’agenda agile (http://www.agenda-agile.org/), qui a pour but de présenter les différents évènements en France et en Europe autour de l’agilité.
Première présentation : Le rythme agile chez Price Minister (Martin Sudmann)
Trois outils ont été mis en place dans cette entreprise : Scrum, Kanban et des lab days. Au démarrage, c’est Scrum qui a été mis en place, avec des sprints de deux semaines pour la maintenance de leur site, avec des pratiques XP (TDD, Pair Programming…). Une définition du « Done » assez poussée : code couvert, code relu, refactoring effectué, démo faite au PO et tests d’intégration écrits. Un point notable : la présence d’un sprint spécifique dit « de livraison » (1 sprint sur 4) juste avant une release, dans le but de corriger les bugs pendant la phase de recette. Les problèmes de cette phase est que le sprint backlog est imprévisible : il s’agit des retours issus de la recette, et ce en plus des tâches à réaliser durant le sprint (et oui ils ne se tournaient pas les pouces en attendant les anos !) ; il est donc difficile pour l’équipe de s’engager sur un contenu. Plusieurs choses ont été tentées pour améliorer cela : baisse de la vélocité, création d’items de livraison, création d’items « fantômes » de correction d’anomalie … sans succès.
Dans un deuxième temps, pour pallier ce problème, il a été décidé de mettre en place une approche Kanban en lieu et place du sprint de livraison. Cette idée est venue à Martin en lisant le livre d’Henrik Kniberg : Kanban et Scrum – tirer le meilleur des deux (http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/).
Pourquoi un tel choix ?
- plein de taches courtes à livrer rapidement
- pas d’engagement de périmètre
- travail en cours limité pour plus de réactivité sur les anomalies
- conceptions techniques (POC) en parallèle
Ici le kanban permet de suivre deux lignes : une pour les correction d’anomalies liées à la livraison, prioritaire sur la ligne de taches de fond, qui peut avancer lorsque l’équipe de recette ne livre pas de retour. Ce mode de fonctionnement permet de tirer le meilleur de l’équipe, qui de sprint en Kanban se retrouve fatiguée, vidée de son énergie.
C’est pourquoi dans un troisième temps, les « lab days » ont été mis en place. Que sont ces lab days ? Il s’agit de demi-journées où l’équipe choisit le sujet sur lequel elle travaille, et toujours en paire (ils sont 6 dans l’équipe) afin de souder l’équipe. Ces demi-journées ont lieu à la fin de chaque sprint, pour rappel toutes les deux semaines, le vendredi après-midi (sprint fini le jeudi, sprint planning le vendredi matin). Les sujets tournent autour de TP, de l’auto-formation et des méthodologies. Petite remarque intéressante pour illustrer ces lab days : la présentation que nous fait Martin Sudmann ce soir là a été réalisé en collaboration avec toute son équipe durant un lab day !
Pour finir sa présentation, Martin nous parle d’autres pratiques mises en place chez Price Minister, tels que des groupes de travail transverses (task forces), pour lesquels un membre de chaque équipe de développement participe sur des sujets liés à l’environnement de développement ou à l’interface utilisateur du site, des sujets communs aux 4 équipes (Scrum) de développement du site. Il nous parle aussi de la communication inter-équipes, via des présentations, des workshops, des newsletters, ou encore des posters.
J’avoue avoir été très intéressé par cette démarche agile, pour plusieurs raisons :
- je ne connaissais pas Kanban
- je trouve ces lab days fabuleux (et en plus la hiérarchie approuve, car ils publient les résultats de leurs travaux, créant l’émulation dans et entre les équipes)
- ça m’a rappelé qu’il fallait être agile dans la mise en place de l’agilité, de toujours adapter les pratiques de l’agilité en étant créatif et audacieux, afin de motiver les troupes et de créer un cadre de travail efficace et convivial !
Deuxième présentation : Scrum et XP dans les entreprises ‘Waterfall’ (Céline Stauder)
Ok, j’ai raccourci le titre, le vrai c’est « retour d’expérience sur l’implémentation de Scrum + XP dans plusieurs DSI de culture traditionnelle » … Soyons synthétiques donc : la présentation s’articule autour de cinq problématiques rencontrées chez un (ou plusieurs) client.
1 – La résistance au changement
Souvent les méthodes agiles sont mal comprises, pour remédier à cela, il faut expliquer, évangéliser et former les équipes de travail, ainsi que le management. Le changement de culture peut poser également problème, mais aussi un manque de prédictibilité apparent. Pour ces différents problèmes Céline a insisté sur l’accompagnement fort qu’il faut faire auprès des équipes pour mettre en place l’agilité dans les meilleurs conditions possibles, et ce de manière progressive (pas de changement brutal).
2 – Les parties prenantes au coeur de l’équipe
Souvent les équipes sont éparpillées et la MOA se détache des équipes de développement. Le but est donc d’impliquer la MOA, qui doit s’approprier la solution, la réalisation du produit. Céline nous rappellera plus tard qu’il est de bon ton qu’un membre de l’équipe métier vienne travailler directement au contact de l’équipe Scrum, membre qui devient alors PO délégué (attention il ne peut pas être le seul PO sans quoi il devient souvent trop indulgent avec l’équipe à son contact).
Il faut parfois recadrer les équipes métier, qui au lieu de venir avec une expression de besoin, arrivent avec un problème et une ébauche de solution technique. Il faut bien diviser les étapes : le métier développe une expression de besoin, l’équipe de réalisation conçoit une solution et la développe si elle répond correctement au métier.
3 – Scrum et le management : définition des rôles
Voyons comment ont été définis les rôles chez le client dont Céline nous parle :
- MOA : PO délégué, au sein de l’équipe Scrum
- Chef de projet technique : il voulait être Scrum Master, mais le lien hiérarchique avec l’équipe Scrum l’en a empêché, ce rôle a donc été exclu de la méthodologie (je parle du rôle, pas de la personne), du coup le SM a été joué par tous les membres de l’équipe (rotation à chaque sprint)
- Pour l’équipe, rien à faire elle était déjà constitué. On note juste que la notion d’engagement sur chaque sprint a due être inculquée.
4 – La transparence et le droit à l’erreur
Dans cette entreprise il y avait une forte culture du cloisonnement et de la culpabilité. Dans ce contexte hostile, difficile de faire quelque chose d’agile ! Plutôt que de partir dans la recherche des coupables quand une erreur est commise, Céline tente de développer une dynamique d’équipe qui a pour but de résoudre le problème en question. On accepte le droit à l’erreur, et on profite de celle-ci pour s’améliorer, par l’expérimentation.
5 – Rituels Scrum et développement itératif
L’environnement de l’entreprise n’est pas toujours adéquat à la mise en place de pratiques agiles. Il faut à tout prix pouvoir intégrer en continu et donner accès au métier à un environnement d’intégration stabilisé.
Quant aux rituels agiles, entre le planning, les daily, la revue, la rétro … ça fait beaucoup de réunions ! Afin d’expliquer tout cela il faut jouer la transparence et réaliser des compte-rendus de ces réunions, pour expliquer la démarche et montrer que des artefacts qui facilitent le travail sont issus de ces réunions.
Bilan
Si c’était à refaire, Céline mettrait en place une démarche Scrum et XP de manière très progressive, presque en douceur, en commençant par mettre en place le tableau Scrum, qui permet d’offrir de la visibilité, puis en mettant en place des métriques, sur les retours de bugs par exemple, qui permettrait de mettre en évidence les gains apportés par la mise en place de l’agilité (si c’est le cas bien entendu 
) et ce afin de négocier le changement. Elle mettrait ensuite en place les daily meetings, car c’est simple et motivant, puis les rétrospéctives, même si cela prend du temps, car elles permettent l’amélioration continue des méthodes de l’équipe Scrum.
Troisième présentation : Scrumers (Ludovic Galabru)
Scrumers, c’est deux choses : une startup et un produit (http://scrumers.com/). Ludovic est donc membre (fondateur ?) de la société qui développe le site web, qui est en fait une application Scrum, au même titre que d’autres que je ne citerais pas pour ne pas faire de l’ombre à cette jolie application qui nous a été présenté à la fin, je vous invite donc à découvrir cette séduisante application (à vous d’y trouver votre compte).
Mais avant cela Ludovic nous a parlé de la mise en place de l’agilité dans une startup. Et oui car pour développer un produit relatif à Scrum, c’est mieux de le faire en Scrum, sinon c’est pas classe.
Le MVP
Ludovic nous présente donc le MVP : Minimum Viable Product (je ne vous ferai pas l’affront de traduire). Il s’agit de faire le minimum qui peut plaire aux clients, et ce afin de cibler un public targué de « early market ». C’est au moment où l’on arrive à ce MVP que l’on peut commencer à itérer et mettre en place Scrum. Mais pas avec un backlog produit, mais avec ce MVP, qui va évoluer et servir de référence pour les sprints.
Avoir du feedback
La revue de sprint, c’est la communauté qui l’a fait ; autant vous dire que l’indulgence n’est pas au rendez-vous, et Ludovic nous a parlé de ses angoisses lors de ses premières itérations (propres à tous les open sourceurs à mon avis).
Il existe des moyens de feedback plus implicites, telle la mise en place de Google Analytics pour surveiller le traffic sur son site et le corréler avec la satisfaction de ses utilisateurs. Pour le contenu des sprints, il met souvent en pratique ce qu’il nomme le A/B testing : il implémente deux solutions répondant à une problématique et laisse la communauté choisir la meilleure.
Quand on a du feedback négatif, il ne faut pas hésiter à « faire un pivot », ça veut dire faire demi tour (au cas où c’était pas clair).
Voilà pour la présentation de ce jeune développeur, je vous invite maintenant à aller voir son produit et pourquoi pas à lui donner du feedback !
Conclusion
Pour ma part, j’ai trouvé cette soirée enrichissante. L’intervention de Martin et sa mise en place de l’agilité m’a particulièrement intéressé, de voir comment on peut mixer Kanban et Scrum, et cette recherche permanente d’améliorer le process, sans s’en tenir à une seule pratique. Bref tout ça pour dire que Scrum c’est bien, mais que ce n’est pas la seule solution pour être agile, il faut avoir l’esprit ouvert et trouver les solutions adaptées à chacun !
J’espère que ce petit compte-rendu vous a motivé à vous rendre au prochain rendez-vous du SUG, sur le thème « Usages et Agilité », qui aura lieu chez Microsoft. RDV en Décembre !
Derniers commentaires