Scrum braucht kein Skalierungsframework, es ist selbst eines
 |
| Bild: Piqsels - Lizenz |
Die Geschichte von Scrum ist voller Missverständnisse, insgesamt so vielen, dass man sie kaum aufgezählt bekommen dürfte. Was die meisten von ihnen gemeinsam haben: mit einem schnellen Blick in den Scrum Guide würden sie sich aufklären lassen. Das gilt auch für eines der am weitesten verbreiteten, für die Fehlannahme nämlich, dass Scrum nur für die Organisation jeweils eines einzigen Teams gedacht wäre, während für die Koordination mehrerer Teams Skalierungsframeworks wie SAFe notwendig wären.
Dass das falsch ist kann man sich von Scrum-Begründer Jeff Sutherland selbst sagen lassen, man kann es aber auch durch Nachlesen im gerade erwähnten Scrum Guide selbst herausfinden. Dort findet man einiges zu diesem Thema, wenn man denn aufmerksam hinsieht:
- Product Owner und Scrum Master haben führende Aufgaben nicht nur in einem Team sondern organisationsweit
- Die verschiedenen Scrum Master arbeiten gemeinsam an der Etablierung von Scrum in der Gesamtorganisation
- Das Sprint Review [sic] ist ein organisationsweites Planungs- und Abstimmungsmeeting
- Mehrere Scrum Teams können ein gemeinsames Product Backlog haben (woraus sich ein gemeinsamer Product Owner ergibt)
- Mehrere Scrum Teams können eine gemeinsame Definition of Done haben
- Auch für gemeinsam entwickelte Produkte und Systeme kann eine gemeinsame DoD bestehen
Das ist deutlich mehr als den meisten Scrum-Anwendern bewusst sein dürfte, andererseits aber auch deutlich weniger als viele von ihnen gerne an Anleitung hätten. Dass dort nicht mehr steht hat aber einen bestimmten Grund: Scrum ist ein Framework und keine Methodik, die nicht regulierten Teile sind bewusst offen gehalten um Flexibilität zu gewährleisten und Bürokratie einzudämmen.
Und wer das noch immer nicht so ganz glauben kann, der kann sich eine weitere Quelle ansehen: auch der zweite Scrum-Begründer Ken Schwaber ist da sehr klar in seinen Aussagen.
