Scrum und agiles Arbeiten lernen

Scrum ist kein Zaubertrick, sondern ein schlichtes Rahmenwerk, das in der Praxis überraschend schwer sauber umzusetzen ist. Wenn du Scrum und agiles Arbeiten lernen willst, musst du vor allem eines tun: die einfachen Regeln ernst nehmen und konsequent leben.

Scrum kurz und ehrlich: Was Scrum ist, und was nicht

Scrum ist ein leichtgewichtiges Rahmenwerk für komplexe Produktentwicklung. Es besteht aus:

• drei Rollen
• fünf Events
• drei Artefakten
• plus einigen klaren Regeln und Commitments

Wichtig ist, was Scrum nicht ist:

• kein detaillierter Projektplan
• keine Sammlung von Tools
• keine Garantie für „schneller und billiger“
• kein Synonym für „wir machen einfach alles spontan“

Scrum hilft dir, in kurzen Schleifen zu lernen, Risiken früh zu sehen und Wert für Nutzerinnen und Nutzer inkrementell zu liefern.

Rollen in Scrum: Wer macht was wirklich?

Die Rollen sind bewusst schlank gehalten. Wenn du Scrum lernen willst, ist ein klares Rollenverständnis der wichtigste Startpunkt.

Product Owner

Der Product Owner ist für den Wert des Produkts verantwortlich. Typische Aufgaben:

• Vision und Ziele des Produkts klären
• Product Backlog pflegen und priorisieren
• Stakeholder einbinden und Erwartungen managen
• Akzeptanzkriterien definieren und „Done“ prüfen

Missverständnis: „Der Product Owner schreibt nur Tickets.“ Realität: Er oder sie trifft inhaltliche Entscheidungen und verantwortet die Produktstrategie, auch wenn die Detailarbeit oft im Team passiert.

Scrum Master

Der Scrum Master sorgt dafür, dass Scrum verstanden und angewendet wird. Typische Aufgaben:

• Team und Organisation in Scrum coachen
• Hindernisse sichtbar machen und beim Entfernen unterstützen
• Scrum-Events vorbereiten und moderieren, wo nötig
• Schutz des Teams vor unnötigen Störungen

Missverständnis: „Scrum Master ist der Projektleiter.“ Realität: Es gibt keinen klassischen Projektleiter in Scrum. Der Scrum Master führt vor allem über Coaching und Moderation, nicht über Weisung.

Developers (Entwicklungsteam)

„Developers“ sind alle, die an der Erstellung des Produktinkrements arbeiten, nicht nur Programmierer. Also auch UX, QA, DevOps, Fachkonzept usw.

Verantwortung:

• Planung der Arbeit im Sprint
• Umsetzung von Anforderungen in ein fertiges Inkrement
• Qualität sicherstellen
• technische Schulden transparent machen

Missverständnis: „Jede Rolle ist nur für ihren Teil zuständig.“ Realität: Das Team ist gemeinsam für das Ergebnis verantwortlich. Spezialwissen ja, Silos nein.

Events: Der Takt von Scrum

Die fünf Scrum-Events geben dir einen klaren Rhythmus. Wenn du sie weglässt oder stark verwässerst, verlierst du schnell die Vorteile.

Sprint

Der Sprint ist der feste Zeitrahmen, typischerweise 1 bis 4 Wochen. Am Ende steht immer ein potenziell auslieferbares Produktinkrement.

Regeln:

• Dauer ist konstant, nicht nach Lust und Laune
• Ziel des Sprints ist klar formuliert (Sprint Goal)
• Während des Sprints werden keine neuen Ziele hineingedrückt

Sprint Planning

Ziel: Was wollen wir im kommenden Sprint erreichen und wie nähern wir uns dem?

• Teil 1: Warum ist der Sprint wertvoll, welches Sprint Goal setzen wir?
• Teil 2: Welche Backlog-Einträge brauchen wir, um das Ziel zu erreichen?
• Teil 3: Wie planen die Developers die Umsetzung in konkrete Aufgaben?

Praxis-Tipp: Lieber ein fokussiertes Sprint Goal als eine endlose Liste einzelner Tickets ohne roten Faden.

Daily Scrum

Tägliches, kurzes Meeting des Developer-Teams, typischerweise 15 Minuten.

Zweck:

• Fortschritt in Richtung Sprint Goal prüfen
• Plan für die nächsten 24 Stunden anpassen
• Hindernisse sichtbar machen

Kein Status-Report an den Chef, sondern ein Arbeitstreffen des Teams. Der Scrum Master ist nicht verpflichtet, dabei zu sein. Der Product Owner nur, wenn es sinnvoll ist.

Sprint Review

Am Ende des Sprints zeigt das Team das fertige Inkrement und sammelt Feedback von Stakeholdern.

Ziele:

• Produktstand transparent machen
• Feedback einholen
• Product Backlog anpassen

Wichtig: Es geht nicht um eine Folien-Show, sondern um das echte Produkt. Am besten direkt im System demonstrieren.

Sprint Retrospective

Das Team schaut auf die Zusammenarbeit und den Prozess, nicht auf das Produkt.

Typische Fragen:

• Was lief gut, was wollen wir beibehalten?
• Was hat uns gebremst, was wollen wir ändern?
• Welche 1 bis 3 konkreten Verbesserungen nehmen wir in den nächsten Sprint mit?

Kleine, kontinuierliche Verbesserungen sind realistischer als der große Rundumschlag.

Artefakte: Product Backlog, Sprint Backlog, Inkrement

Artefakte sind die Arbeitsgegenstände in Scrum. Sie sollen Transparenz schaffen und Entscheidungen erleichtern.

Product Backlog

Das Product Backlog ist die geordnete Liste aller bekannten Anforderungen an das Produkt.

Eigenschaften eines guten Backlogs (oft als DEEP bezeichnet):

• Detailed appropriately: Details nehmen zu, je näher ein Eintrag am Sprint ist
• Estimated: Aufwand grob eingeschätzt, z. B. mit Story Points
• Emergent: Das Backlog verändert sich laufend, neue Erkenntnisse kommen hinzu
• Prioritized (Ordered): Klar geordnet nach Wert, Risiko, Abhängigkeit

Typische Probleme:

• Backlog als „Müllhalde“ für jede Idee
• keine klare Ordnung
• keine regelmäßige Pflege (Refinement)

Sprint Backlog

Das Sprint Backlog entsteht im Sprint Planning und enthält:

• das Sprint Goal
• die ausgewählten Product-Backlog-Einträge
• den Plan der Developers, wie sie diese umsetzen

Wichtig: Das Sprint Backlog ist Eigentum der Developers. Niemand von außen verteilt Aufgaben.

Inkrement

Das Inkrement ist die Summe aller fertigen Product-Backlog-Einträge im aktuellen Sprint plus aller vorherigen Sprints.

Kriterium: Es erfüllt die Definition of Done. Es muss potenziell auslieferbar sein, auch wenn es nicht zwingend produktiv gestellt wird.

Definition of Done: Wann ist etwas wirklich fertig?

Die Definition of Done (DoD) ist eine klare Vereinbarung des Teams, wann Arbeit als abgeschlossen gilt.

Typische Inhalte:

• Code geschrieben, getestet und ins Repository integriert
• automatisierte Tests grün
• Code-Review durchgeführt
• Dokumentation für Nutzer oder Betrieb aktualisiert
• in einer Test- oder Staging-Umgebung deployt

Beispielhafte DoD in Tabellenform:

Bereich	Kriterium
Code	sauber gebaut, keine Compilerwarnungen
Tests	Unit-Tests geschrieben und bestanden
Qualität	Code-Review erfolgt, Richtlinien eingehalten
Doku	relevante Dokumentation aktualisiert
Deployment	in Staging-Umgebung lauffähig

Wichtig: Die DoD gilt für alle Product-Backlog-Einträge. Sie wird vom Scrum Team gemeinsam definiert und regelmäßig überprüft.

Typische Falle: „Fertig“ heißt nur „entwickelt“, Tests oder Doku kommen irgendwann. Das führt direkt zu technischen Schulden und Frust.

Häufige Missverständnisse zu Scrum

Einige Klassiker, die du kennen solltest:

• „Scrum bedeutet, dass alles unplanbar ist.“ Falsch. Scrum plant in kurzen Zyklen. Es akzeptiert Unsicherheit, statt sie zu verstecken.

• „Wir machen Scrum, wir haben Dailys.“ Ein Daily allein macht noch kein Scrum. Rollen, Events, Artefakte und Regeln gehören zusammen.

• „Product Owner entscheidet alles allein.“ Der PO trifft Produktentscheidungen, aber gute POs arbeiten eng mit Team und Stakeholdern zusammen.

• „Scrum ist nur was für Software.“ Scrum kommt aus der Softwareentwicklung, wird aber inzwischen auch in anderen Bereichen eingesetzt. Entscheidend ist die Komplexität, nicht die Branche.

• „Scrum löst Kulturprobleme automatisch.“ Scrum macht Probleme sichtbar. Lösen musst du sie mit den Menschen in der Organisation.

Wann Scrum passt, und wann eher nicht

Scrum eignet sich besonders gut, wenn:

• Anforderungen unsicher oder stark veränderlich sind
• du schnell Feedback von Nutzern brauchst
• interdisziplinäre Zusammenarbeit nötig ist
• du in kurzen Zyklen Wert liefern kannst

Weniger passend ist Scrum, wenn:

• Anforderungen sehr stabil, klar und selten veränderlich sind
• Arbeit stark sequenziell, mit wenigen Rückkopplungen abläuft
• gesetzliche Vorgaben starre Phasen erzwingen
• Teams oder Organisation keinerlei Spielraum für Selbstorganisation haben

In vielen Münchner Unternehmen findest du hybride Ansätze: Teile des Portfolios laufen klassisch, Produktentwicklungsteams arbeiten mit Scrum oder anderen agilen Methoden. Wichtig ist, dass du bewusst entscheidest, wo Scrum sinnvoll ist, statt es dogmatisch überall einzuführen.

Wie du Scrum wirklich lernst: Praxis statt Buzzwords

Scrum lernst du nicht durch das Auswendiglernen des Guides, sondern durch Anwenden und Reflektieren.

Konkrete Schritte:

1. Scrum Guide lesen Der offizielle Scrum Guide ist kurz, aber dicht. Lies ihn mehrfach und diskutiere ihn mit Kolleginnen und Kollegen.

2. Ein echtes Produkt oder Projekt wählen Suche dir ein Vorhaben, bei dem du mit einem cross-funktionalen Team in Sprints arbeiten kannst. Auch ein internes Tool oder eine Fachanwendung im Münchner Unternehmen eignet sich.

3. Rollen bewusst ausfüllen Klärt im Team: Wer übernimmt Product Owner, wer Scrum Master, wer ist Teil der Developers? Vermeidet Doppelrollen, wo es geht, zumindest in der Lernphase.

4. Events ernst nehmen Plane Sprints, halte Dailys kurz und fokussiert, nutze Reviews für echtes Feedback und Retrospektiven für Verbesserungen.

5. Backlog und DoD pflegen Investiere Zeit in ein ordentlich strukturiertes Backlog und eine klare Definition of Done. Das sind deine wichtigsten Hebel für Qualität und Transparenz.

Wenn du tiefer einsteigen möchtest oder professionelle Begleitung suchst, findest du passende Trainings und Workshops bei cmt.de.

Weg zur PSM- und PSPO-Zertifizierung

Die Zertifizierungen „Professional Scrum Master“ (PSM) und „Professional Scrum Product Owner“ (PSPO) von Scrum.org sind weit verbreitet und praxisnah ausgerichtet.

PSM (Professional Scrum Master)

Fokus:

• Verständnis des Scrum-Rahmenwerks
• Rolle des Scrum Masters
• Facilitation von Events
• Coaching von Team und Organisation

Vorbereitung:

• Scrum Guide sehr genau kennen
• Beispielprüfungen und Open Assessments von Scrum.org nutzen
• in einem echten oder simulierten Team als Scrum Master agieren
• typische Praxisfragen durchdenken, z. B. „Wie gehst du mit einem Product Owner um, der ständig in den Sprint reinsteuert?“

PSPO (Professional Scrum Product Owner)

Fokus:

• Produktvision und -strategie
• Wertmaximierung
• Product Backlog Management
• Stakeholder-Management

Vorbereitung:

• Grundlagen von Produktmanagement und Value-Orientierung
• Umgang mit Priorisierungstechniken, z. B. Kano, WSJF, einfache Wert-Nutzen-Matrizen
• reale Backlogs schreiben, schneiden und priorisieren
• typische Konfliktsituationen üben, z. B. zwischen Fachbereich, Management und Entwicklungsteam

Allgemeine Tipps für beide Zertifizierungen:

• Begriffe und Definitionen aus dem Scrum Guide genau beherrschen
• viele Praxisfälle durchspielen, nicht nur Multiple-Choice-Fragen
• in der Prüfung ruhig bleiben, Fragen sorgfältig lesen und auf die Perspektive von Scrum.org achten

Fazit: Agil wirst du nicht durch Zertifikate, sondern durch Haltung

Scrum und agiles Arbeiten lernst du, indem du mit einem Team echte Probleme löst, regelmäßig Feedback einholst und bereit bist, deine Arbeitsweise zu hinterfragen. Rollen, Events, Artefakte, Backlog und Definition of Done sind nur Hilfsmittel, damit ihr als Team besser zusammenarbeitet.

Wenn du die Prinzipien hinter Scrum verstehst und sie bewusst einsetzt, bist du für PSM und PSPO gut vorbereitet. Noch wichtiger: Du hilfst deinem Team, in der täglichen Praxis bessere Produkte zu bauen, egal ob in einem Münchner Mittelständler, einem Start-up oder einem großen Konzern.