Difficultés rencontrées pour la mise en place de Scrum

Communauté Scrum Life
,
1

Bonjour la communauté,

Je travaille dans une ESN d’une soixantaine d’employés, développant un ERP constitué de « x » modules.

Je suis PO et Scrum Master (oui, c’est mal) au sein du département R&D, où l’on essaie de mettre en place Scrum malgré une culture d’entreprise initialement très « cycle en V ».

Le contexte :

On a d’un côté la R&D, de l’autre côté l’équipe projet.
il y a une équipe R&D pour le développement standard du produit, et une équipe projet pour la partie spécifique directement en contact avec le client.
Nous avions des développeurs dédiés à chaque équipe, mais cela n’était pas satisfaisant.

Notre « Roadmap » est surtout tirée par les projets clients vendus, et une partie est constituée par les fonctionnalités identifiées par les PM mais non demandée par les clients.
Ce qui implique des dates de livraisons définies en avant vente sur lesquelles nous n’avons pas réellement notre mot à dire, à part les macro chiffrages (évidement faux) effectués 6-12 mois à l’avance…

Le fait d’avoir « siloté » l’équipe R&D et l’équipe projet ne nous convenait pas.
Du coup, nous avons remué ciel et terre afin de changer notre organisation et notre gestion du produit.

Voici les changements effectués :

1/ Il n’y a plus de développeurs dédiés R&D ou projet, mais il y a une équipe de développeurs dédiés au produit (standard et spécifique).
2/Le code est maintenant constitué du standard et du spécifique, géré par feature flipping.
3/Une spécialisation des équipes de développeurs et PO par périmètre fonctionnel, en tentant au possible d’avoir des équipes stables.

Mais nous rencontrons toujours des difficultés pour mettre en place Scrum de manière stable :

Par exemple, les mises en production et les priorités « entreprise » peuvent changer radicalement d’un sprint à l’autre, ce qui peut impliquer que les équipes Scrum soient amenées à changer. De plus, il arrive que certaines équipes se retrouvent avec peu de demandes clients tandis que d’autres sont surchargées, les développeurs d’une équipe peuvent donc être amenés à aider une autre équipe Scrum « dans le dur ». Idem pour les POs qui peuvent aller aider sur les tests.

Les POs peuvent également manquer d’informations importantes en étant éloignés du contact client direct (leur contact client est le chef de projet).

Le fonctionnement interne des équipes Scrum est le suivant:

-Nous avons des sprints de 3 semaines, les équipes sont synchronisées sur ce rythme.

-Il n’y a qu’un backlog pour l’ensemble du produit, les différentes équipes se partagent ce backlog.
-Le PO récupère les besoins standards et spécifiques, alimente le backlog, le priorise, et alimente « son » prochain sprint avec les US correspondantes à ses modules / son périmètre.

Les US sont affinées avec les développeurs.
-Une réunion est faite avant d’effectuer les sprint plannings, entre les différents POs, la personne en charge de la priorisation globale ainsi que le responsable du groupe des développeurs.

Lors de cette réunion, on tranche dans le vif, on sort des US / sujets jugés comme non prioritaire pour le sprint. On en rajoute si besoin, et on vérifie grosso modo que les différentes équipes sont en capacité de sortir les US pour atteindre les objectifs définis.

Cette réunion permet de s’assurer que les priorités de chaque PO sont bien en adéquation avec les priorités globales et de prendre les décisions nécessaires pour respecter les dates de livraison annoncées aux clients.
-Enfin, chaque PO a sa propre liste finale d’US, qui est ensuite utilisée lors du sprint planning pour que son équipe de développement décide des US qu’elle souhaite inclure dans le sprint.
-Chaque fin de sprint (3 semaines), nous effectuons une démo du travail accompli à toutes les parties prenantes internes (les feedbacks ne sont jamais très nombreux)
-Nous effectuons aussi la rétro.
Ces deux cérémonies sont communes aux équipes.

J’espère avoir été clair sur notre point de départ, notre objectif et les obstacles auxquels nous faisons face dans mon entreprise .

J’aimerais avoir votre avis sur les actions que nous avons entreprises jusqu’à présent. Que pouvons nous faire de plus?

Je suis ouvert à tous les conseils, remarques, je débute dans ce rôle et je ne demande qu’à m’améliorer !

Merci d’avance !
Nico

2

Salut Nicolas,

Tout ca m’a l’air pas mal :). Je ne sais pas si c’est correcte mais de ce que je comprend les problèmes restants sont :

  • roadmap tiree par les projets + fonctionnalités PM qui donne des chiffrages faux
  • MEP et priorités changent
  • différence de charge entre equipes
  • PO manque d’infos metiers
  • peu de feedback

Je te donne mon avis mais il y aura que toi qui pourra vraiment savoir ce qui est bien de faire ;).
Pour les roadmap tirée par les projets, je ne vois pas trop ce que tu peux faire une fois que c’est fait, c’est plutôt au moment de vendre le service qu’il faudrait le vendre dès le début en mode Agile.
Par contre il faut que vous ayez quelqu’un, je ne sais pas si c’est le cas, qui puisse arbitrer sur les prios haut niveau (entre les demandes PM, les différents projets…).

Pour les MEP et priorités qui change, est ce que tu sais pourquoi ? Il faudrait creuser. Si ils fonctionnent par projet au contraire ça devrait être assez claire.

Pour la différence de charge, une des solutions serait d’avoir des équipes moins spécialisés fonctionnel. Car de ce que je comprends c’est juste un seul produit.
Comme vous avez un seul backlog pour tout le monde, ce qui est un bon départ, les features/US pourraient être reparti dans les équipes par priorité, même si ça concerne qu’un domaine fonctionnel.
Ca peut aussi être un mixte, choisir par priorité mais s’autoriser aussi des évolutions spécifiques à « son domaine » si ça amène quand même de la valeur, car je suppose les développeurs vont moins vite quand c’est pas leur domaine. Il semble que vous faites un planning commun entre les équipes de ce que je comprend alors la planification de la capacité devrait être vu là.

Pour les PO qui manquent de contact client, je te dirais continue à remuer ciel et terre pour que ce ne soit pas que le CP qui ait un contact avec le client. Peut être le chef client peut aussi vous fournir des « contacts metiers » chez eux que les PO ou l’equipe pourraient contacter directement.

Enfin pour le manque de feedbacks, étant donné que c’est interne seulement, et en plus basé sur des projets, ce n’est pas très étonnant, car ces parties prenantes n’ont pas vraiment le pouvoir de changer le scope si?

Tu peux éventuellement leur donner accès à une plateforme de test après pour qu’ils puissent plus jouer avec.

Note aussi que pour les rétros vous pouvez aussi en organiser une plus large avec les parties prenantes pour parler de ces obstacles externes par exemple.

En tout cas bravo, j’ai l’impression que ca a déjà bien bougé par rapport au fonctionnement initial. Bon courage.

3

Depuis combien de temps tout ça est mis en place ? Si ces changements datent d’il y a peu, la meilleure chose à faire c’est d’attendre que ça se tasse et que tout le monde ingère et intègre ces changements.

4

Salut Val,

Merci beaucoup d’avoir pris le temps de lire mon long message et d’avoir en plus pris le temps de me répondre !

"Pour les roadmap tirée par les projets, je ne vois pas trop ce que tu peux faire une fois que c’est fait, c’est plutôt au moment de vendre le service qu’il faudrait le vendre dès le début en mode Agile.
Par contre il faut que vous ayez quelqu’un, je ne sais pas si c’est le cas, qui puisse arbitrer sur les prios haut niveau (entre les demandes PM, les différents projets…). "

  • Effectivement, une solution serait de vendre les projets en mode agile. Encore faut il que les commerciaux soient « armés » pour le faire, soient convaincus que c’est la « bonne » façon de mener un projet. On travaille sur ce point, mais ce n’est pas gagné.
  • Concernant l’arbitrage, on est aussi entrain de travailler dessus, en améliorant notre transparence avec l’équipe projet, en essayant d’avoir une roadmap claire, avec les objectifs entreprises stratégiques identifiés, et en allant voir les « décideurs » directement à la source lorsque des sujets se « télescopent ».

« Pour les MEP et priorités qui change, est ce que tu sais pourquoi ? Il faudrait creuser. Si ils fonctionnent par projet au contraire ça devrait être assez claire. »

-On a par exemple une MEP prévue fin de mois, les sprints sont organisés pour pouvoir tenir cette deadline, SAUF que : 1/ des tickets sont au finals beaucoup plus complexes à réaliser 2/ Des bugs bloquants sont découverts… et du coup la MEP doit être décalée, et devient plus prioritaires que des priorités « hautes » prévues pour plus tard. C’est là que les vases communiquant entre les équipes apparaissent, des membres d’une équipe Scrum viennent en aide d’autres équipes qui doivent effectuer la MEP (en retard) le plus rapidement possible, leurs sujets sont donc mis en stand by…

"Pour la différence de charge, une des solutions serait d’avoir des équipes moins spécialisés fonctionnel. Car de ce que je comprends c’est juste un seul produit.

Comme vous avez un seul backlog pour tout le monde, ce qui est un bon départ, les features/US pourraient être reparti dans les équipes par priorité, même si ça concerne qu’un domaine fonctionnel."

Effectivement, c’est bien un seul produit. Le « soucis » que l’on a avec notre produit, c’est que le périmètre fonctionnel est très large, et que si les équipes passent d’un périmètre fonctionnel à un autre (c’était le cas avant), les équipes ne montent pas en compétence, elles connaissent au final un peu de tout, et du coup, un peu de rien. Cela a été remonté par les équipes en rétro. On a donc pris le parti de spécialiser les équipes sur un périmètre fonctionnel (tout de même sur plusieurs modules donc assez large), afin de capitaliser sur la connaissance et gagner en efficacité, plutôt que de répartir les US par priorité sur l’ensemble des équipes, quel que soit le périmètre fonctionnel. On se trompe peut-être de direction ?

« Ca peut aussi être un mixte, choisir par priorité mais s’autoriser aussi des évolutions spécifiques à « son domaine » si ça amène quand même de la valeur, car je suppose les développeurs vont moins vite quand c’est pas leur domaine. Il semble que vous faites un planning commun entre les équipes de ce que je comprend alors la planification de la capacité devrait être vu là. »

On fait une réunion commune entre PO, le responsable « priorisation », et le chef de groupe des développeurs, afin de planifier le sprint prochain dans sa globalité. Ensuite, le sprint planning est effectué par équipe.

C’est bien à ce moment que la capacité de chaque équipe est vu, on compare les US prévues dans le sprint par équipes VS la disponibilité, on vérifie aussi que les dév ne se retrouveront pas sans travail pendant le sprint (problème que nous avions eu une ou deux fois dans les premiers sprints, et que nous avons corrigé grâce entre autre à cette réunion). C’est à ce moment que l’on se rend compte que pour atteindre les objectifs de sprints en adéquation avec les priorités entreprise, certaines équipes se retrouvent surchargées, et d’autres en sous charge. C’est à ce moment que l’on a le phénomène « vase communiquant », avec certains membres allant aider d’autres équipes.

« Pour les PO qui manquent de contact client, je te dirais continue à remuer ciel et terre pour que ce ne soit pas que le CP qui ait un contact avec le client. Peut être le chef client peut aussi vous fournir des « contacts metiers » chez eux que les PO ou l’equipe pourraient contacter directement. »

Effectivement, celà fait partie d’une des batailles, on essaye de faire en sorte que les PO puissent assister à certains ateliers avec le client, évidemment se pose la question financière, il est difficile de facturer 2 personnes à la place d’une…

Comme tu dis, le top serait que le PO puisse avoir un contact direct chez le client si besoin.

Ce sujet me fait penser à un autre, nous effectuons des sprint de 3 semaines, MAIS le résultat n’est présenté qu’à la toute fin par les chefs de projets. On perd donc tout l’intérêt de fonctionner en sprint.

Sur un des récents projets, celà nous a porté préjudice. pour la faire courte, projet validé il y a 6 mois, avec une date de mise en prod définie, spécifications « sommaire » + chiffrage validés eux aussi. Du retard à évidement était pris car il y avait une grosse différence entre le chiffrage / spéc effectués il y a 6 mois, et les US créées / développées au cours de 5 sprints, les US étant beaucoup plus compliquées à réaliser… Résultat, le CP présente le travail accompli au client, et découvre que le besoin du client a évolué → pour le client, son besoin n’a pas été compris.

Un mal pour un bien, des démos (avec de temps en temps le PO) sont maintenant organisées avec ce client, afin de rectifier si besoin les US des prochains sprints, et ne pas se retrouver avec 25% des développements qui ne seront pas utilisés. A voir comment généraliser cette bonne pratique.

« Enfin pour le manque de feedbacks, étant donné que c’est interne seulement, et en plus basé sur des projets, ce n’est pas très étonnant, car ces parties prenantes n’ont pas vraiment le pouvoir de changer le scope si? »

Le scope pourrait potentiellement être changer je pense, si les arguments pour le faire changer sont pertinents.
On réfléchit sur un moyen de récolter plus de feedback, une des pistes envisagées serait de réaliser plusieurs démos chaque fin de sprint, une démo par périmètre fonctionnel, seulement avec les CP travaillant sur ce périmètre. Je pense que l’on aurait du coup plus de retours.

Le problème, est que nous ne voulons pas supprimer la démo globale à l’ensemble de l’entreprise, car il nous semble que c’est important que tout le monde ait le même niveau d’information sur le produit.

Donc si nous gardons la démo globale + les démos par périmètre fonctionnel… trop de temps sera passé en démo.

« Tu peux éventuellement leur donner accès à une plateforme de test après pour qu’ils puissent plus jouer avec. »

Effectivement, je me rends compte que j’ai oublié de mentionner une information importante, les développements effectués au cours du sprint sont d’abord testés par les PO, puis une fois qu’ils sont OK, ils sont livrés au CP, qui effectue des tests. Nous récoltons donc des feedbacks à ce moment, quand les tests sont effectués par les chefs de projet.

« Note aussi que pour les rétros vous pouvez aussi en organiser une plus large avec les parties prenantes pour parler de ces obstacles externes par exemple. »

Très bonne idée, je vais réfléchir à ça, le hic est que nous risquons de faire une rétro à plus d’une quarantaine de personnes, et je n’ai encore jamais été amené à en faire une avec autant de personne. Je vais y réfléchir.

Encore merci beaucoup pour tes conseils !

Nico

5

J’ai l’impression que la « solution » est bien trop grosse pour son propre bien. Est-ce qu’il serait pas possible de la diviser en plusieurs « solutions » plus petites ?

1 « J'aime »
6

Salut Samuel,
Les changements ont commencé a être effectués depuis 6-8 mois à peu près.
Je ne sais pas à partir de combien de temps on peut faire un bilan pertinent ?

7

Désolé, je n’ai pas compris :slightly_smiling_face:

8

Tricky question. Vous avez défini est objectif et des moyens de mesurer que ce que vous avez mis en place fonctionne mieux qu’avant ? Ce genre de mesure à besoin d’un certain temps pour qu’elles soit pertinentes et surtout qu’on puisse observer des variations sur le long terme. Si les variations sont absentes, c’est un bon signe que vous pouvez continuer. Sinon, y’a des ajustements à faire.

9

En gros, plutôt que d’avoir une seule grosse application pour « tout », avoir plusieurs petites applications interconnectées.

1 « J'aime »
10

Effectivement, niveau objectif, on n’est pas très précis → on veut s’améliorer
Et nous n’avons pas mis en place de KPI.

Les seuls indicateurs que nous avons sont : est ce que l’on livre mieux (dans les temps, et y a t’il moins de retours), et est ce que le niveau de confiance des équipes projets s’améliore.
Ce sont des indicateurs qui se basent sur le ressenti, et non pas sur des données.

Je vais réfléchir à ce que l’on pourrait définir comme objectifs, et quel indicateur nous pourrions mettre en place pour vérifier que nous les atteignons.

11

Tu parles du produit que nous développons? Si oui, c’est le cas, le produit est divisé en modules interconnectés, dépendant les uns des autres.
Si non, désolé, je n’ai toujours pas compris

12

Si tu ne l’as pas déjà fait, jette un oeil du côté du bouquin Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations-ebook/dp/B07B9F83WM?ref_=ast_author_dp

1 « J'aime »
13

Je vais regarder ça, merci beaucoup

14

Bonjour @Nico

Déjà plusieurs points ont été abordés.

Mettre en place Scrum est louable, mais est-ce que les pré-requis sont présents ?

Devez-vous utiliser Scrum ? (les prérequis de Scrum)
Bravo @jplambert pour cet article est une référence.

Pourquoi je pose cette question ?

D’après ce que j’ai lu dans les messages précédents.

  • Avant la mise en place de Scrum vous aviez un fonctionnement existait déjà.
  • Après la mise en place de Scrum, je lis que cela a ajouté une couche au fonctionnement préexistant.
  • Résultat : on a « godzilla qui a du mal à se tenir debout ».

Alternative : Faire des petits pas

  • Commencer avec une rétrospective régulière toutes les 2 semaines par exemple. Plus ces événements sont rapprochés, plus l’amélioration est rapide.
  • Puis visualiser le flux de valeur (c.f. value stream mapping).
  • Ce flux de valeur, visualisé, pourrait être transposé en Kanban…

La force du Kanban réside dans sa compréhension !

Pour aller plus loin

2 « J'aime »
15

@Alexandre_Quercia ton lien Devez-vous utilisez Scrum pointe sur un 404…

16

Voilà, C’est corrigé.

1 « J'aime »
17

c’est juste un article excellent ! merci @Alexandre_Quercia de l’avoir retrouvé et à @jplambert de l’avoir écrit, tellement d’accord avec ce qui y est indiqué…

18

Mais… C’est pas tout ! J’en avais fait un meetup avec Malt, donc en version slides et avec JP qui parle : Devez-vous utiliser Scrum ? - YouTube

1 « J'aime »
20

Merci @Alexandre_Quercia d’avoir proposé mon article « La force du Kanban réside dans sa compréhension ».

Au plaisir d’échanger.

1 « J'aime »