Scrum Life te ment ! Pas qu'UNE SEULE Agilité - produit vs à la demande
Жүктеу.....
Пікірлер: 51
@ScrumLife9 ай бұрын
Tu en dis quoi, toi ? Est-ce qu'on devrait plus expliciter quand on donne des conseils pour un mode "approche produit" ou "solution à la demande" ? Ou c'est très bien comme on a fait jusqu'ici ? Dis-nous en commentaire 👇👇👇👇👇🙏
@jasonmarechal55019 ай бұрын
Le problème que je vois en entreprise c'est que lorsqu'on est sur du logiciel à la demande et qu'on veut faire de l'agilité, assez souvent on garde les process, les personnes et leur fonction mais on leur met un label agile (PO, proxi po, SM) "Il faut être pragmatique" est souvent utilisé comme excuse pour ne pas faire ce qu'il serait bon de faire. Pour moi être pragmatique serait justement de dire que si on veut faire scrum, on le fait, à la lettre au moins au début. Si on pense qu'on n'en est pas capable être pragmatique c'est le dire et ne pas le faire mais peut être simplement améliorer les processus et méthode de travail existantes sans couloir tout labeliser scrum ou agile.
@OlivierFarlotti9 ай бұрын
Je comprends le questionnement et en même temps j'en arrive à penser qu'il relève d'une confusion récurrente. C'est devenu plus clair quand j'ai accompagné une équipe qui fait de l'assistance technique et qu'ils m'opposaient "ah oui mais nous on ne fait pas produit !". Ce à quoi je leur répondais : "Quand bien même, vous rendez bien un "service" à quelqu'un. De mon point de vue, leur produit, c'est le service rendu. Ce qui revient à se demander "Pour qui ?", "Pour quoi (quel bénéfice pour le client) ?". En posant la question comme ça, je trouve qu'on remet la valeur ajouté de l'équipe au bon niveau et notamment on remet en avant le client. On remet donc en avant le POUR QUOI avant le COMMENT (est ce que je suis AGILE...)
@ScrumLife
9 ай бұрын
Là dessus, il y a une définition très utile de ce qu'est un produit dans le Scrum Guide 2020 (dans la section sur le Product Goal) : "A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract." Ou dans la traduction française : "Un produit est un vecteur de valeur. Il a une limite claire, des parties prenantes connues, des utilisateurs ou des clients bien définis. Un produit peut être un service, un produit physique ou quelque chose plus abstrait." On a ainsi très souvent un produit selon cette définition. En tous cas merci pour ton partage ! Ta réflexion amène à réexpliquer pourquoi nous avons choisi la nomenclature "solution à la demande" et non pas "relation client / fournisseur" : car dans une relation client / fournisseur on peut soumettre des problèmes à résoudre et adopter une démarche produit. Mais dans une relation client / fournisseur qui impose les solutions à implanter, c'est une autre histoire... Qu'en penses-tu ? Bon, réflexion à continuer ! -- JP
@sixbenjamin9 ай бұрын
Il faut rester comme maintenant. D'une part, c'est plus important d'être challengé par de l'agilité "by the book" pour challenger ses pratiques et d'autre part, vu qu'il y a à peu près autant de forme d'agilité que d'équipe agile on risque de rentrer dans des vidéos où on pourrait passer plus de temps à parler du contexte que du sujet.
@ScrumLife
9 ай бұрын
Merci Benjamin et coucou au passage :-) - Constantin
@charliebaumgaertner9 ай бұрын
Il est intéressant, pour le Junior que je suis, de noter qu'il n'y a pas une seule approche "taille unique" en matière d'agilité. Parfois, une approche produit est appropriée, où l'on se concentre sur le développement et l'amélioration continue d'un produit. D'autres fois, nous pouvons être amenés à créer des solutions à la demande, en réponse à des besoins ou des demandes spécifiques. C'est un rappel utile que l'agilité est avant tout une mentalité et une culture, et que les méthodologies et les pratiques doivent être adaptées en fonction du contexte spécifique. Concernant la question, la distinction entre ces deux approches est cruciale et peut aider les équipes à comprendre et à appliquer les principes agiles de manière plus efficace dans leur contexte spécifique. La pertinence de cette explicitation dépend en grande partie de votre audience, les personnes moins familières avec l'Agilité, ou pour celles qui travaillent dans des environnements dans lesquels les deux approches sont utilisées, cette clarification pourrait être très bénéfique. Je pense que la clarté et la transparence sont toujours bénéfiques lorsqu'il s'agit de communiquer des idées complexes, et l'Agilité n'y fait pas exception !
@ScrumLife
9 ай бұрын
Merci pour ton commentaire ! Mais est-ce que ça ne risque pas d'être "lourd" et donc compliqué à comprendre si on précise systématiquement ce genre d'élément ? -- JP
@johannharguindeguy49409 ай бұрын
Merci Scrum Life de mettre en avant la transparence et le pragmatisme nécessaires pour mener à bon port l'équipage et son produit (bateau). Collaborer par une approche empirique, incrémentale, itérative devient une manière idéale pour s'adapter aux situations rencontrées. Trouver de nouveaux moyens voire, d'autres chemins à parcourir, néanmoins tout en gardant le cap. Désolé pour cette analogie et ce manque de valeur ajoutée, mais en tant que non (encore) Scrum Master, cette vidéo très bien ficelée et parfaitement mise en scène (bravo aux acteurs), aborde les valeurs qui me donnent envie de rejoindre votre profession.
@ScrumLife
9 ай бұрын
Merci à toi ! Très content de te donner envie ou plutôt de confirmer ton envie d'accompagner des équipes 😊 As-tu vu qu'on fait un Live tous les jeudi de 13h à 14h ? Tu es bien sûr le bienvenu ! -- JP
@fredericpetit15559 ай бұрын
C'est très bien d'avoir fait cette vidéo. C'est un débat récurrent : "je fais pas du produit mais pourtant est-ce qu'on fait de l'agilité ?" L'exemple du projet est en réalité le cas d'un travail cycle en V que l'on tente de faire transiter par des modes de travail abordant mieux l'incertitude (complexité), hors cela ne reste pas le seul monde d'Agilité possible à mon sens. Dans vos propositions j'irais plus loin, même si l'exemple de la solution a la demande y ressemble, en parlant des activités de supports (les opérateurs présents sur les chaînes de valeurs des utilisateurs). C'est un monde de gestion d'incidents, de réalisations d'actions simples et/ou compliquées (donc non reliées à de la réelle incertitude) via des outils de Ticketing. Si on prend du recul, cet environnements de techniciens ou d'experts peut (doit ?) tout de même avoir besoin d'améliorer son fonctionnement en rapport à la satisfaction de l'écosystème. L'amélioration et l'adaptation ne sera donc pas basée sur du produit, mais dans le relationnel avec les "clients", ce qui générera une amélioration de la qualité des réalisations. Cela ne change pas le paradigme de la priorisation faite par l'extérieur. Bref, ce 3ème monde se base plus sur du Lean selon les points de vues et pour autant cela reste une recherche d'Agilité.
@ScrumLife
9 ай бұрын
Merci pour ton commentaire et tes retours d'expérience ! Que penses-tu de la définition du Scrum Guide 2020 de ce qu'est un produit ? (dans la section sur le Product Goal) : "A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract." Ou dans la traduction française : "Un produit est un vecteur de valeur. Il a une limite claire, des parties prenantes connues, des utilisateurs ou des clients bien définis. Un produit peut être un service, un produit physique ou quelque chose plus abstrait." -- JP
@fredericpetit1555
9 ай бұрын
@@ScrumLife malheureusement jj'ai toujours trouvé cette définition bien trop large pour aider à s'y retrouver. En tout cas, pour des "experts" cela reste sujet à débat, alors pour des "moins experts" ... quel bazar. Et je pense que ce bazar n'aide pas les équipes (sens large : opérationnels comme stratégiques) à se sentir à l'aise et à comprendre pourquoi Scrum est adapté pour elles ? Ou pourquoi en l'etat, alors que tout le monde autour dit qu'ils font de l'Agilité, pour elles ca ne marchent pas ? (on met de côté tous les éléments qui feraient qu'en fait on est sur du Dark Scrum pour parler avant tout du type d'activité qui ne correspondraient pas à du complexe) ; etc. Après, le loup du sujet c'est qu'a mon sens énormément de situation, quelque soit le type d'activités, seront de l'ordre du complexe notamment du a la complexité des entreprises, la complexité humaine, etc. J'aimerais dire que tout est Agilisable et tendant vers du produit, mais généralement c'est souvent pris comme "c'est bon, nous on fait du produit" alors que dans les faits ... pas du tout. Bref, je préfère donc permettre aux equipes de se catégoriser même si cela ne doit pas être pris comme une finalité en disant qu'il y a des moyens d'optimiser certains mode de travail adaptés au fait de faire de la solution a la demande pour des projets ; de fluidifier les demandes de réalisations de support ; et de réaliser du produit visant à améliorer et rendre plus performant et autonome l'écosystème. Après ce discours d'entrée, on peut avancer plus ou moins à découvert selon la résistance du contexte et les attentes, soutiens du sponsor.
@excellencemania9 ай бұрын
Ceux qui font ont toujours raison 😊
@yarazakaria79949 ай бұрын
Je n'ai pas encore fait une mission avec une approche Produit. Alors pour moi, c'est beaucoup plus intéressant de voir souvent cette comparaison avec des exemples entre ce qu'on aurait dû faire dans une démarche plus agile avec une approche produit, et ce qu'on pourrait quand même faire afin de tendre au max possible vers cette agilité dans le contexte solution à la demande. Sinon c'est peu confus pour les moins expérimentés je pense, car nous voyons des notions qui ne sont pas vraiment applicables dans notre contexte.
@ScrumLife
9 ай бұрын
C'est vrai ! Donc pour toi il faudrait qu'on rappelle à chaque fois de quoi on parle ? Ou même faire l'effort à chaque fois qu'on donne un conseil ou qu'on fait une analyse d'envisager les 2 grands types de contexte ? -- JP
@yarazakaria7994
9 ай бұрын
@@ScrumLife oui plutôt faire l'effort d'envisager les 2 types de contexte à chaque fois. Actuellement, je regarde en moyenne une vidéo par semaine, c'est toujours intéressant, mais si vous faites cet effort je ne louperais plus aucune vidéo 😄
@productvincent9 ай бұрын
Salut à l'équipe! Le titre m'a bien fait rire, je me suis dis ca y est c'est parti pour un bon gros taunt qui va me faire saliver sur chaque seconde de votre vidéo et ça n'a pas manqué ;-) Réactions: 1. Forcément, pour moi dont le métier c'est de transformer les organisations pour les faire travailler en mode produit, je vais être assez exigeant sur la définition: - Non, en mode produit, le décisionnaire qui fait le choix du problème à résoudre n'est pas dans l'équipe. On confie des problèmes à résoudre à l'équipe (au lieu de lui donner une solution à implanter) mais l'équipe n'est pas décisionnaire. - Corollaire de ci-dessous, pour réprendre les points de Robin, donc non l'équipe ne décide pas de l'ordre dans lequel elle attaque les problème. (Elle décide en revanche dans quel ordre elle livre les solutions au problème confié). - L'idée de l'équipe comme mini-entreprise, et la fameuse idée que le product manager est le CEO de son produit est un sale mythe que l'essaye de casser en tant que coach produit des années. - Une équipe produit, bien que pluri-disciplinaire, n'est jamais 100% "auto-contenue", donc en mode produit aussi, on dépend d'autres équipes, départements, expertises avec tous les défis qui viennent avec! 2. Si un jour vous voulez faire une plongée dans le mode produit, honnêtement pingez moi ça me fera plaisir d'amener une perspective produit et j'apprécie toujours les échanges avec les agilistes car le vérité c'est que la clef de l'adoption du mode produit n'est pas chez les product managers malgré ce qu'on aimerait croire, mais du côté des devs alors je vous invite à pas lâcher le sujet :) 3. Après la suite est plutôt bonne en fait et pour avoir le même problème dans mon domaine, pour ceux qui liront mon commentaire, il faut donner du cr;edit à l'équipe de Scrum Life car c'est vrai qu'on est toujours sur une ligne de crête : Comment véhiculer les concept d'une agilité "complète" (ou mode produit complet dans mon monde) tout en restant connecté et crédible et utile quand la majorité du monde est en mode agilité partielle (mode produit partiel pour moi). Il faut parfois faire le funambule et le reconnaitre et l'expliquer est une excellente chose donc GG là dessus. 4. Dernier commentaire qui me vient à l'esprit, je trouve parler de "mode client-fournisseur" au lieu de mode "solution à la demande" est plus clair et bien compris sur le terrain. Au plaisir de s'en reparler :)
9 ай бұрын
Jeudi sur le podium ?
@productvincent
9 ай бұрын
@ Alors désolé pour mon ignorance là dessus, mais kessé le podum ? :)
9 ай бұрын
@@productvincent le jeudi Scrum life organises un live et les membres de la communauté peuvent intégrer le live et discuter directement du sujet avec l'équipe
@ScrumLife
9 ай бұрын
Salut Vincent, super de te voir ici ! Merci beaucoup pour tous ces éléments constructifs ainsi que pour les compliments 🙏 Concernant le choix du problème à résoudre, je suspecte que nous sommes d'accord mais qu'on n'utilise pas le même vocabulaire. Plus précisément, il me semble ici question de granularité. Concrètement, dans la majorité des équipes produits, l'équipe a une mission, un problème général à résoudre que l'on lui donne et que l'on a donc choisi pour elle -- mais ensuite, l'équipe a pour travail de découper ce gros problème en petits problèmes, et est responsable de creuser ces problèmes et de décider lesquels résoudre et dans quel ordre. "La métaphore de la start-up" reste puissante et passe assez bien le sens de l'équipe produit, mais est également trompeuse car simpliste. On devrait sûrement faire plus attention quand on l'utilise. Concernant l'autonomie des équipes, oui ! On aime bien dire "autonomie ne veut pas dire autarcie". Malgré tout se pose la question de la structuration de l'organisation pour créer des organisations composées de plusieurs équipes sans que cela ne crée trop de dépendances fortes entre ces dernières. De ce point de vue, un outil comme Team Topologies est très utile, notamment avec son mode d'interaction "XaaS" qui formalise bien comment on doit avoir une interface claire entre deux équipes qui permet aux deux équipes d'avancer en autonomie malgré leur dépendance. Pour la suggestion de parler de "mode client-fournisseur" plutôt que de "solution à la demande", je suis partagé. D'un côté effectivement tu as raison, c'est un nom plus clair pour tout le monde. De l'autre, je ne crois pas que cela porte réellement le sens que l'on veut. En effet on peut imaginer un mode client-fournisseur où le client donne bien des problèmes à résoudre et non pas des solutions, laissant à l'équipe une grande marge de manœuvre pour analyser le problème et trouver la bonne solution. Je connais d'ailleurs des agences qui se placent spécifiquement sur ce créneau pour permettre une véritable agilité dans leur mode de fonctionnement malgré le cadre client-fournisseur. Bon, je ne sais pas si mes explications et réflexions tiennent la route... À mûrir. Qu'en penses-tu, toi ? Encore merci pour l'échange ! -- JP P.S. Il faut vraiment qu'on parle plus du Live hebdomadaire le jeudi à 13h CET !!!
@productvincent
9 ай бұрын
@ Ah les Live Hebdo! OK je viens de faire le lien, j'avais pas fait le lien avec "le podium". :-)
@thierrysandre4409 ай бұрын
Il n'y a qu'une agilité #ToBeAgile mais plusieurs méthodes de mise en pratique qui dépend de l'approche produit #ToDoAgile comme scrum
@ScrumLife
9 ай бұрын
Certes, maintenant même Scrum il y a plusieurs manières de le mettre en oeuvre ! Notamment comme dit dans la vidéo selon si l'on est dans une approche produit ou dans un contexte de solution à la demande. Penses-tu que cette distinction que nous faisons est pertinente ? -- JP
@thierrysandre440
6 ай бұрын
Je ne sais pas. À creuser. Ce que je peux dire pour l'instant, c'est qu'il y a la théorie et la pratique (Concept et pratique, guide agile et framework). Le guide agile est unique, c'est le fondement, mais qui doit être en amélioration constante suivant les constats de la pratique. Et puis il y a les frameworks (mise en pratique) qui dépendent des secteurs d'activités. C'est pour cela que je ne suis pas d'accord que l'on parle de scrum dans le bâtiment ou du lean en dehors du secteur l'industrie japonaise. La mise en pratique de l'agilité dépend du savoir être humain et donc peut-être différent selon les communautés.
@paul-emmanuelbuttin10069 ай бұрын
Si je comprends bien : logique produit = équipe autodéterminée et autofinancée, et logique à la demande = tous les autres cas (notamment tous les cas où les équipes développent une solution pour un tiers) ? La logique produit représente quelle proportion des équipes de développement selon vous ?
@ScrumLife
9 ай бұрын
Salut Paul-Emmanuel, non tu n'a pas bien compris, enfin j'imagine que du coup c'est notre faute c'est nous qui nous sommes mal exprimés ! Je crois que "la métaphore de la start-up", bien que puissante et passant assez bien le sens de l'équipe produit, est également trompeuse. Dans une approche produit, c'est l'équipe qui prend les décisions produits. Dans un contexte de solution à la demande, on prend ces décisions à la place de l'équipe et on les lui impose. Ce qui est "moins bien" (avec des guillemets car tout reste contextuel, mais dans l'ensemble c'est plutôt vrai) car pour prendre de meilleures décisions et plus rapidement il faut rapprocher la prise de décision de l'information sur laquelle cette décision se base -- sans même parler des enjeux humains de motivation qui à eux seuls génèrent une énorme différence dans la performance de l'équipe. Pour te répondre sur la proportion d'équipes qui sont dans l'un ou l'autre cas : - Je vais te répondre sur la base de la définition que je viens de donner - Je vais parler en nombre d'entreprises plutôt qu'en nombre d'équipes car il y a malheureusement souvent un gros biais qui est que les grosses boîtes avec une ancienne culture aiment bien le mode solution à la demande (pour de mauvaises raisons -- dans le sens où les demandeurs sont dans la même boîte que les fournisseurs donc on pourrait tout à fait s'organiser autrement), et bien sûr les grosses boîtes ont statistiquement plus d'équipes que les petites (vu qu'elles sont grosses) - Je vais également me focaliser sur les contexte d'équipes agiles travaillant dans le domaine de l'informatique, car c'est ce que je connais le mieux et même si l'agilité peut être appliqué à tous les domaines sans exception Une fois ces éléments posés, je dirais que l'approche produit est tout de même relativement courante. Au moins un bon tiers des entreprises. Dans tous les cas on en a croisé un certain nombre, en incluant notamment celles que nous avons accompagné. À noter qu'un contexte "à l'échelle" par exemple avec SAFe peut être aussi bien dans une approche produit qu'en mode solution à la demande selon comment l'implantation du framework a été faite, en particulier sur l'articulation de la dynamique entre PM et PO. (Cas du PM facilitateur et coach produit qui trace une stratégie globale et accompagne les PO et par extension les équipes dans une démarche produit VS le cas du PM qui décide tout et redescend l'info de ce qu'il faut faire aux PO qui sont juste des rédacteurs Jira et des recetteurs) On peut aussi parler des DSI qui ont muté, et qui même si elles ont gardé un lien hiérarchique (les différents experts techniques restent rattachés à la DSI), vivent au quotidien comme une seule grande équipe qui réunit ces experts techniques rattachés à la DSI et des "métiers" (qui ne sont pas rattachés à la DSI) qui travaillent ensemble pour donner la direction au produit dont chaque équipe est en charge. Enfin et bien sûr, c'est le modèle favorisé, et de loin, dans les start-up / scale-up. Ce qui n'empêche pas de nombreux grands groupes de construire des organisations similaires, avec leurs spécificités et leurs contraintes, mais qui font tout de même en sorte de mettre les équipes en contact direct avec leurs utilisateurs et de les laisser prendre les décisions produit en conséquence. En résumé : c'est possible ! Il y a de l'espoir ! Par contre reste ce biais : en tant que consultant si on t'appelle c'est qu'il y a des problèmes... Donc mécaniquement les entreprises que l'on va voir vont souvent avoir encore un long chemin à parcourir... -- JP
@paul-emmanuelbuttin1006
9 ай бұрын
@@ScrumLife Merci pour ta réponse. Quelles sont les "décisions produit" et les décisions qui ne font pas partie des "décisions produit" ? Et où places-tu les limites de l'équipe (PO, PM, CP, SMEs, Key Users, etc.) ?
@ScrumLife
9 ай бұрын
Salut Paul-Emmanuel, Je (Constantin) me permets de rebondir sur ta réponse, déjà pour te dire que je suis content que tu continues de suivre la chaîne. 1) Pour moi, les décisions produits pourraient se traduire en disant : C'est l'équipe qui décide qui fait quoi, quand et comment. Donc, tout ce qui touche à la stratégie, à l'organisation et à la technique, de la conception à la maintenance en passant par tout ce qui est entre les deux, doit dépendre de l'équipe. Alors bien sûr, de façon intelligente. C'est à dire pas en autarcie, pas sans communication et pas sans "guide" (vision produit, objectifs business). En fait, dans une équipe produit, on fait confiance dans les gens pour accomplir une mission en utilisant... leur cerveau et leurs compétences. 2) Que veux-tu dire par "limites de l'équipe" ? Qui fait partie de l'équipe ? Ou bien son périmètre d'action ? Qu'en dis-tu ? -- Constantin
@paul-emmanuelbuttin1006
9 ай бұрын
@@ScrumLife qui fait partie de l'équipe. Forcément plus tu élargis la définition de l'équipe plus il y a de décisions qui échoient à l'équipe.
@ScrumLife
9 ай бұрын
Ah mais on ne t'a pas répondu Paul-Emmanuel ! En général on va partir sur la définition d'équipe Scrum, qui a une définition (qui vaut ce qu'elle vaut) : celle du Scrum Guide. Dans l'équipe on a donc un ensemble de "developers", un ensemble de développeurs produits, un ensemble d'experts, avec toutes les expertises nécessaires pour concevoir, développer, tester, déployer et maintenir le produit. Ainsi que bien sûr les Product Owner et Scrum Master avec des responsabilités spécifiques. À l'extérieur de l'équipe nous avons donc les parties prenantes, terme un peu chapeau qui inclut toutes les personnes qui ont quelque chose à gagner vis-à-vis du produit de l'équipe, que ça soit d'un point de vue résolution de problème (les utilisateurs) ou d'un point vue business model (les sponsors). Si je reprends ta liste : - PO est dans l'équipe. PM aussi en la personne du PO qui est un Product Manager. Si on a le besoin d'un Product Manager externe alors il est au service de l'équipe (dans le cas où le PM est le responsable du PO il doit être dans une posture de servant leadership, coachant le PO et en lui donnant des éléments pour qu'il réussisse sa mission de PO, pas en lui disant quoi et comment faire) - CP = chef de projet ? Oui c'est dans l'équipe, généralement sous la forme d'un ensemble de compétences plus que celle d'un rôle à part entière. (en particulier les événements de Scrum permettent de s'assurer que la gestion de projet est bien suivie via des responsabilités collectives de l'équipe) Dans le cas moins courant où le contexte de l'équipe implique une forte gestion de projet (par exemple parce que l'équipe doit gérer un ensemble de prestataires externes et se retrouve à les coordonner pour mener à bien sa propre mission), on pourrait alors imaginer avec d'autres activités de gestion de projet clairement identifiées. On va les identifier comme des tâches d'équipe que l'équipe gèrera en équipe -- comme toutes ses tâches d'équipe. Ce qui ne veut pas dire qu'on ne peut pas avoir dans les "developers" Scrum des personnes qui ont une profil / une expertise spécifiquement de chef de projet. Toutes les personnes contribuant aux incréments produits sont bienvenues dans la Scrum Team ! - SME = Subject Matter Expert ? Si c'est lié au quotidien de l'équipe, c'est donc un des experts qui contribue aux incréments produits et cela devrait être un des "developers" de la Scrum Team. Si c'est plus exceptionnel, cela peut être une personne externe à l'équipe mais qui là aussi sera au service de l'équipe. On peut aussi imaginer un mode de fonctionnement où la personne rejoint temporairement l'équipe le temps du sujet. - Les Key Users sont en dehors de l'équipe, ce sont clairement des parties prenantes. Dans une approche produit, on prend en compte leurs commentaires, feedbacks et demandes qui vont servir d'input à la démarche de Product Management de l'équipe, sans devenir directement des éléments sur lesquels travaillera l'équipe, qui eux découlent de la vision produit et des objectifs produits que se donne l'équipe en accord avec ses sponsors. Qu'en penses-tu ? -- JP
@agilitybox96819 ай бұрын
canon !
@ScrumLife
9 ай бұрын
Ah, merci ! Tu saurais articuler ce que tu apprécies tout particulièrement ? -- JP
9 ай бұрын
8:00 Invest as dor
@ScrumLife
9 ай бұрын
Cette phrase, ce conseil d'utiliser la DoR comme invitation à la collaboration, reste extrêmement puissante. Peut-être fera-t-on un de ces jours une "vidéo réaction" du mythique Scrum Life #5 (tourné dans ma Twingo !) dont vient cette phrase ! -- JP
@garancera9 ай бұрын
Bizarre, Quand j'entends "pragmatisme" j'entends "faut bien manger" alors qu'en vérité, comme vous le dites ça dépend du contexte... Pour moi l'agilité repose sur deux piliers phares : replacer l'humain au coeur du schéma productif et se donner les moyens pour aborder ce qui relève des sujets complexes. Je mets au défi quiconque de me présenter une entreprise "agile", je ne connais en fait qu'une chose dans ce sens : un cheminement sur la voie du Kaizen comme un mythe de sisyphe... L'agilité se trouve là, pas dans le contexte ou les gens, mais dans cette envie de faire de l'humain là où on faisait hier du projet, rapprocher les narratifs et construire du commun dans une envie de vouloir faire tous les jours un peu mieux qu'hier...
@ScrumLife
9 ай бұрын
😁 -- JP
@patrickvandevoorden83279 ай бұрын
La DOR est indispensable
@patrickvandevoorden8327
9 ай бұрын
Tout comme le DOD
@ScrumLife
9 ай бұрын
Merci pour ton commentaire, est-ce que cela veut dire que tu n'es pas d'accord avec notre analyse ? Qui essaie de nuancer le jugement de la pertinence de la DoR en fonction du contexte de l'équipe. -- JP
@patrickvandevoorden8327
9 ай бұрын
@@ScrumLife La DOR est indispensable pour avoir une description claire de ce qu'on doit faire
@ScrumLife
9 ай бұрын
Merci Patrick, tu mets quoi dans la DOR qui te semble indispensable ? - Constantin
@patrickvandevoorden8327
9 ай бұрын
@@ScrumLife Les spécifications, l'objectif , qui fait quoi et quand. Après on en parle avec le product owner et le business. J'utilise la méthode 3 amigos
@hichamn53299 ай бұрын
Je te pardonne JP. Mais faudra pas recommencer 😊
@ScrumLife
9 ай бұрын
Ah ah ! Autrement, que retires-tu de cette vidéo ? À plus 👋 -- JP
Пікірлер: 51
Tu en dis quoi, toi ? Est-ce qu'on devrait plus expliciter quand on donne des conseils pour un mode "approche produit" ou "solution à la demande" ? Ou c'est très bien comme on a fait jusqu'ici ? Dis-nous en commentaire 👇👇👇👇👇🙏
Le problème que je vois en entreprise c'est que lorsqu'on est sur du logiciel à la demande et qu'on veut faire de l'agilité, assez souvent on garde les process, les personnes et leur fonction mais on leur met un label agile (PO, proxi po, SM) "Il faut être pragmatique" est souvent utilisé comme excuse pour ne pas faire ce qu'il serait bon de faire. Pour moi être pragmatique serait justement de dire que si on veut faire scrum, on le fait, à la lettre au moins au début. Si on pense qu'on n'en est pas capable être pragmatique c'est le dire et ne pas le faire mais peut être simplement améliorer les processus et méthode de travail existantes sans couloir tout labeliser scrum ou agile.
Je comprends le questionnement et en même temps j'en arrive à penser qu'il relève d'une confusion récurrente. C'est devenu plus clair quand j'ai accompagné une équipe qui fait de l'assistance technique et qu'ils m'opposaient "ah oui mais nous on ne fait pas produit !". Ce à quoi je leur répondais : "Quand bien même, vous rendez bien un "service" à quelqu'un. De mon point de vue, leur produit, c'est le service rendu. Ce qui revient à se demander "Pour qui ?", "Pour quoi (quel bénéfice pour le client) ?". En posant la question comme ça, je trouve qu'on remet la valeur ajouté de l'équipe au bon niveau et notamment on remet en avant le client. On remet donc en avant le POUR QUOI avant le COMMENT (est ce que je suis AGILE...)
@ScrumLife
9 ай бұрын
Là dessus, il y a une définition très utile de ce qu'est un produit dans le Scrum Guide 2020 (dans la section sur le Product Goal) : "A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract." Ou dans la traduction française : "Un produit est un vecteur de valeur. Il a une limite claire, des parties prenantes connues, des utilisateurs ou des clients bien définis. Un produit peut être un service, un produit physique ou quelque chose plus abstrait." On a ainsi très souvent un produit selon cette définition. En tous cas merci pour ton partage ! Ta réflexion amène à réexpliquer pourquoi nous avons choisi la nomenclature "solution à la demande" et non pas "relation client / fournisseur" : car dans une relation client / fournisseur on peut soumettre des problèmes à résoudre et adopter une démarche produit. Mais dans une relation client / fournisseur qui impose les solutions à implanter, c'est une autre histoire... Qu'en penses-tu ? Bon, réflexion à continuer ! -- JP
Il faut rester comme maintenant. D'une part, c'est plus important d'être challengé par de l'agilité "by the book" pour challenger ses pratiques et d'autre part, vu qu'il y a à peu près autant de forme d'agilité que d'équipe agile on risque de rentrer dans des vidéos où on pourrait passer plus de temps à parler du contexte que du sujet.
@ScrumLife
9 ай бұрын
Merci Benjamin et coucou au passage :-) - Constantin
Il est intéressant, pour le Junior que je suis, de noter qu'il n'y a pas une seule approche "taille unique" en matière d'agilité. Parfois, une approche produit est appropriée, où l'on se concentre sur le développement et l'amélioration continue d'un produit. D'autres fois, nous pouvons être amenés à créer des solutions à la demande, en réponse à des besoins ou des demandes spécifiques. C'est un rappel utile que l'agilité est avant tout une mentalité et une culture, et que les méthodologies et les pratiques doivent être adaptées en fonction du contexte spécifique. Concernant la question, la distinction entre ces deux approches est cruciale et peut aider les équipes à comprendre et à appliquer les principes agiles de manière plus efficace dans leur contexte spécifique. La pertinence de cette explicitation dépend en grande partie de votre audience, les personnes moins familières avec l'Agilité, ou pour celles qui travaillent dans des environnements dans lesquels les deux approches sont utilisées, cette clarification pourrait être très bénéfique. Je pense que la clarté et la transparence sont toujours bénéfiques lorsqu'il s'agit de communiquer des idées complexes, et l'Agilité n'y fait pas exception !
@ScrumLife
9 ай бұрын
Merci pour ton commentaire ! Mais est-ce que ça ne risque pas d'être "lourd" et donc compliqué à comprendre si on précise systématiquement ce genre d'élément ? -- JP
Merci Scrum Life de mettre en avant la transparence et le pragmatisme nécessaires pour mener à bon port l'équipage et son produit (bateau). Collaborer par une approche empirique, incrémentale, itérative devient une manière idéale pour s'adapter aux situations rencontrées. Trouver de nouveaux moyens voire, d'autres chemins à parcourir, néanmoins tout en gardant le cap. Désolé pour cette analogie et ce manque de valeur ajoutée, mais en tant que non (encore) Scrum Master, cette vidéo très bien ficelée et parfaitement mise en scène (bravo aux acteurs), aborde les valeurs qui me donnent envie de rejoindre votre profession.
@ScrumLife
9 ай бұрын
Merci à toi ! Très content de te donner envie ou plutôt de confirmer ton envie d'accompagner des équipes 😊 As-tu vu qu'on fait un Live tous les jeudi de 13h à 14h ? Tu es bien sûr le bienvenu ! -- JP
C'est très bien d'avoir fait cette vidéo. C'est un débat récurrent : "je fais pas du produit mais pourtant est-ce qu'on fait de l'agilité ?" L'exemple du projet est en réalité le cas d'un travail cycle en V que l'on tente de faire transiter par des modes de travail abordant mieux l'incertitude (complexité), hors cela ne reste pas le seul monde d'Agilité possible à mon sens. Dans vos propositions j'irais plus loin, même si l'exemple de la solution a la demande y ressemble, en parlant des activités de supports (les opérateurs présents sur les chaînes de valeurs des utilisateurs). C'est un monde de gestion d'incidents, de réalisations d'actions simples et/ou compliquées (donc non reliées à de la réelle incertitude) via des outils de Ticketing. Si on prend du recul, cet environnements de techniciens ou d'experts peut (doit ?) tout de même avoir besoin d'améliorer son fonctionnement en rapport à la satisfaction de l'écosystème. L'amélioration et l'adaptation ne sera donc pas basée sur du produit, mais dans le relationnel avec les "clients", ce qui générera une amélioration de la qualité des réalisations. Cela ne change pas le paradigme de la priorisation faite par l'extérieur. Bref, ce 3ème monde se base plus sur du Lean selon les points de vues et pour autant cela reste une recherche d'Agilité.
@ScrumLife
9 ай бұрын
Merci pour ton commentaire et tes retours d'expérience ! Que penses-tu de la définition du Scrum Guide 2020 de ce qu'est un produit ? (dans la section sur le Product Goal) : "A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract." Ou dans la traduction française : "Un produit est un vecteur de valeur. Il a une limite claire, des parties prenantes connues, des utilisateurs ou des clients bien définis. Un produit peut être un service, un produit physique ou quelque chose plus abstrait." -- JP
@fredericpetit1555
9 ай бұрын
@@ScrumLife malheureusement jj'ai toujours trouvé cette définition bien trop large pour aider à s'y retrouver. En tout cas, pour des "experts" cela reste sujet à débat, alors pour des "moins experts" ... quel bazar. Et je pense que ce bazar n'aide pas les équipes (sens large : opérationnels comme stratégiques) à se sentir à l'aise et à comprendre pourquoi Scrum est adapté pour elles ? Ou pourquoi en l'etat, alors que tout le monde autour dit qu'ils font de l'Agilité, pour elles ca ne marchent pas ? (on met de côté tous les éléments qui feraient qu'en fait on est sur du Dark Scrum pour parler avant tout du type d'activité qui ne correspondraient pas à du complexe) ; etc. Après, le loup du sujet c'est qu'a mon sens énormément de situation, quelque soit le type d'activités, seront de l'ordre du complexe notamment du a la complexité des entreprises, la complexité humaine, etc. J'aimerais dire que tout est Agilisable et tendant vers du produit, mais généralement c'est souvent pris comme "c'est bon, nous on fait du produit" alors que dans les faits ... pas du tout. Bref, je préfère donc permettre aux equipes de se catégoriser même si cela ne doit pas être pris comme une finalité en disant qu'il y a des moyens d'optimiser certains mode de travail adaptés au fait de faire de la solution a la demande pour des projets ; de fluidifier les demandes de réalisations de support ; et de réaliser du produit visant à améliorer et rendre plus performant et autonome l'écosystème. Après ce discours d'entrée, on peut avancer plus ou moins à découvert selon la résistance du contexte et les attentes, soutiens du sponsor.
Ceux qui font ont toujours raison 😊
Je n'ai pas encore fait une mission avec une approche Produit. Alors pour moi, c'est beaucoup plus intéressant de voir souvent cette comparaison avec des exemples entre ce qu'on aurait dû faire dans une démarche plus agile avec une approche produit, et ce qu'on pourrait quand même faire afin de tendre au max possible vers cette agilité dans le contexte solution à la demande. Sinon c'est peu confus pour les moins expérimentés je pense, car nous voyons des notions qui ne sont pas vraiment applicables dans notre contexte.
@ScrumLife
9 ай бұрын
C'est vrai ! Donc pour toi il faudrait qu'on rappelle à chaque fois de quoi on parle ? Ou même faire l'effort à chaque fois qu'on donne un conseil ou qu'on fait une analyse d'envisager les 2 grands types de contexte ? -- JP
@yarazakaria7994
9 ай бұрын
@@ScrumLife oui plutôt faire l'effort d'envisager les 2 types de contexte à chaque fois. Actuellement, je regarde en moyenne une vidéo par semaine, c'est toujours intéressant, mais si vous faites cet effort je ne louperais plus aucune vidéo 😄
Salut à l'équipe! Le titre m'a bien fait rire, je me suis dis ca y est c'est parti pour un bon gros taunt qui va me faire saliver sur chaque seconde de votre vidéo et ça n'a pas manqué ;-) Réactions: 1. Forcément, pour moi dont le métier c'est de transformer les organisations pour les faire travailler en mode produit, je vais être assez exigeant sur la définition: - Non, en mode produit, le décisionnaire qui fait le choix du problème à résoudre n'est pas dans l'équipe. On confie des problèmes à résoudre à l'équipe (au lieu de lui donner une solution à implanter) mais l'équipe n'est pas décisionnaire. - Corollaire de ci-dessous, pour réprendre les points de Robin, donc non l'équipe ne décide pas de l'ordre dans lequel elle attaque les problème. (Elle décide en revanche dans quel ordre elle livre les solutions au problème confié). - L'idée de l'équipe comme mini-entreprise, et la fameuse idée que le product manager est le CEO de son produit est un sale mythe que l'essaye de casser en tant que coach produit des années. - Une équipe produit, bien que pluri-disciplinaire, n'est jamais 100% "auto-contenue", donc en mode produit aussi, on dépend d'autres équipes, départements, expertises avec tous les défis qui viennent avec! 2. Si un jour vous voulez faire une plongée dans le mode produit, honnêtement pingez moi ça me fera plaisir d'amener une perspective produit et j'apprécie toujours les échanges avec les agilistes car le vérité c'est que la clef de l'adoption du mode produit n'est pas chez les product managers malgré ce qu'on aimerait croire, mais du côté des devs alors je vous invite à pas lâcher le sujet :) 3. Après la suite est plutôt bonne en fait et pour avoir le même problème dans mon domaine, pour ceux qui liront mon commentaire, il faut donner du cr;edit à l'équipe de Scrum Life car c'est vrai qu'on est toujours sur une ligne de crête : Comment véhiculer les concept d'une agilité "complète" (ou mode produit complet dans mon monde) tout en restant connecté et crédible et utile quand la majorité du monde est en mode agilité partielle (mode produit partiel pour moi). Il faut parfois faire le funambule et le reconnaitre et l'expliquer est une excellente chose donc GG là dessus. 4. Dernier commentaire qui me vient à l'esprit, je trouve parler de "mode client-fournisseur" au lieu de mode "solution à la demande" est plus clair et bien compris sur le terrain. Au plaisir de s'en reparler :)
9 ай бұрын
Jeudi sur le podium ?
@productvincent
9 ай бұрын
@ Alors désolé pour mon ignorance là dessus, mais kessé le podum ? :)
9 ай бұрын
@@productvincent le jeudi Scrum life organises un live et les membres de la communauté peuvent intégrer le live et discuter directement du sujet avec l'équipe
@ScrumLife
9 ай бұрын
Salut Vincent, super de te voir ici ! Merci beaucoup pour tous ces éléments constructifs ainsi que pour les compliments 🙏 Concernant le choix du problème à résoudre, je suspecte que nous sommes d'accord mais qu'on n'utilise pas le même vocabulaire. Plus précisément, il me semble ici question de granularité. Concrètement, dans la majorité des équipes produits, l'équipe a une mission, un problème général à résoudre que l'on lui donne et que l'on a donc choisi pour elle -- mais ensuite, l'équipe a pour travail de découper ce gros problème en petits problèmes, et est responsable de creuser ces problèmes et de décider lesquels résoudre et dans quel ordre. "La métaphore de la start-up" reste puissante et passe assez bien le sens de l'équipe produit, mais est également trompeuse car simpliste. On devrait sûrement faire plus attention quand on l'utilise. Concernant l'autonomie des équipes, oui ! On aime bien dire "autonomie ne veut pas dire autarcie". Malgré tout se pose la question de la structuration de l'organisation pour créer des organisations composées de plusieurs équipes sans que cela ne crée trop de dépendances fortes entre ces dernières. De ce point de vue, un outil comme Team Topologies est très utile, notamment avec son mode d'interaction "XaaS" qui formalise bien comment on doit avoir une interface claire entre deux équipes qui permet aux deux équipes d'avancer en autonomie malgré leur dépendance. Pour la suggestion de parler de "mode client-fournisseur" plutôt que de "solution à la demande", je suis partagé. D'un côté effectivement tu as raison, c'est un nom plus clair pour tout le monde. De l'autre, je ne crois pas que cela porte réellement le sens que l'on veut. En effet on peut imaginer un mode client-fournisseur où le client donne bien des problèmes à résoudre et non pas des solutions, laissant à l'équipe une grande marge de manœuvre pour analyser le problème et trouver la bonne solution. Je connais d'ailleurs des agences qui se placent spécifiquement sur ce créneau pour permettre une véritable agilité dans leur mode de fonctionnement malgré le cadre client-fournisseur. Bon, je ne sais pas si mes explications et réflexions tiennent la route... À mûrir. Qu'en penses-tu, toi ? Encore merci pour l'échange ! -- JP P.S. Il faut vraiment qu'on parle plus du Live hebdomadaire le jeudi à 13h CET !!!
@productvincent
9 ай бұрын
@ Ah les Live Hebdo! OK je viens de faire le lien, j'avais pas fait le lien avec "le podium". :-)
Il n'y a qu'une agilité #ToBeAgile mais plusieurs méthodes de mise en pratique qui dépend de l'approche produit #ToDoAgile comme scrum
@ScrumLife
9 ай бұрын
Certes, maintenant même Scrum il y a plusieurs manières de le mettre en oeuvre ! Notamment comme dit dans la vidéo selon si l'on est dans une approche produit ou dans un contexte de solution à la demande. Penses-tu que cette distinction que nous faisons est pertinente ? -- JP
@thierrysandre440
6 ай бұрын
Je ne sais pas. À creuser. Ce que je peux dire pour l'instant, c'est qu'il y a la théorie et la pratique (Concept et pratique, guide agile et framework). Le guide agile est unique, c'est le fondement, mais qui doit être en amélioration constante suivant les constats de la pratique. Et puis il y a les frameworks (mise en pratique) qui dépendent des secteurs d'activités. C'est pour cela que je ne suis pas d'accord que l'on parle de scrum dans le bâtiment ou du lean en dehors du secteur l'industrie japonaise. La mise en pratique de l'agilité dépend du savoir être humain et donc peut-être différent selon les communautés.
Si je comprends bien : logique produit = équipe autodéterminée et autofinancée, et logique à la demande = tous les autres cas (notamment tous les cas où les équipes développent une solution pour un tiers) ? La logique produit représente quelle proportion des équipes de développement selon vous ?
@ScrumLife
9 ай бұрын
Salut Paul-Emmanuel, non tu n'a pas bien compris, enfin j'imagine que du coup c'est notre faute c'est nous qui nous sommes mal exprimés ! Je crois que "la métaphore de la start-up", bien que puissante et passant assez bien le sens de l'équipe produit, est également trompeuse. Dans une approche produit, c'est l'équipe qui prend les décisions produits. Dans un contexte de solution à la demande, on prend ces décisions à la place de l'équipe et on les lui impose. Ce qui est "moins bien" (avec des guillemets car tout reste contextuel, mais dans l'ensemble c'est plutôt vrai) car pour prendre de meilleures décisions et plus rapidement il faut rapprocher la prise de décision de l'information sur laquelle cette décision se base -- sans même parler des enjeux humains de motivation qui à eux seuls génèrent une énorme différence dans la performance de l'équipe. Pour te répondre sur la proportion d'équipes qui sont dans l'un ou l'autre cas : - Je vais te répondre sur la base de la définition que je viens de donner - Je vais parler en nombre d'entreprises plutôt qu'en nombre d'équipes car il y a malheureusement souvent un gros biais qui est que les grosses boîtes avec une ancienne culture aiment bien le mode solution à la demande (pour de mauvaises raisons -- dans le sens où les demandeurs sont dans la même boîte que les fournisseurs donc on pourrait tout à fait s'organiser autrement), et bien sûr les grosses boîtes ont statistiquement plus d'équipes que les petites (vu qu'elles sont grosses) - Je vais également me focaliser sur les contexte d'équipes agiles travaillant dans le domaine de l'informatique, car c'est ce que je connais le mieux et même si l'agilité peut être appliqué à tous les domaines sans exception Une fois ces éléments posés, je dirais que l'approche produit est tout de même relativement courante. Au moins un bon tiers des entreprises. Dans tous les cas on en a croisé un certain nombre, en incluant notamment celles que nous avons accompagné. À noter qu'un contexte "à l'échelle" par exemple avec SAFe peut être aussi bien dans une approche produit qu'en mode solution à la demande selon comment l'implantation du framework a été faite, en particulier sur l'articulation de la dynamique entre PM et PO. (Cas du PM facilitateur et coach produit qui trace une stratégie globale et accompagne les PO et par extension les équipes dans une démarche produit VS le cas du PM qui décide tout et redescend l'info de ce qu'il faut faire aux PO qui sont juste des rédacteurs Jira et des recetteurs) On peut aussi parler des DSI qui ont muté, et qui même si elles ont gardé un lien hiérarchique (les différents experts techniques restent rattachés à la DSI), vivent au quotidien comme une seule grande équipe qui réunit ces experts techniques rattachés à la DSI et des "métiers" (qui ne sont pas rattachés à la DSI) qui travaillent ensemble pour donner la direction au produit dont chaque équipe est en charge. Enfin et bien sûr, c'est le modèle favorisé, et de loin, dans les start-up / scale-up. Ce qui n'empêche pas de nombreux grands groupes de construire des organisations similaires, avec leurs spécificités et leurs contraintes, mais qui font tout de même en sorte de mettre les équipes en contact direct avec leurs utilisateurs et de les laisser prendre les décisions produit en conséquence. En résumé : c'est possible ! Il y a de l'espoir ! Par contre reste ce biais : en tant que consultant si on t'appelle c'est qu'il y a des problèmes... Donc mécaniquement les entreprises que l'on va voir vont souvent avoir encore un long chemin à parcourir... -- JP
@paul-emmanuelbuttin1006
9 ай бұрын
@@ScrumLife Merci pour ta réponse. Quelles sont les "décisions produit" et les décisions qui ne font pas partie des "décisions produit" ? Et où places-tu les limites de l'équipe (PO, PM, CP, SMEs, Key Users, etc.) ?
@ScrumLife
9 ай бұрын
Salut Paul-Emmanuel, Je (Constantin) me permets de rebondir sur ta réponse, déjà pour te dire que je suis content que tu continues de suivre la chaîne. 1) Pour moi, les décisions produits pourraient se traduire en disant : C'est l'équipe qui décide qui fait quoi, quand et comment. Donc, tout ce qui touche à la stratégie, à l'organisation et à la technique, de la conception à la maintenance en passant par tout ce qui est entre les deux, doit dépendre de l'équipe. Alors bien sûr, de façon intelligente. C'est à dire pas en autarcie, pas sans communication et pas sans "guide" (vision produit, objectifs business). En fait, dans une équipe produit, on fait confiance dans les gens pour accomplir une mission en utilisant... leur cerveau et leurs compétences. 2) Que veux-tu dire par "limites de l'équipe" ? Qui fait partie de l'équipe ? Ou bien son périmètre d'action ? Qu'en dis-tu ? -- Constantin
@paul-emmanuelbuttin1006
9 ай бұрын
@@ScrumLife qui fait partie de l'équipe. Forcément plus tu élargis la définition de l'équipe plus il y a de décisions qui échoient à l'équipe.
@ScrumLife
9 ай бұрын
Ah mais on ne t'a pas répondu Paul-Emmanuel ! En général on va partir sur la définition d'équipe Scrum, qui a une définition (qui vaut ce qu'elle vaut) : celle du Scrum Guide. Dans l'équipe on a donc un ensemble de "developers", un ensemble de développeurs produits, un ensemble d'experts, avec toutes les expertises nécessaires pour concevoir, développer, tester, déployer et maintenir le produit. Ainsi que bien sûr les Product Owner et Scrum Master avec des responsabilités spécifiques. À l'extérieur de l'équipe nous avons donc les parties prenantes, terme un peu chapeau qui inclut toutes les personnes qui ont quelque chose à gagner vis-à-vis du produit de l'équipe, que ça soit d'un point de vue résolution de problème (les utilisateurs) ou d'un point vue business model (les sponsors). Si je reprends ta liste : - PO est dans l'équipe. PM aussi en la personne du PO qui est un Product Manager. Si on a le besoin d'un Product Manager externe alors il est au service de l'équipe (dans le cas où le PM est le responsable du PO il doit être dans une posture de servant leadership, coachant le PO et en lui donnant des éléments pour qu'il réussisse sa mission de PO, pas en lui disant quoi et comment faire) - CP = chef de projet ? Oui c'est dans l'équipe, généralement sous la forme d'un ensemble de compétences plus que celle d'un rôle à part entière. (en particulier les événements de Scrum permettent de s'assurer que la gestion de projet est bien suivie via des responsabilités collectives de l'équipe) Dans le cas moins courant où le contexte de l'équipe implique une forte gestion de projet (par exemple parce que l'équipe doit gérer un ensemble de prestataires externes et se retrouve à les coordonner pour mener à bien sa propre mission), on pourrait alors imaginer avec d'autres activités de gestion de projet clairement identifiées. On va les identifier comme des tâches d'équipe que l'équipe gèrera en équipe -- comme toutes ses tâches d'équipe. Ce qui ne veut pas dire qu'on ne peut pas avoir dans les "developers" Scrum des personnes qui ont une profil / une expertise spécifiquement de chef de projet. Toutes les personnes contribuant aux incréments produits sont bienvenues dans la Scrum Team ! - SME = Subject Matter Expert ? Si c'est lié au quotidien de l'équipe, c'est donc un des experts qui contribue aux incréments produits et cela devrait être un des "developers" de la Scrum Team. Si c'est plus exceptionnel, cela peut être une personne externe à l'équipe mais qui là aussi sera au service de l'équipe. On peut aussi imaginer un mode de fonctionnement où la personne rejoint temporairement l'équipe le temps du sujet. - Les Key Users sont en dehors de l'équipe, ce sont clairement des parties prenantes. Dans une approche produit, on prend en compte leurs commentaires, feedbacks et demandes qui vont servir d'input à la démarche de Product Management de l'équipe, sans devenir directement des éléments sur lesquels travaillera l'équipe, qui eux découlent de la vision produit et des objectifs produits que se donne l'équipe en accord avec ses sponsors. Qu'en penses-tu ? -- JP
canon !
@ScrumLife
9 ай бұрын
Ah, merci ! Tu saurais articuler ce que tu apprécies tout particulièrement ? -- JP
8:00 Invest as dor
@ScrumLife
9 ай бұрын
Cette phrase, ce conseil d'utiliser la DoR comme invitation à la collaboration, reste extrêmement puissante. Peut-être fera-t-on un de ces jours une "vidéo réaction" du mythique Scrum Life #5 (tourné dans ma Twingo !) dont vient cette phrase ! -- JP
Bizarre, Quand j'entends "pragmatisme" j'entends "faut bien manger" alors qu'en vérité, comme vous le dites ça dépend du contexte... Pour moi l'agilité repose sur deux piliers phares : replacer l'humain au coeur du schéma productif et se donner les moyens pour aborder ce qui relève des sujets complexes. Je mets au défi quiconque de me présenter une entreprise "agile", je ne connais en fait qu'une chose dans ce sens : un cheminement sur la voie du Kaizen comme un mythe de sisyphe... L'agilité se trouve là, pas dans le contexte ou les gens, mais dans cette envie de faire de l'humain là où on faisait hier du projet, rapprocher les narratifs et construire du commun dans une envie de vouloir faire tous les jours un peu mieux qu'hier...
@ScrumLife
9 ай бұрын
😁 -- JP
La DOR est indispensable
@patrickvandevoorden8327
9 ай бұрын
Tout comme le DOD
@ScrumLife
9 ай бұрын
Merci pour ton commentaire, est-ce que cela veut dire que tu n'es pas d'accord avec notre analyse ? Qui essaie de nuancer le jugement de la pertinence de la DoR en fonction du contexte de l'équipe. -- JP
@patrickvandevoorden8327
9 ай бұрын
@@ScrumLife La DOR est indispensable pour avoir une description claire de ce qu'on doit faire
@ScrumLife
9 ай бұрын
Merci Patrick, tu mets quoi dans la DOR qui te semble indispensable ? - Constantin
@patrickvandevoorden8327
9 ай бұрын
@@ScrumLife Les spécifications, l'objectif , qui fait quoi et quand. Après on en parle avec le product owner et le business. J'utilise la méthode 3 amigos
Je te pardonne JP. Mais faudra pas recommencer 😊
@ScrumLife
9 ай бұрын
Ah ah ! Autrement, que retires-tu de cette vidéo ? À plus 👋 -- JP