Intronisation en tant que "PO"/"BM"/"Chef"... dans le tunnel

Communauté Scrum Life
1

Bonjour à tout le monde !

Je viens chercher quelques conseils dans la communauté Scrum Life, ainsi merci d’avance pour votre bienveillance.
Je démarre une nouvelle mission pour mener à bien la direction d’un projet de développement produit dans une petite société, développement en cours depuis plusieurs années. Il y avait jusqu’à présent un pilote à bord mais semblant éprouver des difficultés à canaliser ses idées et la gestion du projet de manière générale.
Une roadmap a été produite mais non revalorisée depuis 1 an, également un début de déclinaison fonctionnelle associée mais sans réels cas métiers figés.
Il existe bien quelques docs sous la forme de compilations de règles de gestion (ou d’idées) mais pas du tout versionnées, non classées, et dont les termes métiers évoluent sans cesse.
Aucun backlog mais des to-do list de développement (non quantifiées, ni évaluées). Incapacité des équipes à me donner des estimations ou des conso de temps passé, les sujets sont développés dans des tunnels.
Je crois deviner que l’équipe s’est naturellement sécurisée en développant sur une approche bottom-up, miser sur un modèle de données le plus ouvert possible qui permettrait à n’importe quel « rôle » de faire ce qu’il veut fonctionnellement parlant…le tout étant de se mettre d’accord sur le qui fera quoi in fine dans l’outil.
J’ai expérimenté le rôle de PO il y a une dizainne d’années mais dans un environnement plutôt cadré. Or ici visiblement c’est le bronx, nous en faisons tous le constat.
Les tentatives de rétrospectives sont vaines, je comptais le plus simplement du monde commencer par des groomings pour se mettre d’accord sur les définitions métiers (au niveau business, puis avec l’équipe de développement).
Puis partir au propre sur un use case (qui semble techniquement être en cours de développement…) et de tenter une déclinaison fonctionnelle, applicative et technique from scrach , ce qui nous donnerait un premier élément de backlog, puis de faire l’exercice de l’estimation ensemble.
J’ai le sentiment que chaque use case soulevé est une boite de pandore sans aucune limite d’usage prédéfinie, ni dans la durée ni dans l’espace ni pour le client destinataire.

C’est un peu nébuleux pour moi, ainsi je ne suis pas sur d’avoir la bonne approche.

Dernière chose : l’agilité semble s’imposer de fait, mais peut être n’est ce pas le plus pertinent ?

Merci pour vos conseils.

2

Je commencerais par dire « Bon courage ! » vous allez en avoir besoin.

Quelque part vous avez raison, je pense aussi que l’agilité bien apporté peut-être une solution. Mais, il ne faut pas l’emmener avec un bulldozer. Mais avec un sac de semis, une graine à la fois.

Si vous voulez tout corriger les problèmes, tous les problèmes en même temps, c’est presque l’échec assuré.

Vous nous avez soumis une liste de problème qui comme vous dites pourrait en cacher plus d’autres. Transformez cette organisation, cette équipe et les membres ne sont pas de chose simple.

D’abord, un peu comme un product backulog, j’essaie de faire une liste des grands problèmes et d’essayer d’établir un ordre d’intervention.

Exemple d’ordre :

  • Les problèmes plus critiques pour l’organisation

  • L’impact du changement pour les individus ou l’organisation

  • L’ouverture à ce changement

  • Les besoins de formations (et la disponibilité) pour mener aux changements.

La seconde étape une fois établit cette première liste. Je vous conseillerais de trouver à tout niveau dans l’organisation, de la direction jusqu’aux membres des équipes.

Même, j’opterais pour approche en mode fantôme de l’agilité. C’est à dire, vous pouvez en parler de manière générale. Sans pour autant vous peinturez dans le coin.

Allez y de pas en pas, et au besoin, laisser le temps agir lorsque vous rencontrer trop de résidences. Par fois, une bonne idée doit prendre le temps de germe dans la tête des gens. Visez haut, tout en acceptant que l’objectif ne se fasse pas en un jour… Et peut-être, il ne sera jamais attendu !

Bon courage

Bruno Larouche

3

Bonjour Yvon, et bienvenue sur le forum !

Une erreur que pléthore d’équipes font en démarrant avec des méthodes comme Scrum, c’est qu’elles restent contraintes dans un schéma de pensée algorithmique (où l’ordre des activités se fait en suivant un logigramme, idéalement séquentiel) au lieu de basculer dans un schéma de pensée heuristique :

Qui procède par approches successives en éliminant progressivement les alternatives et en ne conservant qu’une gamme restreinte de solutions tendant vers celle qui est optimale

Dans une véritable approche agile, on passe librement entre des activités marketing (étude de marché) d’ingénierie (conception/design), de production (codage, tests) ou logistique (déploiements). Seulement, sans autre forme de cadre, ça devient vite le « bronx » comme vous dites si bien.

C’est pour ça que la plupart des équipes finissent par revenir à leur vieux démons et organiser de manière algorithmique les activités dans le sprint. Dans une approche traditionnelle algorithmique, la pensée suit un raisonnement du type « j’ai un problème, j’imagine une solution, j’estime les coûts, j’implémente la solution prévue, et j’évalue à la fin ». C’est une démarche classique de type PDCA/roue de Deming. C’est de cette manière qu’on tue sans le vouloir la démarche heuristique. Au final ces équipes ne font pas vraiment du Scrum mais plutôt du RUP déguisé (plein de mini cycles en V).

La situation décrite est parfaitement cohérente avec une approche agile et en particulier Scrum, car vous avez la chance de vous trouver avec une équipe qui fonctionne naturellement de manière heuristique plutôt qu’algorithmique. Ce qu’il vous manque c’est de poser le cadre autour sans détruire cela.

Un point compliqué à expliquer aux personnes qui démarrent avec Scrum c’est de comprendre le sprint comme un cadre « plus fort que la solution ». Il ne s’agit donc pas d’implémenter « la » solution dans le cadre temporel fixé par le sprint, mais d’utiliser la temporalité du sprint comme délai qu’on se donne pour trouver et fournir une solution qui fonctionne (techniquement et commercialement) à un seul problème donné. Cette approche est aussi nettement plus motivante pour les équipes de développement, qui se retrouvent à nouveau en posture d’analyste.

C’est pourquoi les roadmaps, backlogs et estimations ne sont pas très importantes en agile, en tout cas nettement moins que les objectifs de sprint, objectifs produit et les OKR. En effet, le backlog de sprint est une vision à l’instant T des tâches à accomplir durant le sprint, mais cette vision évolue au cours de celui-ci - ce qui n’est possible que si un objectif de sprint a été convenu en sprint planning. De la même manière, la roadmap est une vision temporaire de la manière dont le produit est susceptible d’évoluer pour atteindre les objectifs produit et maximiser les OKR. Les estimations, quant à elles, n’ont pas vraiment d’intérêt puisqu’on connaît déjà le coût réel du sprint avant même qu’il ait commencé par la formule cout = CJM x ETP x durée. Et si j’ai 8 fonctionnalités dans mon backlog, et que j’investis un sprint de 2 semaines pour chaque, j’ai déjà une roadmap trimestrielle.

J’espère que ces éléments permettent de clarifier un peu la démarche vers laquelle Scrum pousse les équipes à aller. Reste ensuite l’épineuse question de la mise en pratique concrète et de l’accompagnement de l’équipe.