Das Agile Manifest begrüßt in der Tat späte Änderungen, siehe Punkt 4:

Antworten auf Änderungen nach einem Plan

Und der Scrum-Leitfaden enthält dies :

Während des Sprints:

Es werden keine Änderungen vorgenommen, die das Sprintziel gefährden würden. ;

Qualitätsziele nicht abnehmen; und

Der Umfang kann zwischen dem Product Owner und dem Entwicklungsteam geklärt und neu ausgehandelt werden, wenn mehr gelernt wird. .

Die Sache für Sie sind der Meinung, dass Ihr Team eine Geschwindigkeit hat und Sie basierend darauf Geschichten in den Sprint aufgenommen haben.

Jetzt müssen Sie die Bestellung veranlassen, die Priorität innerhalb des Rückstands dieser Geschichte festzulegen. Wenn es über einer aktuellen Geschichte (oder Geschichten) liegt, schätzen Sie es und verschieben die niedrigsten Geschichten wieder heraus, bis Sie Ihre Geschwindigkeit wieder ausgeglichen haben. Wenn die Geschichte im aktuellen Sprint unter irgendetwas liegt, ist sie per Definition weniger wichtig, sodass sie warten muss. Wenn die Geschichte am Ende des Sprints ist und nicht genügend Zeit dafür vorhanden ist, starten Sie sie und gehen Sie zum nächsten Sprint über.

Es ist (absichtlich) so einfach, entweder ist es wichtiger und Sie priorisieren es gegenüber der vorhandenen Arbeit oder nicht. Wenn die Bestellung es auch will, erinnern Sie sie daran, dass Geschwindigkeit eine Metrik dessen ist, was Sie tun können, kein Ziel , wenn sie es laden wollen, können sie es, aber Sie werden es nicht erreichen.

Eine andere Sache ist, ein Sprint-Ziel mit der Bestellung / dem Unternehmen gemäß dem Leitfaden zu vereinbaren. Wenn etwas hereinkommt, vergleichen Sie es auch damit (Hilft uns diese Geschichte, das Ziel zu erreichen?). Wenn nicht, muss es vorrangig über die von Ihnen geleistete Arbeit angerufen werden. Ein dringender Fehler kann also Priorität haben, aber etwas anderes wird herabgestuft, da er nicht zum Erreichen des Ziels gehört, oder Sie geben den Sprint für die Arbeit mit höherer Priorität auf.

Ich stimme allen obigen Aussagen über Agile zu, die Flexibilität und Veränderung ermöglichen.

Aber (sehr groß, aber!) Ich habe mit POs gearbeitet, die während des Scrum-Sprints häufig gegen Feuer kämpfen. In diesem Fall kann es sehr ablenkend und / oder demoralisierend sein, wenn sich das Team ständig an diese Änderungen anpassen muss. Diese kontinuierliche Änderung der Prioritäten kann sich auch ernsthaft auf Veröffentlichungen auswirken und hat daher negative Auswirkungen auf den ROI!

In diesen Fällen war ich Teil von Teams, in denen die Entscheidung getroffen wurde, Scrum und Scrum zu streichen experimentiere mit Kanban. Letzteres bietet mehr Flexibilität bei der Definition von Anforderungen als Scrum. Kanban eignet sich auch besser für die kontinuierliche Lieferung als für reguläre Veröffentlichungen.

Weitere Informationen finden Sie unter zwei Gesichtspunkten unter folgenden Links:

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

http://kanbantool.com/kanban-library/scrum-and-kanban/kanban -vs-scrum-wie-man-das-Beste-aus-beidem macht

Zum Schluss ein Zitat aus der letzten Referenz

. Stoppen Sie niemals die Rückschau, um aus Ihren Erfahrungen zu lernen und weiter zu experimentieren, da Sie nie wissen, welche mögliche Lösung sich als die beste für Sie herausstellen könnte.

Als jemand, der sowohl CTO als auch Produktleiter bei verschiedenen Organisationen war, stimme ich @The Wandering Dev Manager weitgehend zu, wollte aber mehr hinzufügen, als ein Kommentar zulässt.

Dies sollte nicht der Fall sein geschehen wie beschrieben. Ich sehe viele rote Fahnen sowohl in der Häufigkeit als auch in der Unmittelbarkeit von Anfragen. Ich schlage vor, ein ehrliches Gespräch mit dem Product Owner über den aktuellen Prozess und die Auswirkungen auf Ihre Arbeit zu führen. Ich würde auch anfangen, nach einem anderen Job zu suchen, da diese Situation möglicherweise nicht besser wird.

Wenn der Product Owner einfach schlecht in seinem Job ist, ist das tatsächlich gut - sie können besser werden oder ersetzt werden. Leider gibt es oft Situationen wie diese, weil der Product Owner tatsächlich ziemlich gut darin ist, was er tut, aber aufgrund des Drucks von oben in bestimmte Muster gezwungen wurde. Nicht jeder kann seinen CEO einladen, sie in jeder Schlacht zu feuern. In diesem Fall wird sich die Situation nicht verbessern.

Insgesamt sind Änderungen während eines Sprints in Ordnung - aber Sie sollten darauf vorbereitet sein. Ich stelle immer sicher, dass meine Produkt- und Technikteams Sprints mit genügend Punkten auffüllen, um "Hotfixes" und Fehler zu behandeln. Als ich ein Produkt bei einem Medienunternehmen betrieb, wussten meine Teams, dass sie für jeden Sprint eine festgelegte Anzahl von Punkten reservieren mussten - es tauchte immer etwas auf, da dies die Natur unseres Geschäfts war. Unser System hat funktioniert, weil wir immer planen konnten, dass ein Ereignis eintritt. Wenn ein prognostiziertes Ereignis irgendwie nicht eingetreten ist, kann die verbleibende Zeit für persönliche Projekte, die Haushaltsführung oder [nach Luft schnappen!] Weiter verwendet werden. Die Handhabung der Funktionen / Änderungen in letzter Minute lag immer im Ermessen des Produktmanagers und in Absprache mit dem Projektmanager und dem Tech-Manager für dieses Team. Wir haben immer darauf geachtet, dass auch die Moral des Teams eine Rolle spielt. Den Geschäftsbereichen wurde nie etwas anderes versprochen als ein "bester Versuch zu liefern".

Manchmal wird eine äußerst schlechte Geschäftsentscheidung getroffen - und niemand merkt dies, bis der Sprint begonnen hat. Dies ist viel passiert bei Startups, die ich rate. Der Umgang mit dieser Art von Situation ist ziemlich einfach: Sie haben ein All-Hands-Meeting, bei dem Sie erneut Punkte festlegen, Prioritäten setzen und neue Zeitpläne festlegen können. Der Sprint wird abgebrochen; Sie fangen bei Null an.

Ihre Geschäftsinteressenten verstehen möglicherweise nicht, dass eine ordnungsgemäße Planung aus vielen Gründen erforderlich ist. Es minimiert den Verwaltungsaufwand, ermöglicht den effizienteren Aufbau miteinander verbundener Systeme, ermöglicht Voraussicht und Planung bei der Gestaltung einer Lösung ... Es gibt eine lange Liste von Gründen, aber es gibt nur zwei Hauptprobleme Die Stakeholder und Product Owners müssen verstehen:

• Sie verschwenden mehr Zeit und Geld mit sofortigen Änderungen und Anforderungen. Diese Methode ist immer die am wenigsten effiziente.
• Mit diesem Workflow beeinträchtigen Sie die Teammoral und die Arbeitszufriedenheit der Mitarbeiter. Ihre Entwickler werden gestresst, verärgert und gehen schließlich.

Wenn der Kunde eine interne Organisation ist, bedeutet dies, dass die Abteilungsleiter diskutieren müssen. Wenn der Kunde ein externer Kunde ist, muss das Unternehmen entscheiden, ob die Geschäftsbeziehung fixierbar oder sogar gerechtfertigt ist.

Theoretisch stimme ich @The Wandering Dev Manager zu, aber ich denke, er / sie macht es der PO möglicherweise zu einfach, den Sprint zu ändern.

Es ist die Aufgabe der PO, sich einer Änderung zu widersetzen zum Sprint (nicht verhindern) von externen Einheiten (Kunden). Sofern keine kritische Situation vorliegt, sollte der Sprint als unveränderlich angesehen werden.

Auch der Sprintzyklus sollte kurz sein, damit alles Neue, das auftaucht, für den nächsten Sprint priorisiert werden kann, ohne den Kunden zu beeinträchtigen . Wenn Sie mehrere Monats-Sprints haben, sind Sie nicht wirklich agil. Das Ziel ist eine schnelle Abwicklung mit sichtbaren Veränderungen (2 bis 4 Wochen).

Ein Sprint kann sich jedoch ändern. Wenn dies der Fall ist, müssen die Kosten für die neuen Elemente berechnet und ein entsprechender Arbeitsaufwand aus dem Sprint gestrichen werden, um dies auszugleichen.

Was sollten Sie also dagegen tun? Nun, das hängt davon ab. Es ist die Aufgabe von PO, den Sprint aufrechtzuerhalten, macht er das? Lässt er angemessene Arbeit fallen, um dies zu kompensieren? Wenn nicht, sollte "The Scrum Master" ein Wort mit der Bestellung haben.

Folgendes verursacht Ihre Bestellung:

Ich habe eine der Aufgaben im Sprint ausgeführt. Ich habe Änderungen an meiner lokalen Codebasis vorgenommen. Ich bin noch nicht ganz fertig. Nachdem ich fertig und zufrieden bin, dass alles auf dem neuesten Stand ist, wird eine Codeüberprüfung durchgeführt, die Qualitätssicherung durchlaufen und dann in den gemeinsam genutzten Entwicklungscode integriert. Wenn es lange dauert, bis ich die Aufgabe starte und bereit bin, gibt es Änderungen im freigegebenen Entwicklungscode, die mit meiner Arbeit in Konflikt stehen und zusätzliche Arbeit und Risiken verursachen.

Ihre Bestellung würde mich veranlassen, meine Arbeit zu unterbrechen und mit etwas anderem fortzufahren, wenn er bekommt, was er will. Einige Zeit später kehre ich zur ersten Aufgabe zurück. Zu diesem Zeitpunkt habe ich die Hälfte vergessen, daher brauche ich Zeit, um erneut zu beginnen. Dinge, die in meinem Kopf getan werden mussten, werden fallen gelassen. Qualität sinkt. Bis ich fertig bin, gibt es viel mehr Änderungen am freigegebenen Code, viel mehr Konflikte, mehr Zeitverschwendung.

Gleichzeitig zerstört es jede Motivation völlig. Eine Aufgabe zu starten und auf halbem Weg zu erfahren, dass sie nicht erwünscht ist, ist total demotivierend. Und Demotivierung erhöht nicht gerade die Produktivität. Warum sollten Sie sich um die nächste Aufgabe bemühen, wenn Sie erwarten, dass sie auch ausgeführt wird?

Ich wäre nicht überrascht, wenn so etwas, das regelmäßig passiert, die Produktivität eines Teams halbieren würde . Mit anderen Worten, das neue Material, das in den Sprint eingefügt wurde, wird nicht schneller fertig als wenn die Bestellung geduldig gewesen wäre, während das ursprüngliche Material massiv verzögert ist. Anstelle von zwei Wochen für die Originalartikel und zwei Wochen für die neuen Artikel dauert es eine Woche, um die Originalartikel zu starten, drei Wochen für die neuen Artikel und zwei Wochen, um die Originalartikel fertigzustellen. Anstelle von vier Wochen + einem glücklichen Team dauert es sechs Wochen + ergibt ein unglückliches, demotiviertes Team.

Was Ihre Bestellung tut, kann völlig legitim sein. Ich nehme an, Sie sind in einem kommerziellen Geschäft und das Geld Ihrer Kunden wird Ihr Gehalt bezahlen. Es gibt Zeiten, in denen Ihre Geschäftsleute "OK, totale Planänderung" sagen und Sie dies akzeptieren sollten.

Andererseits liegt es in Ihrer Verantwortung gegenüber den Eigentümern des Unternehmens, ein Qualitätsprodukt zu einem nachhaltigen Preis zu liefern und Ihre Architektur nicht zu zerstören, da jede Woche jemand eine neue Idee hat.

• Wenn die Storys mit hoher Priorität klein sind und in das Produkt passen, sollten Sie Ihren Fehler -Prozess für sie verwenden, auch wenn es sich um neue Storys handelt. (Ich denke, Sie haben einen definierten Prozess, um Hotfixes in den aktuellen Sprint zu integrieren.)
• Wenn sich die Priorität erheblich ändert, schlagen Sie der Bestellung vor, den aktuellen Sprint abzubrechen . Geben Sie alle unvollendeten Geschichten in den Rückstand zurück. Erinnern Sie die Bestellung daran, dass alle Arbeiten, die Sie bereits an unvollendeten Storys ausgeführt haben, möglicherweise verschwendet werden, wenn Sie die Arbeit nicht neu starten und bald zusammenführen können.

In solchen Situationen ist es wichtig, einen Prozess zum Erwarten des Unerwarteten zu haben. Beispielsweise ist eine Richtlinie, bei der eine Story gegen eine andere Story derselben Größe ausgetauscht wird, ein guter Weg, um das Gleichgewicht aufrechtzuerhalten:

Im Scrum-Prozess wird Scope Creep verwendet tritt auf, wenn der Product Owner oder ein anderes Mitglied des Scrum-Teams zusätzliche Arbeit (z. B. „Vergoldung“ oder Einschleichen in technische Schulden) in den Sprint einbringt, ohne dies mit dem Team zu besprechen. Das gesamte Team sollte immer verhandeln, eine User Story aus dem Product Backlog zu entfernen und in das aktuelle Sprint Backlog aufzunehmen. Wenn das Team jedoch alle Arbeiten abgeschlossen hat, für die es sich im aktuellen Sprint engagiert hat, und ein Entwickler einem anderen oder Tester auf keinen Fall helfen kann, kann er das Problem beim nächsten täglichen Stand-up ansprechen und die Einbringung neuer Aufgaben anfordern Arbeit.

Darüber hinaus hilft das Teilen von Kundenfeedback und Metriken innerhalb des Teams zu klären, ob eine Änderung am Produkt selbst, an den Nachrichten oder an der Analyse der Daten erforderlich ist oder nicht . Eine Roadmap zu haben und diese einzuhalten, ist der Schlüssel, aber dies funktioniert nur, wenn jeder den Plan kennt und Änderungen daran bidirektional sind:

Wir können Aufgaben im vierteljährlichen Plan hinzufügen oder ändern, aber Dies spiegelt sich in einem Scope Creep und einer expliziten Änderung des Plans wider.

Referenzen

• GSA Technische Leitfäden: Durchführen einer Sprint-Planung

• Von der Straßenkartierung über die Planung bis hin zu JIRA und Sprints