Cadrage Agile : Le SPRINT ZERO est-il vraiment agile ?

[@ScrumLife]

Le sprint 0 tel que défini ici, vient souvent après la phase de construction de la vision produit initiale (qui est souvent le début du projet, avec un GO / NOGO) Découvrez toute la communauté Scrum Life ! 👉 sl.run/aMg9zz

[@juliend.604]

Justement une bonne architecture est une architecture qui est modulaire et évolutive, on ne doit jamais penser à la finalité. La conception doit se baser sur des abstractions qui permettent à tous moments, de substituer, ou remplacer, une brique technique ou fonctionnelle sans tout changer.

[@ScrumLife]

Merci Julien, ça me fait penser au concept d'archi hexagonale ce que tu décris. Tu vois autre chose ?

[@juliend.604]

@@ScrumLife Alors oui, ce que l'on appel archis Hexagonales met en œuvre les principes SOLIDD et le DDD. Ce sont des principes d'archi logiciels qui doivent être appliquées. Le principe d'abstraction doit aussi pouvoir s'appliquer en terme d'infrastructure, aujourd'hui avec des outils comme Kubbernetes il deviens très difficile de soutenir qu'une infrastructure figée par une techno soit un bon choix. Si à un instant t les technos "figées" (qui obligent à être spécifique et à s'y tenir), choisies, peuvent paraitre pragmatiques parce qu'elles répondent un peu plus vite, ou pour quelques dollars de gagner, la dette technique apparaitra forcément tôt ou tard (je n'ai pas de contre exemples, je n'ai que des exemples). Le besoin doit être pensé uniquement en terme de contrats, l'implémentation ou le protocole d'échange doivent pouvoir être substitués sans tout remettre en question.

[@LyesDoar]

J'adore votre point de vue!, surtout quand tu dis : - Question : "Est ce que c'est si grave d'accepter ou de proposer de faire un sprint 0 au final où une phase de cadrage?" - Réponse : "Pour moi ce qui est gênant c'est qu'au final c'est du Waterfull déguisé"

[@ScrumLife]

Merci !!! Être au clair sur l'approche, "être droit dans ses bottes" c'est important. Est-ce que cela fait écho à tes précédentes expériences ? -- JP

[@celinejanssens7817]

Super intéressant comme toujours ! Ca m'aide a préparer mes arguments pour les démarrages de projets ! Merci

[@ScrumLife]

Ah tant mieux ! ça se passe comment pour l'instant les démarrages ? -- Constantin

[@benobo]

Certains éléments, comme par exemple la sécurité doivent maintenant être pensés dès la conception, c'est le fameux "security by design" imposé par le RGPD. Si on ne met pas en place correctement ces éléments de sécurité dès le départ car on veut livrer du fonctionnel, de la business value très rapidement, le risque est qu'on ne revienne jamais dessus car ça n'apporte pas de valeur directe. C'est pourquoi à mon sens il est très important que les briques de sécurité soient mise en place dès le départ lors d'un sprint 0. Car une fois l'équipe lancé dans l'enchaînement des sprints il y a fort à parier qu'elle ne reviendra plus jamais sur la façon dont l'authentification fonctionne, puisqu'elle fonctionne.

[@ScrumLife]

Je suspecte que la question n'est pas tant liée à la sécurité que plus généralement à la priorisation des éléments "techniques" ou du moins non-fonctionnel. On l'a déjà évoqué au moins en partie dans de précédents épisodes. Il faut bien prendre en compte toutes les variables lors de la priorisation. De leur côté les développeurs doivent apprendre à expliquer l'impact sur le business d'un élément technique. Pour reprendre l'exemple de la RGPD, c'est assez facile : il y a un risque de subir une amende de 4% du CA il me semble. Ce n'est pas forcément à gérer immédiatement, mais il y a bien un moment où cela deviendra plus prioritaire que de nouvelles fonctionnalités.

[@benobo]

@@ScrumLife oui c'est vrai, je donnais la sécurité en exemple mais le problème concerne plus généralement toutes les tâches techniques qu'on a souvent du mal à "vendre". Je vais essayer de retrouver et visionner la vidéo concernant ce sujet sur scrumlife.

[@metisetmat6454]

J’aime cette idée de partir avec ce qu’on a. Et si ce qu’on a, est une phase de cadrage, partons avec une phase de cadrage. Et améliorons là. Si effectivement, mettre en place un environnement de dév prend du temps, oeuvrons pour réduire ce délai. Si mettre en place la toolchain DevOps, prends du temps. Voyons comment automatiser sa mise en place. Si réunir et aligner les bonnes personnes est compliqué...bref, vous m’avez compris. Et au fur et à,mesure, réduisons la durée de cette phase de cadrage. Sans oublier que tous les projets/produits ne se ressemblent pas et qu’il y a sans doute plusieurs façons de faire ;-)

[@quentinbeucher2866]

Je fait une pause dans le visionnage de cette vidéo. Une bonne architecture logiciel, c'est : Une application qui respect les principes SOLID. Une application couché et que chaque couche soit totalement autonome. Les couches business sont quant à elle couvert par au minimum des testes unitaires (en TDD ou pas). Le reste dépend de l’environnement d'utilisation. Je retourne à mon visionnage (avant de mettre un pouce bleu)

[@juliend.604]

Exactement !!

[@ScrumLife]

Merci beaucoup Quentin, "Le reste dépend de l’environnement d'utilisation." tu entends quoi, par exemple, par "le reste" ?

[@quentinbeucher2866]

Le reste signifie qu'il n'existe pas d'architecture passe partout. Il est impossible de définir une architecture complète sans connaître le contexte de notre application. Pour faire simple, je pense, de ma petite expérience d'architecte, il y a des grands principes qu'il faut respecter, représentant une ossatures à nos applications, tout le reste dépendra du contexte.

[@YvesWeber]

Merci pour tous ces épisodes !

[@kaloumbousdan9997]

Bonsoir, j’ai regardé juste avant l’épisode que l’atelier de construction du backlog produit ( que j’ai beaucoup apprécié au passage ) mais j’aimerais du coup savoir , s’il faut se passer du sprint 0 ( car pas très agile) , à quel moment on peut arrêter avec l’équipe les socles tels que : - Le SGBD ; - Les langages de programmation ( Frontend / Backend ) ? Merci .

[@ScrumLife]

Bonjour Kaloum, a ton avis il faut combien de temps à une équipe pour se décider sur le langage à utiliser ou le type de bdd ? -- Constantin

[@kaloumbousdan9997]

@@ScrumLife pas beaucoup en effet 😅

[@juliedelmontdahan7377]

Bonjour, je suis en pleine formation PSPO1 et ai du mal a definir ce fameux Sprint 0. Je comprend son utilite, ses travers s'il est mal utilise. Mais par rapport au Scrum Guide... mystere ! J'en viens donc a me demander si le Sprint 0 est "reconnu et approuve" par Scrum, OU s'il n'est qu'une "adaptation" faites par les equipes Scrum et peut etre alors que "tolere". Dans l'exam, il y a une question sur son utilite, une des options de reponses etant : "le Sprint 0 n'existe pas!". Quels sont vos avis svp ?

[@ScrumLife]

Bonjour Julie, la réponse est simple, justement à cause de la question dans la certif scrum.org : le sprint 0 n'existe pas. C'est même, à mon avis, un vrai signe d'un manque d'agilité que de vouloir faire un sprint 0 ou un sprint de cadrage car cela empêche complètement (dans la vraie vie) d'avoir une approche empirique. En tant que Product Owner vous devez justement éviter cette phase de cadrage (parfois appelée framing), même si elle porte le nom "d'agile", on ne peut pas pivoter quand on a prévu le plan dès le départ, ou alors, on s'autorise à le changer, mais dans ce cas, pourquoi faire ce travail en amont ? Lorsque j'ai pu accompagner des équipes dès le début, donc sans cette phase de cadrage, cela à été toujours une réussite dans le projet. -- Constantin.

[@adilbennani5780]

sprint 0 oui ou non, cela dépends du contexte de l'organisation; de ce que représente l'équipe scrum par rapport à l'organisation, de la maturité de l'organisation, et aussi de la maturité de l'équipe scrum, de la complexité et de la taille du boulot à fournir pour sortir le produit final (une refonte d'une partie de système d'information pour un groupe qui se base sur le SI pour continuer d'exister sur le marché n'est pas la même chose que produire une petite application qui améliore le confort d'une catégorie des clients) cela dépends aussi des processus interne de l'organisation, une petite boite ne fonctionne pas de la même façon qu'un grand groupe. Aussi cela dépends des enveloppes budgétaires. Dans le cadre d'une transformation digitale d'envergure, les POOCs le Sprint 0 sont importants

[@SylvainDemuyter]

L'architecture est l'ensemble des choix opposable à tous les membres de l'équipe. Une bonne architecture est un ensemble de choix qui aide l'équipe à produire le produit de la plus grande valeur possible.

[@JeanDetoeuf]

La mise en place du socle logiciel est souvent vue comme la valeur ajoutée du sprint 0. Pour les développeurs, c'est plutôt contre productif car c'est le besoin métier qui va guider les choix technologiques, quitte à les adapter en cours de route, bien sur. Le sprint 0 sert plutôt de formation pour l'équipe sur la méthode et permet au PO de "prendre de l'avance" sur le backlog. Je ne dis pas que c'est une bonne pratique, mais que ça contribue plutôt à créer du logiciel et des stories qu'on aura du mal à jeter. Ca c'est uniquement quand le sprint 0 dure plus longtemps qu'un sprint, sinon. L'idéal serait même de commencer par des sprints très courts et quand la méthode est acquise, alors on peut alonger leur durée (tant pis pour le calcul de la vélocité, c'est l'efficacité de l'équipe qui compte).

[@ScrumLife]

Merci Jean pour ce commentaire. Je suis aussi partisan du sprint court, mais du coup si on utilise le premier sprint pour "former l'équipe sur la méthode" et pour permettre "au PO de prendre de l'avance sur le backlog", je pense qu'on peut se demander combien de temps cela peut prendre et si on ne peut pas simplement le faire dans un sprint 1, car après tout, c'est en faisant qu'on apprend. Je serais intéressé de comprendre pourquoi tu penses qu'une fois la méthode acquise, on voudrait allonger la durée des sprints et en quoi ça rendrait l'équipe plus efficace. :)

[@JeanDetoeuf]

@@ScrumLife je pensais commencer par des sprints exagérément court d'une journée. Déjà pour construire de la valeur petit à petit, pour que l'équipe intègre la méthode et m'améliore. Et aussi pour éviter l'écueil du sprint 0 d'avoir forcément un logiciel déployé en production, ce qui suivant l'équipe peut mettre plus ou moins de temps. Le but est d'avoir quelque chose à montrer qui ait de la valeur. Une série d'iterations courtes permet d'améliorer la méthode et de l'adapter à l'équipe des le début. Cela reste mon point de vue. Une fois que l'amélioration se stabilise on peut allonger les sprint à une ou plusieurs semaines si nécessaire

[@paul-emmanuelbuttin1006]

Je comprends la logique de vouloir produire de la valeur au plus tôt. Mais une réflexion préalable au démarrage est une nécessité absolue, ne serait-ce que pour identifier les parties prenantes et constituer/recruter l'équipe. Et on passe par là même si on n'a pas envie de nommer ça cadrage. Penser qu'on peut partir bille en tête dans un premier sprint sans faire de cadrage c'est simplement illusoire. Ce serait même dangereux et introduirait potentiellement une mauvaise compréhension de la notion de sprint pour les parties prenantes car on ne peut pas demander un engagement à l'équipe de développement sur ce premier sprint, et ça laisserait entendre qu'on peut faire un sprint sans objectif et sans engagement. A force de vouloir tout précipiter, on passe de l'Agilité à l'arrache... dommage. Je déplore aussi que les argumentaires soient manichéens ("on prévoit absolument tout en cadrage, c'est du waterfall déguisé"). Avoir des convictions c'est bien, faire des raccourcis n'aide personne. Désolé pour mon franc parler mais je pense qu'une remise en question est nécessaire pour éviter de glisser sur du contenu dangereux.

[@ScrumLife]

Merci Paul-Emmanuel. Je ne pense pas, personnellement, qu'il y ait de "nécessités absolues" dans notre métier, et qu'il n'y a rien d'illusoire là-dedans, j'ai personnellement accompagné plus d'une équipe comme ça et ce fut les plus "performantes" (à défaut d'un meilleur mot) que ce soit du point de vue humain (équipe très soudée) que delivery (on livrait de la qualité, chaque semaine). Donc, j'espère que tu m'autoriseras à reprendre ton terme de ton message Linkedin : il serait dogmatique de penser qu'il faut tout le temps et toujours une phase (longue) de cadrage. Je crois dire justement (mais peut-être pas assez clairement), que cette phase existe, j'ai même donné un exemple de comment elle pourrait se dérouler, mais elle doit être le plus court possible. Le cadrage évolue avec le produit si je puis dire. Constituer l'équipe, à mon avis, ne fait pas parti d'un "sprint zéro" tel que je l'ai décris au début. "on ne peut pas demander un engagement à l'équipe de développement sur ce premier sprint" Dans mon expérience, l'équipe peut s'engager (nuance ^^) sur un premier sprint avec un premier objectif. Qu'en penses-tu ? - Constantin.

[@paul-emmanuelbuttin1006]

@@ScrumLife La durée est à évaluer en fonction des besoins, écourter pour écourter n'a pas de sens. Je n'ai d'ailleurs jamais parlé de cadrage "long", mais j'affirme simplement que tenter de s'y soustraire est contre-productif. J'ai l'expérience opposée à la tienne : tenter de rattraper la mauvaise préparation en cours de route non seulement épuise les équipes mais endette le produit pour un temps considérable.

[@ScrumLife]

@@paul-emmanuelbuttin1006 Je vois ce que tu veux dire. L'agilité exige une extrême rigueur et "la bonne manière de faire" est en fait extrêmement difficile car elle demande un niveau d'excellence très élevée. Il faut bien entendu préparer des choses... Et y passer juste le temps nécessaire. Constantin évoque la conception émergente, au final peu d'équipes arrivent à réellement le mettre en place. Le but n'est pas d'écourter pour écourter, mais bien à cause des dynamiques d'équipes que cela crée, à cause des conséquences sur l'environnement et le contexte de l'équipe. Commencer par un premier sprint qui ne respecte aucune des règles qui devraient être suivies ensuite, cela crée de la dette aussi qu'il peut être difficile à racheter. Il reste évident que l'objectif du premier sprint sera moins ambitieux que les objectifs des sprints suivants, ne serait-ce que parce que l'équipe va utiliser ce premier sprint à apprendre à travailler ensemble. Mais d'un autre côté, c'est bien la nécessité d'accomplir un objectif (même petit) qui va réellement souder l'équipe, qui va donner du sens au DoD, qui va forcer les personnes à collaborer, qui va illustrer l'intérêt de chaque événement de Scrum. Je pointerais du doigt aussi que la réflexion peut être orientée différemment selon si on est en "mode projet" ou "mode produit" (pour prendre la nomenclature communément admise, je sais que tu n'aimes pas ces termes et en utilise d'autres). Dès lors que l'équipe est constituée pour une mission bien définie et bornée dans le temps, cette notion de cadrage en amont ne prend tout à fait le même sens. Malgré tout, on verra bien que les méthodes incrémentales et itératives (autres que Scrum inclus) indiquent la nécessité de construire quelque chose dès les premiers temps du projet, et ce même si ces premiers temps seront majoritairement constitués de conception. -- JP

[@paul-emmanuelbuttin1006]

@@ScrumLife Si je traduis ton dernier paragraphe Jean-Pierre, c'est "si ce n'est pas un projet, pas besoin de cadrage". Et dans les grandes lignes, je te rejoins là dessus : le cadrage est une phase utilisée dans un projet et n'a - a priori - pas de sens dans un contexte de développement continu d'application, par exemple. Sauf que le discours tenu dans la vidéo ne s'embarrasse pas de faire des cas : 2:45 "le spint 0 comme toute autre forme de cadrage vous demande de prendre des décisions très impactantes [...], presque définitives". Amalgame sur amalgame, on généralise du sprint 0 à "toute autre forme de cadrage" et on qualifie les décisions initiales de "presque définitives". Tu connais Jean-Pierre mon affection pour votre travail et le soutien que je vous porte (et je tente d'y contribuer comme je peux), c'est pour cela que je me permets de tirer la sonnette d'alarme : votre force au démarrage c'est de faire peu de cas des pratiques pour mettre en avant l'état d'esprit, le mindset comme tu aimes l'appeler. Je serais triste que votre message devienne la promotion de pratiques telles que le sprint d'une semaine, le no estimate et l'absence de cadrage, en les établissant comme de "bonnes pratiques de l'agilité", en utilisant comme rhétorique la dénonciation de pratiques mal comprises et mal mises en pratique, par une partie des professionnels de l'informatique... La pomme tomberait, selon moi, très loin de l'arbre... Mais je ne fais qu'exprimer mon avis, à vous d'en disposer ! ;)

[@LaMinuteAgile]

Le sprint 0 -> on fait tout le design ? On s’engage à 100% ? Socle 100% fait ? Un backlog engageant... Je suis surpris car c’est pas l’idée d’un sprint 0 Ou phase de cadrage agile... C’est le meme soucis que le scrum... Y a ceux qui le font en mode agile et d’autres non... Mais ceux qui ont fait ce type de cadrage qui amènerait un engagement stricte... Ils font un scrum non agile... La définition est ciblée anti-agile alors que c’est pas la base d’un sprint 0 Le framing agile qui est un framework de cadrage 100% agile rappelle constamment que rien n’est fixe et que la phase de cadrage est infinie (même quand ta réalisation technique démarre réellement). C’est de l’init sur des éléments essentiels qui peuvent toujours évoluer. Il n’y a aucun waterfall dans le framing agile... Tu pourras d’ailleurs trouver d’autres alternatives existantes 100% agile. Utiliser un framework plus adapté à un besoin d’init au lieu d’un scrum n’a rien de non agile... Sur certains produits c’est illusoire de commencer du développement sans même s’intéresser au produit : dans les hôpitaux Ou la vie de patients est en jeu... Commencer à développer sans même faire intervenir un client... Avant même de parler de backlogs, y a d’éventuelles études, vérifier les aspects légaux qui t’autorisent Ou non de faire quelque chose. La complexité de certains sujets ne peut amener à une réalisation rapide : juste parfois à cause de délais (intra entreprise [processus lourds qu’il faudrait sérieusement revoir], avec les administrations extérieures [etat, besoin de validation pour lancer une démarche...], voire autres entreprises externes. Démarrer une réalisation technique sans aucun élément, sans avoir vu des clients/utilisateurs (agile c’est user centric)... sans s’assurer du bien fondé de ce qu’on désire réaliser... Parfois l’obligation d’agréments pour se lancer... Tout n’est pas qu’un soucis de lancer une application, les sujets amènent dans certains cadres une complexité (qui exige des analysent longue et complexe) et des délais incompressible. Au final ce qui est proposé en alternative dans la vidéo est un vrai sprint 0. C’est exactement ce que c’était à la base. Peu importe le nom qu’on veut mettre derrière. Tu peux parfaitement fonctionner de façon incremental et itératif 100% agile sous un format plus axé “init”. Et si l’équipe le fait en format scrum ce qui est possible, cet init peu importe le nom qu’on lui donne peut parfois durer des mois. Dans un projet, tout n’est pas question de reaslisation. Parfois la réalisation peut même n’être que 20% de l’effort à fournir. Tout dépend du sujet traité.

[@ScrumLife]

Merci pour cet ajout. Nous parlons ici en effet d'un Sprint 0 tel que nous (Jean-Pierre et Constantin) avons vu à chaque fois. Je le rajoute en commentaire épinglé :) > "processus lourds qu’il faudrait sérieusement revoir" Devoir faire un sprint 0 pour ça est souvent le signe que les process de l’entreprise ne sont pas adaptés et qu'il faudrait travailler dessus. Chercher à se passer de sprint 0 permet de se contraindre à devoir travailler sur ces sujets et c'est pour moi une grande force, alors que "on fait un sprint 0 car on a un process lourd", c'est accepter la médiocrité et je ne pense pas que ce soit bénéfique pour l'entreprise à long terme (et pour l'équipe et le produit à court et moyen terme). C'est une fausse adaptabilité qui pousse à l'inaction : "on s'adapte, on est agile, pour que la structure de l'entreprise n'ait pas à bouger". - Constantin

[@LaMinuteAgile]

En effet cette façon de faire ce sprint 0 est présente dans certaines structures. Les entreprises l’aiment car elle s’apparente plus au mindset non agile (le mindset agile n’étant pas encore ancré). D’ailleurs en général, ce type de sprint 0 fait suite à un cadrage déjà réalisé côté métiers. Un magnifique waterfall même prôné par certaines méthodologies qui enferme le scrum qu’à la réalisation (ex: hermès qui est constitutionnel en suisse) Mais attention et faut pas s’y tromper certaines entreprises font des phases d’init vraiment agile ; des méthodes autres proposent des init qui n’enferme pas le scrum (ouf). Juste qu’en regardant la vidéo, on a tendance à entendre : “le cadrage” c’est pas agile si c’est pas en scrum. Bien sur, je suppose que c’est pas le message que tu voulais faire passer. Dans ton exemple, oui la mise en place d’un sprint 0 comme vous l’avez rencontré est un palliatif qui peut amener à ne rien changer des causes roots tout comme la mise en place d’un PPO. Mais dans cette façon faire, tu peux aussi avoir des effets négatifs : créer un conflit avec l’entreprise, démotivation des troupes, amener les métiers à vouloir s’isoler sur les prochains projets... C’est du déjà vu. En fait y a pas de méthodes magiques quand l’entreprise ne veut pas changer son mindset mais tout devient palliatif (si on peut vraiment appeler ça comme ça). Mais il faut évidemment proposer des tentatives de changements comme dans ton exemple. Ne pas tester c’est s’assurer de ne rien changer lol Sujet complexe à traiter hihihi au passage bravo pour cette 100eme 👍

[@sydeatn]

Le produit est "saint" ? :D

[@ScrumLife]

Zuuuuuuuuut :( - Const

[@sydeatn]

@@ScrumLife :D Cela arrive, même si le lapsus est particulièrement drôle cette fois-ci :) Dan D

[@dianabiramediabong7905]

P

[@ScrumLife]

Bah... Q ?

[@chrisc.4671]

On a que ça à foutre dans la life ! Passionnant. Les nouveaux d€biles de l'informatique 3.0

[@ScrumLife]

Salut @chrisc.4671, Je comprends que tout le monde n'ait pas la même appréciation des approches agiles. Notre objectif est d'améliorer la collaboration et l'efficacité au sein des équipes. Chacun a sa propre vision, et c'est tout à fait compréhensible ! Peut-être que tu as eu une mauvaise expérience ou que tu n'as pas encore vu les bénéfices de l'agilité ? J'aimerais beaucoup en savoir plus. Ton point de vue est précieux. 😊 À bientôt peut-être pour échanger davantage sur le sujet ? Robin