Scrum est-il adapté à une équipe orientée correction d'anomalies

Bonjour.

Développeur au sein d’une équipe qui traite essentiellement des anomalies, j’ai récemment pris le rôle de Scrum Master.

Depuis quelques mois que j’assure ce rôle, j’ai le sentiment que Scrum n’est pas adapté à ce type de projet.

L’une des parties les plus importante, avoir un objectif de Sprint, ne me semble pas possible.
En effet les anomalies priorisées par le PO sont souvent liées à la criticité de l’anomalie, à l’importance accordée au client qui les crée etc.
Chaque anomalie est totalement indépendante des autres, et je ne trouve pas ce qui pourrait rassembler l’équipe autour d’un objectif commun.
Le Sprint backlog est perturbé par des anomalies plus prioritaires qui arrivent en cours de sprint, ou des regressions à traiter rapidement, mais pas par des éléments ajoutés par l’équipe afin d’atteindre un objectif (inexistant).

De ce fait les daily scrum, orientées sur l’analyse du tableau kanban, afin de déceler les goulots d’étranglement, ne sont pas non plus portées par un objectif commun à atteindre, puisque nous n’en avons pas.
Nous nous contentons de parcourir le tableau et analyser chaque colonne en mode « Walking the board ».

Le backlog est alimenté sans cesse par les anomalies, ce qui fait que nous ne voyons jamais le bout du tunnel.

Le Sprint planning se résume à une présentation des Tickets ajoutés au Sprint par le PO.
Notre champ d’action se limite à s’assurer que chaque Ticket est reproductible avec un scénario clair et des critères d’acceptation, et que le besoin est bien compris par toute l’équipe.
Nous ne faisons pas d’estimation sur des anomalies, car il est difficile d’estimer une correction.

Qu’en pensez-vous ?
Avez-vous des suggestions / des idées ?
Est-ce qu’un cadre Kanban serait plus approprié que Scrum ?

J’ai hâte de lire vos retours.

Je ne sais pas si c’est adapté ou non, j’ai pas assez d’infos.

Avoir une cadence, c’est toujours intéressant. Le seul « avis » que je pourrais donner, c’est : « si vous voulez faire Kanban, gardez les itérations. »

Pour l’objectif commun, ça peut être un SLE (service level expectation) : « un ticket met 6 jours ou moins pour 80% des items ».
Sinon, en fonction de la priorité, vous pouvez vous occuper des tickets par applicatif, par partie du produit… « Maintenir pour « tel utilisateur » la partie XXX ». Pleins de manières de faire.

2 « J'aime »

Je vais aller un peu plus loin. Si vous n’avez pas la main sur les évolutions du produit, vous avez toujours la main sur un point: l’efficacité de l’équipe. Comme le proposait Benjamin, les objectifs au niveau du temps de traitement de tickets sont une piste, tout comme la fluidification de l’information avec les autres équipes, la capitalisation sur les infos récupérées, etc…

Tldr: si vous ne pouvez pas améliorer le produit de manière incrémentale directement, améliorez vos process.

2 « J'aime »

Hello @CedricS

Perso, je vais m’attaquer à l’alignement du vocabulaire.

Et je parle d’alignement (je ne cherche pas à savoir qui a raison, mais qu’on utilise les mêmes définitions).

Voici les miennes.

évènement > Incident > Problème > projet

L’anomalie (bogue, bug) est à l’origine d’évènements
Selon les SLA du service en production, ces évènements sont considérés comme « négatifs »
Un incident vise à prendre en charge l’effet d’anomalies.
Un problème vise à attaquer la cause d’un ou plusieurs incidents (quand on estime que c’est plus bénéfique que de continuer à réparer les incidents.

Un projet est une activité délimitée dans le temps qui avec des ressources (€, matériel, humain) qui vise à apporter de la valeur au produit ou au service.

« Scrum est un cadre de développement » basé sur lean, et dont les créateurs sont signataires d’un manifeste Agile.

Toujours selon moi, la seule chose en SCRUM qui ressemble à un projet, c’est « un sprint » (allocation de ressources pendant une période définie pour un ajout de valeur visé)

Le PO PRODUCT Owner, canalise les actions de l’équipe pour ajouter de la valeur à son produit.
C’est fait par une succession de projets (appelés sprints).
L’objectif de sprint est l’objectif de ce projet.

Résoudre bug/anomalie/problème ou améliorer/Créer/simplifier/retirer une fonctionnalité (superflue dans le cas de « retirer »)…
C’est dans tous les cas ‹ ajouter de la valeur ›

(si on cherche à faire la différence entre un bug et une fonctionnalité, n’a pas de sens en Scrum. C’est plus en mode traditionnel pour savoir qui doit assumer le coût. Si c’est un bug, on se dit que le réalisateur doit assumer, si c’est une fonctionnalité, on pense que c’est le client/demandeur. Dans tous les cas, le travail fera partie du livrable)


En voilà pour mes définitions.

Pour toi, qu’est-ce qui ressemble le plus dans mes définitions à ce que tu appelles « anomalies » et « projet » ?