Warum Scrum sich nicht ständig ändert
Bild: Flickr / Ignacio Palomo Duarte - CC BY 2.0 |
Zunächst möchte ich SAFe und Holocracy an dieser Stelle weglassen, die Frage ob diese beiden Ansätze überhaupt agil sind würde hier zu weit führen.Stattdessen Focus auf Scrum. Müsste sich das nicht permanent an die Gegebenheiten anpassen, je nachdem welche das gerade sind? Wäre das nicht die Voraussetzung dafür, selbst agil zu sein? Vielleicht. Ich würde es aber trotzdem nicht für sinnvoll halten, aus den folgenden zwei Gründen:
Zum einen sehe ich das Risiko, dass Scrum aufgebläht werden würde. Der Scrum Guide ist bewusst schlank gehalten, und erst letzten Monat hat Ken Schwaber, einer seiner Verfasser, geschrieben, dass das mit Absicht so ist. Mit jeder Erweiterung würde Scrum einzelfallspezifischer und damit für immer weitere andere Einzelfälle nicht mehr anwendbar. Es ist sein Minimalismus der es universell anwendbar macht. Dass der bei permanenten Modifikationen erhalten bleiben würde glaube ich nicht.
Zum anderen besteht einer der großen Vorteile von Scrum darin, dass es Leitplanken vorgibt ohne einengend zu sein. Vereinfacht gesagt legt es lediglich eine Art von Gewaltenteilung im Team fest und gibt Intervalle vor in denen über Planungen, Arbeitsfortschritte und Prozessverbesserungen gesprochen werden muss. Ohne dass Detailvorgaben gemacht werden können die Herausbildung von Hierarchien und das Aufkommen von Schlendrian so vermieden werden. Ich wage die Voraussage: diese Leitplanken würden sofort zum Objekt von Verschlimmbesserungen werden.
Aber heisst das, dass Scrum überhaupt nicht angepasst werden darf (bzw. von jemand anderem als den Verfassern)? Doch, natürlich geht das. Der Scrum Guide sagt es selbst: although implementing [...] parts of Scrum is possible, the result is not Scrum. Mit anderen Worten - ändere was Du willst, aber nenne es dann nicht mehr Scrum. Dieser Begriff ist aus guten Gründen (siehe oben) dem bisherigen, weitgehend unveränderbaren Framework vorbehalten.