Sabrina Ferlisi Le but de cet article est de présenter une équipe Scrum réelle et les différents éléments qu’elle a mis en œuvre pour s’améliorer (techniques, ateliers, postures, …). Il met en avant plusieurs aspects importants pour améliorer l’efficacité d’une équipe Scrum comme les conflits d’équipe, l’utilisation de métriques, la qualité des rétrospectives, la qualité du produit, l’importance de la sécurité psychologique, l’environnement d’apprentissage et l’apprentissage partagé. Il s’agit du premier article d’une série de cinq.
J’ai reçu une demande : écrire un article sur le fonctionnement d’une équipe Scrum que j’accompagne en tant que Scrum Master pour inspirer d’autres équipes. L’idée de mettre en avant cette équipe, non pas pour vanter ses mérites, mais pour partager les leçons apprises, était séduisante. J’ai pu observer nos évolutions, nos succès et nos défis, et en particulier sur cette dernière année où nous avons été embarqué dans la transformation digitale de l’entreprise. Lors de mes réflexions et discussions avec l’équipe au sujet de cet écrit, je suis tombée sur cet article de Christiaan Verwijs qui m’a offert une structure pour organiser mes pensées. De plus, afin d’en faciliter la lecture, j’ai ajouté à chaque section un tableau résumant les pratiques, techniques, ateliers que nous avons mis en place, en espérant que cela vous donne des idées.
Avant de plonger dans notre expérience, un mot sur le modèle que j’ai utilisé : il provient d’une étude approfondie sur 1200 équipes Scrum. Grâce à leurs recherches, Daniel Russo et Christiaan Verwijs ont esquissé une théorie sur ce qui fait qu’une équipe Scrum excelle et ont modélisé 5 axes principaux. J’alignerai mon partage autour de ces 5 axes, en y injectant des anecdotes de notre parcours.
Ce premier article se concentre sur l’axe « Amélioration continue ». L’amélioration continue est le pilier de toute équipe Scrum. Elle est l’essence même de l’agilité. J’aimerais ici évoquer quelques aspects distinctifs qui caractérisent notre équipe.
Qualité des Rétrospectives
Pour nous, les rétrospectives sont une boussole. Elles offrent un espace pour réfléchir, critiquer constructivement et s’améliorer. Seraient-elles aussi suivies si je n’étais pas là, en tant que Scrum Master, pour pousser un peu ? Pas certain. Mon regard extérieur et mon expertise facilitent des discussions parfois délicates ou qui ne sont pas vues par le reste de l’équipe. Cependant, chaque membre de l’équipe y voit de la valeur et est désireux de participer.
Les actions prises en cours de rétrospectives sont suivies et révisées régulièrement. Plusieurs rétrospectives ont d’ailleurs mené à des changements significatifs. Je pense en particulier à des améliorations sur « comment avoir plus de Done à la fin de chaque Sprint », la revue du format du Daily Scrum, le split des Product Backlog Items, la mise en place des pratiques Kanban et la mise à jour régulière de la Definition of Done. Nous avons aussi parfois essayé des pratiques, comme le Pair Programming, que nous avons maintenu, sans suivre la littérature à la lettre et en l’adaptant à nos besoins.
L’une des composantes essentielles pour que les rétrospectives soient de qualité, c’est l’ouverture aux changements et aux remises en question.
Gestion saine des conflits
Les conflits, s’ils sont traités de manière constructive, peuvent être bénéfiques. Ils incitent à la réflexion, à la remise en question et souvent à une meilleure compréhension mutuelle.
Trouver sa place
L’une des sources majeures de tension dans une équipe est liée à une confusion dans les rôles et responsabilités dans la prise de décision.
Dans notre équipe, la place de chacun est claire et pourtant nous n’hésitons pas à nous entraider en sortant de notre « zone de travail ». Il est prévu dans notre flot de travail que le Product Owner vérifie en fin de développement ce qui a été fait. Il arrive de temps en temps que le PO n’ait pas le temps, les Developers prennent alors en charge cette tâche sans rechigner, ni avoir peur.
La clarté des rôles et la flexibilité sont donc essentielles. Cela est rendu possible grâce à des règles d’équipe clairement établies, qui évoluent au besoin. L’une des pratiques mise en place depuis un certain temps consiste à définir des rôles spécifiques par sprint pour faciliter le flux de travail. Nous avons par exemple, le Keyboard manager, qui est la personne durant les séances qui va mettre à jour le contenu des tickets Jira en fonction des discussions qui ont lieu (particulièrement lors des refinements). De cette manière, nous avons des rôles tournants, nous ne sommes pas bloqués si quelqu’un est absent. Une telle transparence élimine l’ambiguïté et renforce notre cohésion.
Pourtant, notre équipe est composée de talents diversifiés, y compris des personnes travaillant en nearshore ce qui pourrait amener des disparités dans l’importance que chaque personne a dans l’équipe et de fait des frustrations pourraient émerger. Dans cette équipe, tous les membres sont traitées équitablement, les voix de chacun sont valorisées et elles sont intégrées dans toutes les discussions et prises de décisions. L’histoire de notre apprenti est un parfait exemple : lorsqu’il a constaté que ses pull requests étaient examinées rapidement, il a compris qu’il était pleinement intégré, qu’il avait sa place parmi nous et que son travail avait de la valeur.
De plus, cette considération de chaque individu crée un environnement où chacun peut se tromper, apprendre et avancer sans que cela dégénère en conflit, reproche ou blâme. D’ailleurs, je me souviens de cette fois où, en tant que Scrum Master, j’ai créé une petite pagaille dans Jira. Le Product Owner m’a signalé mon erreur et j’ai appris à être plus vigilante, tout simplement.
Confiance mutuelle
L’une des forces de l’équipe est de savoir se responsabiliser mutuellement, j’entends par là que les membres n’ont pas peur de rappeler les engagements pris, les règles d’équipe à un autre membre, tout ceci avec bienveillance, assurant que chaque membre se sente valorisé et respecté. Dire clairement ce qui se passe permet d’éviter les non-dits et les ressentiments qui escaladent souvent en conflit.
Pour en arriver à cela, la confiance doit être présente et c’est une des bases de notre équipe. Quand un échec se produit, il est vu comme un échec collectif plutôt qu’individuel. Il nous arrive, évidemment, malgré tout (nous sommes humains), de nous tromper ou de surréagir. Par exemple, lors d’une altercation entre un développeur et le Product Owner, spontanément, des excuses ont été présentées, permettant à l’équipe de repartir sur de bonnes bases.
Nous croyons fermement que chacun au sein de l’équipe fait du mieux qu’il peut. Les discussions sont constructives et l’accent est mis sur la solution plutôt que sur le problème. Par exemple, lorsque nous travaillons en refinement à trouver une solution adéquate et que les demandes faites par le Product Owner ne peuvent pas être réalisées, les développeurs sont force de propositions pour trouver des alternatives. Lorsque nous avons le sentiment qu’un membre ne joue pas le jeu ou pourrait s’améliorer, nous n’hésitons pas à donner du feedback, en rétrospective ou en face à face.
Sécurité psychologique
La confiance, l’écoute, le courage et la transparence ne sont pas de simples mots pour nous, mais des valeurs que nous vivons au quotidien. L’ouverture de l’équipe à d’autres pratiques autour de l’humain permet également de renforcer ces valeurs ainsi que la gestion saine des conflits. Nous avons par exemple exploré ensemble des tests de personnalités et également la Communication NonViolente.
Utilisation de Métriques
Notre équipe utilise les pratiques Kanban au sein de Scrum ce qui nous amène à avoir un œil particulier sur notre flux et sur des métriques comme le Cycle Time, le Service Level Expectation et l’âge des éléments du Product Backlog.
Toutefois, un point reste à améliorer : autrefois centrés sur le Product Goal, les métriques actuels sont plus internes et moins axés sur la valeur du produit. Ceci est lié à notre rôle d’exécutants, sans pouvoir décisionnel direct sur la stratégie. Mais j’y reviendrais dans un prochain article…
Le souci de la qualité
La qualité est au cœur des préoccupations de toute l’équipe dans son ensemble, nous veillons à ce que notre produit soit à la hauteur de nos standards.
L’équipe suit strictement la Definition of Done, par exemple en prenant soin de faire des code review minutieuses et utiles, à la fois pour l’amélioration du code, mais également pour l’amélioration des compétences du développeur. Nous avons par le passé constaté certains oublis d’éléments présents dans la Definition of Done. Pour éviter cela, nous avons mis en place une Check-List au Sprint Planning. À chaque fin de planning, nous passons en revue cette Check-List pour nous poser la question, par exemple, si l’un des éléments sélectionnés nécessite une documentation ou des tests graphiques. De cette manière, nous ajoutons un rappel dans l’élément pour que cela ne soit pas oublié durant le sprint.
Des tests variés sont effectués régulièrement, que ce soit des tests automatiques (end-to-end, unitaire, graphique) ou manuel. Nous avons la chance d’avoir une personne dédiée au testing au sein de l’équipe et qui permet d’améliorer la qualité du produit. Ces différentes actions nous permettent de limiter le nombre de bugs créés. Ceux qui sont tout de même découverts sont pris en compte par l’équipe et triés par priorité.
Un effort important est également accordé à la mise à jour des plateformes techniques. Chaque personne dans l’équipe est consciente de l’importance de rester à jour et nous valorisons ce travail nécessaire, même si cela prend du temps à la place de développer de nouvelles fonctionnalités.
Enfin, nous sommes sensibles à ne pas accroître la dette technique et nous n’hésitons pas à effectuer du refactoring si le besoin se fait sentir. Nous sommes conscients que cela est nécessaire lorsque nous développons par itération.
Environnement d’apprentissage
L’équipe est avide de feedback et de remise en question. Des ateliers, tels que ceux sur le feedback, renforcent cette culture.
La curiosité nous pousse à explorer les dernières technologies et à ne jamais stagner. Les développeurs ont été moteur pour l’adoption des dernières versions des plateformes technologiques.
Apprentissage partagé
Des techniques variées telles que le Pair Programming, Crowd Programming, Exploration Day et des sessions de partage de connaissances sont fréquentes et tout le monde est encouragé à contribuer. La collaboration est au centre : si un membre de l’équipe demande de l’aide, elle lui est offerte sans hésitation. Nous ressentons la force de l’équipe comme une entité propre, nous travaillons ensemble (souvent sur des mêmes tâches) afin d’atteindre notre but au plus vite et du mieux possible.
Cet article n’est que le début de l’exploration de ce qu’une équipe Scrum peut accomplir lorsqu’elle est capable de collaborer, d’évoluer et de s’adapter. Avec la bonne attitude et les bons outils, l’excellence est à portée de main.
