Pour documenter la discussion qui a eu lieu et pouvoir y revenir si besoin (« attends, pourquoi on avait mis ça déjà ? »)
Pour faciliter l’onboarding de nouveaux qui n’ont pas intégré la DoR, ou la communication avec des stakeholders ou d’autres équipes
Pour moi, une bonne DoR, au bout de quelques sprints tout le monde en a oublié les termes, mais tout le monde en a intégré l’esprit.
Si un an plus tard l’équipe est toujours à vérifier religieusement point par point que la story est « ready », y a un souci, et la DoR n’en est pas la solution.
En fait on se parle, on juge que c’est prêt parce qu’on se parle, que l’on se fait confiance.
J’ai eu un cas où un PBI semblait clair pour tout le monde, les critères d’acceptation apparemment clairs et discutés. Au final, les développeurs avaient mal jugés la difficulté technique, une refonte technique a du être faite et le PBI devant être réalisé en 1 sprint, l’a été en 2.
Bon ben tant pis. Et une DoR aurait rien changé. L’erreur ? Pas d’affinage du besoin, juste une estimation en sprint planning.
Le sujet était important en terme de valeur, tout le monde a accepté l’erreur et au final on est très content du résultat
Et j’irais plus loin: Tout Scrum est résumable à ça. Une équipe qui collabore de façon mature, communique avec toutes les parties prenante efficacement et qui comprends la nature de pourquoi elle fait les choses n’a pas besoin de Scrum. Scrum est il un anti-pattern pour autant ?
Mais juste que l’on n’a pas de liste : c’est dans nos pratiques et nos refinements servent à ça puisque sont exposés les sujets faisant lien avec l’objectif cible du prochain sprint, que l’on réduit la feature en plus petite US possible, que les tests sont revus et que l’on s’assure que les US sont réalisables dans le sprint ou sont à reprioriser selon la taille de ces US.
Nope, ça c’est un anti-pattern, et ça s’appelle des spécifications détaillés, qui ne sont pas la même chose que des ‹ enabling specifications › (pas d’équivalence en français à ma connaissance)
2-231 Obtaining Patent Rights§ 2.07[6] « A patent specification is enabling if it allows a person of ordinary skill in the art to practice the invention without undue experimentation. »
En regardant les réponses, en fait on se rend compte rapidement d’un truc : beaucoup ici ont utilisé les DoR et il y a beaucoup de débats. Perso je me plains pas de l’outil, je me plains qu’il est tellement facile à utiliser pour du contrôle. Et généralement c’est même pas des DoR mais des SFD, 100% d’accord !
Un anti-pattern, c’est une façon de faire qui est constamment dommageable pour une équipe ou une organisation. Je remarque juste, et j’ai l’impression de ne pas être le seul, que le problème c’est pas la DoR mais la façon dont il est trop souvent mal utilisé. Ce n’est pas un anti-pattern, très loin de là car il peut être super comme principes à suivre, mais c’est un instrument à double tranchant, comme beaucoup d’outils !
Ce qui est intéressant avec la DoR, c’est qu’il n’y a vraiment pas de bonne façon de faire : vraiment, je ne pense juste pas que ce soit un pattern qu’il faille mettre partout.
J’ai juste vu trop d’équipes en abuser. Mais je l’ai déjà utilisé de manière réussie.
Histoire terrifiante : j’étais arrivé en tant que coach agile sur une mission, et la DoR faisait deux slides entières, et la réponse d’un des SMs ? « C’est la liste la plus petite que j’ai vu de ma carrière donc c’est déjà top ! » Voilà. Hahahahahahaaaaaa…
Au moins ce que ce thread m’a apporté : me remettre en question sur ma vision de la DoR. Peut-être que c’est juste une DoD du Discovery, finalement… ?
Merci beaucoup, c’est à ce genre de réponse que je m’attendais avec ma question
Cela dit, j’ai beaucoup aimé ces échanges, car ça soulève très bien les dangers à éviter lors de la rédaction de la DoR originale, mais aussi pendant son évolution par la suite. Merci beaucoup!
Si vous avez d’autres points du genre à ajouter à la liste, n’hésitez surtout pas!
Bravo, super discussion, à mon avis ceci est un bon résumé.
Je souhaite tout de même réagir concernant la proposition de @Samuel_Abiassi, avec une dimension de temporalité.
Contrainte / contexte
Une équipe autonome en collaboration. Ayant toutes les compétences en interne.
Avant le Sprint / Avant de commencer à travailler sur le sujet
Où le domaine de discussion est le problème.
Seulement ces 2 éléments peuvent être complétés :
The planned deliverable has value.
On estime que la résolution au problème apportera de la valeur. Une première version du plan de réalisation émerge au moment du Sprint Planning. Ce serait du gâchis de le faire avant.
J’observe qu’avec ces 2 éléments nous ne sommes pas si loin de la définition du Product Backlog.
Pendant le Sprint / Pendant le travailler sur le sujet
Ici nous sommes en dehors du rayon d’action de la DoR.
Où le domaine de discussion est la recherche d’une solution au problème.
The work is immediately actionable by the team.
It is testable, and theProduct Ownerhas specified tests for it.
Hello, les 3 amigos.
TheDevelopment Teamhas estimated it.
Question à poser à chaque Daily Scrum. L’élément peut-il être terminé-terminé avant la fin du Sprint ? Oui ou non.
Rappel
Tous les membres de la Scrum Team collaborent à toutes les étapes. Mettre ceci dans la DoR serait un rappel, pourquoi pas.
Euh… Non. Ça s’appelle de l’analyse du domaine, de l’analyse systémique, et c’est un des trucs qui manque souvent le plus à Scrum justement.
Ça ne ressemble pas à la définition du product backlog, et seulement très partiellement à celle du product backlog item. Je ne suis pas sur de comprendre d’où vient la remarque.
Quel est le rapport avec la DoR ? C’est du process intra-sprint effectivement, qui n’empêche pas de faire le boulot en amont.
De manière générale, je n’ai vraiment pas compris la teneur de ton message. Tu pourrais expliciter ? :0
J’ai vécu une expérience où ; estimé, s’aligner sur le comportement d’une solution, créer un plan de réalisation pour des sujets qui ne seront jamais réalisés.
Au fil des apprentissages, le plan de réalisation à subit un shit right. Nous le fesions, de plus en plus tard, au dernier moment responsable. Jusqu’à au moment même de démarrer la réalisation d’un sujet.
Dans cette expérience, il n’y avait pas de DoR explicite.
Mais surtout le contexte ne correspondait pas à celui que j’utilise.
Je n’ai pas connu d’expérience d’une équipe autonome en collaboration. J’espère avoir cette expérience un jour.
Je m’explique
Je prends une posture critique, à la limite du dogmatique mais sans l’etre, car je précise le contexte : pour une équipe autonome en collaboration.
Si l’équipe n’est pas autonome, alors le contenu du message est caduque.
Reformulation.
Contexte : pour une équipe autonome en collaboration.
Je pense que dans la DoR que tu partages la majorité des actions devrait être réalisé durant le Sprint.
À mon avis, avoir dans la DoR des éléments qui devrait être réalisé pendant le Sprint, c’est commencer le Sprint avant qu’il ne commence réellement.
Le focus de l’équipe, l’objectif de Sprint courant, est mis en danger, par la charge mentale supérieure causée par ce travail en amont sur des éléments dont le focus sera dans le futur ou même jamais.
Non, vu que c’est trop tard. Si tu commences ton boulot d’analyse pendant le sprint, je suis curieux du nombre de fois où tu vas annuler tes sprints parce que tu te rends compte que trop de choses ne collent pas en plein milieu de sprint. Tu suggères de faire l’analyse du domaine, des use-cases, du système et des process durant le sprint ? Good luck…
Oui, du coup on demande au PO de faire ce boulot en amont. Bien sûr, dans un monde idéal on aurait pas besoin de PO. Mais dans un monde idéal, on aurait pas non plus ni cette problématique, ni cette conversation.
Comment tu savais que c’était le « dernier moment responsable » ? Ou est-ce que c’était juste un sentiment subjectif ?
Nous avions observé qu’il n’y avait aucun problème additionnel de le faire à ce moment-là.
De plus, cela resolvait les problèmes précédemment rencontrés.
Willingness to share incomplete information has long been identified as a necessity for concurrency in design. This can perhaps be best understood in terms of the lean production practice of reducing batch sizes, which belongs with DSM as a technique for restructuring the design process. Sequential processing results in part from the implicit rule that only completed design work is advanced to others. In terms of the beam penetration case, suppose the design team members agreed up front on work sequence, which would start by Team Member A providing just that information needed for Team Member B to calculate what he needs. B would in turn release that information to C, allowing C to do work, etc.
The Lean Construction Institute recommends producing such a work sequence by having the team responsible for the work being planned to work backwards from a desired goal; i.e., by creating a ‹ pull schedule ›. Doing so avoids incorporation of customary but unnecessary work, and yields tasks defined in terms of what releases work and thus contributes to project completion. So doing reduces the waste of overproduction, one of the seven types of waste identified by Taiichi Ohno.
The Lean Design Group case described below (Set Based Design) is an excellent example of the benefits of implementing this strategy. Deferred commitment is a strategy for avoiding premature decisions and for generating greater value in design. It can reduce negative iteration by simply not initiating the iterative loop. A related but more extreme strategy is that of least commitment; i.e., to systematically defer decisions until the last responsible moment10; i.e., until the point at which failing to make the decision eliminates an alternative. Knowledge of the lead times required for realizing design alternatives is necessary in order to determine last responsible moments. Such knowledge now tends to be partial or lacking.
POSITIVE VS NEGATIVE ITERATION IN DESIGN Glenn Ballard
