« Faites en sorte d’arriver à tester vos idées avant d’y tenir. »
Plus on passe de temps sur la concrétisation, plus, on a du mal à accepter de jeter une idée même si elle n’est pas bonne
4 « J'aime »
Petit à petit l’oiseau fait son nid. C’est la premiere phrase qui me soit venue en tête
2 « J'aime »
« Êtes vous prêt a engager cette somme d’argent pour produire quelque chose dont on a pas l’assurance que le client le veut ? Quelle somme êtes vous prêt a engager pour le savoir ? »
1 « J'aime »
« Fail fast & furious »
« Fail fast & furious succeed »
1 « J'aime »
Préambule : je pars du principe qu’on livre en fin ou en cours d’itération et que les feature flags sont à ON.
« Qu’est-ce qu’on perdrait à faire des itérations plus courtes en voulant apprendre d’un feedback utilisateur plus précoce ? »
Après, pour mettre en perspective la question de @Moosh, je me permets une question dissidente (ceci n’est pas un troll !) :
Tu préfères une durée d’itération d’1 semaine mais un retour utilisateur tardant à venir ou une itération de 3 semaines et des utilisateurs réagissant du tac au tac ?
De ma vision cela reste, quoi qu’il se passe une vue de l’esprit que de ne pas aller dans du sprint d’1 semaine.
1 semaine au lancement de l’équipe (et n’importe quand en fait) c’est s’offrir la possibilité d’avoir des boucles d’apprentissages très rapides sur le fonctionnement de l’equipe (interractions, processus, qualité, …), mais aussi le positionnement de l’équipe dans l’écosystème.
En gros, si tu prends la même equipr, celle en sprint d’1 semaine aura vecu 2 fois plus que celle qui fait des itérations de 2 semaines.
Après, si on fait 2 semaines ou 3, je comprends aussi les arguments qui disent que le contexte ne le permettra pas ; les Parties Prenantes ne seront pas dispo ; on aura pas le temps de préparer les cérémonies et de les animer ; on sera trop souvent en réunions …
Mais bon soyons honnêtes (#provoc) si on creuse un peu, on voit bien que rien n’est impossible. C’est avant tout que ca fait mal de se confrontrer a l’inconfort que cela gênerait individuellement et collectivement ;). Et c’est normal.
Bonjour,
Je vais faire comme @Fwedou je ne vais pas respecter la consigne 
.
J’ai proposé à l’équipe de tester des itérations très courte car nous devons sortir du pseudo scrum que nous faisions car nous passons à deux développeurs.
Après s’être planté sur une fonctionnalité il y de cela quelques sprint (fonctionnalité retiré de la prod et en attente de refonte) nous l’avons reprise en cherchant le plus petit incrément que nous pourrions faire pour avancer tout en nous interrogeant sur ce que nous voudrions valider. Nous avons choisi l’enregistrement asynchrone pluggé sur l’ancienne IHM. Cela permet à l’équipe d’avoir un focus et un objectif d’iteration.
Il y a encore quelque mois, jamais je n’aurais proposé cette approche. Dans ces moments là je mesure la transformation de mon état d’esprit à travers les vidéos et les forums SL.
Nous avons un peu de MCO à faire et je vais proposer une itération avec deux tickets au lieu de 10 à 15 d’habitude.
J’ai hâte de voir les impacts sur l’équipe et sur le métier. c’est motivant de passer de la théorie à la pratique.
2 « J'aime »
L’idée de la phrase n’est pas de challenger la durée (du sprint, du développement, ou autre ) mais bien de se lancer sur les hypothèses et arriver à avoir un retour avant que ça ne fasse mal de jeter le travail qui n’atteint pas un feedback validant
1 « J'aime »
ça serait légal de dire « si ça ne servait à rien, on le retient de votre paye » ? 
Si on souhaite que les personnes ne prennent plus d’initiatives, pourquoi pas 
« Vous pouvez avoir ça dans deux semaines et le reste plus tard ou vous pouvez avoir rien dans deux semaines et le reste plus tard. Que préférez-vous ? ».
2 « J'aime »
« Leave us the f*** alone »
Je tente quelque chose à chaud : « si tu n’as pas produit de valeur en 1 semaine, qu’est-ce qui me prouve que tu en sera capable avec plus de temps ? »
Avec le lean, on apprend quelque petite chose importante sur le juste à temps et la qualité. En particulier, la notion du pièce à pièce, du kanban.
Et j’aime bien démarrer avec une équipe en leur disant : Un sprint Scrum c’est 1 semaine sauf si vous m’expliquez pourquoi nous avons besoin de plus de temps..
En général, on m’explique que c’est impossible, que l’on a des problèmes à résoudre pour y arriver. Et alors, je répond : Pourquoi attendre plus d’une semaine pour les voir (transparence), les analyser (inspection) et essayer de les résoudre (adaptation) ?
Je vous invite à faire le test avec vos équipes.
1 « J'aime »
Je pense que c’est surtout symptomatique du fait que Scrum est trop souvent pensé comme un outil de production et pas comme un outil d’organisation du Kaizen. Rien n’a jamais empêché personne d’avoir pour Sprint Goal : « Améliorer notre process pour comprendre pourquoi et comment faire tenir un sprint en une semaine ».
3 « J'aime »
A mon sens, le problème est particulièrement lié à la manière dont le scrum guide décrit le planning :
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.
Cela renforce chez beaucoup de monde l’idée qu’un PBI c’est plus petit qu’un sprint, et qu’un sprint « normal » doit livrer plusieurs PBI. Donc le PO doit se taper le découpage des fonctionnalités en morceaux assez petits. Comme on travaille sur plein de PBI différents et indépendants, il est difficile de structurer cette activité autour d’un Sprint Goal. Cela encourage une organisation dans laquelle on travaille chacun dans son coin sur « ses » éléments. Et donc les mêlées quotidiennes deviennent des points de synchronisation.
Alors qu’au contraire, Scrum c’est fait pour tacler des PBI de 500 jours, en s’obligeant à faire des petits incréments, au départ sur des fonctions implémentées de manière prototypiques, puis plus matures au fur et à mesure qu’on obtient un meilleur feedback.
Et ma petite phrase pour ça : « scrum c’est fait pour jouer au rugby, pas se faire un parcours de golf »
J’ai du mal à voir quel point, si pris de façon littérale, amène à cette conclusion. Je vois très bien le phénomène que tu décris, mais pour moi il ne découle absolument pas du SG qui est plutôt clair de ce côté.
1 « J'aime »
Alors c’est justement pas une lecture littérale qui amène à ça.
C’est l’interprétation, avec les biais de ceux qui ont déjà fait du waterfall.
C’est même « parfaitement mathématique » :
- Un sprint fait en moyenne 50 jours ;
- Un sprint contient en moyenne une dizaine de PBI ;
- Donc, un PBI fait en moyenne 5 jours.
« Bah sinon comment tu fais rentrer 10 PBI de 500 jours dans un sprint de 50 ? »
Car dans un contexte waterfall, un travail « fini » c’est qu’on a couvert 100% des exigences.
D’ailleurs c’est souvent le premier item d’une DOD dans des équipes qui basculent vers Scrum.