Bonjour a tous,
Je suis face à une situation nouvelle : l’équipe a beaucoup de tâche récurrente. Ma question est comment représenter cette récurrence ?
Des tâches de quelle nature ? Dans quelle domaine ? Quels problèmes ces tâches représentent ? Pourquoi as tu besoin de les représenter ?
J’essaye d’être le plus générique possible.
Mais disons que c’est pas soucis de transparence avec une situation classique du management qui ne voit pas la charge que représente ces taches récurrentes
Pourquoi le management en question cherche à voir ce que cette charge représente ? Est-ce que tu dirais qu’il y a des problèmes de confiance dans la structure de l’organisation ? A quoi ces problèmes sont dues d’après toi ?
Pour prendre une posture un peu plus haute, mais n’hésite pas à répondre à Samuel. C’est important de comprendre si c’est réellement un problème, pour qui…
Si vous avez des tâches récurrentes, qu’est-ce qui empêche de les mettre dans vos backlogs à chaque fois ? C’est généralement ce qui est fait dans l’infra. Et ça permet de montrer au management qu’il faudrait même un effort sur de l’automatisation.
1 « J'aime »
Je viens d’arriver sur cette mission donc jai pas trop de contexte. Mais de ce que je sais c’est qu’il n’y a aucune transparence et le management se demande ce que les gens font. Et il y a beaucoup de tâche qui ne sont pas automatisé donc récurrente. Voila un peu plus le contexte.
(Désolé pour le délais de réponse)
Ils font leur boulot.
Ca ne répond pas à la question principale : pourquoi le management se demande ce que fait l’équipe ?
La question n’est pas axée autour de la transparence et d’une meilleure communication, mais au contraire de la compréhension des besoins du management vis-à-vis de l’équipe en tant que subalterne atomique. L’équipe est auto-organisée, et son bon fonctionnement est de la responsabilité du SM. Donc le détail des tâches n’a pas besoin de sortir de l’équipe Scrum. Il ne s’agit pas non plus de prôner l’opacité : l’équipe doit rendre des comptes. Elle le fait généralement via le truchement du SM, qui répondra de manière précise mais globale à l’équipe. D’où l’importance de bien comprendre les problèmes et donc les besoins du management pour y répondre avec le bon niveau de détail.
A trop rentrer dans le détail on s’expose à ce que le management ait un avis sur l’organisation de l’équipe (c’est humain), fasse de l’entrisme, et s’ingère dans le fonctionnement de l’équipe. De là à penser qu’on ne fait pas confiance au SM pour aider l’équipe à s’auto-organiser, il n’y a qu’un pas.
C’est la base de la chaîne de commandement, comme à l’armée. Bien sûr les subalternes ont un devoir d’obéissance vis-à-vis de leur supérieur, mais les supérieurs ont aussi des devoirs vis-à-vis de leurs subalternes, au premier chef desquels, le respect de l’autorité. Or, en s’ingérant dans l’organisation de l’équipe, le management viole l’autorité qu’il avait (normalement) lui-même conféré au SM.
En effet, dans un cadre scrum classique. Mais ne nous sommes pas en scrum. L’équipe a une solution saas(contexte que je n’avais jamais vu auparavant) à disposition sur lequel ils n’ont pas fait la configuration donc peu de connaissances.
Cette configuration et le déploiement de logiciel ne s’est pas forcément fait d’accompagnement utilisateur.
Revenons au sujet. Aujourd’hui nous avons a peu pres 400 « incidents » utilisateurs. Dont certains ouvert depuis plus dun 1 an avec un statut en cours. Alors qu’ils ont été analysés.
Quand on a ça on peut comprendre un peu plus le besoin de transparence sur l’état de l’ensemble des travaux.
Sûr l’accompagnement, je ne comprends pas assez le contexte pour vraiment proposer quelque chose de structurant. J’essaye de créer une vision et de les faire expliciter où se situe leur valeur.
Hello,
Au sens ITIL, le problème de fond c’est une confusion incidents / problèmes.
Le processus de gestion des incidents n’est pas adapté à ce cas de figure. Il est fait uniquement pour la prise en charge immédiate et ponctuelle d’un dysfonctionnement : analyser l’origine du dysfonctionnement et proposer une solution (« faire tomber en marche »). Suite à l’analyse, on peut rattacher l’incident à un problème récurrent. Du moment qu’on a trouvé une solution de contournement, ou décidé de « wontfix » en attendant la résolution du problème, la gestion d’incident est terminée. Les problèmes sont gérés séparément, dans un backlog dédié, ou potentiellement commun avec les demandes d’évolution.
Cela facilite aussi la communication avec les parties prenantes, dont le management. L’important est que ce soit le PO pilote le backlog des problèmes, et de laisser la main au SM pour l’organisation de l’équipe. Dit autrement, la question n’est pas de savoir qui résoud quel problème, mais est-ce que l’équipe est dimensionnée / compétente / disponible / efficace dans l’épuration de ce backlog.
Merci pour cette réponse précise. J’avoue que l’itil est en dehors de mon domaine de compétences.
Je retourne me concentrer sur ma mission, pour le moment, organisée les demandes d’évolutions.
Justement, les problèmes relèvent des évolutions au même titre que les ajouts de fonctionnalités. Ou dit dans l’autre sens, une demande d’évolution peut être soit un ajout de fonctionnalité, soit une correction de problème. En gros, on doit pouvoir écrire une US pour un problème, et prioriser par rapport aux autres problèmes et aux ajouts de fonctionnalité. Ensuite on décide des éléments à prioriser en fonction du product goal.
Par opposition, les incidents relèvent du support utilisateur. La métrique critique est le délai de prise en charge ou de qualification. A chaque fois qu’un utilisateur appelle pour se plaindre d’un dysfonctionnement c’est un incident. Ils ne devraient pas rester ouverts plus de quelques jours, idéalement de quelques heures. Sur 400 incidents utilisateurs, tu peux en avoir 30 qui sont des signalements causés par le même problème, ou sur des problèmes qui ont la même origine. C’est important d’avoir cette vision, car dans la phase de priorisation des travaux du prochain sprint, ça permet d’évaluer l’impact des corrections sur les utilisateurs, et donc la valeur attendue.
Cette approche à deux niveaux permet d’optimiser la valeur fournie aux utilisateurs par la résolution rapide des incidents critiques ou faciles à résoudre (sans dev impliqué), et la priorisation des corrections de problèmes les plus récurrents ou ayant le plus fort impact sur le long-terme.
Oui je suis en accord total avec toi sur l’approche à 2 niveaux qu’il faut mettre en place. C’est ce que j’essaye de leur faire comprendre petit a petit. Mais je ne suis pas certain qu’on attende de moi de structurer la partie assistance (du moins pour l’instant).
De ce qu’on ma rapporter, il n’y avait aucune organisation de gestion de la demande, où plutôt un backlog imaginaire (un fichier excel pseudo-partagerpas du tout utilisé avec aucune projection dans le temps) je te parle meme pas d’analyse de récurrence d’incident. Donc analyse de la valeur il n’y a pas aujourd’hui.
Enfin de ce que j’ai pu observer depuis 2 semaines, toute les points négatifs du cycle en V nous sommes dedans avec un sous effectif.
Sans véritable structure, ni véritable PO.
Miam …
Je te souhaite d’avoir un mandat assez fort pour faire bouger les lignes 
1 « J'aime »
Ce sujet a été automatiquement fermé après 5 jours. Aucune réponse n’est permise dorénavant.