Comment fonctionne notre équipe Scrum — Témoignages d’un développeur de logiciels | de David Übelacker | décembre 2022

Réflexions sur Scrum et Agile

En 2016, j’ai changé d’emploi et j’ai finalement pu travailler en équipe en utilisant le framework Scrum. Toute l’entreprise était passée à Scrum peu de temps auparavant. À ce jour, la transition vers Scrum n’est toujours pas terminée, mais néanmoins, j’ai pu apprendre beaucoup sur le développement logiciel agile.

Je voudrais partager quelques expériences et réflexions que j’ai recueillies au cours des 6 dernières années. Pas du point de vue d’un coach agile ou d’un Scrum Master mais du point de vue d’un développeur de logiciels.

Dans Scrum, il est généralement recommandé que chaque personne ait un rôle clair et précis au sein de l’équipe, plutôt que d’avoir plusieurs rôles. En effet, le fait d’avoir des rôles clairs permet de s’assurer que chaque membre de l’équipe a une compréhension claire de ses responsabilités et de la manière dont il contribue au succès de l’équipe. Cela permet également d’éviter la confusion et les conflits d’intérêts au sein de l’équipe.

Bien sûr, nous ne nous sommes pas conformés à cela. Au début, un développeur assumait également le rôle du Scrum Master, plus tard nous avons même essayé de faire tourner le rôle du Scrum Master tous les trois sprints — pour que chaque développeur soit Scrum Master de temps en temps. Cela a conduit à plusieurs reprises à des conflits et a nui au succès de l’équipe.

Croyez-moi, il est logique d’avoir un Scrum Master bon et dévoué. Tout le monde n’a pas la bonne personnalité pour être un Scrum Master. Le Scrum Master n’est pas un assistant d’équipe, il est le leader serviteur de l’équipe, en possession des bonnes compétences et capacités pour aider une équipe Scrum à être plus efficace et efficiente et à conduire une amélioration continue de son processus. À mon avis, le rôle du Scrum Master est l’un des plus importants et il est certainement payant de le remplir en conséquence !

Dans Scrum, il existe trois rôles principaux : le Product Owner, le Scrum Master et l’équipe de développement.

1. Le propriétaire du produit est chargé de maximiser la valeur du produit et de s’assurer que l’équipe de développement travaille sur les éléments les plus précieux. Le Product Owner écrit des user stories, les hiérarchise dans le backlog du produit et communique avec l’équipe de développement sur ce qui doit être construit.
2. Le Scrum Master est chargé de faciliter le processus Scrum. Cela comprend l’animation de réunions, l’aide à l’équipe de développement et au Product Owner pour comprendre et suivre Scrum, et protéger l’équipe des distractions externes.
3. L’équipe de développement est responsable de la construction du produit. L’équipe de développement s’auto-organise et s’auto-gère et est chargée de terminer le travail nécessaire pour livrer un incrément de produit potentiellement livrable à la fin de chaque sprint. L’équipe de développement se compose de membres d’équipe interfonctionnels, tels que des concepteurs, des développeurs et des testeurs qui travaillent ensemble pour créer le produit.

Cette explication n’est pas nouvelle mais nous ne nous y sommes pas toujours tenus, nous avons mélangé les responsabilités et cela a toujours conduit à des conflits.

Un Product Owner et une équipe de développement

Il est possible pour une équipe de développement de travailler sur plusieurs produits, mais cela n’est généralement pas recommandé car cela peut entraîner des conflits d’intérêts et empêcher l’équipe de se concentrer sur un seul produit. Dans Scrum, l’équipe de développement est responsable de la construction du produit, et il est important pour elle d’avoir une compréhension claire de ce qui doit être construit et pourquoi. Si une équipe de développement travaille sur plusieurs produits, il peut être difficile pour elle de rester concentrée et de hiérarchiser efficacement son travail.

Nous avions plusieurs Product Owners et travaillions sur plusieurs produits en même temps. Cela a conduit les propriétaires de produits à se disputer l’équipe et les développeurs à être frustrés parce qu’ils travaillaient constamment sur autre chose.

Ne mélangez pas les hiérarchies de gestion classiques avec les rôles Scrum

Ni le Product Owner ni le Scrum Master ne doivent être supérieurs aux autres membres de l’équipe.

L’équipe de développement s’organise et s’autogère, et elle est chargée de déterminer la meilleure façon de terminer le travail nécessaire pour livrer un incrément de produit potentiellement livrable à la fin de chaque sprint. Le Product Owner et l’équipe de développement travaillent ensemble en tant qu’équipe collaborative, le Product Owner fournissant des conseils sur ce qui doit être construit et l’équipe de développement déterminant comment le construire.

Il est important que le Product Owner et l’équipe de développement entretiennent une relation de confiance solide et travaillent ensemble efficacement pour assurer le succès du produit. Le Product Owner doit respecter l’expertise et l’autonomie de l’équipe de développement et ne doit pas essayer de microgérer l’équipe ou dicter comment le travail doit être effectué.

Si le propriétaire du produit est également le supérieur, il y a un risque qu’il abuse de son pouvoir et s’affirme contre l’équipe de développement. Cela conduit à ne pas exploiter le potentiel de l’équipe, car elle ne peut pas vraiment travailler de manière organisée.

Product Owner avec une formation technique

Avoir une formation technique peut aider le Product Owner à mieux comprendre les capacités et les limites de la technologie utilisée pour créer le produit, et à communiquer efficacement avec l’équipe de développement sur ce qui peut et ne peut pas être fait. Cependant, il n’est pas essentiel que le Product Owner ait une compréhension approfondie des détails techniques du produit.

Dans notre cas, un de nos PO avait une formation très technique. Par conséquent, il a écrit des histoires très techniques et a également pris des décisions d’architecture sans impliquer l’équipe de développeurs.

Les développeurs ne sont pas les esclaves du propriétaire du produit, pas de stupides singes du code. Ils ont besoin d’un défi et veulent trouver ensemble la meilleure solution.

Si un propriétaire de produit dicte tout et que l’équipe de développeurs ne se sent pas coresponsable du produit, le développement logiciel agile et le principe d’équipes organisées ne fonctionneront pas.

Dès le début, nous avons suivi la devise selon laquelle tous les membres de l’équipe doivent pouvoir tout faire. Nous voulions des généralistes, pas des spécialistes.

Cela avait en premier lieu, du moins en théorie, le gros avantage que si quelqu’un quittait l’équipe – était malade ou était en vacances – il n’y avait pas de dépendances et quelqu’un d’autre dans l’équipe pouvait reprendre ses tâches.

De plus, le travail était varié pour tous les membres de l’équipe et nous pouvions travailler sur des tâches de sprint selon le principe du pull.

Je pense qu’il n’y a rien de mal à cela. Cependant, il y a quelques éléments à prendre en considération :

1. Si tous les membres de l’équipe peuvent tout faire, tout le monde peut vouloir participer à toutes les décisions. Cela peut à son tour conduire à des processus de prise de décision longs et fastidieux et ralentir l’équipe.
2. À mon avis, chacun veut son propre truc, quelque chose dont il est le premier responsable. Quelque chose avec lequel ils peuvent avoir du succès et gagner le respect des autres.

Pour cette raison, je recommande également que les généralistes confient la responsabilité des domaines techniques et spécialisés à des membres individuels de l’équipe. Non pas que ceux-ci en aient alors la responsabilité et le pouvoir exclusifs, mais que des personnes individuelles soient responsables de domaines et les fassent progresser avec l’équipe.

Idéalement, votre produit évoluera de MVP à un produit amélioré et meilleur. Vos clients veulent de plus en plus de fonctionnalités, les bugs et les problèmes techniques deviennent de plus en plus nombreux et doivent également être traités.

Bientôt il arrivera que l’équipe ne gérera pas tout et donc l’équipe devra s’agrandir. Si vous comptez du coup plus de 10 personnes dans le Quotidien et que vous avez du mal à suivre tout le monde, vous avez raté le bon moment pour évoluer en fonction de la charge de travail.

Je ne peux que recommander de traiter le sujet de la mise à l’échelle dès le début et d’élaborer un plan avec l’équipe. C’est un sujet très difficile lorsque plusieurs équipes doivent travailler simultanément sur un produit de la manière la plus indépendante possible.

Pour plus de détails dans ce contexte, je recommande le livre “Team Topologies” (https://teamtopologies.com/), le Squad Framework de Spotify et le modèle SAFe.

Soyez patient si vous voulez travailler selon scrum. Embaucher de l’aide, des coachs agiles externes ou des membres d’équipe expérimentés qui travaillent avec Scrum depuis plusieurs années, ça vaut le coup. Il ne suffit pas de lire un livre et d’obtenir le certificat Scrum Master pour travailler de manière significative avec Scrum.

Il ne s’agit pas de faire Scrum pour le plaisir de faire Scrum, il ne s’agit pas de respecter les règles, il s’agit d’établir une manière agile de faire les choses qui surmonte les vieilles habitudes et les problèmes et vous permet d’exploiter le plein potentiel de tous les membres de votre équipe et faire beaucoup plus.

Cela ne fonctionne que si l’entreprise dans son ensemble s’adapte à une méthode de travail agile. Rappelez-vous toujours le manifeste agile et rappelez à votre direction son contenu. Surtout quand ils proposent de nouveaux processus, outils, bureaucratie, documentation, planification insensée et microgestion inutile.