Organiser l’agilité : les 8 erreurs du Scrum Master

Halte aux idées reçues ! Réussir son passage à une organisation agile n’est pas si facile ! La preuve avec Oussema Ghodbane qui a répertorié les 8 erreurs les plus fréquemment commises par les Scrum Masters en termes d’organisation de l’agilité.

Alors que les méthodes agiles et Scrum sont de plus en plus répandues, on dénombre néanmoins de plus en plus d’échecs lors de leur mise en place. La raison : ces échecs sont souvent liés à la sous-estimation des changements qu’elles impliquent. Afin de vous aider à adopter au mieux la culture agile dans vos projets, voici quelques erreurs à éviter et idées reçues à bannir.

Dès qu’il s’agit d’agilité, certaines erreurs contreproductives persistent encore et mènent souvent à l’échec. Ces erreurs s’expriment le plus souvent à deux niveaux : d’un point de vue organisationnel – comment organiser mes équipes, mes projets, mes départements en interne autour de l’agilité – et d’un point de vue humain – comment gérer mes équipes.

Dans cette 1^re partie de notre série consacrée aux erreurs du Scrum Master à ne doit pas commettre, nous nous attacherons à présenter les plus fréquentes en termes d’organisation.  

#1 : pratiquer sans respecter les principes de la méthode Scrum

Pratiquer les événements Scrum, remplir les rôles Scrum et utiliser les artefacts Scrum peuvent donner l’impression que les pratiques Scrum sont correctement mises en œuvre. Cependant, ce n’est que la moitié du chemin parcouru pour qu’une entreprise devienne agile. Pratiquer le framework de Scrum sans pratiquer les principes agiles ne rendrait pas l’organisation durable à long terme. Souvent, le Scrum Master néglige de mettre en œuvre le principe agile pendant la pratique de Scrum.

Comme les principes sont beaucoup plus difficiles à incorporer que les pratiques, de nombreuses entreprises échouent et ne réalisent pas les parties les plus difficiles. Le Scrum Master doit d’abord comprendre les principes et appliquer les techniques en comprenant pleinement pourquoi il le fait. L’agilité concerne les personnes, les interactions et la culture, et non les processus, les pratiques et les outils. Par conséquent, le Scrum Master et l’ensemble de l’équipe Scrum doivent toujours intégrer les principes dans leurs pratiques.

#2 : attendre que quelqu’un d’autre prenne l’initiative d’un changement

Souvent, le Scrum Master pense qu’une personne est responsable d’initier un changement lorsque l’organisation n’avance pas. Il devient alors réticent à initier un changement, et ne s’approprie pas ou ne prend pas le leadership de l’organisation. Attendre que quelqu’un d’autre initie un changement est une erreur courante commise par le Scrum Master. Il est de la responsabilité de chaque individu d’initier un changement ! Au Scrum Master alors de devenir un agent du changement et de prendre la responsabilité de transformer l’organisation en une entreprise agile plus efficace.

#3 : s’attendre à une transformation agile Scrum facile

Les Scrum Masters sont souvent engagés par des entreprises pour transformer l’organisation en un environnement agile. On attend d’eux qu’ils transforment facilement le modèle de travail de l’entreprise et qu’ils apportent tous les avantages de l’agilité. Mais se contenter de découper le besoin utilisateur en « user stories », de commencer les stand-ups quotidiens et de développer des logiciels en deux ou trois semaines ne devrait pas être considéré comme agile.

Les Scrum Masters devraient envisager de mettre à profit la période initiale de mise en œuvre de la méthode agile pour prendre le temps d’insuffler un état d’esprit agile au sein des membres de l’organisation. Le début sera toujours désordonné et la transformation peut également mettre en avant certains problèmes corporate et culturels existants. Or il importe de prendre en charge tous ces problèmes – tels que la mauvaise communication, le manque de responsabilité, la méfiance, etc. En effet, une transformation agile efficace inclut un changement de culture au sein de l’ensemble de l’organisation. Tous les membres de l’organisation, y compris le Scrum Master, doivent donc consacrer le temps nécessaire pour que cette transformation puisse avoir lieu efficacement. 

#4 : avoir un backlog produit qui n’est pas prêt

Un backlog de produit qui n’est pas « prêt » est l’une des causes d’échec d’un sprint et du manque de motivation des équipes les plus courantes. C’est également une raison fondamentale de la baisse de vélocité de l’équipe. La plupart des nouveaux product owners ne sont pas prêts à être productifs par eux-mêmes. Devenir product owner peut prendre beaucoup de temps. Ils ont besoin d’instructions, de coaching et de soutien pendant les premiers sprints pour apprendre à développer et à maintenir un backlog de produit contenant suffisamment de fonctionnalités, estimées à un niveau élevé et classées par ordre de priorité en fonction de la « business value ».

Il est indispensable de préparer le backlog bien avant le(s) prochain(s) sprint(s). Vous ne voulez jamais que l’équipe soit à court de travail à faire, travail qui doit être de la plus haute valeur à ce moment-là, selon les priorités du product owner. Donc définissez les bonnes attentes, fournissez toutes les formations nécessaires et aidez le product owner à maintenir le flux de valeur.

#5 : ne pas respecter l’objectif du sprint

Le processus agile et de Scrum établit un certain nombre d’attentes explicites. Parmi lesquelles : pendant la planification du sprint et le travail sur le backlog du sprint, l’équipe s’engage sur un ensemble de travaux que les développeurs peuvent réaliser pendant le sprint. Le Scrum Master a alors pour rôle de faciliter le processus de planification du sprint, ainsi que de travailler avec l’équipe de développement pour déterminer à tout moment si ce sur quoi elle travaille est appropriée et dans l’esprit de l’achèvement du travail du sprint.

Une erreur fréquente commise par un Scrum Master est de rester les bras croisés alors que les user stories ou les éléments engagés dans le sprint en cours débordent sur un sprint ultérieur. Une façon d’éviter cette erreur est de coacher l’équipe sur les moyens d’éviter ce piège commun. Une partie de ce piège se produit lorsque le Scrum Master ne conseille pas correctement à l’équipe de s’en tenir au sprint en cours comme prévu initialement. Des erreurs peuvent se produire à cette occasion, mais il incombe au Scrum Master de s’efforcer d’aider l’équipe à planifier en conséquence et à résister aux changements de sprint en cours de route. Les équipes ne doivent s’engager et n’exécuter que le travail réalisable dans le délai défini pour le sprint.

#6 : ne pas soulever les obstacles suffisamment tôt

L’une des principales fonctions du Scrum Master est de communiquer les obstacles afin que le travail soit effectué efficacement. Attendre de soulever un obstacle jusqu’à ce qu’il soit devenu un problème plus important est l’une des erreurs fréquentes que commettent les Scrum Masters. Ce n’est que lorsque l’incrément du produit est entièrement développé que le Scrum Master identifie l’erreur de l’équipe de développement. Cependant, jusqu’à cette phase, beaucoup de temps et d’efforts ont été consacrés au processus. Cela conduit à un retard dans la livraison du produit et aussi à une mauvaise qualité du produit fourni. Pour éviter ce problème, le Scrum Master doit identifier tout problème avant que l’ensemble des développeurs n’y travaillent.

Les membres de l’équipe doivent être encouragés à communiquer pendant les réunions quotidiennes pour faire part de tout problème qui risque d’entraver leur travail et qui doit être signalé immédiatement au Scrum Master. Le Scrum Master doit ensuite rappeler à l’équipe d’évoquer tout obstacle potentiel susceptible de provoquer un blocage, afin d’éviter de tels scénarios. S’il y a la moindre chance que quelque chose puisse retarder leur travail, il est toujours bon de le porter à la connaissance de l’ensemble de l’équipe et du Scrum Master lors des stand-ups quotidiens.

#7 : mener des stand-ups quotidiens laxistes

Le stand-up est un événement Scrum qui a lieu chaque jour et au cours duquel les membres de l’équipe de développement discutent de leurs réalisations de la veille et de leur programme pour la journée. Il joue un rôle crucial dans la communication, la collaboration et la compréhension entre les membres de l’équipe. Bien que le Scrum Master ne doive pas nécessairement organiser des réunions quotidiennes de Scrum, il les facilite généralement, en particulier lorsque les équipes en sont encore au stade initial. Le fait de ne pas organiser de stand-up quotidien ou d’avoir des stand-ups quotidiens laxistes, dans lesquels les conversations ne portent pas sur le sujet, signifierait que les membres ne sont pas connectés et n’ont pas de vision sur les idées qu’ont les autres pour le projet.

Le Scrum Master doit diriger ces stand-ups quotidiens et veiller à ce que ces réunions soient limitées dans le temps. Ces stand-ups ne devraient donc pas durer plus de 15 minutes, et devraient viser à apporter plus de transparence et de visibilité quant au projet donné. Un « meet after » peut-être mis en place après le Daily pour traiter les sujets abordés, et ainsi ne pas rallonger le stand-up.

Pour éviter toute ambiguïté dans les stand-ups quotidiens, vous devez répondre à ces trois questions :

• Qu’est-ce qui a été accompli hier ?
• Quels sont les objectifs à atteindre aujourd’hui ?
• Quels sont les obstacles rencontrés au cours du processus de développement ?

Les réunions quotidiennes doivent être organisées pour discuter des problèmes et des défis à relever. Elles peuvent se dérouler en mode distribué. Le Scrum Master et les autres membres doivent effectuer cette tâche de manière continue.

#8 : ne pas organiser de réunions rétrospectives après chaque sprint

Les réunions de rétrospective de sprint sont l’un des événements les plus importants de Scrum. Elles sont menées pour que les membres de l’équipe puissent comprendre quelles erreurs ils ont commis dans le sprint précédent et en tirer des leçons afin de ne pas les répéter dans les sprints à venir. Certains Scrum Masters peuvent penser que les rétrospectives ne valent pas la peine d’être effectuées et qu’elles prennent beaucoup de temps. Donc ils les ignorent et conduisent d’autres événements Scrum.

C’est l’une des erreurs courantes des Scrum Masters qui doit être évitée. La tenue de réunions rétrospectives peut aider l’équipe à évaluer un projet et à accroître son efficacité. Les équipes peuvent prendre des notes détaillées sur le travail effectué, les tâches en attente, ce qui leur permettra de développer un développement continu.

Voici quelques avantages importants des rétrospectives :

• Elles fournissent aux membres de l’équipe un espace pour exprimer leurs points de vue et leurs opinions d’une manière efficace ;
• Elles permettent à l’équipe Scrum de devenir plus agile ;
• Elles accélèrent le processus de développement à travers le process d’inspection et d’adaptation ;
• Elles constituent souvent un moyen et une opportunité de favoriser l’échange et la cohésion de l’équipe.

Conclusion

Comme les erreurs sont inévitables, le Scrum Master en commettra de manière certaine dans son parcours pour rendre l’entreprise agile. Apprendre de ses propres erreurs est une bonne vertu, mais apprendre des erreurs des autres rendrait la personne plus productive et efficace. Elle posséderait ainsi une vertu encore plus grande et continuerait sans cesse à apprendre des autres.

Partie intégrante de l’équipe Scrum, le Scrum Master est essentiel au succès de toute équipe Scrum. Lorsqu’il commet des erreurs, cela coûte donc à l’ensemble de l’organisation. Dans un 2^e article, nous aborderons les erreurs humaines que peut éviter le scrum master.

---