Discussion :

[Thogrom]

Bonjour,

Je suis expert administratif dans une administration.

Depuis 2 ans, nous utilisons une application informatique réalisée par notre ICT avec la méthode scrum.

Cette méthode a été conservée en post-production pour les change-requests du business et les implémentations de fonctionnalités liées à de nouveaux projets (changement de la législation, digitalisation des courriers entrants,...)

Comme l'ICT a des sprint de 15 jours, cela a demandé une adaptation de l'organisation du travail de notre côté.

Sur internet, je trouve des échanges d'expériences côté ICT mais rien côté business. Peut-être que certains d'entre vous pourront m'aider car je rencontre 2 soucis.

Avant tout, une brève explication de notre procédure

Les CR et les fonctionnalités liées à un nouveau projet sont examinés par des groupes de travail. Les groupes les valident (ou pas) et les prioritisent.
Ils doivent les classer en :
* essentiels (réservé aux projets en phase projet)
* intermédiaires (niveau 1 à 3)
* de confort

Mon job consiste, entre autres, à :

• vérifier qu'un nouveau CR n'a pas déjà été demandé
• vérifier qu'un CR n'est pas un bug
• transmettre les CR au groupe de travail compétent
• transmettre les CR prioritisés au product owner
• m'assurer de la cohérence des priorités (au sein d'un groupe et entre les groupes)

Mes soucis :

1/ Travaillant dans une administration, je rencontre un certain pessimisme (immobilisme) chez certains utilisateurs. J'aimerais leur faire comprendre que l'application ne peut s'améliorer que s'ils se manifestent pour demander des CR.

2/ Lorsqu'une story arrive dans le futur sprint, l'analyste ICT la transmet au SPOC du groupe de travail concerné et aux membres de ma cellule de travail pour validation.
Certains spoc's sont un peu lent à la détente et nous devons parfois valider des stories (qui nous semblent correctes) alors que nous n'avons pas fait partie du groupe de travail.

Si vous avez des expériences similaires, des conseils, des idées,... N'hésitez pas !

[Bruno Orsier]

Merci pour ce témoignage. J'aurais besoin de savoir ce que veulent dire SPOC, ICT, CR.

Au vu de la description, j'ai l'impression que travailler en Scrum met en évidence certains problèmes, qui probablement pré-existaient, c’est-à-dire qui ne sont pas causés par Scrum ?

Concernant "l'immobilisme" des utilisateurs, est-ce que vous travaillez réellement sur ce qui a de la valeur pour eux ? Est-ce que vous allez sur le terrain voir ce qui se passe pour eux (activités du type "vis ma vie") ? En général, vouloir "faire comprendre" des choses aux gens est une posture assez peu efficace - il est plus efficace de changer soi-même, changer la relation, faire des choses différentes (approche systémique).

Même réflexion pour le "lents à la détente". Là, que se passerait-t-il si vous ne prenez pas en charge leur part de travail pas faite ? Quelles sont les conséquences ? Peut-être rien ? Et dans ce cas, peut-être que vous ne travaillez pas sur les bonnes priorités ?

Une autre piste, dans un tel contexte, serait de travailler sur les nouveaux comportements attendus et pertinents autour de Scrum - il s'agit de faire par exemple des ateliers collectifs (agilité comportementale, intelligence collective).

Voilà quelques idées,
Bruno

[Thogrom]

Bonjour,

Avant tout quelques précisions :

SPOC : single personne of contact, personne de contact du groupe de travail mais qui est également la personne qui dirige le groupe et organise les réunion

CR : Change-request, demande de changement de l'application par un utilisateur

ICT : Service informatique

-----------------------------------------------------

1/ J'ai travaillé comme utilisateur sur l'ancienne application. Pas sur la nouvelle.
J'avais déjà pensé à aller à la rencontre des utilisateurs via des séances d'informations/questions. Je trouve que c'est une bonne idée. Reste à convaincre mes collègues directs.

2/ Si on ne prend pas en charge le travail, la fonctionnalité demandée par les utilisateurs et "prioritisée" par le groupe de travail ne sera pas développée. Au final, c'est l'utilisateur qui est perdant.

En résumé, je pense que je dois renouer un dialogue avec les utilisateurs et avec les groupes pour leur démontrer qu'ils sont les acteurs de 1er plan des améliorations de l'application.

Merci pour les remarques constructives

[Luckyluke34]

J'interprète peut-être, mais ta description laisse penser que les décideurs métier ne sont pas intégrés à l'équipe. Dans Scrum, le Product Owner est dans l'équipe et participe à toutes ses réunions. Je ne sais pas exactement à quoi correspond un "groupe de travail" mais ça donne l'impression d'un électron libre qui bosse sur les sujets quand il peut, n'est pas réellement associé à l'équipe et ne vit pas le rythme des sprints. Pas étonnant que dans ce cadre, l'implication laisse à désirer.

Concernant l'indifférence des utilisateurs, je vois deux aspects à travailler :

• La communication (on pourrait même dire le marketing) lors de chaque release. Tu dis que les utilisateurs finaux sont peu source de proposition mais sont-ils bien sensibilisés aux applications en question ? Faire des communications écrites, des sondages, organiser des présentations, des ateliers et des formations sur une application qui va sortir. Voire même impliquer un user en plus du PO dans certaines réunions, tout cela permet aux gens d'être au courant (ça parait idiot, mais ce n'est pas toujours le cas), de s'approprier leur outil et réduit l'impression que c'est "l'application du PO" ou du décideur qui l'a demandée.

• La relation utilisateur une fois le produit en prod est d'autant plus efficace qu'elle est intégrée à l'application elle-même. Ne pas hésiter à releaser tôt (même en béta) et recueillir les avis utilisateurs via une petite fonctionnalité "qu'en pensez-vous" pour aider le pilotage du produit. J'ai fait ça récemment pour mesurer le taux de satisfaction sur un moteur de recherche et les retours (notation + commentaires) sont très intéressants. C'est une mine de nouvelles fonctionnalités potentielles. L'analyse du comportement utilisateur est aussi une bonne façon de savoir si les usages sont tels qu'ont les prévoyait et de valider/invalider des hypothèses de développements futurs.

[Thogrom]

Bonjour,

Un groupe de travail est composé d'utilisateurs de l'application et d'au moins un analyste ICT (dont le scrum master de l'équipe de développement concernée par le thème géré par le groupe de travail).

Comme nous sommes en post-production, les groupes de travail liés à des thèmes "généraux" ne travaillent plus que lorsqu'il y a une demande d'adaptation de l'application par les utilisateurs (n'importe quel utilisateur peut faire une demande mais c'est le groupe de travail qui la valide, lui donne une priorité et la transmet à l'ICT).

Par contre, quand une nouveau projet a un impact sur l'application (p. ex : modification de la législation), s'il est "léger", il est donné à un groupe existant et s'il est "lourd", un nouveau groupe est créé. Ce type de groupe est plus actif durant sa phase "projet" et les adaptations de l'application qu'il décide sont prioritaires par rapport à celles des autres groupes.

Donc, l'implication d'un groupe de travail dans un sprint varie fortement d'un sprint à l'autre.
NB : chaque équipe de développement est liée à plusieurs thèmes (et donc plusieurs groupes de travail) pour ne pas rester à ne rien faire ;-)

Ta première remarque rejoint celle de Bruno sur la communication. C'est une idée qui me trottait dans la tête : il me reste à convaincre collègues directs et hiérarchie.

Ta deuxième remarque est intéressante. J'aime le côté sondage comme source d'idée.

[Drawingrom]

Bonjour,

Deux remarques :

* Quand je vous lis, je comprends que les groupes de travail ICT n'intègrent pas les développeurs. Si vous êtes en contexte Scrum, il serait bon de les intégrer tous : ils pourront donner une estimation de complexité et aider au murissement via une réflexion sur les cas de tests.
* Vos utilisateurs remontent peu de besoin ou de remarque ? C'est que votre mécanisme de collecte de feedback n'est pas adapté. Une suggestion : pourquoi ne pas passer une journée avec eux, pour voir comment ils appréhendent leur travail et quelles sont leur réactions à chaud lors de l'utilisation de l'application ?

[Luckyluke34]

Comme nous sommes en post-production

Lorsqu'une story arrive dans le futur sprint, l'analyste ICT la transmet au SPOC du groupe de travail concerné et aux membres de ma cellule de travail pour validation.
Certains spoc's sont un peu lent à la détente et nous devons parfois valider des stories (qui nous semblent correctes) alors que nous n'avons pas fait partie du groupe de travail.

Dans ce cas, Scrum est-il toujours adapté ? Je n'ai pas très bien compris si les sprints mélangent des features de plusieurs applications, mais si c'est le cas, est-ce qu'on n'émiette pas une grosse partie de l'intérêt de Scrum qui est de focaliser toute la puissance de l'équipe sur un seul objectif ? Tout en s'obligeant à des contorsions liées à la présence, si j'ai bien saisi, de multiples acteurs : PO, groupes de travails, analyste...

Dans un mode davantage basé sur du pull, il y pourrait y avoir une chaine de responsabilités mieux identifiée et plus séquentielle : un utilisateur fait une demande/bug report, le groupe de travail s'en saisit, la priorise, la met dans le backlog de l'équipe, celle-ci tire l'item et le réalise.

[Thogrom]

Bonjour,

@ Drawingrom :

1. Les groupes de travail sont des groupes "business" renforcés par au moins un analyste ICT(au minimum le scrum master de l'équipe concernée par le thème du groupe de travail)

2. Deux collègues de mon équipe travaillent encore 2 jours semaines en tant qu'utilisateurs de l'application.

@ Luckyluke34

Il s'agit ici d'une seule application. C'est une application qui gère plusieurs centaines de milliers de dossiers et effectue des paiements dans 360.000 de ceux-ci.
Mais, dans cette application, on ajoute des change-request mais également des groupes de change-requests qui sont gérés quasi comme des projets parce qu'ils découlent d'une adaptation importante de la législation ou parce qu'ils nécessitent une extension vers d'autres applications.
Par exemple, il y a quelques mois, on a décidé de scanner tous les documents "papiers" reçus. Il fallait, en plus de gérer la partie scanning et archivage des documents, générer une tâche à destination du gestionnaire du dossier concerné dans l'application générale pour qu'il puisse prendre connaissance du contenu du document et adapter les données du dossier en conséquence. Dans ce cadre, un groupe de travail spécifique a été créé, à la fois pour gérer le processus organisationnel du scanning mais également les change-request nécessaires au niveau de l'application.

Nous avons une chaîne de responsabilité :

Un utilisateur fait une demande/bug report, le groupe de travail s'en saisit, la priorise, et la transmet au productowner qui gère le productbacklog.

Ici s'arrête le rôle du business. Commence celui de l'ICT.

Le productowner la met dans le backlog d'une des équipe, celle-ci tire l'item et le réalise.