Alors que les concepts et techniques Scrum sont assez faciles à comprendre, maîtriser leur exécution quotidienne est très difficile. Après tout, changer des habitudes profondément enracinées n’est rien que nous puissions faire du jour au lendemain.
En fin de compte, nous (en tant que praticiens et participants agiles) voulons être en mesure de reconnaître et d’éliminer les comportements préjudiciables à la manière agile de penser et de travailler. Ces mauvaises influences sont ce que nous appelons anti-modèles.
Cet article examinera en profondeur comment nous définissons les anti-modèles dans Scrum et à quoi ressemblent certains d’entre eux.
Définition des Scrum Anti Patterns
Les anti-modèles dans Scrum sont des habitudes qui sont fréquemment exposées mais globalement inefficaces ou peut-être même nuisibles.
Ces anti-modèles se produisent tout au long des cérémonies Scrum et entravent finalement leur exécution (en temps opportun).
De plus, même les praticiens agiles (tels que le Scrum Master ou le Product Owner) peuvent eux-mêmes souffrir de certaines de ces lacunes. Cela les rend d’autant plus compliqués.
Anti Patterns lors de la réunion de planification de sprint
Carnet de produit non raffiné. L’un des plus grands péchés du propriétaire du produit (car il est responsable de la gestion du backlog du produit) est de participer à la réunion de planification du sprint en essayant de comprendre les détails des tâches de sprint à venir. Cela enlèvera un temps précieux qui devrait être consacré à la planification du sprint à venir.
Principaux intervenants manquants. Nous ne pouvons planifier en conséquence que lorsque l’effort des tâches peut être estimé en conséquence. En tant que tel, nous avons besoin de toute l’expertise nécessaire dans le domaine pour nous aider à le faire. Cela peut entraîner de nombreux problèmes, tels que :
- Le propriétaire du produit pousse trop de tâches dans le sprint
- L’équipe de développement peut ne pas imposer de temps à réserver pour les corrections de bogues et le travail ad hoc (par le biais de ce que l’on appelle objectifs étendus)
- L’équipe de développement ne peut pas s’engager sur sa disponibilité pour le sprint à venir (au cas où certains membres de son équipe seraient absents)
En conséquence, les équipes finissent par s’engager dans trop de tâches. Beaucoup d’entre eux finissent par se répercuter sur le sprint suivant, entravant finalement les performances de l’équipe.
Définition faible de Terminé et/ou Prêt. Les DoR et DoD permettent aux équipes d’estimer avec précision les efforts de livraison d’un incrément de travail. Lorsque les équipes n’ont pas une compréhension commune de ce qui constitue prêt et fait (et des tâches sous-jacentes impliquées pour expédier l’article), il devient alors presque impossible d’estimer l’effort de manière fiable.
Anti Patterns pendant la mêlée quotidienne
Bruit extérieur. L’équipe tolère que des intervenants extérieurs participent activement au stand up, qui se solde finalement par des discussions inutiles sur le travail à faire.
Autre bruyant
les problèmes peuvent inclure :
- Les membres de l’équipe s’interrompent
- Les membres de l’équipe se parlent pendant que quelqu’un d’autre parle
- Les membres de l’équipe arrivent en retard au stand up, créant ainsi une distraction pour les autres personnes impliquées
- L’environnement dans lequel se tient la réunion (par exemple au milieu du bureau) provoque des interruptions
Discussions intenses sur le travail. Le Daily Scrum ne doit pas être utilisé pour déclencher des discussions animées (ou toute autre sorte de) discussions. Cela a) empêchera les membres de votre équipe d’être productifs, b) affectera négativement le moral et c) n’est pas conforme à l’objectif de cette réunion. Les réserver pour après la réunion est la voie à suivre.
Problèmes en cours. Les membres de l’équipe ne sont pas en mesure de résoudre les problèmes en cours ou ne proposent tout simplement pas d’aider. Cela montre souvent soit un manque de confiance, de temps, de compétence ou même une combinaison de tout cela.
Sauter complètement. Le Daily Scrum se tient à la même heure et au même endroit chaque jour pour réduire la complexité. Faire la réunion rarement prive l’équipe de l’opportunité de rattraper son retard et d’élaborer une stratégie pour la journée à venir.
Impréparation. Les membres de l’équipe ne peuvent tout simplement pas se souvenir de ce sur quoi ils travaillaient ou laisser des détails importants aux autres. Un manque de préparation peut également conduire à la violation du délai de 15 minutes. Conseil de pro : notez sur un post-it ce que vous avez fait la veille et utilisez-le comme source d’information.
Anti-modèles lors de la revue de sprint
Manque de fréquentation. Les gens, qu’ils soient internes ou externes, ne se présentent tout simplement pas aux revues de sprint. Cela peut être dû à plusieurs raisons, par exemple :
- Manque d’informations présentées, les parties prenantes n’ont donc pas l’impression de pouvoir rassembler les informations nécessaires
- La réunion semble très répétitive et l’ordre du jour ne change pas vraiment beaucoup
- Les mêmes visages apparaissent encore et encore
- Style de présentation ennuyeux dans lequel les gens lisent simplement quelques diapositives
De plus, bien qu’il puisse y avoir un bon niveau de participation, les parties prenantes peuvent se sentir désengagées et ne poseront donc aucune question. Que ce soit parce qu’ils ne ressentent pas le besoin ou la liberté de s’exprimer, c’est quelque chose qui devrait être étudié et corrigé, car cela crée des discussions et des idées fructueuses.
Inachevé. L’équipe de développement présente des éléments de travail qui ne répondent pas à la définition de terminé, créant ainsi un faux sentiment d’accomplissement.
Impréparation. Les membres de l’équipe finissant les diapositives quelques minutes avant ou les parties prenantes ne connaissant pas le but de l’événement peuvent être quelques-uns des facteurs qui peuvent entraver l’efficacité de la réunion. Encore une fois, cela pourrait aboutir à ce que les parties prenantes ne se présentent pas la prochaine fois ou soient simplement désengagées pendant la réunion.
Anti Patterns pendant la rétrospective du sprint
Devenir personnel. Les membres de l’équipe s’attaquent pendant la rétro, causant finalement des frictions et de l’inconfort. Tel que défini par le Valeurs Scrumles équipes doivent se traiter avec respect tout en ne perdant pas leur courage
pour parler des problèmes sous-jacents.
Se précipiter ou sauter rétro. L’équipe se précipite ou saute complètement la rétrospective. C’est souvent le signe d’un manque de compréhension de l’importance de cette réunion. De plus, les équipes ne pourront pas profiter de ses nombreux avantages de réflexion.
Les Scrum Masters devraient essayer de faire en sorte que le rétro vaille le temps de l’équipe. Nous pouvons pimenter la réunion de multiples façons – qu’il s’agisse de changer de lieu et de techniques ou simplement de commander des beignets et du café en cours de route.
Aucune mesure prise. Malgré les problèmes persistants et l’élaboration de plans d’action, personne ne les suit réellement. Cela peut être dû à plusieurs facteurs, notamment :
- Personne dans l’équipe ne se sent responsable
- Le Scrum Master ou le coach agile n’est pas capable de réfléchir et de suivre les points d’action discutés
- Personne ne prend de notes et ne se souvient donc pas de ce qui a été discuté
Mouchard.
Les membres de l’équipe partagent les points discutés avec les parties prenantes externes. Cela crée un énorme abus de confiance et une crainte de ramification. Les membres de l’équipe perdront donc leur courage de s’exprimer.
Manque d’ouverture. Que l’entreprise manque d’un lieu approprié pour le rétro ou qu’il y ait les parties prenantes extérieures (par exemple les supérieurs hiérarchiques) invitées à la réunion, un manque d’ouverture va complètement à l’encontre de l’objectif de la rétrospective. Cela conduit souvent à la passivité sans que personne ne ressente le besoin de parler.
Scrum Master Anti Patterns
En dehors des cérémonies, il existe une multitude d’anti-patterns dont le Scrum Master et le Product Owner peuvent souffrir.
Porter plusieurs casquettes. Cela se produit souvent dans les organisations qui sont habituées à un style de livraison en cascade. Par exemple, d’anciens responsables hiérarchiques ou chefs d’équipe deviennent Scrum Master tout en continuant à gérer leurs tâches quotidiennes. Cela ne fonctionne tout simplement pas – à la fois du point de vue du temps et de l’auto-organisation.
Éviter les conflits. En tant qu’êtres humains, nous avons tendance à éviter les situations inconfortables partout où nous le pouvons. Au lieu de cela, nous recherchons la sécurité et la stabilité, en particulier dans les contextes impliquant des groupes. La recherche de conseils extérieurs, par exemple par le biais de coachs ou de psychologues, peut aider à guider le Scrum Master sur la manière de résoudre efficacement les conflits.
Trop de liberté. Ce n’est pas parce que Scrum est basé sur des équipes indépendantes et sur l’auto-organisation que ses membres ont un ticket gratuit pour faire ce qu’ils veulent. Au contraire, il coache toutes les personnes impliquées sur la façon de s’auto-organiser dans le domaine des cérémonies tout en orientant l’organisation vers une adoption efficace de Scrum.
La compétition comme motivation. Utiliser les performances des autres équipes pour stimuler et motiver peut nuire au moral de l’équipe. Cela peut se faire au détriment de la livraison d’incréments de haute qualité, ce qui stresse les membres de l’équipe et met tout le monde dans l’organisation sur place. Le Scrum Master doit motiver son équipe par un sentiment d’accomplissement, et non par la peur d’être pire que quelqu’un d’autre.
Manque d’expérience. Nous ne pouvons que nous répéter : Scrum est facile à apprendre, mais difficile à maîtriser. Avoir un Scrum Master inexpérimenté peut conduire à un échec dans l’adoption et l’exécution des méthodes agiles. Cela dit, tant que votre équipe progresse, avoir un peu plus de patience peut suffire.
Product Owner Anti Patterns
Bon de commande inaccessible. Le Product Owner n’est pas systématiquement accessible à l’équipe pour répondre aux questions chaque fois qu’elles se posent. Cela peut être dû à plusieurs facteurs, notamment :
- L’organisation a décidé de n’employer qu’un PO à temps partiel
- Le Product Owner gère plusieurs produits (gros non non !)
- Le Product Owner assume d’autres rôles (par exemple Scrum Master) en même temps
- Un groupe de personnes (c’est-à-dire un comité) représente le rôle du PO pour pouvoir se concentrer sur son travail quotidien
Dans tous ces cas, l’équipe de développement et l’organisation dans son ensemble manquent d’une force directrice constante qui les oriente vers la maximisation de la valeur du produit.
Mauvaise gestion du backlog. Encore une fois, la mauvaise gestion du backlog produit se présente sous de nombreuses formes. Les exemples impliquent :
- Surdimensionnement du backlog, empêchant l’équipe de livrer à temps
- Articles obsolètes qui ne sont tout simplement plus pertinents
- Les éléments ne sont pas raffinés et n’incluent pas de descriptions détaillées de la user story (par exemple, en ajoutant uniquement des titres à chaque user story)
- Il manque à la user story des critères d’acceptation (Définition de Ready)
- Toutes les user stories sont estimées des semaines à l’avance, ce qui peut entraîner un travail supplémentaire inutile pour tous les membres de l’équipe (car ces user stories peuvent devenir obsolètes au cours des sprints suivants)
.. et beaucoup plus. Dans tous ces cas, il est conseillé d’avoir un Scrum Master fort qui peut guider et enseigner au PO une gestion efficace du backlog.
PO égoïste. Le Product Owner s’attribue tout le mérite des réalisations de son équipe. Cela affectera indéfiniment le moral de l’équipe et entravera l’influence positive que le PO peut avoir sur la performance de l’équipe.
PO non réfléchissant. Le Product Owner ne réfléchit pas de manière critique sur son travail au cours des sprints passés. Ils interprètent les échecs comme des complots contre eux parce que “Comment cela pourrait-il être de ma faute si je ne fais pas le travail?”
Manque de vision. Le PO ne pense pas au-delà des domaines de ce qui est possible et utilise une vision qui est a) peu inspirante, b) pas unique, c) évitant tout risque, d) manquant des étapes sur la façon de réaliser la vision ou une combinaison de celles-ci.
Excellents produits sont capables de rallier leurs troupes autour d’une vision commune et fédératrice, convaincante, atteignable (mais un peu audacieuse) et globalement inspirante.