Merci JP pour cette vidéo. J'ai une petite précision à faire. Tu dis dans la vidéo que ça devrait être livré en production à chaque fin d'itération ou du moins que le produit doit apporter de la valeur. Je pense qu'on ne peut pas forcément mettre en production (même si j'aime cette idée là). Cependant, il est important que ça soit mis dans les mains de l'utilisateur pour qu'il puisse donner son feedback. Techniquement, ça peut être sur un site de préversion ou de démonstration. ça peut aussi être fait à l'aide de toggle feature. Il existe de nombreuses techniques. Je me permets de dire ça car souvent j'entends des équipes dire qu'elles ne peuvent pas livrer en production car elles n'ont pas terminé toutes les US de la feature. Ce n'est pas grave, au contraire. Il faudrait livrer en préproduction ou en démo pour que le client donne son avis et qu'on adapte le plan en fonction. On évite ainsi l'effet tunnel et un écart entre le besoin de l'utilisateur et la réponse qu'on apporte.
Top cette vidéo. Bravo ! Super résumé et comparatif agile/traditionnel. Et surtout il faut insister sur le fait que la qualité n'est pas négociable en agile et ne doit pas être utilisée comme variable d'ajustement pour tenir des délais irréalistes.
Super vidéo ! Pour ma part, je me posais plein de questions sur le rythme d'avancement d'un projet et comment tenir les délais. Ce qui m'a parlé tout particulièrement, c'est la vision "chef de projet" vs " la réalité des développeurs (carte vs territoire). Et le burn-up ? Je suis convaincue et burn-up adopté !
Bonjour Anders, je ne connais pas, j'ai donc regardé des images de l'interface et je me demande si l'équipe à un moyen de voir d'un seul coup d'oeil l'état d'avancement du sprint sans avoir à lire les cartes et encore moins à rentrer dedans ? Typiquement c'est un problème que je vois avec Trello et autres, le manque de "swimlanes" permettant de voir ET la tâche principale (comme une US) ET les tâches 'techniques' pour la concevoir, ce qui donne, même de loin, une visibilité sur l'état d'avancement. Tu vois ce que je veux dire ? -- Const
Hello ! Vidéo très intéressante encore ! Je me pose une question au sujet du Burnup Chart et de la quantité de TODO : ça signifie qu'il faut tout estimer en amont ? D'autre part le PB évolue en permanence, donc c'est difficile de se baser là-dessus ? Après si on se concentre sur une fonctionnalité en particulier, c'est jouable car globalement, on a une idée un peu plus précise mais à l'échelle d'un projet, ça semble compliqué, non ?
Hello @LaPapaye11 ! Merci pour ton commentaire et tes questions très pertinentes ! Concernant le Burnup Chart, tu as raison de souligner que l’estimation en amont peut sembler complexe, surtout dans des environnements où le Product Backlog évolue fréquemment. Cependant, l'idée n'est pas de tout estimer de façon immuable, mais plutôt de revoir régulièrement les estimations pendant les événements Scrum, comme le Sprint Planning. Cela permet d'ajuster constamment en fonction des nouvelles informations et des évolutions du backlog. Pour une fonctionnalité spécifique, comme tu le soulignes, c’est effectivement plus gérable. Mais à l’échelle d’un projet, c’est là que les approches agiles montrent toute leur valeur : elles nous offrent une flexibilité et une visibilité continue. L'important est de maintenir un équilibre entre estimation et adaptation pour naviguer efficacement à travers les incertitudes. Comment gères-tu la mise à jour de tes estimations dans ton propre contexte ? 🤔 Robin #ScrumLife
Merci Scrum Life! J'ai un petit retour sur le remarque "livrer la valeur des le premier sprint". Normalement on aura du mal a livrer les vrais valeurs visible pour les utilisateurs, car on a des preparation a faire, structures a monter, pipe line, test environments etc... Du coup de mon experience, on a definie le Sprint 0. c'est la ou on fait les preparation qui ne sont pas visible pour les utilisateurs.
Qu'est-ce qui vous empêche de construire tous ces éléments incrémentalement ? Petit à petit ? En se focalisant à chaque fois sur le strict minimum pour pouvoir créer de la valeur ? Et de les faire évoluer petit à petit, en parallèle des évolutions du produit ? Il faut aussi se dire que tous ces éléments ont de la valeur. Sinon pourquoi les faire ? Si vous n'arrivez pas à expliquer au client la valeur de ces outils, c'est un problème aussi. Qu'en pensez-vous ? Quelques vidéos complémentaires sur le sujet : Conception logicielle : faire pousser plutôt que construire -- analogie pour expliquer le développement incrémental et itératif : ua-cam.com/video/VJVP2GTG_KI/v-deo.html Déterminer et mettre en avant l'impact sur le produit et le business de chaque élément du backlog : ua-cam.com/video/wD5WeJ7xde8/v-deo.html Notre avis sur le Sprint Zéro : ua-cam.com/video/FjoO4A0x7-0/v-deo.html -- JP
Merci pour ces informations ! Pensez-vous faire une vidéo sur le framework SaFE ? En tant que PO, je trouve qu'il n'est pas toujours simple de conserver un ownership sur le produit en SaFE.
Bonjour Jean-Christophe, Pour moi il y a deux manières d'approcher cette question ainsi que le framework SAFe en général. 1. Vous êtes dans une situation où les équipes sont très autonomes sur la construction produit. Cela se ressent dans la conception même du produit, dans l'approche produit adoptée, et dans la structure des équipes et de l'organisation en général. Dans ce cas, je te rejoins, SAFe risque de poser des contraintes sur le travail de Product Ownership qui seront plus limitantes qu'une aide. Plus généralement cela ne sera pas spécifique à SAFe mais aux "frameworks de passage à l'échelle." Le problème ici est que votre manière de fonctionner ne nécessite pas SAFe, bien au contraire. 2. Ou alors, vous êtes au contraire dans une situation où SAFe (ou un autre "framework de passage à l'échelle") est justifié. Que cela soit parce que le produit est énorme et n'a pas été conçu pour être géré comme un ensemble de sous-produits indépendants. Ou parce que les ingrédients pour s'en passer ne sont pas encore là, comme une incompatibilité entre la culture de l'entreprise et autonomisation des équipes par exemple. Dans ces situations, SAFe n'est pas un mauvais choix et cette difficulté à conserver un Product Ownership dans les équipes n'est pas un problème, bien au contraire : c'est exactement ce qui est recherché. Dans tous les cas j'ai donc envie de ne pas accuser SAFe : - Soit on applique SAFe par erreur (cas 1) - Soit l'organisation ne *veut pas* déléguer le Product Ownership dans les équipes, le problème n'est pas intrinsèquement SAFe mais justement l'organisation qui fait ce choix, consciemment ou inconsciemment (cas 2) Je conclurai en notant que "Scrum en SAFe" n'est pas Scrum. Il y a un certain nombre de différences, petites sur le papier mais qui mènent à un mindset et donc une pratique profondément différents. Autrement, voici quelques autres contenus qui t'intéresseront peut-être si tu ne les as pas déjà vus : - Product Owner (PO) et Product Manager (PM) : quelle différence ? - Scrum Life 28 ua-cam.com/video/pSIYgV8_j9E/v-deo.html - Safe Agile Francais - Pourquoi tant de haine ? - Scrum Life 84 ua-cam.com/video/Unrb5H1ltkA/v-deo.html - Safe Agile Francais - SAFe est-il agile ? ua-cam.com/video/e8k9DglF6Bw/v-deo.html - Meetup : Table ronde autour de SAFe ua-cam.com/video/Esbyvv1jeuM/v-deo.html Nous avons prévu de faire toute une série de vidéo autour de cette notion de passage à l'échelle, qui parlera aussi de SAFe, mais aucune date de prévue pour le moment. Dis-moi tout ce que cela t'évoque ! -- JP
@@ScrumLife merci Jean-Pierre pour ta réponse. On est plutôt dans la situation n°2! Je vais commencer par visionner les contenus que tu me proposes. Faire bouger les lignes au sein de l'organisation n'est pas toujours chose aisée...
Bonjour, mesurer la vélocité de l'équipe et donc de pouvoir s'en servir de base pour les futures estimations est très pertinent selon moi. Mais comment mesure t-on cette vélocité ?
Bonjour, cette vidéo devrait répondre à vos questions sur la vélocité : ua-cam.com/video/JcpWqm23-qA/v-deo.html Si ce n'est pas le cas, revenez vers nous qu'on éclaircisse ça !
@@ScrumLife Bonjour et merci pour votre réponse. J'ai donc regardé la vidéo proposée et il y a plein de chose très intéressantes. J'ai bien compris par exemple l'intérêt de connaître la vélocité. Maintenant je reste un peu sur ma faim concernant le point qui sert de base de calcul. Je m'explique. Corrigez moi si je me trompe. Déjà le point ne peut pas être le jour homme (sinon comment par exemple augmenter la vélocité ? ) ... Donc on va utiliser le "point" : mais qu'est ce que ce "point", comment le définir ? Un point = une User Story ? sachant qu'on définit des US de même "taille", ça me paraît plus pertinent déjà. Mais quand j'entends parler de point aussitôt on me parle de suite de Fibonacci et là je décroche. Y a t-il un épisode de Scrum life sur ce qu'est un point ? Merci.
Merci pour cette vidéo très bien simplifiée, et questions ? Si on veut être reconnus dans le domaine, est-ce qu'ont passé des certifications, si oui lesquelles ? et j'ai trouvé une vidéo en exemple ua-cam.com/video/Rx11lSvyKK8/v-deo.html
Salut Ramon, On a essayé de répondre à cette question dans cet épisode de Scrum Life : ua-cam.com/video/KKmBU7VYrkE/v-deo.html Je te laisse regarder et nous dire si ça répond à tes interrogations ? À très vite ! -- JP
Découvrez toute la communauté Scrum Life ! 👉 sl.run/02zpi0
Merci JP pour cette vidéo.
J'ai une petite précision à faire. Tu dis dans la vidéo que ça devrait être livré en production à chaque fin d'itération ou du moins que le produit doit apporter de la valeur. Je pense qu'on ne peut pas forcément mettre en production (même si j'aime cette idée là). Cependant, il est important que ça soit mis dans les mains de l'utilisateur pour qu'il puisse donner son feedback. Techniquement, ça peut être sur un site de préversion ou de démonstration. ça peut aussi être fait à l'aide de toggle feature. Il existe de nombreuses techniques.
Je me permets de dire ça car souvent j'entends des équipes dire qu'elles ne peuvent pas livrer en production car elles n'ont pas terminé toutes les US de la feature. Ce n'est pas grave, au contraire. Il faudrait livrer en préproduction ou en démo pour que le client donne son avis et qu'on adapte le plan en fonction. On évite ainsi l'effet tunnel et un écart entre le besoin de l'utilisateur et la réponse qu'on apporte.
Top cette vidéo. Bravo !
Super résumé et comparatif agile/traditionnel.
Et surtout il faut insister sur le fait que la qualité n'est pas négociable en agile et ne doit pas être utilisée comme variable d'ajustement pour tenir des délais irréalistes.
Super vidéo ! Pour ma part, je me posais plein de questions sur le rythme d'avancement d'un projet et comment tenir les délais. Ce qui m'a parlé tout particulièrement, c'est la vision "chef de projet" vs " la réalité des développeurs (carte vs territoire). Et le burn-up ? Je suis convaincue et burn-up adopté !
Quand je pense que j'ai passé ma certification agile avec un formateur soporifique...j'aurais vraiment aimé connaître cette chaîne plus tôt.
Merci ! Au passage, as-tu vu que l'on proposait une formation ? 😋 scrumlife.tv/meilleursm/
-- JP
Super vidéo. Restyaboard est le meilleur outil de gestion de projet Agile et Scrum open-source pour planifier, organiser et suivre les projets.
Bonjour Anders, je ne connais pas, j'ai donc regardé des images de l'interface et je me demande si l'équipe à un moyen de voir d'un seul coup d'oeil l'état d'avancement du sprint sans avoir à lire les cartes et encore moins à rentrer dedans ?
Typiquement c'est un problème que je vois avec Trello et autres, le manque de "swimlanes" permettant de voir ET la tâche principale (comme une US) ET les tâches 'techniques' pour la concevoir, ce qui donne, même de loin, une visibilité sur l'état d'avancement. Tu vois ce que je veux dire ?
-- Const
Très clair comme d'hab ! Merci
Hello ! Vidéo très intéressante encore ! Je me pose une question au sujet du Burnup Chart et de la quantité de TODO : ça signifie qu'il faut tout estimer en amont ? D'autre part le PB évolue en permanence, donc c'est difficile de se baser là-dessus ? Après si on se concentre sur une fonctionnalité en particulier, c'est jouable car globalement, on a une idée un peu plus précise mais à l'échelle d'un projet, ça semble compliqué, non ?
Hello @LaPapaye11 ! Merci pour ton commentaire et tes questions très pertinentes !
Concernant le Burnup Chart, tu as raison de souligner que l’estimation en amont peut sembler complexe, surtout dans des environnements où le Product Backlog évolue fréquemment. Cependant, l'idée n'est pas de tout estimer de façon immuable, mais plutôt de revoir régulièrement les estimations pendant les événements Scrum, comme le Sprint Planning. Cela permet d'ajuster constamment en fonction des nouvelles informations et des évolutions du backlog.
Pour une fonctionnalité spécifique, comme tu le soulignes, c’est effectivement plus gérable. Mais à l’échelle d’un projet, c’est là que les approches agiles montrent toute leur valeur : elles nous offrent une flexibilité et une visibilité continue. L'important est de maintenir un équilibre entre estimation et adaptation pour naviguer efficacement à travers les incertitudes.
Comment gères-tu la mise à jour de tes estimations dans ton propre contexte ? 🤔
Robin
#ScrumLife
Merci Scrum Life! J'ai un petit retour sur le remarque "livrer la valeur des le premier sprint". Normalement on aura du mal a livrer les vrais valeurs visible pour les utilisateurs, car on a des preparation a faire, structures a monter, pipe line, test environments etc... Du coup de mon experience, on a definie le Sprint 0. c'est la ou on fait les preparation qui ne sont pas visible pour les utilisateurs.
Qu'est-ce qui vous empêche de construire tous ces éléments incrémentalement ? Petit à petit ? En se focalisant à chaque fois sur le strict minimum pour pouvoir créer de la valeur ? Et de les faire évoluer petit à petit, en parallèle des évolutions du produit ?
Il faut aussi se dire que tous ces éléments ont de la valeur. Sinon pourquoi les faire ? Si vous n'arrivez pas à expliquer au client la valeur de ces outils, c'est un problème aussi. Qu'en pensez-vous ?
Quelques vidéos complémentaires sur le sujet :
Conception logicielle : faire pousser plutôt que construire -- analogie pour expliquer le développement incrémental et itératif : ua-cam.com/video/VJVP2GTG_KI/v-deo.html
Déterminer et mettre en avant l'impact sur le produit et le business de chaque élément du backlog : ua-cam.com/video/wD5WeJ7xde8/v-deo.html
Notre avis sur le Sprint Zéro : ua-cam.com/video/FjoO4A0x7-0/v-deo.html
-- JP
Merci pour ces informations !
Pensez-vous faire une vidéo sur le framework SaFE ?
En tant que PO, je trouve qu'il n'est pas toujours simple de conserver un ownership sur le produit en SaFE.
Bonjour Jean-Christophe,
Pour moi il y a deux manières d'approcher cette question ainsi que le framework SAFe en général.
1. Vous êtes dans une situation où les équipes sont très autonomes sur la construction produit. Cela se ressent dans la conception même du produit, dans l'approche produit adoptée, et dans la structure des équipes et de l'organisation en général. Dans ce cas, je te rejoins, SAFe risque de poser des contraintes sur le travail de Product Ownership qui seront plus limitantes qu'une aide. Plus généralement cela ne sera pas spécifique à SAFe mais aux "frameworks de passage à l'échelle." Le problème ici est que votre manière de fonctionner ne nécessite pas SAFe, bien au contraire.
2. Ou alors, vous êtes au contraire dans une situation où SAFe (ou un autre "framework de passage à l'échelle") est justifié. Que cela soit parce que le produit est énorme et n'a pas été conçu pour être géré comme un ensemble de sous-produits indépendants. Ou parce que les ingrédients pour s'en passer ne sont pas encore là, comme une incompatibilité entre la culture de l'entreprise et autonomisation des équipes par exemple. Dans ces situations, SAFe n'est pas un mauvais choix et cette difficulté à conserver un Product Ownership dans les équipes n'est pas un problème, bien au contraire : c'est exactement ce qui est recherché.
Dans tous les cas j'ai donc envie de ne pas accuser SAFe :
- Soit on applique SAFe par erreur (cas 1)
- Soit l'organisation ne *veut pas* déléguer le Product Ownership dans les équipes, le problème n'est pas intrinsèquement SAFe mais justement l'organisation qui fait ce choix, consciemment ou inconsciemment (cas 2)
Je conclurai en notant que "Scrum en SAFe" n'est pas Scrum. Il y a un certain nombre de différences, petites sur le papier mais qui mènent à un mindset et donc une pratique profondément différents.
Autrement, voici quelques autres contenus qui t'intéresseront peut-être si tu ne les as pas déjà vus :
- Product Owner (PO) et Product Manager (PM) : quelle différence ? - Scrum Life 28 ua-cam.com/video/pSIYgV8_j9E/v-deo.html
- Safe Agile Francais - Pourquoi tant de haine ? - Scrum Life 84 ua-cam.com/video/Unrb5H1ltkA/v-deo.html
- Safe Agile Francais - SAFe est-il agile ? ua-cam.com/video/e8k9DglF6Bw/v-deo.html
- Meetup : Table ronde autour de SAFe ua-cam.com/video/Esbyvv1jeuM/v-deo.html
Nous avons prévu de faire toute une série de vidéo autour de cette notion de passage à l'échelle, qui parlera aussi de SAFe, mais aucune date de prévue pour le moment.
Dis-moi tout ce que cela t'évoque !
-- JP
@@ScrumLife merci Jean-Pierre pour ta réponse.
On est plutôt dans la situation n°2!
Je vais commencer par visionner les contenus que tu me proposes.
Faire bouger les lignes au sein de l'organisation n'est pas toujours chose aisée...
Bon courage ! Et tiens-nous au courant de ce que ça donne 💪👍
Bonjour,
mesurer la vélocité de l'équipe et donc de pouvoir s'en servir de base pour les futures estimations est très pertinent selon moi.
Mais comment mesure t-on cette vélocité ?
Bonjour, cette vidéo devrait répondre à vos questions sur la vélocité : ua-cam.com/video/JcpWqm23-qA/v-deo.html
Si ce n'est pas le cas, revenez vers nous qu'on éclaircisse ça !
@@ScrumLife Bonjour et merci pour votre réponse.
J'ai donc regardé la vidéo proposée et il y a plein de chose très intéressantes. J'ai bien compris par exemple l'intérêt de connaître la vélocité.
Maintenant je reste un peu sur ma faim concernant le point qui sert de base de calcul.
Je m'explique. Corrigez moi si je me trompe.
Déjà le point ne peut pas être le jour homme (sinon comment par exemple augmenter la vélocité ? ) ...
Donc on va utiliser le "point" : mais qu'est ce que ce "point", comment le définir ?
Un point = une User Story ? sachant qu'on définit des US de même "taille", ça me paraît plus pertinent déjà.
Mais quand j'entends parler de point aussitôt on me parle de suite de Fibonacci et là je décroche.
Y a t-il un épisode de Scrum life sur ce qu'est un point ?
Merci.
Pour les estimations en points ça se passe ici : ua-cam.com/video/NZxcqei5qIE/v-deo.html
😊
@@ScrumLife super ! merci
Merci pour cette vidéo très bien simplifiée, et questions ? Si on veut être reconnus dans le domaine, est-ce qu'ont passé des certifications, si oui lesquelles ? et j'ai trouvé une vidéo en exemple ua-cam.com/video/Rx11lSvyKK8/v-deo.html
Salut Ramon,
On a essayé de répondre à cette question dans cet épisode de Scrum Life : ua-cam.com/video/KKmBU7VYrkE/v-deo.html
Je te laisse regarder et nous dire si ça répond à tes interrogations ?
À très vite !
-- JP
tes cheveux vont être très longs dans un 1 mois :)
Ca fait déjà longtemps qu'ils devraient être coupés !
@@ScrumLife oui :) promis je regarde ce soir le reste de la vidéo :)
Ben alors on se rase plus ;o)
Tournage en fin de semaine !