Comprendre et appliquer Scrum : la différence cruciale

Dans le monde professionnel dans lequel j’évolue, je peux souvent lire, entendre et même participer à des débats sur la méthode Scrum qui, pour plusieurs, ne serait en fait pas une méthode, mais un cadre de travail.

Quand on regarde de loin, on peut se dire qu’on joue sur les mots. Quelle importance finalement? On utilise toutes et tous le même outil et les personnes qui débattent ne sont là que pour satisfaire leur égo.

Mais en réalité, c’est plus complexe que cela. Et d’ailleurs : si tout le monde avait raison? D’un côté la méthode Scrum, de l’autre le Scrum professionnel.

Alors, c’est quoi la méthode Scrum?

C’est quand Scrum est simplement appliqué.

Dans beaucoup d’équipes et/ou d’organisations, on « est en Scrum ». Ce sont les endroits dans lesquels on va mettre en place des cérémonies assez standardisées, des rôles comme écrits dans le guide Scrum. On retrouve donc bien des Sprint Planning (planifications de sprints), des Daily Scrums (Scrums quotidiens), des Sprint Reviews (revues de sprints) et des Sprint Retrospectives (rétrospectives de sprints). On identifie aussi des personnes sur les rôles de Scrum Master et de Product Owner, et on a même des équipes pluridisciplinaires. À première vue, tout semble fonctionner correctement!

Le problème, c’est que si on s’arrête là et qu’on applique Scrum comme une recette de cuisine, sans vraiment comprendre la philosophie sous-jacente, cela se traduit par des pratiques mécaniques et souvent inefficaces. Tu as d’ailleurs remarqué que j’ai bien parlé de cérémonies… C’est normal : alors que les événements Scrum sont conçus pour provoquer le changement, les cérémonies sont là… parce que « c’est Scrum qui le dit! ». On se retrouve donc souvent avec :

• des Daily Scrums sans valeur ajoutée : les membres de l’équipe se contentent de réciter ce qu’ils ont fait la veille, sans réelle discussion ni résolution de problèmes. On se retrouve davantage sur un rapport d’activité que sur un événement collaboratif;
• des Sprint Planning et sprints qui génèrent du gaspillage : les objectifs des sprints ne sont pas toujours clairs, ni même existants, et les équipes ont du mal à s’adapter aux changements de priorité à cause du manque de centralisation;
• des Sprint Reviews creuses : toute l’équipe a fourni des efforts pour terminer le Sprint (c.-à-d., fermer toutes les demandes du sprint). Le problème c’est que l’on court partout, on avance beaucoup de choses, mais sans alignement à des objectifs, on a du mal à livrer de la valeur à l’utilisateur ou l’utilisatrice;
• des Sprint Retrospectives superficielles : on connaît les problèmes, mais on n’a pas le courage de les affronter en face, alors on a tendance à se cacher sur des problèmes liés à l’organisation pour lesquels « on ne peut rien faire de toute façon ».

Et le Scrum professionnel?

C’est quand Scrum est compris et vécu.

En revanche, les équipes et organisations qui ont vraiment compris Scrum vont bien au-delà de l’application stricte du guide. Elles vont incarner les valeurs de Scrum dans leur quotidien et exploiter pleinement ses principes pour maximiser leur efficacité ainsi que la satisfaction de leurs utilisateurs et utilisatrices vis-à-vis de leur produit. Voilà ce qui va changer :

• des Daily Scrums dynamiques et collaboratifs : ces réunions sont des moments de réelle collaboration, par les développeurs/développeuses et pour les développeurs/développeuses. On fait face toutes et tous ensemble aux difficultés rencontrées et on s’ajuste quotidiennement pour atteindre notre objectif de sprint;
• des Sprint Planning et sprints alignés aux objectifs d’affaires : l’équipe travaille sur un objectif de sprint clair et pertinent, et ajuste son travail en fonction des rétroactions et des nouvelles priorités. On ne cherche pas à fermer l’ensemble de nos tickets avant la fin du sprint, on travaille collaborativement pour atteindre coûte que coûte notre objectif;
• des Sprint Reviews centrées sur l’utilisateur et l’utilisatrice : l’équipe cherche à avoir le plus de rétroactions possible sur ce qui a été construit pendant le sprint afin de se réaligner à son objectif produit et d’être sûre qu’elle est bien en train de répondre à la problématique actuelle de ses utilisateurs et utilisatrices;
• des Sprint Retrospectives profondes et constructives : tout le monde est ouvert et transparent sur le travail réalisé et la façon dont il a été réalisé. On trouve toutes et tous ensemble des pistes d’amélioration et on ne craint pas de régulièrement remettre en question son environnement direct (l’organisation, ses parties prenantes et même ses processus de livraison!).

Les clés de la différence

La différence entre ces deux approches tient dans la compréhension et l’appropriation des valeurs et des principes de Scrum. Comme on ne veut pas utiliser Scrum pour le plaisir d’utiliser Scrum, voici quelques clés pour passer d’une simple application de Scrum à une utilisation du cadre de travail :

1. Comprendre les valeurs de Scrum : les valeurs de courage, de focus, d’ouverture, de respect et d’engagement doivent être vécues au quotidien. Pour ça, n’hésite pas à t’inspirer des articles existants sur les valeurs de Scrum.
2. Favoriser la collaboration : les interactions entre les membres de l’équipe doivent être encouragées et valorisées.
3. S’adapter au changement : Scrum est conçu pour être flexible et répondre aux évolutions. Les équipes doivent être prêtes à revoir leurs priorités et ajuster leur travail en conséquence. Il n’est pas question de chaos, car on s’aligne toutes et tous à une même vision et un même objectif!
4. Valoriser l’amélioration continue : on ne peut pas être des champions dès le début, en revanche on veut être sûr d’aller dans la bonne direction. Tes rétrospectives doivent être des moments clés pour identifier des axes d’amélioration et mettre en place des actions concrètes (un pas à la fois, avec les valeurs de Scrum en tête).

Les équipes qui adoptent pleinement ces principes voient non seulement une amélioration de leur performance, mais aussi des gains concrets comme une réduction significative des délais de livraison, une meilleure qualité du produit ou encore une satisfaction accrue des utilisateurs et utilisatrices.

Conclusion

Finalement, pour moi, il est tout à fait correct que certaines équipes utilisent effectivement la « méthode Scrum ». Le fait est que beaucoup d’entre elles parviennent tout de même à livrer régulièrement de la valeur à leurs clients. Après tout, chaque organisation a ses propres contraintes et objectifs, et chaque organisation a des attentes différentes pour ses équipes. Ce qui fonctionne chez l’une ne fonctionnera probablement pas chez une autre!

Le plus important, c’est de comprendre la situation dans laquelle on se trouve et de mettre en mouvement une inertie (ou de le poursuivre) qui va tendre vers un Scrum de plus en plus professionnel. Et d’ailleurs, attention : ici, je parle de Scrum, mais le raisonnement peut être appliqué à n’importe quelle pratique de travail d’équipe, ou même de mise à l’échelle (on en parle beaucoup).

En tant que professionnel(le), on doit toujours avoir en tête que notre mission n’est pas de simplement appliquer un cadre (et de faire rentrer des ronds dans des carrés), mais d’accompagner son organisation et ses équipes vers une façon de travailler plus agile, en suivant notre boussole, le Manifeste Agile.