Zum Hauptinhalt springen

Scrum als Fallstudie

Scrum ist kein Garant für organisatorische Reife.

Scrum ist ein Rahmenwerk, das strukturelle Annahmen über Arbeit sichtbar macht.

Ob Scrum stabil wirkt oder Spannungen erzeugt, hängt weniger vom Framework ab als vom zugrunde liegenden Steuerungsmodell der Organisation.

→ siehe: Organisationsreife

Warum Scrum ein gutes Diagnoseinstrument ist

Scrum setzt implizit voraus:

  • Komplexe Wissensarbeit
    → siehe: Komplexität vs. Determinismus
  • Iteratives Lernen
  • Klare Entscheidungsräume
  • Relative statt absolute Planung
  • Teamverantwortung

Wenn diese Voraussetzungen nicht erfüllt sind, wird Scrum nicht wirksam – sondern ritualisiert.

Scrum im industriellen Steuerungsmodell

Wenn eine Organisation primär deterministisch steuert, entstehen typische Spannungen.

Beobachtbare Muster:

  • Zeit-Schätzung dominiert Planung
  • Velocity wird als Leistungskennzahl verwendet
  • Sprint Planning dient Prognoseabsicherung
  • Tickets werden im Planning verteilt
  • Product Owner besitzt kein echtes Priorisierungsmandat

Strukturelle Spannung:

Iterative Methode trifft auf kontrollorientierte Steuerungslogik.

→ siehe: Kontrollorientierte Organisation

Hier wird Scrum als Kontrollinstrument interpretiert, nicht als Strukturierungsrahmen für Unsicherheit.

Scrum im Spannungszustand: Ritualisierte Agilität

In diesem Zustand:

  • Events finden formal statt
  • Artefakte existieren
  • Begriffe werden verwendet

Doch:

  • Unsicherheit wird weiterhin prognostisch behandelt
  • Planung soll Sicherheit erzeugen
  • Selbstorganisation ist formal erlaubt, strukturell begrenzt

→ siehe: Ritualisierte Agilität

Hier entsteht ein Modellkonflikt:

Komplexe Wissensarbeit wird mit deterministischer Steuerungslogik kombiniert.

Scrum in operativ stabilisierten Organisationen

Merkmale:

  • Backlog-Schnitt reduziert operative Unsicherheit
  • Refinement erzeugt reale Klarheit
  • Sprint Goals beeinflussen Entscheidungen
  • WIP wird implizit begrenzt

→ siehe: Operativ stabilisierte Organisation

Hier beginnt Scrum, strukturell zu wirken.

Die Organisation erkennt, dass Unsicherheit nicht eliminiert, sondern strukturiert werden muss.

Scrum in systemisch reflektierten Organisationen

In diesem Zustand:

  • Planung dient Orientierung, nicht Kontrolle
  • Relative Schätzung wird nicht zur Leistungsbewertung genutzt
  • WIP wird aktiv begrenzt
    → siehe: Durchsatz und WIP
  • Auslastung wird nicht maximiert
    → siehe: Auslastung vs. Systemleistung
  • Mandate sind klar definiert

→ siehe: Systemisch reflektierte Organisation

Scrum ist hier kein Identitätsmerkmal.

Es ist ein Werkzeug.

Scrum-Artefakte als Reifeindikatoren

Scrum-Artefakte zeigen besonders deutlich, welches Steuerungsmodell implizit verwendet wird.

Product Backlog​

Spiegelt es Domänenstruktur wider – oder ist es eine Ansammlung von Aufgaben?

Refinement​

Reduziert es Unsicherheit vor dem Sprint – oder wird Analyse in das Sprint Planning verschoben?

Sprint Planning​

Wird Arbeit übernommen – oder verteilt?

Sprint Goal​

Dient es als Orientierungsrahmen – oder als Reporting-Element?

Commitment​

Ist es ein freiwilliges Teamversprechen – oder ein impliziter Leistungsdruck?

Artefakte wirken nur dann, wenn das zugrunde liegende Steuerungsmodell konsistent ist.

Zentrale Beobachtung

Scrum scheitert selten an Scrum.

Es gerät in Spannung, wenn das zugrunde liegende Steuerungsmodell nicht zum Charakter der Arbeit passt.

→ siehe: Steuerungsparadigmen im Vergleich

Selbstreflexionsfragen

  • Wird Planung als Prognose oder als Lerninstrument verstanden?
  • Wird Unsicherheit modelliert oder kontrolliert?
  • Sind Rollen mandatierte Entscheidungsräume?
  • Wird Durchsatz oder Einzelzeit optimiert?
  • Dient Velocity dem Lernen oder dem Vergleich?

Diese Fragen richten sich nicht gegen Methoden. Sie richten sich an das zugrunde liegende Weltbild.