C'était aujourd'hui la première rétrospective de sprint de ma seconde équipe,(vous savez, mon équipe de tueurs). Il faisait beau. C'était vendredi. La fin du sprint (forcément!). D'un premier sprint ambitieux, avec des contenus à risques potentiels, pour de nouveaux collaborateurs qui montaient en marche dans le train de nos "vieilles" applications. D'un sprint plutôt bien réussi, pleinement agile, sans cahier des charges. Et même une user story qui reste sur le carreau, après une phase d'analyse qui s'avère amener peu de plus value, remplacer par l'ajout d'un peu plus de contenu à une autre. Toujours aller vers l'efficacité. Ne pas se perdre dans les méandres des bois du cerf, mais bien suivre la corne de la licorne.
Il faisait beau, disais-je...Je proposai donc de mener cette rétrospective de sprint en terrasse, plutôt qu'au sein de la War Room un peu surchauffée de ces derniers temps par nos neurones en ébullition. Et nous voilà donc tous partis, vers les 15 heures, moi, avec mon bloc note sous le bras et le team, les mains dans les poches. Nous nous sommes installés confortablement, à la première terrasse avenante, rapprochant les tables et les chaises. La commande prise, j'animai la rétrospective, ponctuée de quelques petits commentaires sur scrum en général et notre projet en particulier.
L'un des "What Went Well" évoqués fut l'usage de la méthodologie scrum, justement. Et sa pratique au quotidien. La découverte de l'intérieur d'une équipe scrum. Un autre WWW était aussi relié à scrum : il s'agissait de l'impression de confiance donnée à chacun. Ce qui me permettait de faire quelques comparaisons entre un projet traditionnel, avec son chef de projet qui place son équipe sous contrôle, un peu à la manière des usines d'autrefois où le contremaître surveillait les ouvriers à la baguette. Et un projet scrum, dans lequel le chef de projet s'est effacé pour laisser place au scrum master, qui ne contrôle pas, mais permet à l'équipe de s'auto-organiser, qui ne dirige pas mais anime, fluidifie les échanges entre collaborateurs, tente d'aplanir les obstacles et difficultés qu'ils peuvent rencontrés, bref, cherche à amener chacun naturellement vers le maximum de ses capacités. En effet, quand un chef de projet affecte les tâches aux membes de son équipe, il le fait en se basant sur ce qu'il croit que chacun est capable de faire. Et si un collaborateur peut faire plus? Comment le saura-t-il, puisqu'il ne lui aura rien confié qui dépasse les compétences supposées?
Pour ma part, j'avais un petit "What We Can Do Better" sur mon organisation personnelle : scrum master sur la première équipe, scrum master et product owner sur la seconde, ce n'est pas si facile tous les jours, surtout au ddébut, et cela demande, outre une bonne dose d'énergie, quelques règles de fonctionnement individuel que je me mets moi-même en place au fur et à mesure.
Commentaires