Scrum Life te ment ! Pas qu'UNE SEULE Agilité - produit vs à la demande
Vložit
- čas přidán 22. 07. 2024
- 🎁 Le guide du Scrum Master compétent 👉 sl.run/vK0ENv
Oui ! On a honte d'avouer qu'avec nos clients on ne fait pas toujours ce qu'on explique dans nos vidéos. Et bien justement, aujourd'hui, creusons cette question et voyons qu'il est avant tout question de PRAGMATISME et de prendre en compte le CONTEXTE. Concrètement, il y a des situations où l'on peut adopter une APPROCHE PRODUIT, et d'autres où l'on est réduit à construire des SOLUTIONS À LA DEMANDE. On t'explique tout ça ! #ScrumLife #Honnete #Pragmatisme
💜️ Rejoins la communauté Scrum Life 👉 sl.run/wboSME (c'est gratuit !)
----------
SOMMAIRE️
00:00 Scrum Life te ment ?
01:10 Le pragmatisme avant TOUT !
01:37 Tout dépend du contexte
06:13 Exemple : Definition of Ready
18:17 Faire bouger les lignes
23:05 Transmettre sans reproduire
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...)
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.
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 !
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.
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é.
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
@@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.
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
@@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 😄
canon !
Ah, merci ! Tu saurais articuler ce que tu apprécies tout particulièrement ?
-- JP
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
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
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 ?
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
@@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.) ?
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
@@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.
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
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 :)
Jeudi sur le podium ?
@ Alors désolé pour mon ignorance là dessus, mais kessé le podum ? :)
@@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
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 !!!
@ Ah les Live Hebdo! OK je viens de faire le lien, j'avais pas fait le lien avec "le podium". :-)
8:00 Invest as dor
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...
😁
-- JP
Je te pardonne JP. Mais faudra pas recommencer 😊
Ah ah !
Autrement, que retires-tu de cette vidéo ?
À plus 👋
-- JP
La DOR est indispensable
Tout comme le DOD
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
@@ScrumLife La DOR est indispensable pour avoir une description claire de ce qu'on doit faire
Merci Patrick, tu mets quoi dans la DOR qui te semble indispensable ?
- Constantin
@@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