Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇 Nous en échangerons lors du 🔴Live jeudi : sl.run/9h21b5

@ViolaineT

2 жыл бұрын

Ce plan de charge est souvent demandé par les managers qui veulent pouvoir prédire l'avenir justement en termes d'embauche de ressources. En tout cas, SAFe ne dit il pas de préparer chaque PI avec un capacitaire justement issu de la velocité. Vous en pensez quoi du capacitaire ? Sinon, ds cette vidéo je rajouterais bien qqs extraits qui vous a plu du livre de Mike Kohn plutôt que de le citer deux fois.... on a compris c la bible. Mais au final, qu'en retenir ? Merci beaucoup.

@gotrektom

2 жыл бұрын

Hello @ScrumLife, J'adore vos vidéos! Celle-ci est hyper instructive et éveille chez moi plein de questions. Si je vois bien la plus-value du no-estimate (ou d'estimations relatives) au niveau des PM, comment voyez-vous les choses au niveau du portefeuille de projets? En tant que PMO, je me demande souvent comment transposer la pratique de l'agilité dans la gestion du portefeuille. Pratiquement, lors des réunions d'arbitrages, on fait quoi au niveau du resource management; en particulier si on entend sans cesse que des ressources sont manquantes, que des goulots d'étranglement sont rencontrés par des multiples chefs de projet?

@unehermineauborddeleau5983

2 жыл бұрын

@@gotrektom ca m interesse aussi de savoir ! 🙂

Nous avons nous aussi un document qui y ressemble, nous l'appelons "effort planning". Mais au lieu d'y ajouter la notion de "charge" (qui correspond aux chez nous aux jours par semaine), on y ajoute la notion de "budget". On y retrouve également les grands jalons du projet. Cet effort planning évolue à tous les incréments en fonction des changements et permet au PM de partager des informations avec l'équipe. C'est surtout un outil qui permet d'être transparent et d'essayer d'anticiper des problématiques et donc de gérer aussi certains risques, liés justement à un contexte qui n'est pas agile.

Est-ce qu'une truelle à plâtre est un outil pour les équipes d'ébenistes?

Là on pactise avec le diable 😈 Surtout, on perd de l'énergie pour rien ... et on cherche à obtenir ce qui est à bannir : le contrôle par d'illusoires prédictions. N'oublions pas la seule VRAIE prédiction : il y a toujours plus de choses à faire que le temps et le budget nous permettent de réaliser ET rajouter des personnes à court et moyen long terme ne fera pas livrer plus. Sinon : - Un budget - Une équipe pour déterminer une date butoire. - Un impact mapping - Un story mapping - Des itérations courtes - Vérifier la valeur puis PRIORISER encore et encore - Un plan de livraison à mettre à jour pour tenter d'anticiper un possible écart avec la capacité à livrer. Et basta :)))

@ScrumLife

2 жыл бұрын

Oui ! Bien dit Eirian ! J'en déduis que tu es d'accord avec nos propos dans cette vidéo. Est-ce qu'il y manque quelque chose ? Un truc en plus dont on aurait dû parler ? -- JP

Chez nous, on a un besoin qui se rapproche d'un plan de charge, qu'on détermine de manière hebdomadaire. Pourquoi on a mis ça en place? Et bien (je commentais ça sous une autre vidéo scrum life), nous sommes une petite équipe avec de multiples produits, qui ont souvent besoin d'avancer en parallèle. Avant, on gérait ça au jour le jour mais on a rencontré une dispersion du travail, des revues qui traînaient parce qu'il y avait moins d'objectifs communs sur le court terme. Ce qu'on a fait pour palier ça, c'est déterminer en début de semaine une charge estimée pour atteindre nos objectifs de sprint, et affecter des jours sur les différents produits, afin que plusieurs personnes travaillent en même temps sur le même sujet. Évidemment on se laisse la place à une urgence si elle se présenter mais on essaie de se tenir à ce "plan de charge". Ça nous a bien aidé à recentrer l'équipe sur des objectifs communs

@eirianlegoux

2 жыл бұрын

Dans ce que vous dites, ça reste intelligent et flexible. Encore plus si c'est une décision prise collectivement. Aujourd'hui vous avez cette solution, demain ce sera peut-être une autre. Vous appelez ça un "plan de charge hebdomadaire" mais on pourrait presque y lire un "Sprint planning" ;)

@ScrumLife

2 жыл бұрын

Salut @ttehir, je rejoins Eirian, déjà si vous faites ça en bonne intelligence ça change la donne ! Dans tous les cas merci BEAUCOUP pour ton partage et retour d'expérience. Cela reste un des apports les plus précieux que tu puisses faire à la communauté ! Merci ! Est-ce que tu dirais que la vidéo t'aide à remettre en continue les pratiques de ton équipes et de ton organisation ? -- JP

@ttehir

2 жыл бұрын

@@ScrumLife la partie sur l'agilité dans le cadre d'une réponse formalisée fait toujours du bien à entendre ;-) C'est déjà comme ça qu'on fonctionne mais ça donne des billes pour justifier la démarche auprès des clients (et des commerciaux). Vous avez besoin d'un cadre avec un chiffrage, très bien on va vous le faire pour l'exercice car vous en avez besoin pour avancer, mais ce sont les besoins qui guideront les développements, pas ce document

@ScrumLife

2 жыл бұрын

@ttehir est-ce qu'en parallèle vous essayez de trouver d'autres modes de fonctionnement / de contractualisation avec vos clients ? Pour sortir de ce mode à l'ancienne dès le début ? -- JP

@ttehir

2 жыл бұрын

@@ScrumLife oui, on fait ce genre de choses uniquement quand on n'a pas le choix, lors de réponses à des appels d'offre par exemple

OK, c'est bien beau mais dans la pratiqué c'est un peu utopique. Vous ne prenez pas toutes les dimensions : Entreprise en cours de passage en agile sur un domaine mais les passages pour obtenir le budget reste ancrés dans les méthodes traditionnelles (plan de charge, planning de gant,...) Sous traitant avec des livraisons dans le temps vont vous contraindre à établir des sprint en fonctions des livraisons donc planning de Guant Autant de raison pour effectuer un plan de charge que vous n'explique pas et surtout comment vous prévoyez un release si vous devez vous accoster à une livraison d'un sous-traitant ? C'est la réalité pas la théorie Merci

@ScrumLife

2 жыл бұрын

Merci Didier pour ton message, désolé d'y répondre un peu tard. Ce que nous décrivons dans cette vidéo ce n'est pas que de la théorie, nous avons pu mettre ces choses en place "dans la vraie vie", dans des grosses boîtes ou des plus petites. C'est sûr que dans ce que tu décris, il manque une part essentielle qui est l'influence de l'équipe sur le process. Tu décris une équipe qui voudrait être agile, dans un monde rigide, mais ce n'est pas une fatalité. La question du sous-traitant, des dépendances est cruciale et si tu ne l'as pas vu, je t'invite à regarder la vidéo que nous avons fait sur l'agilité chez Tesla ou SpaceX : kzread.info/dash/bejne/qoqg2aZrqMLHdqQ.html Ce qui est sûr, c'est que c'est un changement de mindset très important, mais ce qui est bien, c'est que ce n'est que ça, ce n'est qu'une question de volonté des acteurs... et en même temps, c'est le plus difficile à changer :) -- Constantin

Bonjour, intéressant votre avis sur le plan de charge. Mais cela me fait me poser une question : le plan de charge est entre autre utile pour visualiser les équipes sur ou sous occupees. Les goulots d etranglement surtout quand on est dans un contexte où les ressources sont sur du multi projet (par exemple, une dsi). Comment si le plan de charge n est pas mis en place, comment une orga peut elle identifier les équipes en sur et sous capacité et sur les périodes sur lesquelles elles le seront ? L idee étant d etre capable de prédire l occupation des équipes autant que faire se peut. Je suis impatiente de vos retours ! 🙂

@ScrumLife

2 жыл бұрын

Merci pour ta question "Hermine" :) Ce qui est intéressant dans ta formulation c'est ce qu'on devrait rechercher dans les équipes. Le plan de charge ne dira que rarement si l'équipe est en surcharge ou pas. Le plan de charge peut dire simplement que "en fonction de ce qu'on a mis dessus, elles devraient être trop occupée". Ce n'est pas la réalité. Sur le terrain, à chaque fois que j'ai pu assister à ça, on se rendait compte que finalement ce n'est pas ce qui se passe. Nous pensions la charge de l'équipe équilibrée et finalement, elle est sous l'eau, bloquée et ralentie tout le monde. Comme beaucoup d'autres artefacts dans le monde de la gestion de projet traditionnel, sont considérés comme étant la réalité et pourtant sont très rapidement invalidés par le terrain. De plus, ils risquent de ne pas aider à traiter les vrais problèmes comme le changement de contexte, les dépendances, etc. On se dit qu'on les gère (ce qui est un mensonge qu'on se fait) au lieu de chercher à les éviter. -- Constantin

@unehermineauborddeleau5983

2 жыл бұрын

@@ScrumLife bonjour Constantin 🙂, merci pour ton retour. Je suis d accord avec toi sur la limite du plan de charge et son danger dans la mesure où il peut donner l illusion de la maîtrise d un pilotage traditionnel. Nous avons un système qui implémente la notion de plan de charge mais qui met en regard le réel par rapport au planifie. Ce qui permet de voir les écarts réels vs plan et au moins on a ces 2 dimensions : ce qu on pensait et ce qui a réellement été fait. L'exercice continue d avoir des limites que je ne nie pas. Mais au moins on a une comparaison pour visibiliser les écarts. C est déjà ca...après ce qu on en fait c est une autre question 😅. Mais je m interroge quand meme : les dsi qui sont en mode scrum, elles ne s interessent pas à la question de si les équipes sont sur ou sous occupées ? Tant qu un projet est en cours, j ai compris que les équipes de devs sont staffees. Mais quand on autre projet veut arriver, quand peut on dire au sponsor du moment où son projet sera mis à ordre du jour, si il n y a pas de suivi du plan de charge des membres de l equipe projet ? Peut-être que l equipe projet est toujours mono-projet ? Dans ce cas, on peut en déduire un plan de charge biaisé en se disant ok l equipe est staffee full jusqu'à telle date puis de nouveau 100% de dispo. Franchement ça m interesse vraiment comme question. Hâte de ton retour 😉

@ScrumLife

2 жыл бұрын

Des questions tout à fait légitimes. Pour y répondre, il faut à mon avis se forcer à désapprendre ce qu'on sait, à faire bouger nos acquis. Par exemple, pour une équipe produit, une équipe agile, la notion même de "DSI" est à mon sens un boulet. C'est un frein car c'est un silo qui ne bénéficie pas à l'équipe, au contraire. Ce qui a de la valeur, c'est le produit de l'entreprise. Or, avoir une DSI implique que celle-ci a un objectif : son utilisation. Pour une DSI, il est important de survivre parfois, de ce que j'ai pu observer, au détriment du produit pour justifier son existence, son budget, etc. Dans une équipe agile et Scrum en particulier, il ne peut pas y avoir plusieurs directions (et donc plusieurs objectifs généralement), tout le monde doit travailler dans le même sens, dans le même but. Comme tu l'écris, la DSI va vouloir que ses techniciens soient occupés, puis de les passer rapidement vers un autre projet. Pour qu'un produit réussisse, je pense pour ma part qu'on doit jouer le "infinite game" (notion empruntée à Simon Sinek), c'est à dire qu'on produit ne fini pas, il évolue constamment pour s'adapter aux besoins du marché. Entre le produit v1 et ce qu'il sera 3 ans plus tard, ça peut très bien être complètement différent. On ne cherche plus à caser les dev, mais à ce qu'il vivent avec un produit et l'aide à se développer. Pour cela, ils vont même devoir adapter leur compétences parfois, apprendre des nouvelles choses. C'est une vision différente. Je dis souvent, pour provoquer, que les entreprises qui ne se séparent pas de leur DSI sont vouées à mourir. -- Constantin

@unehermineauborddeleau5983

2 жыл бұрын

@@ScrumLife merci Constantin pour ta réponse ! Je comprends que tu appuies fortement sur les notions d'équipe, de produit et de valeur pour l entreprise. Tu invoques un cas de dilemne de la théorie des contraintes à mon sens, basé sur le fait que la somme des objectifs locaux ne fait pas forcément l'objectif global optimal. Ou pour être plus concret, l entreprise a un but qui est de créer de la valeur pour l entreprise (via un produit "vivant" du coup) alors que les maillons qui la constituent en ont d autres (dsi =>survie). Ok. Mais pourtant, le thème de la dsi agile est à la mode et est portée par les dsi eux-mêmes. De ce que je vois, ils sont curieux de tout ce qui se passe à ce niveau là et se demandent comment traiter des projets en agile dans leur orga. De ce que je vois, ils aimeraient bien faire mais ils savent aussi qu ils n y arrivent pas. Est-ce que tu dis qu'une dsi agile est un non sens pour toi ? Que c est impossible ? Pourtant, il y a un dsi qui s etait vanté d avoir transformé l'essai. Je ne sais plus qui par contre...qu en penses-tu ? Une dsi ne peut elle pas être agile selon toi ? Toujours hâte d avoir de tes retours 😉

Je vous partage ma vision. Le plan de charge, c'est jouer à tétris. On va mettre un peu de capa ici, en enlever là et BINGO !!! Regarde tout rentre, on tient les dates… Game over. Le plan de charge donne de la visibilité, il montre que tout rentre, que les dates seront atteintes, ça rassure les personnes… Le problème est là, ça rassure, où est la confiance ? Ma vision est fortement biaisée par mon contexte

@ScrumLife

2 жыл бұрын

Un sujet que nous n'avons pas trop évoqué dans la vidéo, c'est l'importance du contexte et du modèle d'équipe choisi. Dans un environnement agile, les équipes stables sont l'unité de base et le plan de charge perd de son sens. Dans un environnement traditionnel, typiquement en silo de compétences et où les personnes ou "ressources" sont partagés à X % entre chaque projet, le plan de charge fait alors du sens... Ou disons plutôt que le problème n'est pas tant le plan de charge, que le modèle organisationnel justement. Qu'en dis-tu ? -- JP