Confessions d’une Scrum Master – 2ème partie : Comment devenir pro du Scrum par Guylaine Drolet

N’est-ce pas fâchant quand quelqu’un met des ananas sur une pizza et ose encore appeler ça une pizza? Je blague, mais c’est précisément cette déception que je ressens lorsque je vois des gens se prévaloir de la méthode Scrum sans avoir le bon état d’esprit.

Alors servez-vous un café et laissez-moi vous expliquer pourquoi on me qualifie d’agent de changement.

(Si vous n'avez pas encore lu le premier billet de cette série, je vous invite à le faire maintenant!)

Si une équipe met en œuvre toutes les cérémonies Scrum, pourquoi a-t-elle besoin de toi?

Ouch! Votre question fait mal, mais elle est honnête. Ce n’est pas en organisant la planification, la rétrospective et la revue des sprints qu’on devient automatiquement agile. Je crois que c’est ce qu’il faut d’abord et avant tout comprendre. Adopter les méthodes Kanban, Lean, XP ou même Scrum sans être agile en premier lieu donne place à… quelque chose, mais quelque chose qui ne correspond pas à ces méthodes.

Ces méthodes sont profondément ancrées dans l’état d’esprit agile et sans celui-ci, elles sont incomplètes.

Mais comprenez-moi bien : la méthode Scrum peut aider. Elle permet de boucler certaines tâches en 2 à 3 semaines plutôt qu’en plusieurs mois. Mais en fin de compte, vous faites le même travail que si vous adoptiez le modèle en cascade.

Au milieu de toute la préparation et des cérémonies, je dois m’assurer que l’équipe Scrum et l’entreprise dans son ensemble adoptent tous l’état d’esprit agile. Et pour y arriver, croyez-en mon expérience, les obstacles sont nombreux.

Quelle est la différence entre la méthode agile et le modèle en cascade?

Le modèle en cascade s’attaque aux différentes parties du projet les unes à la suite des autres. Son objectif est de faire les choses dans un certain ordre et de maintenir le cap sur le parcours prédéterminé.

La méthode agile est pour sa part un processus itératif qui prend la forme à gauche.

Et on recommence pour chaque itération. L’agilité est menée par les objectifs plutôt que par la portée du projet. 

Les valeurs agiles aident à mieux comprendre la méthode: 

  • Les individus et les interactions sont plus importants que les procédés et les outils 
  • Un logiciel fonctionnel est plus utile que la documentation exhaustive 
  • La collaboration avec le client est à privilégier à la négociation de contrats 
  • L’adaptation au changement prévaut sur le respect du plan 

Je vais maintenant emprunter une tangente, parce que je crois que les gens doivent comprendre que ce n’est pas parce que je suis Scrum Master que tout ce que je fais doit être agile.  

Je n’y crois tout simplement pas. 

La méthode agile ne fonctionne pas pour tous les modèles de travail et parfois, le modèle en cascade constitue le choix le plus judicieuxAlors posez-vous cette question avant de commencer votre transition vers la méthode agile. Par exemple, bâtir une maison : ne le faites pas selon l’approche agile Ça serait absolument terrifiant. 

Pourquoi adopter la méthode agile, dans ce cas-là?

Un propriétaire de produit avec lequel j’ai déjà travaillé avait l’habitude de dire que toute fonctionnalité sur laquelle on travaille est soit :

  • Déjà proposée par un compétiteur ou
  • Déjà en retard. Attendre n’est pas une option.

J’ai souvent entendu des gens dire que « la méthode agile permet une livraison plus rapide ». Ce n’est pas vrai. Et ce n’est pas le but de la chose.

La rapidité n’est pas la raison d’être de la méthode agile. Elle vise d’abord et avant tout à livrer la bonne chose. Et on ne livre pas plus que ce que le client a demandé, mais bien exactement ce qu’il désire. La valeur de la méthode est fondée sur les besoins du client.

Ainsi, on ne commence pas avec un projet de grande envergure, mais plutôt avec quelque chose qui fonctionne. Une chose très simple qui fonctionne. Une chose TRÈS, TRÈS simple et minimaliste qui fonctionne.

C’est ce qu’on appelle un produit minimum viable, ou MVP en anglais.

Si on lançait un produit minimum viable sur le marché maintenant, il fonctionnerait, et on serait déjà capables d’en évaluer les points forts et les points faibles. Un produit minimum viable permet de raccourcir la boucle de rétroaction, ce qui est crucial pour bâtir la bonne chose. Nous pouvons ensuite bâtir sur ses bases, en restructurant le processus au besoin. Ici, l’itération est la clé!

Lorsqu’on échoue, mieux vaut le faire aussi rapidement que possible pour pouvoir se remettre sur la bonne voie et apprendre de nos erreurs. Et je dis bien « lorsqu’on échoue » plutôt que « si on échoue » : les échecs sont inévitables et notre environnement doit les permettre.

Pour une perfectionniste comme moi, c’était là une notion très difficile à accepter lorsque j’ai troqué mon chapeau de développeuse pour celui de Scrum Master. Ma tête était remplie de questionnements et j’avais peur de bâtir quelque chose de chambranlant et d’inapproprié.

Mais c’est également à ce moment-là que j’ai appris à faire confiance.

Le propriétaire de produit avec qui je travaillais à l’époque m’a dit que tout était une question de confiance. Il m’a fait confiance en me demandant de m’assurer qu’il était efficace et qu’il communiquait adéquatement avec l’équipe de développement, et il a fait confiance à celle-ci pour prendre les bonnes décisions et créer de la valeur.

Qu’est-ce qui est gage de succès pour un Scrum Master?

Tout ce que j’ai mentionné précédemment! Être Scrum Master ne s’arrête pas aux cérémonies Scrum – c’est bien plus que ça. Être Scrum Master, c’est essayer de promouvoir une culture que certains adoreront, qui laisseront certains indifférents et que d’autres détesteront. À titre de Scrum Master, il faut jongler avec tout ça.

Mais le succès de la méthode Scrum n’est pas tributaire d’une seule personne ou d’un simple état d’esprit. Il nécessite une équipe hautement interfonctionnelle, où tous les employés possèdent la liberté nécessaire pour devenir la meilleure version d’eux-mêmes.

Développez les jeux mobiles de demain, dès aujourd'hui!