Le Manifeste Agile accueille en effet les changements tardifs, voir le point 4:

Répondre au changement en suivant un plan

Et le guide Scrum a ceci :

Pendant le Sprint:

Aucune modification n'est apportée qui mettrait en danger l'objectif du Sprint ;

Les objectifs de qualité pas diminuer; et,

La portée peut être clarifiée et renégociée entre le Product Owner et l'équipe de développement au fur et à mesure que nous en apprendrons plus .

La chose pour c'est que votre équipe a une vélocité et que vous avez accepté des histoires dans le sprint en fonction de cela.

Ce que vous devez maintenant faire est que le bon de commande définisse la priorité dans le backlog de cette histoire. S'il se trouve au-dessus d'une histoire (ou d'histoires) en cours, vous l'estimez et déplacez les histoires les plus basses jusqu'à ce que vous équilibriez votre vitesse. Si l'histoire est en dessous de quoi que ce soit dans le sprint actuel, alors par définition, elle est moins importante et devra donc attendre. Si l'histoire est à la fin du sprint et qu'il n'y a pas assez de temps pour le faire, démarrez-la et passez au sprint suivant.

C'est (intentionnellement) aussi simple, soit c'est plus important et vous donnez la priorité au travail existant, ou ce n'est pas le cas. Si le bon de commande le souhaite également, rappelez-lui que la vélocité est une métrique de ce que vous pouvez faire, et non un objectif , si elle souhaite la charger, elle le peut, mais vous n'y arriverez pas.

Une autre chose est de convenir d'un objectif de sprint avec le bon de commande / l'entreprise conformément au guide. Si quelque chose arrive, vous le comparez également à cela (cette histoire nous aide-t-elle à atteindre l'objectif?), Sinon, elle nécessite un appel prioritaire sur le travail que vous faites. Donc, un bug urgent peut être prioritaire, mais quelque chose d'autre est rétrogradé car cela ne fait pas partie de l'objectif, ou peut-être que vous abandonnez le Sprint pour le travail plus prioritaire.

Je suis d'accord avec toutes les déclarations ci-dessus sur l'Agile permettant la flexibilité et le changement.

Mais (très gros mais!) J'ai travaillé avec des OP qui combattent souvent les incendies tout au long du sprint Scrum. Si cela se produit, cela peut être très distrayant et / ou démoralisant pour l'équipe de devoir constamment s'adapter à ces changements. Ce changement continu de priorités peut également affecter sérieusement les versions, et en conséquence il aura un effet négatif sur le retour sur investissement!

Dans ces cas, j'ai fait partie d'équipes où la décision a été prise d'abandonner Scrum et expérimentez avec Kanban. Ce dernier offre une flexibilité dans la définition des exigences bien plus que Scrum. Kanban est également plus adapté à la livraison continue que aux versions régulières.

Pour plus d'informations, à partir de deux perspectives, consultez ces liens:

https: // www. scrumalliance.org/community/articles/2014/july/scrum-vs-kanban

http://kanbantool.com/kanban-library/scrum-and-kanban/kanban -vs-scrum-how-to-use-the-most-of-both

Enfin, en prenant une citation de la dernière référence

.. .ne jamais arrêter la rétrospective, afin de tirer les leçons de votre expérience et de continuer à expérimenter, car vous ne savez jamais quelle solution possible pourrait s'avérer la meilleure pour vous.

En tant que personne qui a été à la fois CTO et Head of Product dans différentes organisations, je suis largement d'accord avec @The Wandering Dev Manager mais je voulais ajouter plus qu'un commentaire ne le permettrait.

Cela ne devrait pas se passe comme décrit. Je vois beaucoup de signaux d'alarme dans la fréquence et l'immédiateté des demandes. Je suggère d'avoir une discussion honnête avec le Product Owner sur son processus actuel et comment il affecte votre travail. Je commencerais aussi à chercher un autre emploi, car la situation ne s’améliorera peut-être pas.

Si le Product Owner est simplement mauvais dans son travail, c'est vraiment bien - il peut s'améliorer ou être remplacé. Malheureusement, de nombreuses situations comme celle-ci existent parce que le Product Owner est en fait assez bon dans ce qu'il fait, mais a été contraint de suivre certains schémas en raison de la pression d'en haut. Tout le monde ne peut pas inviter son PDG à les renvoyer à chaque bataille. Lorsque c'est le cas, la situation ne s'améliorera pas.

Dans l'ensemble, les changements pendant un sprint sont bien - mais vous devez vous y préparer. Je m'assure toujours que mes équipes produit et technique remplissent les sprints avec suffisamment de points pour gérer les «correctifs» et les bogues. Lorsque je dirigeais un produit dans une entreprise de médias, mes équipes savaient qu'il fallait réserver un certain nombre de points à chaque sprint - quelque chose revenait toujours, car c'était la nature de notre entreprise. Notre système fonctionnait, car nous pouvions toujours planifier une sorte d'événement. Si un événement prévu d'une manière ou d'une autre ne se produisait pas, alors le temps restant pourrait être utilisé pour des projets personnels, des tâches ménagères ou [gasp!] Pour avancer. La gestion des fonctionnalités / modifications de dernière minute était toujours à la discrétion du chef de produit, et en consultation avec le chef de projet et le directeur technique de cette équipe. Nous nous sommes toujours assurés que le moral de l'équipe était également un facteur. Rien n'a jamais été promis aux unités commerciales autre qu'une "meilleure tentative de livraison".

Parfois, une très mauvaise décision commerciale est prise - et personne ne s'en rend compte tant que le sprint n'a pas commencé. Cela s'est souvent produit avec les startups que je conseille. Gérer ce type de situation est assez simple - vous avez une réunion à tous les participants pour re-pointer, redéfinir les priorités et reprogrammer. Le sprint est interrompu; vous partez de zéro.

Les parties prenantes de votre entreprise peuvent ne pas comprendre qu'une planification appropriée est nécessaire pour de nombreuses raisons. Il minimise les frais administratifs, il permet de construire des systèmes interconnectés de manière plus efficace, il permet de prévoir et de planifier la façon dont une solution est conçue ... Il y a une longue liste de raisons, mais il n'y a que 2 principaux points à retenir. les parties prenantes et les propriétaires de produits doivent comprendre:

• Vous perdez plus de temps et d'argent avec des changements et des demandes immédiats. Cette méthode est toujours la moins efficace.
• Vous blessez le moral de l'équipe et la satisfaction professionnelle des employés avec ce flux de travail. Vos développeurs deviendront stressés, en colère et finiront par partir.

Lorsque le client est une organisation interne, cela signifie que les chefs de service doivent discuter. Si le client est un client externe, l'entreprise doit décider si la relation commerciale est réparable ou même justifiée.

En théorie, je suis d'accord avec @The Wandering Dev Manager mais je pense qu'il / elle rend potentiellement trop facile pour le PO de changer le sprint.

C'est le travail du PO de résister au changement au sprint (ne pas l'empêcher) d'entités externes (clients). À moins qu'il n'y ait une situation critique, le sprint doit être considéré comme immuable.

De plus, le cycle de sprint est censé être court afin que tout ce qui arrive puisse être priorisé dans le prochain sprint sans affecter le client . Si vous avez des sprints de plusieurs mois, vous n'êtes pas vraiment agile. L'objectif est une rotation rapide avec quelques changements visibles (2-4 semaines).

Mais un sprint peut changer. Si c'est le cas, le coût des nouveaux éléments Doit être calculé et une quantité de travail équivalente supprimée du sprint pour compenser.

Alors, que devez-vous faire à ce sujet? Eh bien cela dépend. C'est le travail de PO de maintenir le sprint est-ce qu'il le fait? Abandonne-t-il un travail approprié pour compenser? Sinon, "The Scrum Master" devrait avoir un mot avec le PO.

Voici ce que votre bon de commande provoque:

J'ai fait l'une des tâches du sprint. J'ai apporté des modifications à ma base de code locale. Je n'ai pas tout à fait fini. Une fois que j'ai terminé et que je suis convaincu que tout est à la hauteur, cela passe à une révision du code, il passe par le contrôle qualité, puis il est intégré dans le code de développement partagé. S'il faut beaucoup de temps entre le début de la tâche et la préparation, il y aura des changements dans le code de développement partagé qui entreront en conflit avec mon travail, ce qui créera du travail supplémentaire et des risques.

Votre PO, s'il obtient ce qu'il veut, me ferait interrompre mon travail et continuer sur autre chose. Quelque temps plus tard, je reviens à la première tâche. À ce moment-là, j'en ai oublié la moitié, il me faut donc du temps pour recommencer. Les choses qui étaient dans mon esprit qui devaient être faites sont abandonnées. Baisse de qualité. Au moment où j'ai terminé, il y a beaucoup plus de changements dans le code partagé, beaucoup plus de conflits, plus de temps perdu.

En même temps, cela détruit totalement toute motivation. Commencer une tâche et se faire dire à mi-chemin qu'elle n'est pas souhaitée est totalement démotivant. Et être démotivé n'augmente pas exactement la productivité. Pourquoi devriez-vous faire des efforts dans la tâche suivante alors que vous vous attendez à ce qu'elle soit également tirée?

Je ne serais pas surpris si ce genre de chose, qui se passe régulièrement, réduirait de moitié la productivité d'une équipe . En d'autres termes, le nouveau truc qui a été inséré dans le sprint ne sera pas terminé plus rapidement que si le PO avait été patient, tandis que le truc original est massivement retardé. Au lieu de deux semaines pour les éléments d'origine et de deux semaines pour les nouveaux éléments, il faut une semaine pour démarrer les éléments d'origine, trois semaines pour les nouveaux éléments, deux semaines pour terminer les éléments d'origine. Au lieu de quatre semaines + une équipe heureuse, cela prend six semaines + produit une équipe malheureuse et démotivée.

Ce que fait votre bon de commande peut être entièrement légitime. Je présume que vous êtes dans une entreprise commerciale et que l'argent de vos clients va payer votre salaire. Il y a des moments où vos gens d'affaires disent «OK, changement total de plan» et quand vous devriez l'accepter.

D'un autre côté, il est de votre responsabilité envers les propriétaires de l'entreprise de livrer un produit de qualité à un rythme durable, de ne pas ruiner votre architecture parce que quelqu'un a une nouvelle idée chaque semaine.

• Si les histoires à haute priorité sont petites et s'intègrent dans le produit, envisagez d'utiliser votre processus de bogue pour elles, même s'il s'agit de nouvelles histoires. (Je suppose que vous avez un processus défini pour obtenir des correctifs dans le sprint actuel.)
• S'il y a des changements majeurs dans la priorité, suggérez au PO de abandonner le sprint actuel . Remettez toutes les histoires inachevées dans l'arriéré. Rappelez au bon de commande que tout travail que vous avez déjà effectué sur des articles inachevés peut être gaspillé si vous ne pouvez pas redémarrer le travail et fusionner bientôt.

Dans des situations comme celle-ci, il est essentiel d'avoir un processus pour s'attendre à l'inattendu. Par exemple, une politique dans laquelle une histoire est échangée contre une autre histoire de la même taille est un bon moyen de maintenir l'équilibre:

Dans le processus Scrum, scope creep se produit lorsque le Product Owner, ou tout autre membre de l'équipe Scrum, apporte du travail supplémentaire (par exemple «plaquage or» ou se faufiler dans la dette technique) dans le sprint sans en discuter avec l'équipe. Toute l'équipe doit toujours négocier le retrait d'une user story du Product Backlog et son intégration dans le Sprint Backlog actuel. Cependant, si l'équipe a terminé tout le travail sur lequel elle s'est engagée dans le sprint actuel et qu'un développeur ne peut en aucun cas aider un autre ou un testeur, elle peut soulever le problème lors de la prochaine réunion quotidienne et demander à apporter de nouveaux

De plus, le partage des commentaires des clients et des mesures au sein de l'équipe permet de clarifier si un changement est nécessaire ou non dans le produit lui-même, la messagerie qui l'entoure ou l'analyse des données . Avoir une feuille de route et y adhérer est essentiel, mais cela ne fonctionne que si tout le monde connaît le plan et les modifications qui y sont apportées sont bidirectionnelles:

Nous pouvons ajouter ou modifier des tâches dans le plan trimestriel, mais cela se traduit par une dérive de la portée et une modification explicite du plan.

Références

• GSA Guides techniques: réalisation d'une planification de sprint

• De la cartographie routière à la planification en passant par JIRA et les sprints