Mode projet ou mode produit ? Quelles différences ? - Scrum Life 60

🎁 Le guide du Scrum Master compétent 👉 sl.run/itFYh3
"Mode projet" et "mode produit" sont deux manières distinctes de poser un cadre à une équipe de développement logiciel. Y a-t-il une date de fin ? Les clients sont-ils clairement identifiés, indiquent-ils à l'équipe le travail à faire, ou bien est-ce plutôt l'équipe qui définit et découvre le travail à faire ?
Mais surtout, quelles sont les conséquences de ces deux modes de fonctionnement ? En quoi le cadre posé pour l'équipe diffère-t-il ?
💜️ La communauté Scrum Life 👉 sl.run/nHv9E5
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
On répond à vos commentaires : • On répond à vos commen...

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/JTiUBD

[@orsikordev2807]

Le parti pris est évident mais les question de fond sont posées. C'est principalement un soucis de mindset du management. Respect inconditionnel des processus projet vs attentif aux retours clients ET techniques et ses nombreuses adaptations possibles

[@benburnstoshine]

Enorme le passage à 6:00 !!!!!

[@ScrumLife]

😝

[@lutaseb]

effets spéciaux de fou!

[@benburnstoshine]

Clairement un parti pris dans la vidéo ;) Après la vidéo coup de gueule "bien sûr qu'on est agile", je trouve qu'elle adresse des arguments factuels sur l'avantage de s'orienter en mode produit et du coup vraiment en agile/scrum.

[@YBCause]

Cool développement sur les tests à partir de 7:15

[@aymericrichard6931]

Très bien ce format de présentation. Tout ce qui soutient le discours est présent, le rend clair et agréable. S'il fallait encore améliorer ça serait travailler le décor et la lumière (ex avoir une lampe à l'arrière sur le côté et vers le bas afin de découper la silhouette). Il me semble que le volume sonore est plus faible que d'habitude.

[@cog_g]

Pour le son c'est aussi ce que je me suis dit hier, je dois vérifier. Merci en tout cas pour les remarques constructives ! :)

[@ScrumLife]

Que donne ces deux modèles "mode projet" et "mode produit" appliqués à l'agilité à l'échelle ? Que cela vous évoque-t-il ? À vos commentaires !

[@D3licator]

L'implication est la facteur clef à mon avis Video très pertinente, je n'avais jamais vraiement réfléchi à ses deux approches...

[@aymericrichard6931]

@@D3licator je ne comprends pas le lien entre implication et orientation projet ou produit.

[@D3licator]

@@aymericrichard6931 je n'aurais aucune difficulté à m'impliquer en mode produit alors qu'en mode projet ça me semble plus dur (c'est peut être moi...) Mais si on arrive à avoir la bonne implication en mode projet c'est la bonne voie

[@cog_g]

Je suis assez d'accord, en mode produit on à l'impression d'apporter une vraie plus value, alors qu'en mode projet, on est plus à exécuter des tâches prévue

[@DavidLacourt]

Merci pour cette vidéo ! Elle m’a apporté des éléments de compréhension sur l’état de mon organisation qui est en mode projet ET nous demande de penser produit. En plein dans la « schizophrénie » et donc difficulté de rendre agile le tout.

[@aymericrichard6931]

Projet ou produit, oui c'est compliqué. D'autant plus dans un département infrastructure où l'essentiel des évolutions est tiré par des besoins d'intégration. Ajoute un management à l'ancienne qui ne comprend pas les notions d'engagement et priorités agile.

[@sbertho82]

Parle-t-on d'agile ou agile à l'échelle ? Agile est me semble-t-il une clé de 13 du SAFe mais je peux me tromper. Il m'a semblé que le problème principal est d'adapter sa réponse au client, c'est à dire le mode projet peut être adapté à un client et le mode Agile ou SAFe adapté à un autre client. Comme une clé de 13 est adapté ou alors il vaut mieux une clé de 12. C'est le bon sens, non ?

[@marcquentin6232]

Bonjour, Dans la video, on sent clairement un parti pris; c'est dommage. D"un côté vous définissez aussi le mode projet mais sans trop définir le mode produit. Le mode projet est un scope fini dans un temps clairement défini pour satisfaire une demande client; d'un autre côté, le mode produit va consister à se concentrer sur la gestion continue d'un backlog applicatif. Dans un grand nombre d'organisations, les budgets sont libérés pour la mise en oeuvre d'un projet. On peut donc parfaitement s'organiser en projet (scope fini, délai fini) tout en gardant l'état d'esprit que tu suggères pour le mode produit (notamment le partage des responsabilités, l'importance du test). Cet état d'esprit n'est heureusement pas spécifique au mode produit. Le client aura une meilleure compréhénsion de l'organisation IT et pourra s'y intégrer d'autant plus facilement. Dans le cas également où une organisation est composée d'un grand nombre d'applications fortement connectées, le mode produit perd de sa pertinence car on n'a plus un ensemble de backlog indépendants à livrer mais une réponse concertée qui va impliquer plusieurs produits. Je découvre votre chaîne, super intéressant, je m'abonne ! Félicitations

[@ScrumLife]

Merci beaucoup pour ces précisions ! Je concède que nous faisons certaines approximations, et nous essayons de nous améliorer avec le temps. La vidéo commence à dater un peu maintenant ! Encore merci pour ces compléments qui serviront à toute la communauté. -- JP

[@paul-emmanuelbuttin1006]

Même si je soutiens ton travail JP, ce sujet fait partie de ceux sur lesquels je ne suis pas d'accord du tout; et je déplore l'adoption d'une pensée disjonctive, opposant le projet au produit; là où les deux notions sont fondamentalement différentes et toutes deux nécessaires à l'activité de développement logiciel. Gros amalgame en outre entre un mode projet (caractère unique du résultat et forte incertitude) et les méthodes d'engagement sur le périmètre et de pilotage par les activités. Affirmer également qu'on peut appliquer Scrum avec le "mode projet" que tu présentes (5'20) donc avec une relation menant à l'opposition (4'44) est complètement contraire aux valeurs de Scrum. Dommage...