Beaucoup se posent encore des questions sur ce sujet des urgences pourtant vous allez voir que la réponse est relativement simple globalement. Quelques outils peuvent vous aider quand l’environnement est plus complexe que prévu.
Qu’est-ce qu’une urgence ?
Ce titre peut faire sourire mais beaucoup se retrouveront dans la situation décrite ci-dessous. Si on peut imaginer une définition facile du mot « urgence », dans de nombreuses structures, celle-ci se complexifie sérieusement.
Une urgence ne doit être que la réponse à celle définition : « si nous ne corrigeons pas cela, l’entreprise en subira d’énormes conséquences ».
Simple à lire pourtant cela peut vite amener des membres des parties prenantes à exagérer les conséquences pour dire leurs demandes « urgentes ». Pourquoi ?
Exemples de fausses urgences
Les raisons peuvent vite être complexes et avoir des raisons très profondes. Voici quelques exemples que j’ai déjà rencontré.
- Objectifs personnels
C’est horrible à dire mais parfois les objectifs personnels peuvent amener à cette situation. Si une partie prenante a des chiffres à réaliser (pour éventuellement décrocher une prime), elle va maximiser les risques d’impacts de sa demande. Et cela parce qu’elle sait que sa demande ne sera jamais prise en compte, si la notion d’urgence n’est pas enclenchée.
Voici des axes d’amélioration :
- travailler la notion de prime / objectif (sujet très complexe)
- utiliser un modèle ROAM de façon visible
- Définir la notion « urgences » et son processus
- Laisser les développeurs valider si c’est urgent
- Le Scrum Master doit accompagner une révision du comportement
Pas toujours évident pour un scrum master de se mettre en affront face à la partie prenante, cependant il devra le faire. Il ne faut pas laisser passer ce type de demande au risque de les voir se multiplier très vite au point de cour-circuiter la notion de « sprint« .
2. Vision personnelle de l’urgence
Il peut arriver que certaines personnes n’aient pas une définition personnelle de la notion d’urgences. Chaque métier amène à sa propre perception de la notion des urgences car les affinités deviennent différentes.
Il faut impérativement que cette notion soit définit quitte à faire une Definition of Urgence (DoU) pour que tout le monde partage la même vision au maximum.
Gérer les vraies urgences en Scrum
Les urgences réelles sont très faciles à gérer en Scrum ; le seul soucis est d’avoir une vraie définition partagée de celles-ci. La partie prenante donne l’urgence à l’équipe selon le processus défini et les développeurs vont la prendre en charge (sprint backlog) ou la rejeter (mettre dans le backlog). Seuls eux auront la décision finale.
Quand les urgences ne sont pas rares, cela peut impacter considérablement le sprint. C’est pour cela que certaines équipes ne prennent pas en considération les points d’effort nécessaires à la résolution des urgences. En effet, cela permet à la fin d’avoir uniquement la vélocité de la réalisation de ce qui était planifié ; et cela permettra de ne pas trop prévoir pour les sprint suivants (et prévoir par défaut la notion des urgences à traiter). N’oublions pas que beaucoup d’équipes utilise la notion de point d’effort pour valider la définition d’un objectif du sprint lors du sprint planning.
Trop d’urgences à traiter
C’est malheureusement un cas que nous pouvons rencontrer de temps en temps. Il faut impérativement mettre les efforts pour arrêter ce type d’engrenage. Pour cela, il faut lancer des travaux de fonds au plus vite même si ceux-ci ont un coup considérable.
N’oubliez pas les impacts du traitement des urgences :
- dette émotionnelle en augmentation des membres de l’équipe
- risque de dette technique plus forte
- produits qui avancent au ralenti
N’hésitez pas si vous avez la moindre question sur cet article.
Soyez le premier à commenter