J’ai toujours connu ce combat, et jamais réussi à mettre en place une solution parce que ça demande un équilibre entre des parties qui n’ont pas les mêmes KPI ;(
Je suppose que tu parles d’un contexte où l’équipe de 9 devs assurent directement le support et le développement.
C’est grave le glissement de sprint ? Ça veut dire quoi glissement de sprint ? Y aurait-il eu des promesses ? Du waterfall planqué ?
Un sprint => Objectif et on essaye de réaliser le plus possible pour cet objectif.
Glissement = « on n’a pas su tout faire » … Et alors ???
Si tout faire est obligatoire, c’est qu’on revient à l’ancien triangle
Le Zéro-Bug : tous les tickets des apps en prods, soit c’est de l’incident, soit du problème, soit de la demande d’amélioration
- Réparer un incident, c’est rétablir le service
- Régler un problème, éviter qu’un type d’incident ne se (re)produise.
- Une demande d’amélioration : c’est ajouter de la valeur.
Régler un problème est une forme d’amélioration.
Mon amélioration => PO => est-ce que ca peut attendre d’être cohérent avec l’objectif de sprint ?
OUI => Item du Product Backlog
NON=> opérationnel (comme les incidents)
Zero bug => PO (qui aura sans doute discuté avec l’exploitant du produit) a 2 choix
→ On intervient et tout de suite
→ On n’intervient pas et on assume
(note il y a déjà eu un choix plus haut qui correspond à "on interviendra => product backlog)
Il reste le « on le fait immédiatement »
Pas besoin de le mettre dans le kanban de sprint
Autre version c’est
On l’ajoute au « Kanban du bruit et des imprévus »
==> C’est ce qu’on voit avec les SCRUMBAN
Un choix peut être : "ok on ne stoppe pas l’encours dès qu’un hors « objectif de sprint » survient, mais dès que la personne a fini sa tâche en cours.
QUI doit le faire ?
Le coup de l’équipe dédiée : perso il y a 2 choses qui font que je n’aime pas ça.
=> c’est donc équipe dédiée à un type de tâche et non au produit, c’est une équipe support.
C’est du silo. Si cette équipe touche au code, il va falloir mettre en place des échanges réguliers entre l’équipe support et l’équipe ajout de valeur. ⇒ perte de temps et complexité de communication
Être dans une équipe de support, c’est toujours vu comme « moins » fun, moins valorisant.
Chez les dev ça développe une acceptation de baisser la qualité, de toute façon, il y a le support pour encaisser mon mauvais travail.
Je suis partisan de l’équipe qui développe le futur et assume le présent.
Il y a un cas de figure qui passe parfois.
1 équipe de support N et les autres équipes qui font « futur » + "Support niveau N+1.
Donc le support N protège la N+1 tout en apprenant à devenir de futurs membres de N+1
Dans cette équipe, on trouve des apprentis (nouveau dans la boite, pas forcément junior en compétence) qui évoluent et apprennent à la dure pour monter en compétence et découvrir le produit et/ou des gars qui aiment ça. Le support ça peut être aussi plus de défi, plus de variétés, plus de contacts avec les utilisateurs, plus de « solitude » et « autonomie » …
Donc, on revient à ta situation actuelle. Mais là, il y a encore des adaptations possibles.
Soit ce fameux Zero bug => ca demande l’acceptation de mon préambule « un glissement de sprint, c’est pas grave »
Soit la marge.
Il y a plusieurs possibilités pour ca (à combiner)
- n% du temps de sprint est consacré à cela.
- n% de l’équipe se consacre à ça (pour protéger les autres, à la shadock), un rôle tournant
- …
L’important, c’est de comprendre que
1° c’est le PO qui choisi et assume ce qu’il prend par rapport au SLA
2° L’équipe n’a qu’un seul décideur humain. (Le PO)
Perso, je l’observe au quotidien. Les managers qui font de l’ingérence dans le travail des équipes pour protéger leurs KPI persos au détriment du sprint, de Scrum.
3° Le SLA défini le temps de réaction aux incidents et demandes imprévues. Donc ca aide énormément à faire les choix du « maintenant ou pas »