septembre
2009
Un article de Bruno Orsier
Après quatre années de pratique de Scrum, nous avons des équipes qui fonctionnent bien, qui délivrent régulièrement des fonctionnalités satisfaisantes pour les product owners (et même parfois qui enchantent des clients, par exemple par la vitesse de livraison), mais il nous reste plusieurs problèmes à résoudre, et des problèmes difficiles qui plus est. Rien d’étonnant à cela, Scrum est en effet un excellent révélateur de problèmes, et il serait vain de croire que la pratique de Scrum ferait disparaître les problèmes par elle-même !
L’un des problèmes actuels est que les projets fonctionnent en silos isolés. Bien sûr les membres des équipes se parlent toujours en prenant le café ensemble, mais ils vont plus rarement aux démonstrations des projets autres que celui dans lequel ils travaillent. Ou encore, quand la réflexion progresse dans un projet sur, disons, la problématique du test ou la gestion des défauts, les équipes des autres projets ne sont pas au courant. Ou encore, les gens des divers projets qui souhaiteraient progresser sur la qualité du code ou la mesure de la couverture de test ne se rencontrent jamais…
Scrum n’est pas responsable de ce fonctionnement en silos qui est un peu ancien, mais il peut l’accentuer. Dès qu’un sprint est terminé, on fait la démo, la rétrospective, et le lendemain déjà il y a les réunions de démarrage dans lesquels il faut s’engager à faire bon nombre de points… Il n’y a guère de place dans tout cela pour passer un temps conséquent avec les gens d’un autre projet que celui sur lequel on est impliqué !
Certains inconvénients d’enchaîner les sprints sans délai ont déjà été identifiés par Henrik Kniberg dans Scrum et XP depuis les tranchées (voir Chapitre 11 – Relâcher le rythme entre les sprints) : absence de vraie pause, difficulté de digérer toutes les informations et d’apprendre les leçons, difficulté d’ajuster les priorités, difficulté de garder ses connaissances à jour. C’est pourquoi Kniberg préconise de réserver une journée « labo » une fois par sprint (ou au moins une fois par mois), journée qui devrait concerner tous les membres de l’entreprise à la fois.
Nous avons déjà expérimenté une telle journée ‘labo » avec les dojos agiles, en réunissant les membres de deux équipes travaillant sur deux projets différents. Le contenu des diverses sessions était préparé par moi-même, avec parfois les conseils d’un autre chef d’équipe. Donc il y avait peu de place pour l’auto-organisation des équipes, que nous n’avons pas su favoriser pour l’instant (autre problème difficile que nous avons identifié).
Les dojos agiles ont suffisamment convaincu les participants, ainsi que notre directeur. Alors depuis peu nous changeons d’échelle, en impliquant toutes les équipes de tous les projets, et avec des sujets au choix des participants (ceci afin de développer l’auto-organisation). Voici le format que nous suivons actuellement :
- Communication générale : échange de nouvelles sur les projets, retour d’information après un déplacement chez des collègues ou des clients, annonces diverses… Ca peut paraître trivial, mais un tel espace d’échange régulier n’existait pas auparavant.
- Proposition de sessions : chacun des participants peut proposer un sujet de travail, qu’il note sur un grand post-it, avec son nom, et l’affiche.
- Vote : tous ceux qui n’ont pas proposé de session s’inscrivent dans les sessions proposées.
- Réduction : les sessions qui n’ont pas au moins 1 inscrit sont supprimées, et leurs anciens propriétaires se répartissent dans les sessions déjà pourvues.
- Session du matin (en gros de 10h à 12h)
- Point intermédiaire (de 13h30 à 14h) durant lequel on discute des sessions en cours, on redémarre un nouveau sujet si l’un d’eux est terminé (cela n’est encore jamais arrivé).
- Session de l’après-midi
- Réunion de clôture, courte (30 minutes) car tout le monde est bien fatigué après une telle journée, et ce n’est pas le lieu de prendre des décisions délicates ou de débattre en détail. Chaque groupe explique donc simplement ce qu’il a fait.
- Vote ROTI à chaud à main levée
- quelques jours plus tard, envoi d’une enquête anonyme pour un ROTI à froid et recueil d’idées d’améliorations pour la session suivante.
La principale règle est que les sessions proposées doivent améliorer concrètement quelque chose dans notre travail, et ce dans la journée ! Voici quelques catégories possibles :
- modifier du code existant pour en améliorer la qualité
- modifier des tests
- modifier ou produire des documents (mode d’emploi d’un outil, documents du système qualité, …)
- réorganiser documents ou fichiers
- éliminer un gaspillage
- …
Une autre règle est que, si possible, les groupes de travail doivent composés de membres de divers projets et de divers équipes (c’est-à-dire pas d’une seule équipe Scrum par exemple).
Si le travail ne peut pas être fait dans la journée, alors soit il faut l’aborder dans un autre cadre, soit on peut en réduire la portée pour le faire dans la journée.
Les participants à une session de travail doivent s’assurer que les modifications prévues sont dans leur zone de contrôle, et si non, s’assurer le concours de la personne nécessaire (responsable qualité, responsable IT, directeur du site) qui de toute manière participe à la journée.
Voici par exemple quelques sujets déjà traités :
- examen de nouvelles règles de conception de FxCop, avec pour conséquence l’application de règles plus sévères à l’un de nos modules (donc modification dans notre système d’intégration continue)
- travail commun entre testeurs et développeurs pour créer des outils simples (fichiers .BAT) facilitant le deploiement des données de test. Gain de temps de plusieurs heures pour les testeurs.
- travail commun entre les testeurs et le responsable IT pour optimiser les images de PC utilisées pour les tests. Réalisation d’un poster pour la salle de test indiquant comment utiliser ces machines. Réutilisation de ce poster dans le labo. Gain de temps pour les testeurs et gain de place sur les serveurs.
- Utilisation d’un outil de recherche de duplication de code (Simian) afin d’en comprendre le fonctionnement, et de contrôler les éventuelles violations du principe DRY. Rédaction d’un mode d’emploi. Mise en place de Simian dans le système d’intégration continue. Obtention de métriques de duplication de code.
- Calcul de couverture de code Delphi durant l’exécution des tests unitaires grâce à l’outil Aqtime. Rédaction d’un mode d’emploi.
- Mise au point d’un exemple de meilleure gestion du temps dans les tests unitaires qui demandent attentes et synchronisations. Réalisation d’une bibliothèque d’outils pour factoriser un schéma courant dans certains de nos tests.
Sans l’organisation de ces journées, ces actions n’auraient tout simplement pas eu lieu. De plus les travaux réalisés ont été à l’initiative des membres d’équipes ; pour preuve, les sujets que j’ai proposés n’ont pas été retenus ! Cela illustre probablement une évolution nécessaire d’un rôle de manager dans un contexte Scrum : plutôt que rechercher soi-même des solutions, il est possible en place une organisation de travail permettant aux équipes de trouver de meilleures solutions !
10 Commentaires + Ajouter un commentaire
Commentaires récents
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Rétrospectives, la directive première
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
Intéressant ce lien. Dans les commentaires j’ai aussi noté « 20% time is a joke. Senior management makes obligatory ceremonial noises about it now and then, but the bottom line is that you always have a performance review coming up, so you can either make your peers think you are a selfish jerk (and kiss that promotion goodbye) or you can do what most people do and spend 120% of your time on your primary project plus additional duties. »
Il ne faut pas trop fantasmer sur la plus verte prairie de google, et trouver ce qui marche dans notre propre contexte.
A+
Bruno
A propos des googles days, un ami a récemment posté ce lien http://www.cringely.com/2009/09/the-peoples-republic-of-google/ où l’on peut lire :
Which brings us to the vaunted 20 percent time Google engineers are supposed to get to work on anything they like. Most of them apparently use that time for corporate housekeeping — for doing all that peer reviewing. It makes sense: if you want to appear productive in your main job yet are still required to do all this work that would normally be handled by managers, when else can you do it but during time you don’t have to account for?
De quoi nuancer un peu ces googles days au final… Qui sait, peut être que l’équipe de Kniberg est plus googliste que Google
Et merci pour les remerciements… A noter que pour le « from the trenches » je ne plaisantais pas tant que ça, vu que la mise en place de process Agile est plus « ardue » qu’il ne pourrait y paraitre parfois : tout retour d’expérience est intéressant
joseph
Joseph, en effet ce que Kniberg raconte paraît bien proche des fameux google days. On y viendra peut-être un jour, mais c’est encore plus dur à « vendre » au management.
Pour le ScrumMaster développeur dans une autre équipe, c’est une de nos inventions en effet, mais elle n’est pas sans inconvénient, ne serait-ce que par le « task-switching » qu’elle cause. Donc je ne la recommande pas trop. Il y a certainement mieux à faire.
En tout cas merci pour ta participation au fil de discussion et pour tes encouragements à publier :=)
Bruno
Chez Henrik Knibberg, ils font ainsi :
« One way to do this is “lab days” (or whatever you choose to call them).
That is, days where developers are allowed to do essentially whatever
they want (OK, I admit, inspired by Google). For example read up on the
latest tools and APIs, study for a certification, discuss nerdy stuff with
colleagues, code a hobby project, etc. »
A priori il n’y a pas d’évaluation de cette journée off en termes de productivité.
Concernant le scrum master développeur dans une autre équipe, c’est la première fois que j’entends une telle approche. Ceci dit, pourquoi pas, tant que le daily scrum a des horaires suffisamment différents. Cela ne pose t il pas non plus de problèmes pour les plannings/rétrospectives ? De même, les scrum masters se coordonnent ils de façon à répandre les bonnes pratiques ? Et y a t il un scrum master of the scrum masters ?
Ca me fait penser qu’un Scrum and Xp from Bruno Orsier’s trenches serait sans doute bien intéressant
joseph
@Joseph, en ce qui concerne le « pont » entre les équipes, le ScrumMaster d’une équipe est souvent développeur dans une autre équipe, et ainsi c’est lui qui fait le pont.
Chez nous, la journée « off » est tout de même transversale, avec toutes les équipes, et le contenu est relativement libre : la contrainte est surtout de réaliser quelque chose de concret dans la journée. On est tout de même loin d’un « google day » sans doute, ou les gens travailleraient sur des projets perso.
Merci pour les précisions sur les sprints « détendus ».
Bruno
Bonjour
Je relisais en diagonales Scrum and XP from the trenches (cf la dernière version http://www.infoq.com/minibooks/scrum-xp-from-the-trenches) et je suis tombé par hasard sur la partie « Spreading lessons learned between teams », en page 69. Henrik Knibberg y dit en substance qu’il ont une personne dédiée au rôle de « pont » entre les équipes afin de passer les bonnes pratiques. Cette personne assiste aux différentes rétrospectives et transmet les retours nécessaires à tous.
A mon sens, cela est distinct d’ailleurs du rythme des sprints et d’un éventuel essoufflement lié à ce dernier, qu’Henrik dit solutionner avec la journée « off ». A noter d’ailleurs que son approche est bien plus ouverte que la votre, tant par son aspect transversal à toutes les équipes (synchronisées sur un même jour off) que par son contenu laissé à l’appréciation de chacun… Donc pas quelque chose de franchement dédié à la communication de bonnes pratiques (même si cela doit aider).
Enfin, concernant notre pratique de sprints parfois plus détendus, cela n’est sans doute pas tant par les attentes liées au sprint qu’à son contenu : entre produire des fonctionnalités qui répondent aux attentes, comme dans 80% des sprints, et consacrer un sprint à de l’exploration (pour causes de nouveaux besoins) ou de la veille techno (pour l’amélioration continue), voir du refactoring, la nature même du sprint est suffisamment différentes pour introduire une variété appréciable et rafraichissante.
Joseph
@zedros, merci pour le témoignage. Chez nous les présentations se sont toujours essouflées, + passent à la trappe dès qu’il y a peu de pression dans le sprint… Donc on essaie cette nouvelle formule. Votre alternance de sprints est également très intéressante, mais sans doute pas non plus trop faisable dans notre contexte, la pression ne se relâchant jamais à l’échelle d’un sprint !
Bruno
@rad_hass, en effet on espère un résultat concret, et même un résultat dans la journée. Je suppose que ca pourra évoluer quand nous aurons plus de maturité et de recul. Mais je pense que mettre en avant l’aspect « résultat » était de toute manière important pour « vendre » l’intérêt de ces journées à nos managers.
Bruno
De notre côté nous fonctionnons avec des présentations qui ont une durée limitée (tant pour la présentation que pour les discussions qui s’ensuivent). Les temps sont, de mémoire car on ne les applique pas strictement, respectivement 20 et 25 min. Lorsqu’un sujet de présentation est retenu, on planifie alors cette tache dans un sprint (les règles sont : réutiliser le modèle type en latex + préparation de 2h max). Les présentations au lieu suite aux rétrospectives, le vendredi après midi. La cible étant d’une présentation par sprint.
Etant une petite structure, on n’a grosso modo que 2 équipes, du coup tout le monde assiste à toutes les présentations, avec parfois des petits décalages technologiques (technos utilisées un peu différentes).
Quoiqu’il en soit, c’est toujours intéressant : les équipes se mélangent, les sujets présentés sont variés et permettent de faire de la veille aisément. De plus, on présente aussi les nouvelles technos utilisées ou certaines réalisations qui méritent le coup d’oeil.
Enfin, concernant le rythme des sprints, on essaie d’alterner les sprints qui méritent vraiment leur nom avec d’autres sprints plus détendus (exploration, refactoring) afin que la pression se relâche à l’occasion. Après clairement faut avoir ces occasions…
Après, quand des thèmes d’améliorations ressortent, on les planifie comme n’importe quelle activité de sprint.
Super retour d’expérience, c’est une initiative très intéressante, j’avais beaucoup aimé l’idée en lisant le papier d’Henrik Kniberg, mais au contraire de ce que propose Henrik Kniberg vous dirigez plus les labs en attendant un résultat, ça risque de s’essouffler à long terme, non ?