Les attentes (en particulier) de la nouvelle équipe Scrum sont élevées. La méthodologie est encore nouvelle pour de nombreuses entreprises, et une fois qu'elles sont enfin assez courageuses pour faire le changement, elles attendent beaucoup du changement.
C'est très facile pour le équipe Scrum échouer à tenir sa promesse, et l'échec peut avoir de nombreuses variantes, toutes également possibles 😀.
Maintenant, cet article ne détaillera pas les processus Scrum en tant que tels. Je voudrais plutôt me concentrer sur l'objectif ultime de (n'importe quelle) équipe - livrer ce qui a été convenu dans les délais et en qualité. Et dans ce cas, l'accent sera mis sur les activités plus techniques au sein de l'équipe qui peuvent conduire à des sprints infructueux et sur ce qui pourrait être un moyen efficace de les gérer.
Maintenant, nous allons discuter des aspects techniques qui peuvent ruiner votre sprint et comment les résoudre.
Backlog Generation Without a Solid Roadmap Target
En fonction de la difficulté technique du contenu de la livraison et de la distance entre la compréhension complète des sujets par les clients et le contenu du sprint, les backlogs peuvent être l'un des premiers problèmes qui frappent l'équipe. Cela appelle de graves complications comme :
- Les histoires peuvent être générées presque au hasard et non en suivant une ligne logique, basée sur les idées flash actuelles de quelqu'un d'important sur le plan hiérarchique, plutôt que sur la base d'un plan chronologique.
- Ensuite, l'équipe scrum, sur le point de sauver la cohérence, ajoutera ses propres histoires pour compléter celles déjà données. Mais à terme, il en résultera plusieurs gros sujets en parallèle dans le backlog.
- Comme les besoins des clients sont toujours la priorité, certaines histoires importantes mais trop techniques sont reportées pour livrer les fonctionnalités demandées par le client.
- L'équipe essaiera ensuite de livrer, mais le résultat inévitable est une livraison de contenu de sprint qui semble incomplète (ou même boguée), et la dette technique augmente (ce qui conduit à d'autres histoires dans le backlog).
Donnez-lui quelques cycles de sprint, et le problème évoluera de manière exponentielle vers une situation où ce qui est dans le backlog n'est plus important car il est clair que le contenu suffisamment bas ne sera jamais résolu. Il n'y aura pas le temps de choisir les histoires; dans chaque sprint, un lot de nouvelles histoires est généré (et a une priorité plus élevée).
Comment réparer la génération de backlog
Approcher une solution ici et convaincre les partenaires de changer est particulièrement difficile, car c'est le territoire où la hiérarchie de l'organisation a une influence considérable.
Cependant, il y a certaines actions à lancer, et même si elles ne sont pas immédiatement approuvées, les rappeler périodiquement et les mettre en contexte avec la situation actuelle du backlog et comment elle pourrait être pourrait conduire au succès au fil du temps :
# 1. Demandez des objectifs concrets de feuille de route pour l'équipe
Cela devrait être à la fois dans une perspective à court et à long terme. Expliquez clairement quelles fonctionnalités doivent être réalisées dans les prochains mois et à quoi le produit devrait ressembler un an plus tard. Une vision claire doit être démontrée de manière approfondie et associée à des objectifs spécifiques de la feuille de route.
# 2. Priorisation des défis des fonctionnalités sur la chronologie
Il ne devrait jamais arriver de laisser l'équipe en équilibre entre plusieurs histoires hautement prioritaires et hautement complexes simultanément. Cela ne fera que ralentir les progrès dans tout au lieu de démontrer des progrès incrémentiels substantiels dans les grands sujets.
# 3. Revisitez régulièrement les vieilles histoires
Revisiter les anciennes histoires et obtenir la confirmation si elles sont effectivement toujours valables et quelle est la priorité de celles-ci. Associez-les à des objectifs spécifiques de la feuille de route s'ils sont toujours valables. Évitez les histoires non cartographiées dans le backlog - c'est un signe que ces histoires n'ont pas de valeur commerciale claire ou que la priorité sur elles a été perdue au fil du temps.
Technical Debt Postponement
La dette technique est un état du code (ou de ses parties) dans le logiciel développé qui est créé comme un effet secondaire de la priorité accordée à la rapidité de livraison par rapport à la qualité. Parfois, la publication de nouvelles fonctionnalités dans un sprint est un sujet urgent, de sorte que l'équipe peut décider de ne pas terminer les histoires parfaitement.
Cependant, de cette manière, il répond toujours à l'exigence majeure de fonctionnalité du côté commercial. S'il n'est pas identifié correctement et à temps, il peut même être oublié en cours de route et redécouvert uniquement en rencontrant des problèmes dans les phases ultérieures du projet.
L'équipe elle-même est la plus capable de définir des histoires pour la dette technique créée en cours de route. Malheureusement, ces histoires sont souvent placées à la fin des tableaux de priorité, soit par le client, soit par le propriétaire du produit.
L'accumulation de dette technique est un problème sérieux pour l'équipe Scrum. Il commence petit mais croît de façon exponentielle avec le temps :
- De nouvelles histoires commencent à être affectées par des problèmes inachevés du passé.
- La correction d'un nouveau bogue dans un système à forte dette technique conduit souvent à des résolutions très complexes car pour corriger le nouveau bogue, plusieurs autres problèmes doivent être résolus pour amener le traitement à l'étape où la correction peut être apportée.
- La frustration de l'équipe de développement grandit lorsqu'elle constate à quel point il est plus difficile d'implémenter de nouvelles fonctionnalités dans un système plein de problèmes techniques non résolus qui compliquent inutilement la nouvelle extension de fonctionnalité.
Comment réparer le report de la dette technique
La cohérence est la clé ici. Chaque équipe Scrum doit développer un processus adapté à son cas d'utilisation et s'y tenir quoi qu'il arrive. Le processus en question peut ressembler à :
Établissez une règle où au moins 1 ou 2 histoires seront ramassées de l'arriéré de la dette technique.
Réserver un pourcentage du sprint dédié uniquement aux tâches techniques liées à la dette. Cela peut cependant être délicat, car il est très difficile de suivre un tel engagement. Si vous suivez cette voie, il est probablement préférable de définir une journée concrète dans le sprint dédiée uniquement aux activités de dette technique.
Définir chaque 5e sprint environ est réservé au rattrapage de la dette technique histoires. Remplissez autant de contenu de dette technologique pertinent que possible dans ce sprint. Si, au fil du temps, il n'y a pas assez d'histoires de dette technique sur lesquelles travailler en ce moment, complétez le reste de cette capacité de sprint avec de nouvelles fonctionnalités. Dans tous les cas, ce sprint concret sera réservé en premier lieu aux histoires de dette technologique.
Too Flexible Sprint Content Change Before End of the Sprint
Les équipes Scrum doivent être flexibles et prêtes au changement, car cela implique directement dès le Manifeste Agile, qui devrait être au cœur de chaque équipe Scrum.
Mais imaginez une situation où le contenu du sprint change tous les 2-3 jours :
- Les histoires sont repriorisées, de nouvelles histoires entrent dans le sprint et d'autres histoires sortent rarement.
- Le contenu change non seulement mais augmente également au fil du temps de la période de sprint.
- Le changement de priorité conduit à une équipe démotivée, car elle est alors obligée de sauter d'un sujet à un autre, augmentant le stress et, au final, ne livrant pas de contenu. Non seulement pour les histoires acceptées pour faire partie du sprint lors de la planification du sprint, mais souvent aussi pour les histoires nouvellement ajoutées.
Ce serait formidable si nous pouvions simplement donner la liberté à l'équipe Scrum et ensuite regarder comment les histoires se termineront, malgré tous les changements à venir dans l'équipe pendant le sprint. L'expérience montre que cela ne fonctionnera pas. L'équipe sera distraite et submergée par le contenu ; avec le temps, l'engagement de sprint ne signifiera rien.
Il deviendra standard pour l'équipe de ne pas terminer les histoires à l'intérieur du sprint ; de la même manière, il deviendra standard de reporter les histoires de sprint en sprint comme conséquence directe.
Le client se plaindra alors qu'il n'y a aucune garantie que les histoires placées dans un sprint seront livrées dans ce sprint. La planification des fonctionnalités et des objectifs de la feuille de route sera désactivée.
Comment réparer la flexibilité des sprints
Je pense que sacrifier une sorte de liberté pour quelques processus qui limiteront la flexibilité des sprints augmentera considérablement la fiabilité de la livraison des sprints. Un tel processus comprendrait des étapes telles que :
- N'autorisez pas l'ajout non organisé de nouvelles histoires dans le sprint existant. Ayez un processus de révision en place, même s'il est très simple, mais un point de confirmation que la nouvelle histoire est pertinente et a une priorité plus élevée que toute autre chose déjà dans le sprint.
- Pour chaque nouvelle histoire ajoutée au sprint, supprimez une histoire de complexité équivalente du sprint. Idéalement, ce doit être une histoire qui n'a pas encore commencé dans le sprint ou qui n'a commencé que très récemment.
- N'ajoutez pas automatiquement les bogues ad hoc découverts dans le sprint au backlog du sprint. Ce sont de nouvelles histoires à estimer et à planifier pour une inclusion spécifique au sprint.
Insufficiently Defined Stories Leave Too Many Open Items
Vous définissez donc les histoires pour le prochain sprint, l'équipe procède à la clarification et au raffinement, à l'estimation et à la répartition des tâches, et tout est prêt pour un développement clair, n'est-ce pas ? Eh bien, pas avec des histoires peu claires apparaissant dans les sprints.
Même si les histoires sont affinées, l'équipe s'accordera sur une sorte d'estimation, même si personne ne communique le manque de clarté avec les histoires. Les histoires mal définies peuvent être identifiées facilement de telle sorte que l'équipe revient à plusieurs reprises pour discuter des histoires dans le sprint.
Cela prolonge non seulement naturellement le temps de raffinement de l'équipe, mais cela conduit également à un changement de portée supplémentaire après que les estimations pour le sprint ont été faites et que le contenu du sprint a été validé par l'équipe.
Par conséquent, les histoires deviennent plus grandes et plus complexes qu'initialement estimées. De plus, le vrai travail de développement sur une telle histoire commencera bien plus tard qu'au début du sprint simplement à cause de toutes les clarifications supplémentaires requises.
Dans la plupart des cas, cela conduit finalement à une histoire inachevée dans le sprint.
Comment réparer une histoire inachevée dans le sprint
Si l'équipe est servie avec trop d'histoires peu claires, elle deviendra ingérable avec le temps, et gestion de projet SUR mesure ne peut que se demander pourquoi chaque sprint se termine par des histoires inachevées.
Cela peut être un problème complexe à résoudre. Cela dépend principalement de la distance entre le propriétaire du produit et ses connaissances de l'équipe de développement et de sa capacité à comprendre les besoins de l'équipe concernant la définition claire des histoires.
Souvent, les propriétaires de produits sont des personnes fortement orientées vers la fonctionnalité et leur lien avec l'équipe de développement est peu profond. Dans d'autres cas, le rôle de propriétaire de produit est combiné avec le rôle d'analyste d'affaires, ce qui conduit à une confusion encore plus grande. Alors que faire dans ce cas ?
Planifier des appels mensuels pour la préparation de l'histoire, où les fonctionnalités qui n'ont pas encore été introduites dans les sprints doivent être discutées en profondeur à l'avance. Avoir une feuille de route claire est la condition préalable ultime pour que cela réussisse.
Préparer les pages d'analyse pour des histoires aussi complexes bien à l'avance (avant que les histoires ne soient placées dans des sprints) afin que les propriétaires de produits puissent facilement définir des histoires riches en contenu pour les équipes de développement.
Dans les cas très complexes, c'est un bon moyen de consacrer du temps à la préparation de la conception avant que le sujet n'atteigne l'équipe Scrum. Des PME spécifiques de l'équipe seront dédiées à cette activité.
En aucun cas, ne laissez pas l'histoire non préparée atteindre un sprint. Insistez sur son achèvement du point de vue du contenu. Cela créera une pression positive supplémentaire sur les parties prenantes concernées pour mieux préparer les histoires pour l'équipe.
Mot de la fin
Se concentrer sur le bon contenu de chaque histoire rapporte beaucoup au fil du temps. La gestion du backlog est un territoire indéfini pour la plupart des équipes Scrum. Cartographier des histoires dans des objectifs concrets et les placer dans le contexte de cibles plus visibles est une activité sous-estimée.
Cette liste visait à jeter un peu de lumière sur ces détails techniques et, espérons-le, à aider à l'orientation si certains des problèmes ci-dessus sont familiers.
Ensuite, découvrez le meilleur outils de mêlée pour une startup à une moyenne entreprise.
