05 Quiz: Scrum Grundlagen

Der Product Owner besitzt das Product Backlog und ist die einzige Stimme für die Priorisierung. Er entscheidet, WAS gebaut wird und in welcher Reihenfolge. Wenn ein neues Feature wirklich dringend ist, könnte der PO mit dem Team verhandeln, es gegen bestehende Sprint-Arbeit auszutauschen, aber diese Entscheidung gehört dem PO - nicht dem SM (der den Prozess handhabt) oder dem Team (das entscheidet, WIE gebaut wird).

Das Beseitigen von Impediments ist eine Kernverantwortung des Scrum Masters. Wenn das Team durch etwas außerhalb ihrer Kontrolle blockiert ist (wie IT-Zugang, Bürokratie oder organisatorische Probleme), eskaliert und löst der SM es. Der SM agiert als “Servant-Leader”, der das Team vor Ablenkungen schützt und Hindernisse beseitigt, damit sie sich auf die Lieferung konzentrieren können.

Das Development Team entscheidet, WIE Dinge gebaut werden. Technische Entscheidungen wie Frameworks, Architektur und Implementierungsdetails gehören den Leuten, die die Arbeit machen. Der PO entscheidet, WAS gebaut wird (Features, Prioritäten), aber nicht WIE. Der SM moderiert, aber trifft keine Entscheidungen für das Team.

Der Product Owner akzeptiert oder lehnt abgeschlossene Arbeit ab, basierend darauf, ob sie die Definition of Done und die Akzeptanzkriterien erfüllt. Während Stakeholder-Feedback wertvoll ist (und beim Sprint Review gesammelt wird), ist der PO der einzige Entscheidungsträger, um widersprüchliche Anweisungen zu vermeiden. Wenn Stakeholder nicht einverstanden sind, verhandeln sie mit dem PO, nicht direkt mit dem Team.

In Scrum wird Arbeit von Teammitgliedern GEZOGEN, nicht von irgendjemandem ZUGEWIESEN. Das Development Team organisiert sich selbst, um zu entscheiden, wer an was arbeitet. Die Rolle des PO ist es, das Backlog zu priorisieren (WAS), nicht das Team zu managen (WIE/WER). Auch der Scrum Master weist keine Aufgaben zu - er beseitigt Impediments und coacht das Team in Scrum-Praktiken.

Der Scrum Master ist KEIN Manager. Die Verwendung von Aufgabenzahlen für Leistungsbeurteilungen schafft individuellen Wettbewerb, der der Teamzusammenarbeit schadet. In Scrum ist das Team als Ganzes erfolgreich oder scheitert - es gibt kein “meine Aufgaben” vs “deine Aufgaben.” Der SM moderiert den Prozess und beseitigt Impediments; er managt keine Leute und bewertet keine Leistung.

Während kleine Teams manchmal aus Notwendigkeit Rollen kombinieren, schafft es Spannungen, wenn eine Person sowohl PO als auch Developer ist. Als PO möchtest du vielleicht Feature X zuerst; als Developer würdest du vielleicht lieber an Feature Y arbeiten, weil es technisch interessanter ist. Die Trennung existiert, um Objektivität bei der Priorisierung zu wahren. Wenn du Rollen kombinieren musst, sei dir dieses Konflikts bewusst.

8 Elemente in Bearbeitung zu haben mit keinem fertig zur Halbzeit ist ein klassisches “zu viel WIP”-Problem. Wenn Leute an zu vielen Dingen gleichzeitig arbeiten, schadet Kontext-Wechsel der Produktivität und nichts wird fertig. Ein gesundes Muster ist: weniger Dinge anfangen, beenden was du angefangen hast, dann mehr Arbeit ziehen. Das Board sollte von links nach rechts fließen, sich nicht in der Mitte anstauen.

Ein stagniertes Board zeigt normalerweise versteckte Probleme an. Wenn sich in 3 Tagen nichts bewegt hat, sind Aufgaben entweder blockiert (und niemand eskaliert), schlecht definiert (und Leute drehen sich im Kreis), oder das Team aktualisiert das Board nicht. Das Daily Scrum sollte diese Probleme aufdecken - “Ich stecke bei X fest wegen Y” - damit der SM helfen kann, sie zu lösen.

Das Development Team besitzt das Sprint Backlog und entscheidet, wie die Arbeit ausgeführt wird. Der PO hat Prioritäten während des Sprint Planning gesetzt; während des Sprints sollte er das Board nicht mikromanagen. Wenn der PO über den Fortschritt besorgt ist, sollte er es beim Daily Scrum oder mit dem SM ansprechen, nicht direkt Karten verschieben oder Arbeit zuweisen.

Das Board ist ein “Informationsstrahler” - es macht Arbeit für alle sichtbar, ohne fragen zu müssen. Ohne es verlässt du dich auf jedermanns Gedächtnis und Annahmen, die mit der Zeit auseinanderdriften. “Ich dachte, du wärst damit fertig!” und “Ich wusste nicht, dass du blockiert bist!” werden häufig. Das Board ermöglicht Transparenz, eine der drei Säulen von Scrum (neben Inspektion und Anpassung).

Barry Boehms Forschung zeigte, dass die Kosten zur Behebung eines Defekts exponentiell steigen, wenn man durch die Entwicklungsphasen geht. Ein Requirements-Fehler, der während der Requirements-Phase gefunden wird, kostet 1x zu beheben; derselbe Fehler in der Produktion gefunden kostet 30-100x mehr. Die sequentiellen Phasen des V-Modells bedeuten, dass Probleme erst spät entdeckt werden, wenn sie am teuersten sind.

Dies verbindet sich mit Herbert Simons “begrenzte Rationalität” - Menschen können komplexe Systeme nicht vollständig vorhersagen. Benutzer wissen oft nicht, was sie brauchen, bis sie mit einem funktionierenden Prototyp interagieren. Das klassische Beispiel: “Ich sagte, ich wollte X, aber jetzt wo ich es sehe, erkenne ich, dass ich eigentlich Y brauche.” Agile umarmt dies, indem früh funktionierende Software geliefert und basierend auf Feedback iteriert wird.

In einem sequentiellen Prozess kaskadiert eine Requirements-Änderung durch alle nachgelagerten Artefakte. Die Spezifikation muss sich ändern, was das Design ungültig macht, was Code-Änderungen erfordert, was neue Tests erfordert. Die Dokumentation jeder Phase muss überarbeitet werden. Agile minimiert dies, indem in kurzen Zyklen gearbeitet wird, wo “Änderung” nur das Repriorisieren des Backlogs ist - nicht das Neuschreiben von Monaten an Dokumentation.

Regulierte Branchen (Medizin, Luftfahrt, Automobil-Sicherheit) erfordern oft umfangreiche Dokumentation für die Zertifizierung. Die explizite Phasen-zu-Test-Zuordnung des V-Modells bietet die Nachverfolgbarkeit, die Auditoren brauchen. Allerdings übernehmen auch diese Branchen agile Praktiken innerhalb regulatorischer Beschränkungen - das US-Army-Beispiel zeigt, dass “reguliert” nicht “muss Wasserfall verwenden” bedeutet.

Sprint Planning produziert: (1) Das Sprint Backlog - die aus dem Product Backlog ausgewählten Elemente plus einen Plan für ihre Lieferung, und (2) Das Sprint Goal - eine kurze Aussage darüber, was der Sprint erreichen soll. Das Sprint Goal bietet Fokus und Flexibilität: wenn bestimmte Elemente nicht abgeschlossen werden können, könnte das Ziel trotzdem durch alternative Ansätze erreicht werden.

Das Daily Scrum ist für das Development Team, um sich untereinander zu synchronisieren - nicht um jemandem zu berichten. Die klassischen drei Fragen (Was habe ich getan? Was werde ich tun? Was blockiert mich?) helfen zu identifizieren, wer Hilfe braucht, was feststeckt und wie koordiniert werden kann. Es ist kein Status-Report-Meeting - es ist ein Planungsmeeting für die nächsten 24 Stunden.

Das Sprint Review untersucht das Produkt - das Team demonstriert, was abgeschlossen wurde, Stakeholder geben Feedback, und das Product Backlog kann basierend auf Erkenntnissen aktualisiert werden. Die Sprint Retrospective untersucht den Prozess - was gut funktioniert hat, was nicht, und was im nächsten Sprint verbessert werden soll. Beide sind essenziell, haben aber unterschiedliche Fokuspunkte.

Nur der Product Owner kann einen Sprint abbrechen, und nur wenn das Sprint Goal obsolet wird (z.B. das Unternehmen pivotiert, der Markt ändert sich dramatisch). Sprint-Abbrüche sind selten und störend. Hinweis: unvollständige Arbeit ist KEIN Grund zum Abbruch - sie kehrt einfach zum Backlog zurück. Der Sprint endet trotzdem pünktlich, und das Team reflektiert, warum Arbeit nicht abgeschlossen wurde.

Retrospektiven sollten konkrete, umsetzbare Verbesserungen produzieren. “Wir werden versuchen, Reviews zu pairen, um sie schneller zu machen” oder “Wir werden ein Review-SLA von 4 Stunden hinzufügen” sind gute Action Items. Das Team besitzt seinen Prozess und experimentiert mit Änderungen. Qualitätspraktiken zu überspringen schafft technische Schulden; an das Management zu eskalieren nimmt dem Team das Eigentum. Der SM ordnet keine Lösungen an - er moderiert, dass das Team seine eigenen findet.