Est ce qu'on atteint la limite de l'agilité ? On court à la cata!

Communauté Scrum Life
1

Bonjour à tous,
Tout d’abord merci de m’avoir acceptée dans cette communauté, merci de nous offrir cette endroit d’échange de qualité. J’apprends tout les jours grâce à vous, grâce aux vidéos youtube qui traitent des vrais sujets de nos quotidiens.

Nous sommes dans un process de réécriture de notre logiciel phare avec des technos web, plus intuitif, performant et ergonomique. Nous avons une roadmap de 5 ans, nos clients ne pourant pas attendre 5 ans à utiliser l’ancien logiciel.

L’idée de départ des chefs c’est d’agrandir l’équipe R&D et l’équipe produit afin de réduire ce délai de 5 ans.

Résultats des courses, nous avons :

Un service R&D avec deux équipes de devs :

  • l’ancienne équipe : lead dev + 7 devs ( périmètre la nouvelle version du logiciel phare + les différents produits qui l’entourent)

  • la nouvelle équipe : lead dev + 3 devs ( périmètre la nouvelle version du logiciel)

Côté PO : 2 products owner pour alimenter la R&D, gérer les webinars, la communication autour du produit…

Nous sommes en recherche de notre nouvelle organisation, nous avons vécu un sprint ou tous nos rituels sont long et donc pénibles au bout d’un moment. Les deux lead dev qui ne sont pas toujours en phase voir de la concurrence entre les deux.

L’ancienne équipe perdue avec la nouvelle vision du nouveau lead dev.

L’ancienne équipe qui ne veut pas se retrouver à gérer l’ancienne version du logiciel, la réécriture en technos web était attendu par les membres de l’ancienne 'equipe.

Sachant que la nouvelle équipe ne connait pas le métier encore, n’a pas l’historique, et surtout la documentation de l’existant n’est pas complète.

Je ne sais pas si vous avez une idée de la meilleure organisation à mettre en place dans notre situation ?

Est ce qu’il faut séparer les deux équipes ? Sachant que le travail de l’une va impacter le travail de l’autre, que nous allons avoir le même objectif au sein des deux équipes

Est ce que 2 lead devs sur le même produit est envisageable ? Si oui, comment s’organiser ?
Est ce que un lead dev peut gérer une équipe de 10 dev ?

Comment garder une vision commune si on sépare les équipes ?

Merci de votre retour d’expérience ou même théorique.

PS : la lead dev de l’ancienne équipe :blush:

2

Ah ! La théorie que veut que 9 femmes pourraient faire un bébé en 1 mois a encore frappé :slight_smile:

Les deux points de départ à mon avis sont ces deux questions :

  • Si quelqu’un a estimé qu’il fallait 5 ans pour réécrire votre application actuelle, c’est certainement que l’application actuelle fait plein de choses compliquées. Etes vous certains que migrer d’une grosse application à une grosse application est la bonne approche ? Ne faudrait-il pas plutôt morceler le besoin ?

  • Quelle est votre stratégie de migration ? Comment vous passez de 100% des utilisateurs sur l’ancienne application à 100% des utilisateurs sur la nouvelle application : Big bang, migrer par fonctionnalité, par segment utilisateur, par géographie, … ?

3

Hello ! Bienvenue ici !

Je vais noter les choses qui me marquent dans ce que tu écris, et tâcher de répondre honnêtement à tes questions.

Déjà, sur ton titre : « La limite de l’agilité » et une roadmap à 5 ans, je peux déjà en déduire que ce n’est pas une vision de l’agilité. Il n’y en a pas dans une roadmap comme ça. J’ai déjà vu le cas sur une scaleup avec une roadmap à 5 ans aussi, et laisse tomber l’agilité produit là-dedans : c’est du cycle en V car on espère que le marché est hyper stable. Et c’était le cas et le marché leur a donné raison… dans les démarches ultra innovantes le feedback peut être une erreur… Mais je m’égare !

Passons la contrainte. Là, on est typiquement sur plusieurs problématiques où tu as potentiellement la main, et où il peut être pertinent de se poser ces questions :

  • Pour réduire le temps à moins de 5 ans, il faut absolument rendre le périmètre visible et jeter ce qui ne sert à rien. J’en ai suivi et bossé dessus, des migrations, et les deux erreurs classiques sont de ne pas découper le besoin, et de vouloir absolument être ISO avec l’ancien produit (donc ne rien jeter). C’est dangereux pour le business à long terme de la boite.
  • Les « rituels » sont longs : qui est le facilitateur ? S’il n’y en a pas d’exprimé réellement, comment en faire émerger un.e ? Y a pas de secret : même avec 5 ou 30 personnes un facilitateur peut faire des merveilles pour animer des réunions efficaces.
  • Il y a un conflit entre les deux lead dev : comment permettre aux deux d’apprendre à travailler ensemble ? Pour moi c’est une question de « comment prend on une décision (technique) quand les deux lead dev sont impliqués ? » Faut se poser directement la question et trouver des manières de fonctionner.

Et plussun sur la stratégie de migration.

4

Hi !
Merci pour ton temps.

Nous avons effectivement une stratégie de migration.
Nous allons migré module par module. Le fonctionnement de chaque module est revue, le besoin est identifiée, la solution est repensée avec un designer, validé par un groupe de clients… Tout cela prend du temps.

Les PO vont définir des épics, découper en US.
Derrière, chaque équipe va prendre en charge soit une us soit une epic, tout dépend de la priorité du PO.

Nous avons nos rituels agiles / scrum en place : daily, réunion de chiffrage, ateliers, démo, rétrospective, planification du sprint…

Sachant qu’on bosse tous sur le même produit, est ce qu’il faut diviser les deux équipes ? Quitte à faire certains rituels ensemble, si oui, lesquels ?

Ou est ce qu’il ne faut pas séparer les deux équipes, et retravailler les rituels ?

Merci

5

Je reformule la situation pour être sûr de bien comprendre :

  • Vous avez une application complexe mais découpée/découplable en modules
  • Vous voudriez paralléliser le travail pour éviter de garder l’ancienne appli pendant 5 ans
  • Votre migration est prévue module-par-module
  • Vous ne pouvez pas gérer plusieurs modules en même temps car le marketing/produit fait goulot

Si le marketing fait goulot, vous ne pouvez pas paralléliser le travail. Faire une, deux ou cinquante équipes de dev n’y changera rien, sauf mettre le bazar dans l’organisation. Vous allez devoir rester sur une migration de modules en séquence, les uns après les autres. Vous ne pourrez pas réduire le délai pour décommissionner l’ancienne application, il faudra la garder vivante jusqu’à la migration du dernier module.

2 « J'aime »
6

C’est très pertinent ce que tu me dis là. Ça reflète le constat d’aujourd’hui.
Ok, si on part de principe qu’on a une seule équipe de dev.

C’est quoi la limite logique en nombre de personnes qu’un scrum master peut gérer ?

C’est quoi le nombre max de personnes à gérer si on veut que la prise de parole ne soit pas compliqué, que les réunions et rituels ne soient pas long ? Qu’on est pas l’impression d’être dans une usine… ( J’ai rien contre l’usine :blush:)

Comment ce lead/scrum ou autre peut être présent efficacement à cette équipe, sachant qu’on a une production en parallèle, qu’on plusieurs services qui ont souvent besoin de notre aide ?

Merci merci

PS : j’ai adoré les 9 mois ==> bébé en 1 mois :joy:

7

Est-ce une manière de dire que c’est actuellement un des problèmes dans ton équipe ?
Quels sont les événements qui posent ce problème et quelle analyse portes-tu dessus ?
Pourquoi avez-vous mis en place ces événements à l’origine ?

La limite n’est pas déterminée par le nombre de personnes mais par les besoins d’accompagnement de l’équipe. Certaines équipes de 3/4 personnes nécessitent un SM à plein temps ; d’autres peuvent se contenter d’un SM à 20% pour une équipe de 20/30 personnes. Tout dépend de l’équipe.

J’ai un doute sur la compréhension de cette remarque. Est-ce que tu voulais dire :

  • que vous assurez la maintenance de la production en parallèle du développement, ou
  • que vous produisez l’application en parallélisant des tâches de développement sur plusieurs sujets ?

Pour les sollicitations d’équipes externes, je trouve que XaaS est un bon outil : cadrer les interactions comme un service rendu à l’autre équipe, avec une interface claire sur les services fournis, les délais de prise en charge et les modalités de sollicitation.

Ca rend ces demandes plus faciles à organiser.

8

Je me permets de mettre en avant cette citation du Scrum Guide | Scrum Guides :

If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

Corollaire : les équipes partagent les concepts au niveau produit donc elles ne partagent pas les concepts au niveau sprint : elles n’ont pas le même sprint goal, sprint backlog, ni les mêmes dates ou durée de sprint.